本文探讨脚本化测试中的测试用例的有效性问题，尤其是针对功能性测试用例而言。 我的答案:Incremental Analysis & Traceability - 对用例进行检视 - 看用例总数 - 看代码覆盖率 - 网上问题多少 - 千行代码用例数 OK， 用户反馈的问题确实能总体上评价测试的有效性，不过这已经是事后了，我们想事前就能有信心。 那么，换一种问法。 程，你的分析越来越深入，最终出来的是代码，这样的系统化的过程本身就一定程度地保证了你的代码是针对这些需求的、是有效的(这就是 verification)，但不一定是正确的，也许其中还有bug，这可以通过事后的测试活动找出来(这就是validation)。 即使你采用敏捷开发，也仍然需要进行“需求分析”“系统设计”“编码”。 你是否经过了一个“系统化的、增量的、分析过程”，来一步一步地确保你的用例能够充分覆盖这些需求?这就是我所说的测试分析设计的框架的概念。你需要分 析、画model、找出测试条件，然后才出具测试用例，你需要这样一系列的过程。 你是否因为需求分析、功能设计、技术设计等这些CMM的中间过程太耗时，而要求员工直接编码呢?不会。那为什么叫喊“测试分析、画model等测试设计活动工作量太大了”呢?(每当我讲完一次“MFQ&PPDCS:软件测试分析与测试设计”这门课，培训调查表中就会有这样的反馈:“测试分析的工作量太大了，没有时间做”;而与此同时，课前反馈的培训需求中又总是会有“学习测试设计技术，确保测试用例的有效性”、“设计出高质量的用例”。) 一边希望几乎不花什么时间、不用太费脑筋，就能得出测试用例;一边又对测试用例的有效性和评估提出高要求。测试是一种投资，测试设计活动更是一种投资， 用户会买你的代码，但不会买你的测试用例。你的用例的质量可以增加你对代码质量的信心，这其中是个平衡。如果你自信你的代码质量很高，那么恭喜你，无须在 测试用例上投资太多;如果你没有这份自信，那么请不要不舍得在测试设计上多投一些时间，请不要不愿意花一点精力去专研测试设计这门技术，更不要认为只有编
温馨提示：答案为网友推荐，仅供参考