如何保证测试用例的广度？（10-8-2）（获奖名单已公布）

愚人

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

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

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

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

    得出测试规格后，即确定测试范围，这个范围基本决定了用例的范围。当然测试需求分析也是有很多工程方法的，如集成分析，交互分析等。根据每一条测试规格进行测试方案分析，比如有哪些输入，哪些输出，实现此规格测试需要哪些条件，工具。
   
    以上工作做完，做好了，就可以利用测试用例设计方法来设计用例了。相信此时设计的用例已经是比较广的了。

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

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

[ 本帖最后由 愚人 于 2010-8-6 08:58 编辑 ]

愚人

原帖由 ricmy 于 2010-8-9 11:06 发表
首先我想说的是，“广度”并不代表就是多，而应该指的是一种精细程度，其实作为每一个撰写Case 人员所追求的是用尽可能少的Case 达到一个尽可能高精细程度，而这个过程是需要大量运用撰写方法（就是通常我们所讲的等 ...

是指粒度吧，测试用例的粒度要均匀合适，不能有的粒度很大，有的很小，也就是有的很粗，有的很细……

愚人

多总结，多积累……没其他办法了……