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

默默巫

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

本问题由会员leelei提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
二等奖	zdlzx	300论坛积分	14#

Jackc

利润是企业的最终追求目标。如果把企业比作创造利润发动机，研发部门就是汽油，测试部门则是润滑油。

所以，测试的最终目标是提高产品质量，降低产品生产成本。而用例设计作为测试中的一环，也就不能跳出这个范围。

几乎所有的测试人员都明白一个简单的道理：测试用例是无穷无尽的……
这也是引入用例设计方法的初始点。使用科学的统计概率方法将无穷无尽的数据整理成具有实际操作意义的专业测试数据。

那么如何合理的分布测试数据，设计出效率更高的用例呢？

大家都玩过扑克吧？其实用例覆盖率策略设计过程和玩扑克是一样的。
（下面以设计测试覆盖率策略为中心的描述，对实际测试用例设计方法描述较少。如需实际用例设计方法，请百度“黑盒用例设计白皮书”和“白盒测试用例设计”）

1、基本能力
玩牌玩的好的人，要求的基本能力就是熟悉玩牌的规则和各种牌组的作用。
而设计用例覆盖策略的测试员，要求的基本也是熟悉测试流程/标准和各种测试资源的属性。

2、确定目标
开始一场新的牌局前，期望值通常是“赢”。
而在开始一轮新的测试前，用例设计的期望值通常是“更有效的覆盖率”。（请仔细思考“更有效”与“更高”的区别）

3、整理资源
当开始牌局，拿到一手牌后，你会直接就开始出牌吗？肯定不会！通常都会先提牌，将各个类型的牌组分类整理。
而在定义用例覆盖率之前，也同样需要先收集整理测试资源：时间、人力、硬/软件……

4、定义策略
提牌结束后，你通常就会思考出牌的策略。怎样将手里不同组合的牌组，以什么方式，什么时间打出去，并期望得到怎么样的结果等等。这就是出牌策略。
而测试用例覆盖率策略也是一样的。参考之前整理的资源清单，根据需求的要求，将手中的测试资源分布到整个测试周期中。
这一过程中，注意根据需求提及的各种优先级，对测试资源作对应调整。需求优先级高的功能或模块，测试资源分配相对较多，反之也然。
而测试用例覆盖率则与资源分布率一致。资源越多的测试点，覆盖率越高。

5、实际用例设计
出牌过程中，拽着手中有限的牌组，挣扎于“普通出牌”（出计划中的牌寻求上手机会）、“过”（时机不对，放弃出牌权）和“押宝”（针对关键的上手机会，出大牌进行赌博）这三者中。

而测试整个过程中，覆盖率也同样在这三种状态中循环。
优先级的低功能，用例覆盖率低，甚至在极端情况下会“放弃”此功能的测试。
优先级高的功能，用例覆盖率很高，极端情况下会将当前阶段的所有测试资源都压在这个功能的测试上。

而控制用例覆盖的最直接手段有两个：测试资源和测试用例
测试资源足够多，即使是Monkey Testing也能达到很好的测试效果。 微软热衷于区域性的用户体验测试正是源于此。
测试用例指导性够强，能有计划的分布测试资源和监控测试过程。

而用例设计目前主要分为白盒和黑盒两类，分别都有很清晰的标准文档，而控制手段其实也就在这些用例设计方法中。有希望深入了解的朋友，可以认真学学概率统计学的内容。
比如黑盒测试中，等价法的等价类分为强/弱等价类，这就是用例覆盖率控制的开关。
而黑盒的其他方法则往往使用等价法和边界值法提供的覆盖率开关，达到控制覆盖率的目的。比如，判定表法在生成判定表后，需要做一次“无效类”用例的删除，而其删除原理与等价法挂钩，变相实现了对覆盖率的控制。

综上，用玩牌的心态对待测试，就能实现测试用例广度的有效性覆盖。也能在有限资源中，最大程度的保证测试用例的广度。

[ 本帖最后由 Jackc 于 2010-8-4 12:00 编辑 ]

nathanhe

把各种输入条件都分析清楚，然后使用等价类等黑盒测试方法组成有效的用例，这样既保证了测试用例的广度，又精简了用例的数量。

牛粪

占个位置等答案

fachu121

如果在时间充足的基础上上要保证用例的广度，那就要几个人坐在一起，一个屏幕，一个看需求，一边将每个人考虑的点和方法都记录下来，然后，分块分发到相关的人编写详细的用例数据，编写完了，几个坐在一起将用例拿出来过一次。审核。

gotoyu

问题比较含糊，是指一个测试用例适用的广度呢？比如一个用例能多次使用？ 还是指测试用例针对需求的覆盖度、全面性，就是通常说的覆盖率呢？

[ 本帖最后由 gotoyu 于 2010-8-4 15:47 编辑 ]

愚人

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

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

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

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

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

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

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

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

牛粪

