测试用例的评审和变更.pdf

测测试试⽤⽤例例的的评评审审和和变变更更 ⾸先，要清楚是内部评审的定义，是测试组内部的评审，还是项⽬组内的评审。评审的定义不同，内容也会不同。 果是测试组内部的评审，应该着重于： 1.测试⽤例本⾝的描述是否清晰 2.是否考虑到测试⽤例的执⾏效率，往往测试⽤例中步骤不断重复执⾏，验证点却不同，⽽且测试设计的冗余性，都造成了效率的低下。 3.是否针对需求⽂档，测试⽤例是否覆盖了所有的软件需求。 4.是否完全遵守了软件需求的规定，这并不⼀定的，因为即使在严格的评审，也会出现错误，应具体情况具体对待 1.需要评审的原因 测试⽤例是软件测试的准则，但它并不是⼀经编制完成就成为准则。由于⽤⼒开发⼈员的设计经验和对需求理解的深度各不相同，所以⽤⼒的质量难免会有不同程度的差异。 2.进⾏评审的时机 ⼀般会有两个时间点。第⼀，是在⽤例的初步设计完成之后进⾏评审_第⼆是在整个详细⽤例全部完成之后进 ⾏⼆次评审。 果项⽬时间⽐较紧张，尽可能保证对⽤例设计进⾏评审，提前发现其中的不⾜之处。 3.参与评审⼈员 这⾥会分为多个级别进⾏评审。 1)部门评审，测试部门全体成员参与的评审。 2)公司评审，这⾥包括了项⽬经理、需求分析⼈员、开发⼈员和测试⼈员。 3)客户评审，包括了客户⽅的开发⼈员和测试⼈员。这种情况在外包公司⽐较常见。 4.评审内容 评审的内容有以下⼏个⽅⾯ 1)⽤例设计的结构安排是否清晰、合理，是否利于⾼效对需求进⾏覆盖。 2)优先极安排是否合理。 3)是否覆盖测试需求上的所有功能点。 4)⽤例是否具有很好可执⾏性。例 ⽤例的前提条件、执⾏步骤、输⼊数据和期待结果是否清晰、正确_期待 结果是否有明显的验证⽅法。 5)是否已经删除了冗余的⽤例。 6)是否包含充分的反⾯测试⽤例。充分的定义， 果在这⾥使⽤28法则，那就是4倍于正⾯⽤例的数量，毕 竟⼀个健壮的软件**。** 7)是否从⽤户层⾯来设计⽤户使⽤场景和使⽤流程的测试⽤例。 8)是否简洁，复⽤性强。例 ，可将重复度⾼的步骤或过程抽取出来定义为⼀些可复⽤标准步骤。 5.评审的⽅式 1)召开评审会议。与会者在设计⼈员讲解之后给出意见和建议，同时进⾏详细的评审记录。 2)通⽤邮件与相关⼈员沟通 3)通⽤IM(办公通讯)⼯具直接与相关⼈员交流 ⽅式只是⼿段，得到其它⼈员对于⽤例的反馈信息才是⽬的。 ⽆论采⽤那种⽅式，都应该在沟通之前把⽤例设计的相关⽂档发送给对⽅进⾏前期的学习和了解，以节 省沟通成本。 6.评审结束标准 在评审活动中会收集到⽤例的反馈信息，在此基础上进⾏⽤例更新，直到通过评审。 测试⽤例的变更 测试⽤例并⾮⼀成不变。 果软件修改之后发⽣变化，或者需求发⽣变更，那么测试⽤例便不再满⾜当前版本 软件的测试需求，由此需要进⾏修改和变更操作。