谈测试用例的评审

　　何时进行用例的评审，一般情况下是在用例的初步设计完成之后进行评审，如果需要或时间允许，在整个详细用例全部完成之后还会进行二次评审，三次评审等。

　　大体分文三个级别的评审：

　　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/