我没有这么丰富的测试经验，我只说说我的点点认识，保证测试用例的广度的我的理解就是测试用例尽量的覆盖需求，不要漏测点。那怎么保证测试用例的覆盖率呢，我觉得要从以下几点加强自己：
1.要熟练的掌握被测软件的和被测软件相关联的业务知识。业务知识在测试分析中的重要性我想大家都应该明白，只有我们充分了解了业务知识，才能分析出我们测试的边界值，测试的侧重点等等的
2.要不断的积累自己的经验。我一直是从事黑盒测试的，也就是手工测试。我觉得测试就是一个经验积累的行业，依靠自己的经验可以比较准确的判断出我们哪些地方该深入测试，哪些地方需要测试不会遗漏的。很多bug其实都是靠自己掌握的业务知识和经验分析出来。随机测试测出来的bug是需要运气成分。
3.要尽量的跟开发沟通，要了解开发的解决方案。其实开发的解决方案是决定我们测试范围的决定性因素。所以每个需求都要了解开发是怎么做的，怎么改的，当然前提是你要先了解这个需求是为了解决什么问题。
4.切当的用一些测试方法，比如把输入域划分为几个等价类，这样可以避免遗漏。对重要的点可以用画个脑图什么的进行发散性的思维
5.准备一份自己的公共测试数据，我指的是公共测试数据是指对某类输入的的一个归纳。举个简单的例子，测试一个用户的登入，你的要有个用户状态的公共数据库。包括正常用户，冻结用户，未激活用户，不存在的用户。。。。，这样你有需要判断用户状态的地方只要遍历下这个用户状态的公共数据，就不会有漏测了，而且效率特高。公共测试数据库是要靠平时积累的，其实积累的过程占用不了你多少时间
   我想到的自由这些了，等想到了再补充吧。

皇家马德里之魂

在测试规格初稿期，一种可行的方法是 测试team 的 Brains storm ，让更多的人的思考来扩充测试用例的广度。

ricmy

首先我想说的是，“广度”并不代表就是多，而应该指的是一种精细程度，其实作为每一个撰写Case 人员所追求的是用尽可能少的Case 达到一个尽可能高精细程度，而这个过程是需要大量运用撰写方法（就是通常我们所讲的等价类的划分，边界值，因果图，决策表等），虽然这些方法书本上都有讲到，但是每个人所掌握的程度会不一样，或是理解也有可能不一样，所以说保证测试用例的广度，从某种意义上就等于保证人对这些方法的把握了。
  既然是这个问题演变到 如何保证人对撰写方法的掌握，我想可以从这几个方面来讨论：
1. 首先是要挑选一个合适的人去写Case，这个人不但对这些方法掌握的很熟练，而且细心，对待问题一丝不苟，只有这样的人写出来的Case 你才会放心。
2. 通过模板的建立（请见http://www.51testing.com/?uid/37 ... itemid/218209/php/1），来减少对人的依赖，从而保证测试用例的广度。
3. 采用会议的形式Review。将几个有经验的Case撰写人组织在一起，同时可以邀请RD参与进来，通过会议的形式对Case进行Review，这样很大程度上也可以保证Case 的广度。

以上只是敝人的一些意见，欢迎讨论

愚人

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

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

dumb_dora

我也头疼这类问题，每次重新审视TC时，总能有一些新的idea,这有时候让我很是怀疑，我的测试真的做到位了嘛？
继续关注

愚人

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

zdlzx

个人理解相对深度而言，广度是指覆盖率。一般在以下3个阶段来考虑保证测试用例的覆盖率。

阶段1：测试用例设计时一般做如下考虑：

1、最基本的先保证以正反两大类用例全面覆盖需求（且先不论需求中的主次），其中包括

（1）细化各种数据类型，达到有效和无效数据类型的覆盖

（2）细化各种流程分支（考虑主流程、辅流程、异常处理、出错处理等）

2、考虑需求不完善之处（如与其它模块的交互、如对于性能的要求等），进一步补充用例

3、考虑设计约束（如分页处理、并发处理等），进一步补充和修改用例

阶段2： 测试用例设计好后与需求人员、开发人员、组内其他测试人员组织评审，可以吸取大家从不同角度看到的遗漏之处，进行补充；

阶段3：测试执行阶段
测试用例执行时可能产生新的测试想法，可以补充；根据测试覆盖率工具提供的报表，可以发现没有执行到的代码，对测试用例再进行补充；进行用户验收测试或上了产品后，用户报告的问题也可以补充到测试用例中去，提高覆盖率。

自由与完整

试着答一下：

基于需求，从如下两个方面考虑
1、划分需求的测试纬度，如基本功能、协议一致性、性能、指标、压力等，先把纬度划分好，从不同纬度去考虑用例设计；
2、功能交互：需求和其他功能，包括老特性，去做功能交互，识别相互间是否有影响，来设计用例；
通过1和2两个步骤保证用例的广度

swinfans

测试新手，坐等高手来解答