測試設計重要性
設計是測試的靈魂，質量的龍頭。
測試設計面臨問題
1、測試對象的邏輯路徑和測試輸入數據的組合幾乎是無窮的，而窮盡的測試是不可能的
2、不同利益相關者對軟件或者軟件產品的質量要求是不同的
3、測試時間和資源有限
4、測試得到的需求和資源不完整
5、測試設計語言規范
窮盡的測試是不可能的
1、如何有效減少測試用例的數目？
2、如何避免測試用例之間的冗余？
3、如何滿足測試覆蓋率的要求？
如何有效減少測試用例的數目？
1、等價類
（1）有效等價類
（2）無效等價類
2、邊界值
如何避免測試用例之間的冗余？
1、規范測試設計
（1）按照一定的設計思路進行測試用例設計
（2）減少熱帶風暴
2、可復用的測試用例
特性：通用性、有效性、獨立性
如何滿足測試覆蓋率的要求？
測試覆蓋率常用的計算公式：
1、 功能覆蓋率
至少被執行一次的測試功能點數/ 測試功能點總數（功能點）
2、 需求覆蓋率
被驗證到的需求數量 /總的需求數量（需求）
3、覆蓋率
至少被執行一次的測試用例數/ 應執行的測試用例總數
4、語句覆蓋率
至少被執行一次的語句數量/ 有效的程序代碼行數
5、判定覆蓋率
判定結果被評價的次數 / 判定結果總數
6、條件覆蓋率
條件操作數值至少被評價一次的數量 / 條件操作數值的總數
7、判定條件覆蓋率
條件操作數值或判定結果至少被評價一次的數量/(條件操作數值總數+判定結果總數)
8、上下文判定覆蓋率
上下文內已執行的判定分支數和/(上下文數*上下文內的判定分支總數)
9、基于狀態的上下文入口覆蓋率
累加每個狀態內執行到的方法數/(狀態數*類內方法總數)
10、分支條件組合覆蓋率
被評測到的分支條件組合數/分支條件組合數
11、路徑覆蓋率
至少被執行一次的路徑數/程序總路徑數
目前采用覆蓋策略
1、基于需求的測試覆蓋評估
依賴于對已執行/運行的測試用例的核實和分析，所以基于需求的測試覆蓋評測就轉化為評估測試用例覆蓋率：測試的目標是確保100%的測試用例全部成功地執行。
2、基于代碼的測試覆蓋評估
是對被測試的程序代碼語句、路徑或條件的覆蓋率分析。如果應用基于代碼的覆蓋，則測試策略是根據測試已經執行的源代碼的多少來表示的。這種測試覆蓋策略類型對于安全至上的系統來說非常重要。
基于代碼的測試覆蓋評估
1、針對于java的項目采用EMMA工具進行分析
2、針對于delphi項目采用工具還沒有定
不同利益相關者對軟件質量要求是不同的
1、如何獲取利益相關者的不同質量要求？
2、如何設計測試用例以滿足不同的質量要求？
3、如何分析和評估最終軟件產品的質量？
4、如何提高客戶對軟件產品的滿意度？
測試時間和資源有限
1、如何有效的選擇測試重點？
2、如何確定測試優先級？
3、如何有效的配置測試資源？
4、如何分析和評估測試的有效性？
如何有效的選擇測試重點
1、軟件產品的每個功能模塊，對于客戶而言并不是是同等重要的；
2、用戶實際使用過程中的使用頻率的分布
基于風險的測試策略
1、選擇測試重點：對測試范圍進行優先級的劃分，將測試設計和執行放在優先級高的區域。
2、將測試資源分配到高風險的地方，從而更加有效的利用測試資源；
3、確定測試對象在哪些地方容易出現錯誤，并設計相應的測試用例來發現這些錯誤；
4、基于風險可以更好的對測試狀態和測試結果進行報告，從而更好的對測試過程和測試質量進行監控，并根據實際的測試狀態對后續測試進行及時調整。
測試得到的需求和資源不完整
1、如何獲取盡量多的顯現需求和隱現需求？
2、如何利用已有的經驗有效設計測試用例？
3、如何應對需求的不斷變更？
如何獲取盡量多的需求？
1、 站在用戶角度出發
（1）了解用戶原始需求
目前公司需求來源于需求人員和項目經理的理解，我們如何得到用戶的需要和期望
（2）了解行業隱含需求
（3）需求復用
2、 利用逆向思維方式推測問題
用戶當前遇到的問題，是否可以在系統中找到解決方案
如何利用已有的經驗有效設計測試用例？
錯誤推測法
（1）基于代碼
（2）基于業務
（3）基于代碼的編寫者
（4）基于系統框架
如何應對需求的不斷變更？
1、變更流程的規范
2、測試流程規范
測試設計語言不清晰導致問題
1、執行者的痛苦
2、測試覆蓋率下降
3、測試執行效率下降
4、測試設計的工作成果不被認同
測試用例設計語言規范
1、不要采用一些個性化語言或簡稱來描述用例
2、用例描述必須含有主謂賓
3、預期結果采用smart原則，必須量化、具體
例如：驗證數據正確性
4、涉及類似產品，在產品間描述保持一致
5、同一界面的相同實體描述名稱必須一致
6、專業術語必須準確一致