测试用例评审检查单

序号    主要检查项
1       《需求规格说明书》是否评审并建立了基线？
2       是否按照测试计划时间完成用例编写？
3       需求新增和变更是否进行了对应的调整？
4       用例是否按照公司定义的模板进行编写？
5       测试用例是否覆盖了《需求规格说明书》？
6       用例编号是否和需求进行对应？ 
7       非功能测试需求或不可测试需求是否在用例中列出并说明？
8       用例设计是否包含了正面、反面的用例？
9       每个测试用例是否清楚的填写了测试特性、步骤、预期结果？
10    步骤/输入数据部分是否清晰，是否具备可操作性？
11    测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述？
12    测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法？是否针对需求不同部分设计使用不同设计方法？
13    重点需求用例设计至少要有三种设计方法？
14    每个测试用例是否都阐述预期结果和评估该结果的方法？
15    需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置；表格和数据格式是否有说明或附件？
16    用例覆盖率是否达到相应质量指标?
17    用例预期缺陷率是否达到相应质量指标?

1.每个经评审的测试用例发现的主要缺陷
2.每个经评审的测试用例发现的次要缺陷
3.每个经评审的测试用例发现的缺陷总数
4.每个经评审的测试用例发现的主要缺陷与次要缺陷的比例
5.每一个小时评审的测试用例发现的缺陷总数
6.每一个小时评审的测试用例发现的主要缺陷
7.每一个小时评审的测试用例发现的次要缺陷
8.每个经评审的测试用例发现的处于Open状态的缺陷个数
9.每个经评审的测试用例发现的处于Closed状态的缺陷个数
10.每个经评审的测试用例发现的处于Closed状态的缺陷个数与处于Open状态的缺陷个数的比例
11.每个经评审的测试用例发现的处于Open状态的主要缺陷个数
12.每个经评审的测试用例发现的处于Closed状态的主要缺陷个数
13.每个经评审的测试用例发现的处于Closed状态的主要缺陷与处于Open状态的主要缺陷的比例
14.每个经评审的测试用例发现的处于Open状态的次要缺陷个数
15.每个经评审的测试用例发现的处于Closed状态的次要缺陷个数
16.每个经评审的测试用例发现的处于Closed状态的次要缺陷与处于Open状态的次要缺陷的比例
17.每个经评审的测试用例发现的总缺陷个数占缺陷总数的百分比
18.每个经评审的测试用例发现的主要缺陷个数占缺陷总数的百分比
19.每个经评审的测试用例发现的次要缺陷个数占缺陷总数的百分比
20.每个经评审的测试用例发现主要缺陷的百分比与次要缺陷的百分比之间的比例。
21.每一个小时评审的测试用例发现的缺陷数占总缺陷数的百分比
22.每一个小时评审的测试用例发现的主要缺陷数占总缺陷数的百分比
23.每一个小时评审的测试用例发现的次要缺陷数占总缺陷数的百分比
24.每一个小时评审的测试用例发现的主要缺陷的百分比与次要缺陷的百分比之间的比例
25.每个经评审的测试用例未能发现的缺陷的百分比
26.每个经评审的测试用例未能发现的主要缺陷的百分比
27.每个经评审的测试用例未能发现的次要缺陷的百分比
28.每个经评审的测试用例未能发现的主要缺陷的百分比与次要缺陷的百分比之间的比例
29.每一个小时评审的测试用例未能发现的缺陷的百分比
30.每一个小时评审的测试用例未能发现的主要缺陷的百分比
31.每一个小时评审的测试用例未能发现的次要缺陷的百分比
32.每一个小时评审的测试用例未能发现的主要缺陷的百分比与次要缺陷的百分比之间的比例
33.计划要评审的测试用例的个数
34.计划要评审但未评审的测试用例的个数
35.计划要评审的测试用例个数与计划要评审但未评审的测试用例的个数之间的比例
36.评审过的测试用例的个数
37.未评审的测试用例的个数
38.评审过的测试用例的个数与未评审的测试用例的个数之间的比例
39.评审通过的测试用例的个数
40.评审不通过的测试用例的个数
41.评审通过的测试用例的个数与评审未通过的测试用例的个数之间的比例
42.通过的评审次数
43.不通过的评审次数
44.通过的评审次数与不通过的评审次数之间的比例

  的评审能够使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来说也是一个快速提高用例设计能力的过程。 测试用例

