测试用例的评审

从网上搜索测试用例的评审，也能搜出好多，我这里把自己能想到的或是借鉴于他人的都在这里进行总结和归纳。

　　测试用例的设计很重要，无论你采用的是敏捷测试还是传统的开发模式，测试用例都应该要文档化，并且根据项目的schedule，把握好粒度。而QA lead要根据项目的实际情况，先定好模板，制定好测试用例的编写规范。测试用例设计出来，质量如何？这就需要对测试用例进行评审，这个过程非常重要，对测试人员的能力提高，测试效率的提高都有很好的作用。如果公司流程没有这个硬性要求，项目再忙，也要抽出一定时间，召集相关人员开个哪怕是非正式的评审会议，大家一起讨论用例并给出意见和建议，及时发现问题，并完善测试用例的设计。

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

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

　　a）部门评审，测试部门全体员工参与的评审。

　　b）公司评审，这里包括了项目经理，需求分析人员，架构设计人员，开发人员和测试人员。

　　c）客户评审，包括了客户方的开发人员和测试人员。

　　测试用例的评审检查单（Checklist for Test cases）：

　　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. （预期结果中不要使用模糊的语言）

 

摘至:http://www.51testing.com/html/60/n-228860.html

 

在很多的软件公司，软件测试用例设计完成后，都需要进行检查或者评审，一般评审的依据都有哪些那？以下可以作为软件测试用例检查的标准：

　　1、操作步骤应与描述相一致

　　2、操作步骤应仅包含与被测项相关的内容，即没有多余的或不相关的内容

　　3、期望结果应是确定的、唯一的

　　4、可重用（对被测项的当前版本和后续版本）

　　5、可跟踪（与软件测试需求相对应）

　　6、软件测试用例执行后是应将软件测试环境恢复到执行前的状态

　　7、软件测试用例是应有正确的名称和编号

　　8、软件测试用例应标注有执行优先级

　　9、软件测试用例目的的描述应包含该用例用于测试什么内容

　　10、应包含了所采用的测试方法的描述

　　11、应包含相关的配置信息：环境、数据、前置测试用例、用户授权等

　　12、操作步骤和期望结果应完整、一致、清晰

　　13、应指明：系统返回的任何错误信息或屏幕快照需保存

　　14、用词规范、准确、一致

　　15、每个软件测试用例的操作步骤<=15

　　16、自动化测试脚本必须带有注释

　　17、自动化测试脚本的注释应包含：目的、输入、期望结果等

　　18、场景测试用例的执行顺序应符合实际的业务流程

　　19、场景测试用例应覆盖最复杂的业务流程

　　20、对于由系统自动生成的输出项应注明生成规则

　　21、对于查询和表格，应设计产生数据的用例

　　22、软件测试用例应包含对中间和后台数据的检查

　　23、场景测试用例中应包含每个业务流程环节的中止和回退相关的设计和组合

　　24、如果存在不可测需求，应列出并进行说明

　　25、软件测试用例应确保所有的软件测试需求被覆盖

摘至:http://www.51testing.com/html/59/n-228859.html

 

评审过程:

 

1:评审的过程
A:开始前做好如下准备
   1、确定需要评审的原因
   2、确定进行评审的时机
   3、确定参与评审人员
   4、明确评审的内容
   5、确定评审结束标准
   6、提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
   7、 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
   8、 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
B：开始评审
    1、 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
    2、 通用邮件与相关人员沟通
    3、 通用IM工具直接与相关人员交流
    4、根据评审内容进行评审

2：评审内容
   1、 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
  2、 优先极安排是否合理。
   3、 是否覆盖测试需求上的所有功能点。
   4、 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
   5、 是否已经删除了冗余的用例。
   6、 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
   7、 是否从用户层面来设计用户使用场景和使用流程的测试用例。
   8、 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。