怎么样的设计才能算测试用例
引自:IEEE Standard 610 (1990):
A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
(IEEE Std 829-1983) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.
但是，当每一次迭代中，执行全部的测试用例很多时候变成了一个很难的事情。
没有软件系统是完美的，任何系统都有BUGS。但是每一次得迭代都有一个期望，测试工程师需要知道本次迭代的项目关系人的预期，找到对应的目标和风险。
Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中描述了如何获取上面说的的目标和风险。文章说在详细的计划、设计或者编码前就明确质量目标，这样会更好的保证交付一个满足预期质量目标的交付物。
Ross Collard指出10%到15%的测试用例发现被测系统的75%到90%的BUGS。
这也是二八原则，二八原则影响了软件测试很多。
我相信你肯定也遇见过如下场景，面对成百上千的测试用例，要挑选出一个最小的、最终要的、优先级最高的测试用例集的时候却无法下手。对测试用例进行优先级的定义并不容易，而且优先级的定义在每一次迭代中或者迭代后都有可能修改。因此测试用例的优先级是动态的。
BVT也成为冒烟测试用例集。是每次测试开始allin投入前最希望被运行得以确认的测试用例集。
冒烟测试用例集的规则：如果该用例无法正确执行成功，其他测试用例都没有办法执行。如果满足该条件的测试用例，那么就应该纳入冒烟测试用例集。
高优先级测试用例集合是按照执行频度和业务功树的根部分支的条件选入的。
高优先级测试用例的规则：BVT中加入最常用的测试用例，用来验证重要或者主干流程的功能稳定、功能正确。测试用例中既包含了正确的数据流也包含了错误的数据流。
中优先测试用例集合是按照执行频度和业务功树的主要分支的条件选入的。
中优先级测试用例的规则：在新迭代影响域（新功能区域）或者功能更加详尽。测试用例包含了大多数方面的功能，其中除了有正确数据流和错误的数据流，还应该有一些配置方面的测试。
低优先测试用例集合是按照执行频度和业务功树的根部分支的条件选入的。
低优先级测试用例的规则：这个是最不频繁的测试用例执行的部分。但是低并不是说不执行，不测试。只是在迭代的过程汇总，执行频率比较低，不常常被执行。例如：错误消息，可用性，压力和性能测试等。
将全部功能的正确性验证（happy path）的测试用例定义为高优先级；
将全部有错误或者有边界值验证的测试用例定义为中优先级；
将其他定义为低优先级（这里面主要是非功能测试用例）
通过对每一个测试用例以及其优先级的标记的重新review，开了测试的重要性以及执行频度等，按照下面进行降级处理。
将功能验证测试分为两组重要和非重要,将“不太重要”的功能验证测试降级为中等优先级;
将错误和边界测试分为两组重要和非重要。将“重要”错误和边界测试推广到高优先级。
将非功能性测试分为两组重要和非重要。将“重要”非功能性测试推广到中等优先级。
对每组高，中和低优先级测试用例重复划分和升级/降级过程，直到达到优先级之间移动的测试用例数量变为0，终止。
将高优先级测试分为两组，分别为致命和严重（如果出现bug就是致命bug，那么这条测试用例也设定为致命。将致命的测试用例归并到BVT优先级。
相对统计的优先级分布BVT 10-15％，高20-30％，中等40-60％和低10-15％。
http://thinktesting.com/articles/rapid-test-case-prioritization/
http://thinktesting.com/articles/regression-testing-strategic-and-risk-driven-can-you-afford-not-to/
http://thinktesting.com/articles/write-a-test-strategy-what-choices-do-i-have/
http://thinktesting.com/articles/risk-mitigation-and-scarcity/
网友评论