Day 3 測試設計講義
經過前面兩天的課程內容，我們已經能夠具備分析一個需求，通過其驗收標準來確定測試范圍，劃分測試重點，然后根據分析的情況，編寫測試用例，準備測試數據，執行測試用例并發現軟件的缺陷，提交Bug。事實上這些已經是測試人員的常規操作了。
接下來我們重點要解決的問題是：如何對測試活動有一個“持續”的概念。或許大家還沒有那么明確的概念：持續。當前互聯網時代的軟件行業，絕大多數的軟件都是一個“持續”更新的狀態，那么有一些功能就會被“持續”的測試，所以，雖然有了之前的方法和實踐，我們依舊需要對測試實踐進行詳細的設計，這樣能夠接受“持續”帶來的挑戰。
最直接的“持續”活動，就是將軟件測試實踐“套路化”，給出文檔，方便任何時候進行。這里的文檔就是“測試計劃”。
這里解決的主要問題如下：
- 如何保證你測試的功能接受重復測試（或者反復測試）而質量不受影響？
- 請問你們有測試評審么？如果有的話，評審都有哪些內容呢？
- 如何保證不同的人員對同一功能測試取得類似的測試效果？
0 主要內容
- 1 B4_方法策略
- 2 B5_測試場景
- 3 T2_測試計劃
1 B4_方法策略
首先，我們接著前兩天的內容繼續。分析了測試的范圍和重點以后，我們是直接開始編寫測試用例了。但是實際上，我們沒有探討：方法策略。好的方法策略的選擇，可以是測試活動變得可靠。
1.1 方法的作用
合理的方法，可以使得軟件測試的執行變得更加有效，并且盡量的保證軟件測試的執行不遺漏。在具體的項目中，合理的方法，可以使得漏測的缺陷減少。
如果沒有確定方法，那么不同的測試人員，執行同一份測試，可能會選擇不同的方法，那么帶來的效果可能也不同，這樣就把軟件測試的結果寄托于“人”身上了，而并不是流程與節點，對于測試結果是不負責任的。
1.2 方法的選擇
這里，我們首先來討論一下方法的分類。
我們可能聽過很多的說法：等價類、邊界值、正交試驗法等，還有說黑盒測試、白盒測試等，其實這樣的討論并不是在同一個層面上。我們先來澄清一下測試方法的分類。
-
按照對被測試對象的執行情況
- 手工測試
- 自動化測試：Automatic Testing
-
按照對被測試對象的觀察視角
- 白盒測試：White Box Testing，研究源代碼的內部結構，保證程序正確。
- 黑盒測試：Black Box Testing，不關注系統內部，只關注輸入與輸出。
- 灰盒測試：Grey Box Testing，介于上述兩者之間。
-
按照對被測試對象的操作情況
- 動態測試：Dynamic Testing，被測試的系統需要運行起來。
- 靜態測試：Static Testing，被測試的系統一定不能運行，檢查代碼和文檔。
-
按照對被測試對象的質量維度
- 功能測試
- 性能測試
- 安全測試
- 兼容性測試
- 可用性測試
- 穩定性測試
- ……
-
按照對被測試對象的階段劃分
- 單元測試，Unit Testing，一般是開發人員對編寫的類，方法進行測試
- 集成測試，Integration Testing，主要包括接口測試
- 系統測試，System Testing，傳統的測試人員進行的功能、性能測試
- 驗收測試，Acceptance Testing，由用戶，或者模擬用戶進行遍歷測試
-
按照對被測試對象的系統結構
- 界面測試，UI Testing
- 接口測試，Interface Testing
- 數據庫測試，Database Testing
- 業務邏輯測試，Business Testing
- 服務器測試，Server Testing
-
按照被測試對象的測試活動
- 回歸測試，Regression Testing
- 冒煙測試，Smoke Testing
- 隨機測試，Random Testing
我們可能聽過很多的說法：等價類、邊界值、正交試驗法等，還有說黑盒測試、
1.3 方法的使用
實際上，大部分的項目中的日常測試，使用的是黑盒或者灰盒測試，而我們常說的黑盒測試方法，例如等價類，邊界值就屬于主要使用的過程。
一般來說：等價類、邊界值和流程法這三個是被用的最多的測試方法。主要用來：準備測試數據。
2 B5_測試場景
2.1 什么場景
場景，Scenario，指的是行為，用戶的實際使用行為。測試場景，就是在測試的過程中，模擬的用戶的使用行為。
以登錄作為栗子：
- 用戶打開瀏覽器首次登錄
- 用戶在不同的瀏覽器同時登錄
- 用戶在不同的設備同時登錄
- 用戶在已經登錄的瀏覽器打開登錄頁面
- 用戶退出以后，不關閉瀏覽器，直接重新登錄
- 用戶……
2.2 場景的描述
需要注意的是，場景的描述，不能帶有“預期結果”。很多測試的初學者在一開始是區分不清楚場景的概念，在編寫場景的時候，往往會添加上“預期結果”。例如：用戶打開瀏覽器首次登錄成功登錄。這樣一來，編寫的已經不再是測試場景，而是測試用例了。請注意，這樣是不對的。
場景的描述，需要講明白：用戶的具體行為。
2.3 場景的設計
場景的設計，其實并不會非常復雜，但是往往有遺漏，我們來談一下具體的設計方法。
首先，需要從最“正常”的用戶使用著手，這也是最重要的，最常用的地方。需要參考和針對的點就是：測試重點。把所有的測試重點的地方，依次分析用戶可能的行為，并一一列出來。
其次，類似和雷同的場景，應該匯總在一起，作為一個場景來編寫。
最后，仔細考慮“不正常”的用戶有可能的使用方式，包括：
- 錯誤操作
- 錯誤流程
- 意外情況
3 T2_測試計劃
3.1 測試計劃的作用
“凡事預則立，不預則廢”。測試計劃的作用其實無需多言，已經非常明確。任何事情都需要有一個計劃。測試當然也是不例外的。
- 測試計劃是評審的對象
- 測試計劃是規范的體現
- 測試計劃是提升的依據
3.2 測試計劃的格式
測試計劃的具體格式，在不同的團隊和不同的項目組，一般是有差別的，目前國內外都沒有非常明確的格式。我們這里推薦的測試計劃，是與前面的內容相關的。包括以下幾個方面：
- 測試目的
- 需求描述
- 測試范圍
- 測試重點
- 策略方法
- 測試場景
是不是看上去非常眼熟？因為就是之前的內容，放到一起。
3.3 如何使用測試計劃
測試計劃是需要在測試實踐開始之前，針對某一個需求來編寫的。注意：一個測試計劃，只針對一個需求。這是敏捷測試團隊的一般情況。
編寫好測試計劃以后，一般需要經過一個評審過程。后續的測試行為，會在測試計劃的基礎上做改動，并持續使用。
不同的測試人員，針對同一份測試計劃，需要做出同樣的測試執行。
此外，禪道目前還沒有測試計劃的功能，這一點值得期待。但是TAPD是有測試計劃的功能的。
- 相關學習