　　1、需要评审的原因

　　测试用例是的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。软件测试

　　2、进行评审的时机

　　一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审；第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。

　　3、参与评审人员

　　这里会分为多个级别进行评审。

　　1) 部门评审，测试部门全体成员参与的评审。

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

　　3) 客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

　　4、评审内容

　　评审的内容有以下几个方面：

　　1) 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

　　2) 优先极安排是否合理。

　　3) 是否覆盖测试需求上的所有功能点。

　　4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。

　　5) 是否已经删除了冗余的用例。

　　6) 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。

　　7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。

　　8) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

　　个人认为，一个“健康”的测试用例至少要通过前5个标准。

　　5、评审的方式

　　1) 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。

　　2) 通用邮件与相关人员沟通

　　3) 通用IM工具直接与相关人员交流

　　方式只是手段，得到其它人员对于用例的反馈信息才是目的。

　　无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。

　　6、评审结束标准

　　在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。

国内软件测试工程师的职位从无到有，经历的时间还不足10年。成熟的软件测试理论体系构建也仅有10余年的历史。而纵观现在如雨后春笋般蓬勃增长的计算机软件企业，对优秀软件测试工程师需求和渴望的现实，不禁让我们不得不去思考一个问题：如何开展并做好软件测试工程师的培训工作。

　　对于软件测试的重要性，很多人有些误解。因为刚刚开始做软件测试的人员往往是从黑盒测试做起，而黑盒测试不需要编程经验，所以总是给人感觉测试人员不需要太多的知识，无论谁上了岗都能做，因此也就导致软件企业不愿意、也认为不需要对软件测试工程师开展培训工作。一旦软件产品发货到用户手中，发现质量低劣、效率低下、维护成本昂贵，又都毫不留情地骂测试人员无能，为什么测不出Bug（软件缺陷）。

　　中国有句老话：磨刀不误砍柴工。看到上面这种恶果，显而易见，现在至少我们应该达成一种共识：软件测试工程师也需要培养，并且需要接受正规培训。培训什么？我想应至少从三个方面入手培训工作。

　　一、入职培训

　　软件测试工程师初来乍到一个公司，往往兴趣十足，预备全身心投入到“捉虫”的战斗中。但往往不得其法，事倍功半，因为抓不到虫子，或是即使抓到了虫子并不重要也被开发人员视而不见。设身处地的为这些雄心勃勃的测试工程师想想，他们是多么需要入职培训。

　　软件测试工程师的入职培训可以从三个方面来分头进行。产品的培训、测试技术的培训和测试工具的培训。软件测试的工作对象即是企业开发的软件产品，所以务必要对软件产品有一个全面的了解和清醒的认识。作为一个测试管理者，应至少安排足够的培训时间，让测试新手研习被测试软件的内容。我们可以利用一切可利用的培训资料。软件产品本身、用户手册、开发组的需求规格说明书、技术文档，包括熟悉产品的人员进行功能讲解等等，用这些形式不拘一格的产品内容来迅速武装起测试工程师的头脑。光有这些培训还不能罢休，要善于检查测试工程师的学习情况，及时地向他们提问产品中那些最关键性的问题，如产品的核心概念、业务流程等。有培训有检查，通过一问一答的方式，既了解了初学者对产品的了解程度，同时也传授了产品中的精髓，并且还能够从初学者的疑问中抓到培训工作中的漏洞，为今后更好地开展培训奠定基础。

