如何保证测试用例的广度

愚人

当前问题：如何保证测试用例的广度？



如何保证测试用例的广度？

http://bbs.51testing.com/viewthread.php?tid=280759&pid=1668722&page=1&extra=#pid1668722

鄙人浅薄的认识：

拜读了Jackc的长篇大作，也想谈一下个人一点浅薄的想法……本人没做过高深的测试，什么白盒，自动化都不懂，仅仅站在黑盒的角度来说一下。

    黑盒测试，正如大家所了解的，就是把产品当成一个黑盒子，不关心产品内部，只关心输入和输出，也就是说关键弄清楚输入和输出。显然，要想提高输出的广度，那么只有提高输入的广度了，提高用例覆盖的广度。有人说，这不废话吗？是有点废话，但是我们想想，测试用例何尝不是一种输出呢？假如我们把这个过程也比作一个黑盒的话，用例就是我们重要的输出，那么要提高用例的广度，就要提高输入的广度。

    那么产生用例的输入是什么呢？很多人都会相当设计文档，产品规格。恭喜您答对了！但是光有这些还是不够的。鄙人在之前的学习中还了解到几种来源，认为也是比较重要的，这里跟大家分享一下：
    1、 开发需求（又名设计规格，产品规格）
     这点大家都了解，不再罗嗦。
    2、协议规范
    这里的协议规范包括国际标准，如ITU-T协议，ANSI协议；国家标准，如WAPI，IPTV标准，电信标准等等；行业标准，如中国国家电话网NO.7信号方式技术规范；公司内部的规范，如license规范，GUI规范。之所以是标准或者规范，肯定是要经得起考验的，产品也必须遵守这些标准规范。
     3、用户需求
     和开发的需求分析不重复，分析角度，检验开发需求能否满足标准和用户需求，获取客户需求的主要手段有，市场与客户的交流报告，客户方考核验收指标，研发内部与客户的答疑，外部的达标测试，与客服市场部门的交流等。
     4、继承产品
     主要对之前产品有继承的产品测试，需要了解对之前产品继承情况，改变地方，历史测试是否充分，缺陷库，根据经验，上一个产品的bug就是下一个产品的风险，所以对继承产品质量评估也很重要，当然如果是完全开发，可以降低此优先级，但也可以拿来做参考。
     5、测试经验库
     测试经验库包括网上问题分析，产品内部问题分析，缺陷分析，各种经验教训总结，正所谓前事不忘，后事之师。这里说明一下网上问题不是公司的缺陷库（bug库），而是已发布的产品，经市场和客服反馈的问题，基本属于漏测的问题，需要好分析，为什么漏测。估计多数问题表象都是由于覆盖度问题，淡然引起覆盖度不够的原因就是多种多言的了。
     6、其他
     其他来源是什么，有待于大家补充……（不要打我啊，拍砖可以）

     除了上述几点，鄙人认为个人经验和行业或者产品知识也很重要，丰富的经验可以起到未雨绸缪的作用，产品知识包括自己产品，对手产品。这也是我想说的如何保证测试用例的广度另一个关键点——人。有句话叫巧妇难为无米之催，但是反过来，如果各种好料都配齐了，没有好的厨师，也是做不出佳肴美味的。这个人在不少大的公司叫做TSE，即测试系统工程师，对其要求绝对不低于SE。此人将把前面提到的原始的材料进一步融合，然后加上自己的功底和科学的方法加工，会得出完美的佳肴——测试规格，在测试规格中将定义产品所涉及到的覆盖范围。鄙人对此过程接触不深，就不在献丑了，如果大家感兴趣可以请教坛子里的高手。

   总结一下，鄙人对如何保证测试用例的广度理解是，好的大厨+全而齐的材料=》美味佳肴

   以上只是浅薄的认识，欢饮批评指正……

zhangting85

说的很对，其他的可以参考：待测功能与下列heuristics是否符合。
1）与本产品内的类似功能是否符合
2）与同类产品的同种功能是否符合
3）与本产品历史版本是否符合
4）与测试人员对系统的想象是否符合
5）与非技术文档以及本产品的广告的描述是否符合
6）与一些必须实现的要求是否符合
7）与用户的预期是否符合
8）与产品或者功能的明显目标是否符合

另外，很重要的一点，这样的测试其中蕴含着风险那就是，有可能你的待测软件和你用来参考的heuristics是不需要符合的,也就是说，拿来参考的东西，不一定对，这些都是测试人员需要考量的。

liuhaisheng2008

来学习，谢谢分享