很多测试团多都会既开展脚本化的测试(Scripted Testing)，也开展探索性的测试(Exploratory Testing).

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

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

　　我的答案：Incremental Analysis & Traceability

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

　　- 对用例进行检视

　　- 看用例总数

　　- 看代码覆盖率

　　- 网上问题多少

　　- 千行代码用例数

　　- 用例发现缺陷密度

　　。。。。。。

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

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

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

　　那么，换一种问法。

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

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

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

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

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

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

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

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

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

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