　　因为软件测试工程师总是如人们所预料的一样，来自于各行各业、五湖四海。有测试经验的，无测试经验的，统统汇集到企业中。所以必须的测试技术培训一定是要有的。培训内容主要以黑盒测试技术为主，一是因为黑盒测试技术是基础，二为的是成本更为昂贵的白盒测试人员在需要的时候，也能够出色的完成黑盒测试的任务。黑盒测试常用的测试方法、测试用例的设计、黑盒测试常见的测试类型、不同测试类型各自关注的主要问题等等，在入职培训中都应有所全面接触。同样，方法的学习离不开实践的过程。可以找一些具有普遍性的功能点，由测试人员尝试设计测试用例。只有通过由易到难，由简单到复杂，不断反复的练习，才能慢慢建立起测试人员的测试概念、设计方法、捉虫的敏感度，并且保证他们不会走不必要的弯路。

　　在入职培训中，测试工具的培训已经逐渐提到议事日程上来。随着软件规模和复杂度的提高，纯粹意义上的人工测试已经不能满足软件测试各个方面的要求，因此对于测试工具的使用需求应运而生。为了使大家尽早成为会使用工具的高端测试人员，所以在入职培训中也应重视测试工具的培训。LoadRunner、WinRunner、TestDirector，这些常用的测试工具是需要让测试工程师尽早掌握的。网络上汇集了这些工具的大量资料，只是看我们如何自己整合打包形成适合自身需要的培训资料。

 

　　二、在职培训

　　入职培训不过是软件测试领域的一块敲门砖，能够带领初学者尽早领悟到测试工作中最精华的那部分内容。要想真正培养出一位合格的软件测试工程师，只靠入职培训显然是远远不够的。几年前曾听一位资深软件开发工程师提到过InJobTraining的概念。意思是说，作为工程师自己要注重工作过程中的自我培训，作为管理者更需加强在工作进程中对员工的知识灌输和能力培养。

　　InJobTraining可以是正式培训，也可以是非正式培训。按照以往经验，一对一式的非正规培训，其培训效果更容易得到保证。每经历一个产品或是项目的测试，都将是一次在职培训的极好机会。从跟随开发组开发用户需求开始，到协助开发组并审核开发组的功能设计，而后是测试工程师独立的完成测试设计工作，到最后的测试执行，测试管理者始终需要指导和带领测试工程师，教会他们在软件开发全生命周期的各个阶段，软件测试的工作目标、工作内容和结果物是什么。那些在入职培训中刚刚建立起的一点点测试概念和技术理论，需要在实际工作中得到最大化的尝试和实践。在在职培训过程中，测试管理者务必要花费较大的力气去审核测试工程师的各项工作，就如同在软件产品中捉虫一样，需要尽早发现每位测试工程师的工作漏洞、工作缺陷和改进的重点方向。不能以为通过入职培训，测试工程师就真的什么都已经学会了。不要忘记软件测试工作也是技术性很强的工作，和功能设计、代码开发一样，需要反复的实践，找出其中的不足，不断的加以改进，工作技能才能得到稳步的提高。

　　现在企业中定义软件测试工作范畴，恐怕大多数情况已经不再单纯是测试执行本身了。所以一批批软件测试工程师入职企业后，企业应该按照各位工程师不同的特点和特长，在在职培训过程中，为其选择重点进行培训，也就是进一步加强在职培训的趋向性。比如说，有人可能擅长完成较大规模功能的测试设计工作，那就重点培养其测试设计的能力；有人可能擅长利用测试工具开发测试案例，那就重点培养其测试工具开发的能力；有人可能具有极强的耐心、探究精神和怀疑的态度，那就重点培养其测试执行的能力；还有人可能具有一两年、两三年的开发经验，那就重点培养其白盒测试的能力。总之，在职培训过程中，应当依照测试工程师不同的工作经验和技术背景，为其正确选择重点培养方向。如果面面俱到，很有可能发生投入大产出小的低价结果，而且会挫伤测试工程师的积极性，同时也会影响到测试管理者对测试工程师的客观评价。更何况作为测试管理者，也不可能有足够的时间和精力，逐个培养每位测试工程师的每项能力。所以基于这点考虑，在职培训中加强目的性、重点性，明确培训的方向和目标就显得尤为重要了。

　　三、软件测试工程师的职业生涯发展规划

