談測試用例的評審

　　何時進行用例的評審，一般情況下是在用例的初步設計完成之後進行評審，如果需要或時間允許，在整個詳細用例全部完成之後還會進行二次評審，三次評審等。

　　大體分文三個級别的評審：

　　a）部門評審，測試部門全體員工參與的評審。

　　b）公司評審，這裡包括了項目經理，需求分析人員，架構設計人員，開發人員和測試人員。

　　c）客戶評審，包括了客戶方的開發人員和測試人員。

　　1）has the correct template been used？（是否使用了正确的模闆？）

　　2）have all the scenarios specified in the requirement –explicit， implicit， nonfunctional and  been converted into test conditions？（是否覆寫了需求規格說明，包括内在需求和外在和非功能需求？）

　　3）have the related areas that include possibly be affected by the implementation of the requirement been identified and included in the test cases？（case是否對需求變更的部分進行對應的調整和增加？）

　　4）have the following details been filled up correctly？ requirement references， test procedure， expected result， priority， author’s name， date created…（測試用例是否正确填寫了測試對應的需求，測試步驟，預期結果，優先級，作者姓名，建立日期等..）

　　5）has the test date set， if required been generated appropriate？ （測試用例是否包含測試資料，測試資料的生成是否正确？）

　　6）have the required negative scenario between identified in the test conditions？ （是否包含了負面測試用例？）

　　7）have the testing techniques—equivalence partitioning， boundary value analysis be used？ （是否使用了等價類劃分和邊界值分析的測試方法？）

　　8）have the steps been correctly given in appropriate sequence for each test scenario？ （測試步驟是否被闡述清楚？）

　　9）have the expected result been identified correctly？ （預期結果是否表達正确？）

　　　● expected results should respond to the user actions given in each step/action.（每個步驟都應給出相應的測試結果）

　　　● ensure that too many things are not included to be verified under one expected output.（給出一個預期結果的驗證步驟不要太多）

　　　● ensure that separate cases are written for multiple verifications of the application’s behavior. （每條case最好驗證一個問題）

　　　● vague statements like “appropriate message/value/screen” etc. should not be part of expected result. every detail should be clearly spelt out. （預期結果中不要使用模糊的語言）

本文出自seven的測試人生公衆号最新内容請見作者的github頁：http://qaseven.github.io/