良好的测试用例管理对测试执行的益处

偶然看到一篇关于测试用例管理的文章，总的来说有4个方面：

1）. 迭代周期中测试用例的范围

2）. 测试用例编写的规范。这个问题之前文中有简单提到过，即要在项目kickoff前定义好测试用例的编写方式，做到简洁、统一

3）. 每轮测试中应该关注的是什么？是测试的执行率，还是真正有效的测试

4）. 测试覆盖率是否足够

这几个问题深入讨论的话会发现相互依托。第一个问题，要先在测试开始之前考虑好执行测试的范围，对于不同的测试制定不同的测试计划。以Scrum来说，每个Sprint都会有可交付的功能需要测试，那么测试的范畴就应该是本轮需要交付的功能；当然，每个Sprint之间也会相继开发相关或业务上有所关联的功能，就需要在关联功能完成之时进行相关测试；另外，在项目上线前的一些特殊测试，要准备的测试用例也会有所不同，例如，有需要串接不同业务流程、关键业务的测试，那执行的测试用例的重点就在串接测试部分（E2E）。为了应对不同测试类型、测试范畴的情况，那么在测试用例的开发之时，就要定义好如何区分不同类型的测试用例，例如，Functional（为单一功能，Form validation层面的测试用例），UI（界面），Integration/Business Logic（偏重业务逻辑，业务逻辑串接层面的测试用例）。那么这也就谈到了第二个问题，测试规范定义的问题，这是测试的框架。

第三和第四个问题一起来讨论。针对测试后的产出物，想必测试执行率、通过率、Bug率是显而易见被大家关心的。但回想我去年的经历，有种为了测试覆盖率而覆盖率的感觉，想必QA们也被我催着要这些东西而头晕脑胀吧，又由于Tester们至死不渝的怀疑精神。那么我们如何保障测试的有效性呢，执行了100条用例就保证相应模块的功能是通过的呢。想想看，定义有效的规范是首当其冲。测试用例的评审review也可以帮上大忙。最后，挑选合适的用例进行测试也是保障措施之一。最后的最后，对于不同类型测试用例的类型（Function，UI，Business Logic，E2E），组合在一起符合测试范畴的测试用例，这样来尽量满足足够大的测试范畴。就像白盒测试，可以有最小单元、针对每个方法的测试，也可以有针对业务逻辑的测试。黑盒测试而言同样，既要包括覆盖了基本功能的用例，也要包括业务流程、业务交互的测试用例。这样，无论从黑盒、白盒都可以满足测试覆盖率的要求。作为Leader自然对测试的结果会充满信心了。

目前想到了这些方面，后面如果想到再补充进来吧。