　　相信经过正规的入职培训和有的放矢的在职培训之后，我们的测试工程师在一两年时间里都应该能够有一个长足的进步了。但此时新的问题发生了。做了几年的软件测试之后，我的发展前途在哪里？好像我该学的我能学的都已经学会了。这时候，一系列的危险信号会陆续出现在测试工程师的身上。敷衍了事，吃老本，另谋职位找工作。哎，测试管理者发出一声叹息：仿佛曾经的培训投入都将付之东流了。要想遏制这种不良事态的发展，我们有一解：做好软件测试工程师的职业生涯发展规划。

　　勿庸置疑，谁都不想一辈子只做一个测试工程师。更何况按照自然规律，做了两三年测试工程师之后，一定有更好的发展前景等待测试工程师们去开拓。高级测试工程师、测试经理、测试主管；软件品质保证工程师、高级品质保证工程师、品质保证经理、品质保证主管、品质保证总监，几个职业发展序列都可以由测试工程师去自由选择，而从一位普通的测试工程师发展成为品质保证总监，没有十年八年的技术积累和经验沉淀，也是很难实现的。

　　选择适合于测试工程师自身条件的目标，并为其明确目标，并在目标基础上为其设计呈阶梯状的职业发展规划，也是测试管理者对测试工程师实施培训工作的重要组成部分。

　　现代软件企业一般都已有一套科学合理的职位序列，并每年在固定时间内为每位员工评定企业内部的职位。在此期间，测试管理者应在充分了解和掌握测试工程师实际工作水平和当年业绩的情况下，评定出最新的职位水平。更为重要的是，要在此时为测试工程师仔细设计和规划下一年度的职业发展方向。是向高级测试工程师序列发展，还是向测试经理序列发展，还是向品质保证工程师序列发展，要定义好明确的方向。一是为了便于测试工程师了解自己当前的工作状态，以及与今后的发展目标存在的差距；二是为了加强测试工程师的工作热情和动力，让他们体会到企业的发展要依赖于他们个人的发展；三是为了企业能够明确自身人才结构和知识结构的现状，扬长避短，为今后不断发展壮大企业，积累自身实力并增强信心。

　　在设计软件测试工程师的职业生涯发展规划时，往往会陷入到一个两难的境地：一个工作出色的测试工程师，今后是往测试经理方向发展，还是向高级测试工程师方向发展。

　　从人们的传统意识上来讲，总是觉得当了测试经理好像就有了一官半职，远远要比高级测试工程师显得高贵得多。所以形成了千军万马想过测试经理独木桥的现象。如何决策，一句话，要以人为本，从测试工程师的自身条件出发。很显然，高级测试工程师主打自身的技术优势，只要保持技术优势就行了。而测试经理需要从无到有大量累积管理的能力和经验。最起码要具备经营能力、成本控制能力、工作统筹安排能力、人员管理能力、沟通协调能力等等。也就是说，如果选择了测试经理的发展方向，则无疑要付出更多的艰辛和努力，方可达到职位目标的要求。所以测试管理者在为测试工程师设计职业发展规划时，务必要冷静头脑、全面分析，不应也不能轰轰烈烈的一拥而上，让技术型人员去做管理工作，而擅长管理工作的人员就只在技术单方面谋求发展。

　　设计职业生涯发展规划的过程，严格意义上应该属于年度培训工作的开端工作，制定既定目标的工作。所谓万事开头难，为了一年甚至更长时间的软件测试工作卓有成效，测试管理者在开展好职业生涯设计工作的同时，务必要与每位测试工程师做好充分的沟通，达成双方的理解和共识，保证大家一条心，劲往一处使。在此测试管理者还可以借助外部的力量来完成沟通工作。如利用企业的人力资源部门、技术委员会的资源和力量，群策群力，优势互补，减少设计工作中的偏差，积累设计工作的经验和技巧。

　　以上只是凭借实际的一些工作经验，总结出来的有关软件测试工程师培训工作的一些心得。潦草几笔，不成体系，欢迎大家批评指正。

　　看看现在软件企业的发展前景，以及对测试人员、测试环境、测试工具的需求增长，我们真的要脚踏实地的做好软件测试工程师的培训工作了，抓好软件企业的第一生产力，凭借人的智慧和才干，提高我国软件企业的核心竞争力。