送给佳佳同学的礼物：测试用例设计
需求：
接上一篇博客：送给佳佳同学的礼物：测试流程及并行测试介绍?， 本次主要介绍测试用例设计，虽然偏理论，但是测试还是需要理论支持的。 本博文的大部分内容来自@淘郑萼?新人培训ppt —— 测试用例设计，感谢郑萼MM对新人的培养。
?
测试用例设计的几个要点如下：
?
1. 原则： 通常应该避免依赖先前测试用例的输出；
tips：如果测试用例直接相互依赖，那么当出现测试无法通过时，将很难去定位问题并查找原因。因此，最好是能够保证一个测试用例针对一个功能测试点；
?
从这一原则还可以衍生出两点注意点：
a. 测试数据准备：
如在测试数据库查询操作时，就必须先在数据库中准备相应的被查询数据（测试数据），我们需要保证每个测试用例所使用到的测试数据不会影响到其他测试用例的测试数据。这样避免因为某个测试用例的误操作而导致其他测试用例失败。
b. 测试环境恢复：
在完成每个测试用例的测试过程之后，需要尽量将所用到的测试环境恢复到执行该测试用例之前的干净的测试环境，这样也是为了避免测试用例直接的相互干扰。
?
2. 目的：?
a. 促使测试人员深入了解需求；
tips：测试人员在设计测试用例的过程，也是对产品的深入了解的过程，而且我个人认为在执行测试用例的过程，也是对产品深入了解的过程，通过测试过程的交互，再采用探索式测试方式不断的补充和完善测试用例，从而保证产品的质量。
b. 有利于测试的组织，避免盲目测试并且提高测试效率；
c. 确保功能不被遗漏；
tips：通过测试用例设计，产出下面第四点提出的MM图或TestCase，从而使测试人员了解当前的测试进度、功能点覆盖情况等信息，提高测试效率和功能覆盖面。
d. 有利于测试的重复执行，减少对个人的依赖；
tips：完成测试用例设计及自动化测试代码编写之后，能够使本次测试过程及以后的新版本回归过程不依赖于特点的测试人员。同样的每次的测试项目结束之后如果能够有一些知识沉淀，那么也会更有效的提高新测试人员接受测试项目的效率，节约人员流动成本；
e. 测试过程可量化 —— 特别是在高风险的测试中，能够证明确实执行了测试计划；
f. 使软件测试的实施重点突出、目的明确；
tips：在测试用例设计结束之后，可以进行测试用例评审，在评审过程中可以突出重点、明确目的，并且也便于监控整个测试过程；
?
3. 依据：所有能够得到的项目文档或已经达成一致的讨论（tips：尽量将讨论结果落实成文档并邮件发出确认）
a. “需求说明”及相关文档；
b. 相关的设计说明（概要设计，详细设计等）
c. ?与开发或产品讨论并达成共识的邮件或口头结论（tips：尽量落实成文本，便于以后复查）
d. 已经基本成型的demo
tips：由于互联网企业的特点是敏捷开发，很少积累下详细的文档材料，因此在测试实施过程中经常会发现与最初讨论/文档不符或者没有记录的地方，这时候需要积极与相关人员（开发、产品经理）进行沟通确认，并将最终结果完善到相应的文档中。
?
4. 产出： 形式包括但不限于以下几种：
a. 功能需求分界MM图： Free Mind， Xmind；
b. 系统交互图： Rose；
c. 数据流程图： Rose；
d. 分析完成的用例思路集合；
e. 接口设计的具体测试用例（接口）
f. ?性能测试的具体测试方案，包括测试场景和模型（性能）
?
几种形式的优缺点比较：
a. Checklist
-优点： 验证点较明确，维护成本较低，适用于小需求，且不需要长期维护的项目；
-缺点： 由于没有执行步骤，所以要求项目组成员对项目比较熟悉，不易管理和传承；
b. MM图
-优点： 书写快速，条理清晰，与checklist相比，模块之间的层次关系明确；
-缺点： 依然是没有执行步骤，不过可以采用层次关系来表明执行步骤，但这又会导致层次过于复杂
c. TestCase:
-优点： 测试步骤比较详细，有明确的优先等级和严重级别，能够很好的指导测试执行人员进行测试，适用于长期维护的大项目；
-缺点： 维护成本较高，TestCase管理难度较大；
?
tips：我个人更喜欢用MM图来进行用例设计，因为MM图层次分明，条理清晰，在进行用例评审和自动化测试代码编写的时候，能够有效的将设计思路表达出来，并且如果需要可以很方便的进行修改和补充。在完成所有测试工作并代码入库的时候，我会将MM图转换成TestCase保存在测试平台（BugFree[一淘出品]、kelude[淘宝出品]、QC）上；
?
5. 测试用例设计方法：
a. 等价类
定义： 把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例；
tips：如果能够在阅读产品源码的基础上选取代表性数据的话，那将更容易测出问题；
?
原则：
1. 在输入条件规定了取值范围或值的个数的情况下，可确立一个有效等价类和两个无效等价类；
tips：如果有效范围是{1-10}， 那么无效等价类可以是{1-10范围之外的数字}, {所有非数字字符}；
2. 在输入条件规定了输入值的集合或规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类；
tips：有效等价类可以是{输入A， 才得到B}， 无效等价类可以是{输入C， 得到其他一些无效值}；
3. 在输入条件是一个布尔量的情况下，可确立一个有效等价类和一个无效等价类；
tips：即布尔量为true 和 false两种；
4. 在规定了输入数据的一组值（假定n个），并且程序要对每个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类；
tips：如输入数据为（1、2） 那么有效等价类{输入1，返回A}和{输入2，返回B}， 无效等价类{输入非1和2的值，返回其他结果}；
5. 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类和若干个无效等价类（从不同角度违反规则）；
tips：如输入必须为正整数，那么有效等价类{所有正整数}，无效等价类{所有负整数}、{所有小数}、{所有非数字字符，如特殊符号、字母等}等等；
6. 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步划分为更小的等价类；
tips: 如输入必须为正整数且等于10的倍数时加1，那么有效等价类{所有正整数}可以划分为{所有非10倍数的正整数}、{所有10倍数的正整数}；
?
转换成测试用例：
1. 为每个等价类规定一个唯一的编号；
2. 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖；
3. 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖；
?
tips： 转换的思路是：有效等价类，可以用尽量少的用例来覆盖他们，而无效等价类，要尽量做到一个Case只覆盖一个无效等价类；
?
b. 边界值
定义： 是对输入或输出的边界值进行测试的一种黑盒测试，同时也是对等价类的一种补充；
原则：
1. 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值为为测试输入数据；
2. 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的数作为测试数据；
tips：如输入范围或个数为（1-10的正整数），那么取值可以是1、10、0、11；
3. 将a和b的原则同样应用到输出上，即设计测试用例使输出值达到边界及其左右的值；
tips：对输出的范围验证与输入同样重要，很多同学在测试的时候会忽略对输出范围的验证，导致输出结果越界的情况时有发生；
4. 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例；
5. 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例；
tips：这种测试也成为灰盒测试；
?
边界值与等价类配合的方式：
1. 划分等价类；
2. 确定所有的边界值；
3. 利用边界值作为测试数据[min-1;min;min+1;max-1;max;max+1]；
4. 内部边界值的分析（数值的边界值；字符的边界值）；
5. 根据分析出的测试数据设计测试用例；
?
c. 场景
定义：从用户角度分析SUT所有被事件触发的流程并形成相应的用例场景，并描述不同的事件流(基本流和备选流)
原则：?
1. 制定User Case(相关的数据和覆盖这个case所流经的路径)
2. 通过UC来确定需要测试的场景(一个复杂的场景包含对多个user case的组合，通过控制场景或子场景的执行顺序、条件控制、并行或反复处理来组合而成的)
3. 场景需要定义actors, roles, business processes, events以及the goal(s) of the actor(s)
4. 确定每个场景的基本流和备选流
5. 根据基本流和备选流的组合和正反面来确定场景用例
6. 对于所有场景用例进行复审和验证其准确和适度，并取消多余或等效的场景用例
7. 对于场景用例设定测试数据形成真正的测试用例
?
d. 因果图
定义：?因果分析是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况
?
原则：
1. 分析需求规格说明的描述中，哪些是原因，哪些是结果
2. 分析需求规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的因果图
3. 在因果图上使用若干个特殊的符号标明特定的约束条件
4. 把因果图转换成判定表
5. 把判定表中每一列表示的情况写成测试用例
?
6. 测试用例属性及格式：
a. 属性：
1. 优先级： 需要为测试用例区分优先级，以保证重点和紧急功能点能够得到充分测试；
2. 自动化程度： 分为已完成自动、待完成自动化和不需要自动化；
3. 执行结果： 分为Pass、Fail、Block、Not Complete；
4. 编写者及测试执行者；
5. 编写时间及与其相对应的项目/产品版本号；
?
b. 格式：
1. 用例编号及标题： 便于用例管理和查找；
2. 前置条件： 每个测试用例执行前所需要准备的前置条件，如测试环境，测试数据准备等；
3. 执行步骤： 每个测试用例所需要的执行过程描述；
4. 预期结果： 在上述前置条件及执行步骤完成结束之后，所期望看到的测试结果；
5. 备注： 对测试环境进行描述，如数据库信息、浏览器信息等；
?
OK， 送给佳佳同学的礼物：测试用例设计介绍完毕，欢迎拍砖。转发请备注转自：100continue.iteye.com。 谢谢
