谈测试用例的评审

简介:

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

  测试用例的设计很重要,无论你采用的是敏捷测试还是传统的开发模式,测试用例都应该要文档化,并且根据项目的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. (预期结果中不要使用模糊的语言)



本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/
目录
相关文章
|
测试技术 UED
如何实施测试用例评审维护与更新?附模板
如何实施测试用例评审维护与更新?附模板
270 0
|
测试技术
软件交付问题之为什么测试用例不能全由开发人员告知测试人员
软件交付问题之为什么测试用例不能全由开发人员告知测试人员
|
存储 数据可视化 测试技术
软件测试 —— 需求评审报告
软件测试 —— 需求评审报告
182 0
|
敏捷开发 测试技术
软件测试/测试开发|测试用例设计和评审应该怎么做,一篇文章告诉你?
软件测试/测试开发|测试用例设计和评审应该怎么做,一篇文章告诉你?
|
测试技术
软件测试用例评审标准规范是什么?附模板
软件测试用例评审标准规范是什么?附模板
1196 1
|
测试技术
嵌入式软件测试笔记9 | 嵌入式软件测试中如何做好评审工作?
嵌入式软件测试笔记9 | 嵌入式软件测试中如何做好评审工作?
244 0
|
数据可视化 测试技术
测试用例评审如何开展
测试用例评审如何开展
229 0
测试用例评审如何开展
测试思想-文档评审 关于需求评审
测试思想-文档评审 关于需求评审
156 0
|
敏捷开发 人工智能 自然语言处理
测试思想-文档评审 需求分析和评审简述
测试思想-文档评审 需求分析和评审简述
188 0
|
测试技术
软件测试面试题:阶段评审与项目评审有什么区别?
软件测试面试题:阶段评审与项目评审有什么区别?
156 0

热门文章

最新文章