如何评价测试用例的有效性?

很多测试团多都会既开展脚本化的测试(Scripted Testing),也开展探索性的测试(Exploratory Testing),关于二者的定义和区别,可以参见Cem Kaner的胶片

本文探讨脚本化测试中的测试用例的有效性问题,尤其是针对功能性测试用例而言。

如何评价测试用例的有效性?

我的答案:Incremental Analysis & Traceability

你所在团队是如何评价测试用例的有效性的?

- 对用例进行检视

- 看用例总数

- 看代码覆盖率

- 网上问题多少

- 千行代码用例数

- 用例发现缺陷密度

。。。。。。

如何评价代码的有效性?– 通过测试验证。

如何评价测试用例的有效性? — 通过产品发布后用户反馈的问题。

OK, 用户反馈的问题确实能总体上评价测试的有效性,不过这已经是事后了,我们想事前就能有信心。

那么,换一种问法。

如何确保,你写的代码确实实现了给定的需求?

看一看我们的V模型吧,从“需求”到“代码”你走了怎样的路?你从拿到需求开始,开展了一系列的活动,需求分析、功能设计、技术设计,经过这些增量的过程,你的分析越来越深入,最终出来的是代码,这样的系统化的过程本身就一定程度地保证了你的代码是针对这些需求的、是有效的(这就是verification),但不一定是正确的,也许其中还有bug,这可以通过事后的测试活动找出来(这就是validation)。

 即使你采用敏捷开发,也仍然需要进行“需求分析”“系统设计”“编码”。

那么如何确保,你写的测试用例充分地测试了给定的需求?

从“需求”到“测试用例”你走了怎样的路?你是拿到需求,基于个人经验,写出来一大批用例?(这就像你拿到需求一上来就编码一样。) 你是否经过了一个“系统化的、增量的、分析过程”,来一步一步地确保你的用例能够充分覆盖这些需求?这就是我所说的测试分析设计的框架的概念。你需要分析、画model、找出测试条件,然后才出具测试用例,你需要这样一系列的过程。

你是否会对每一行代码进行检视之后,才知道代码的有效性或质量?不会。那为什么要求“通过逐个检视测试用例,就能判断出测试用例的有效性”呢?

你是否会通过代码行的总数判断代码的有效性(是否实现了需求)?不会。那么为什么要去“通过检查测试用例个数或密度的方法来判断测试用例的有效性”呢?

你是否因为需求分析、功能设计、技术设计等这些CMM的中间过程太耗时,而要求员工直接编码呢?不会。那为什么叫喊“测试分析、画model等测试设计活动工作量太大了”呢?(每当我讲完一次“MFQ&PPDCS:软件测试分析与测试设计”这门课,培训调查表中就会有这样的反馈:“测试分析的工作量太大了,没有时间做”;而与此同时,课前反馈的培训需求中又总是会有“学习测试设计技术,确保测试用例的有效性”、“设计出高质量的用例”。)

一边希望几乎不花什么时间、不用太费脑筋,就能得出测试用例;一边又对测试用例的有效性和评估提出高要求。测试是一种投资,测试设计活动更是一种投资,用户会买你的代码,但不会买你的测试用例。你的用例的质量可以增加你对代码质量的信心,这其中是个平衡。如果你自信你的代码质量很高,那么恭喜你,无须在测试用例上投资太多;如果你没有这份自信,那么请不要不舍得在测试设计上多投一些时间,请不要不愿意花一点精力去钻研测试设计这门技术,更不要认为只有编码是高尚的技术行为、测试只是没有什么技术含量的活儿。

如果你想知道你的产品的测试用例的有效性,我的建议,从测试分析设计框架上看,不仅仅看最终的一个一个的测试用例,更要看的是中间的、增量的、测试分析设计的过程,同时确保从需求到model、到测试条件、到测试用例的可跟踪性。

 《如何评价测试用例的有效性?》有 4 条评论

  1. yuleishou说:

    赞同“更要看的是中间的、增量的、测试分析设计的过程,同时确保从需求到model、到测试条件、到测试用例的可跟踪性”。
    另外我觉得获取代码覆盖率也是评估测试用例有效性的一种辅助手段,虽然代码覆盖率高不一定说明测试用例就很完备,但这个覆盖率低就需要我们认真分析原因。


  2. aux0说:

    测试用例的有效性建立在测试的过程中,与需求覆盖率,代码覆盖率,bug这几个要素关系密切。


  3. Mysoft_熊锐奇说:

    非常认同晓梅老师的观点,测试用例的有效性评估,重点在于测试分析过程,这也是我前期进行用例评审中悟到的;为什么呢?
    第一:用例设计也是一个智力活,我们不可能只看结果
    a、产出的用例篇幅很大,没有那么多精力一条一条去评审
    b、产出的用例是经过大脑分析“加密”过的,没人思维方式不一样,花大量时间去评审用例效率很低;
    第二:从用例设计分析的过程产物去把关,纠正分析纬度的缺失,纠正分析方法的错误,帮助提前理清楚分析思路;比事后去评审用例价值高的多;
    第三:过程中评审,这个时候测试人员才会体会到你是在真正帮助我,而不是在我的用例完成后,到处挑我的毛病。


  4. tester说:

    本人的理解是这样的,邰老师的建议与RBT,ReqBT是一脉相承的,检验用例有效性的一个重要标准就是该用例是否真正有的放矢,也即真正瞄准了靶心,这个靶心就是关键场景下的关键特性。关注测试设计过程,实际上就是关注用例是否瞄准了靶心。采用统计用例总数、 代码覆盖率、 网上问题多少、 千行代码用例数、 用例发现缺陷密度的方式是无法揭示用例是否真正瞄准了靶心。


Comment Box is loading comments...