再说说APP测试用例设计（一）

lsekfe

【前言】
　　●之前的测试规范，很多人都做过一些分享了，内容大多集中在测试用例的分析方法（如等价类划分）、书写格式以及测试类型对应的用例选取范围（如冒烟测试对应的用例如何选取）本篇也将涉及这几个方面的内容，但不做特别深层的探讨，因为这部分作为经典的内容，已经有非常成型的内容产出，且传承良久。
　　●这里将针对智能手机以及平板电脑的特性，结合在过完几年的移动端测试经验，主要讨论针对移动设备如何进行用例的组织，如何用于执行，如何结合各种测试方法手段，如何把握各种测试深度以及用例的选取。
　　1. 测试用例分析常用方法
　　从理论上讲，手机软件规模越大，模块间的关系越复杂，组合的情况越多，测试用例数目占的比例也就越大，因而总是很难设计出“足够”的测试用例。
　　虽然理论上缺陷空间（测试空间上所有可能发生的缺陷构成的集合就是缺陷空间）可以接近无限大，但实际情况中存在的缺陷只是缺陷空间的一个很小的子集。测试中最重要的是要找到已经存在的缺陷，但在没有进行测试前，手机软件中存在多少缺陷却是不知道的。从理论上讲，测试是不能穷尽的，就意味着不存在一种方法能将所有的缺陷都所以找出来，找到缺陷的问题注定是一个概率问题，将那些发生概率较大的缺陷找出来就成了测试的主要任务。测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使测试程序在这种场景下运行并且达到程序所设计的执行结果。
设计测试用例首先要考虑以下几个问题：
　　●为什么要设计测试用例？
　　●谁来写测试用例？
　　●这些写测试用例的人的测试技术如何？
　　●以及对被测试产品了解有多深入？
　　●测试用例写给谁看，多少人将使用测试用例文档？
　　●分配给编写测试用例的时间是多长？要安排几个人来写？
　　●怎么在测试用例的成本、质量和效率方面达到平衡？
　　目前的手机市场对于新推出的功能和应用程序有着迫切的需要，使得产品周期非常短；然而只有回答了这些问题，才能确定测试用例的具体写作方法和表现形式。一般而言，手机软件测试项目中分配写测试用例的时间并不长，而且提供的文档也不全面，所以写测试用例要符合测试部门的当前现状和项目的测试特点。
　　对于测试设计工程师来说，设计测试用例需要考虑以下几个方面：
　　●测试用例设计必须考虑有效：容易发现并呈现错误；
　　●测试用例设计必须覆盖全面又不冗余：数量上不应有重复的、多余的用例，对软件规格说明书和设计功能点有全面的覆盖，不仅包括功能测试用例，还包括性能测试用例，外场测试、易用性等测试用例；
　　●测试用例设计必须明确粒度和测试分类的程度：粒度越细，测试成本就越高，测试周期就越长；分类越多，测试成本相应增加，测试周期就越长；
　　●测试用例设计完成后必须经过评审：以帮助进一步补充用例，提高测试覆盖率，提高用例质量。 对于测试执行工程师来说，测试用例的内容应包括以下几个方面：
　　●测试用例的测试目标；
　　●测试用例的被测功能点描述；
　　●测试用例的测试运行环境；
　　●测试用例的执行方法（包括测试步骤，输入测试数据或测试脚本）；
　　●测试期望的结果；
　　●执行测试的实际结果；
　　●其他辅助说明。
　　一个好的测试用例是指可能找到迄今为止尚未发现的错误的测试，由此可见，测试用例设计工作在整个测试过程中占有十分重要的地位，所以我们不能只凭借一些主观或直观的想法来设计测试用例，而应该要以一些比较成熟的测试用例设计方法为指导，再加上设计人员个人的经验积累来设计测试用例。 下面我们将由一般到特殊，先从经典的软件测试分析方法开始讨论。
　　1.1 等价类划分
　　如果把所有可能的输入数据分为有效等价类和无效等价类两种，那么可以做出这样的合理假定：如果等价类中的一个输入数据能发现一个缺陷，那么等价类中其他输入数据也能发现同一个缺陷；反之，如果一个输入数据不能发现某个错误，那么等价类中其他输入数据也不能发现这一错误。
　　有效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
　　与有效等价类恰巧相反，无效等价类是指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。
　　等价类分析法不但可以针对输入数据，而且可以针对输出数据进行划分。总之，他们发现缺陷的概率是等效的。
　　等价类划分方法设计用例的原则：
　　●如果输入条件规定了取值范围，或者值的个数，则可以确定一个有效等价类和两个无效等价类；
　　●如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可以确立一个有效等价类和一个无效等价类；
　　●如果输入条件是一个布尔量，则可以确立一个有效等价类和一个无效等价类；
　　●如果规定了输入数据的一组值，则程序要对每一个输入值分别进行处理；这时要对每一个规定的输入值确立一个等价类，并且对于这组值之外的所有值也都确立一个等价类；
　　●如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（即遵守规则的数据）和若干无效等价类（从不同角度违反规则的数据）；
　　●如果已划分的等价类中的各元素在程序中的处理方式不同，则应进一步划分成更小的等价类。范例，假设需求描述如下图：

　　

　　则等价类划分结果如下：

　

　　1.2边界值分析
　　边界值分析法基本概念
　　边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
　　长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。说明程序在边界值上出现错误概率的可能性大。
　　边界值分析法设计用例的原则
　　通常边界值分析法是作为对等价类划分法的补充，其测试用例来自等价类边界，每个边界都要作为测试条件。因此，边界值分析不仅考虑输入条件，还要考虑输出产生的测试情况。边界值分析法设计用例的原则如下：
　　●如果输入条件规定了值的范围，则应该取刚刚达到这个范围的边界值，及刚刚超越这个范围边界的值作为测试数据；
　　●如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一的数、比最大个数多的数作为测试数据；
　　●根据软件规格说明书的每个输出条件，应用上述的原则（1）和原则（2）；
　　●如果软件程序规格说明书所给出的输入域或输出域是有序集合，则应该选取集合的第一个元素和最后一个元素作为测试数据；
　　●如果程序中采用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试数据；
　　●分析软件规格说明书，找出其他可能的边界条件。
　　按照上述方法，可以做到更好地使用边界值对用例进行选择，更容易发现缺陷。在实际测试中可以按照这样的分类思路进行扩展。常用的边界值举例：

　　

　　1.3 因果分析
　　等价类划分和边界值分析方法，都是着重考虑输入条件，而未考虑输入条件之间的联系。如果在测试时必须考虑输入条件的各种组合则可能又会产生一些新的情况。检查输入条件的组合不是容易的事情，即使把所有输入条件都划分成等价类，它们之间的组合情况也相当多。
　　如果没有系统性的方法来选择输入条件的一个子集，可能导致低效率的测试。因此，必须考虑使用一种适合于描述这样一种情况的测试用例，对于多种条件的组合相应产生多个动作的形式，这就用到了因果图——实际上是一个数字逻辑电路。因果图是高效的方法，同时也可检查规范中的二义性和不完整性。因果图方法最终生成的是判定表，它适合于检查程序输入条件的各种组合情况。
　　因果图法的步骤：
　　●1、将规范分成若干个可工作的部分（对于大的规范来说因果图难以使用）。
　　●2、标识出规范中的原因与结果：
　　原因是输入条件和输入条件的等价类；
　　结果是输出条件或系统变换；
　　每个原因、结果都标上一个编号。
　　●3、分析规范的语义内容，将其转换为连接原因和结果的布尔图，即因果图。
　　●4、由于语法和环境的限制，存在不可能的原因和结果的组合，对此用约束条件在因果图上加以注释。
　　●5、有条理地跟踪因果图中的状态条件，将因果图转换为有限项的判定表，表中每一列代表一个测试用例。
　　●6、将判定表中的每一列形成一个测试用例。
　　范例：有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角 钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押 下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。
　　●分析这一段说明，列出原因和结果
　　原因：

1. 1.售货机有零钱找
   
2. 　　2.投入1元硬币
   
3. 　　3.投入5角硬币
   
4. 　　4.押下橙汁按钮
   
5. 　　5.押下啤酒按钮

复制代码

结果：

1. 21.售货机〖零钱找完〗灯亮   
   
2. 　　22.退还1元硬币
   
3. 　　23.退还5角硬币              
   
4. 　　24.送出橙汁饮料
   
5. 　　25.送出啤酒饮料

复制代码

●画出因果图，如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：

　　投入1元硬币且押下饮料按钮
　　押下〖橙汁〗或〖啤酒〗的按钮
　　应当找5角零钱并且售货机有零钱找
　　钱已付清

　　●转换成判定表：

　

　　●在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。第16列与第32列因什么动作也没做，也删去。最后可根据剩下的16列作为确定测试用例的依据。
　　1.4 判定表驱动法
　因果图方法中已经用到了判定表（Decision Table），它是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期,判定表就已被当做编写程序的辅助工具了。由于判定表测试严 格，能够将复杂的逻辑关系和多种条件组合的情况表达得既具体又明确，针对不同的逻辑条件组合值，分别执行不同的操作，因此，使用判定表能够设计出完整的测 试用例集合。判定表是一种针对存在条件、动作关系或者因果关系的特性测试的用例设计方法。

　

　　●判定表的组成
　　判定表通常由4个部分组成，如图3-6所示。
　　1）条件桩（Condition Stub）：列出了问题的所有条件，列出条件的次序没有约束。
　　2）动作桩（Action Stub）：列出问题规定可能采取的操作，这些操作的排列顺序无关紧要。
　　3）条件项（Condition Entry）：列出条件桩给出的条件并列出所有可能的取值。针对条件桩的条件和条件项的取值，判断在整个程序模块中的所有可能的情况下其结果的真假值。
　　4）动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
　　●判定表的建立步骤
　　判定表的建立步骤如下：
　　1）确定规则的个数，例如，有n个条件，那么决策表中就有2n个规则（每个条件取真、假值）。
　　2）列出所有的条件桩和动作桩。
　　3）填入条件项。
　　4）填入动作项，得到初始判定表。
　　5）简化判定表，合并相似规则。
　　1.5 正交法
　　主要用于解决组合爆炸问题。通过使用正交分析的收队，对多条件多因素的逻辑进行处理，组合分析出一些典型用例，它们能够覆盖大多数的用例场景，提高测试效率。
　　以手机浏览器设置功能为例，如下图：

　　

　　因子状态表如下：

　　1.6 场景法
　　从用户的角度来描述系统的运行行为，完全站在用户的视角来描述用户与系统的交互。在场景法中，测试流程是软件功能按照正确的事件流实现的一条正确流程，那么我们把这个成为该软件的基本流；而凡是出现故障或缺陷的过程，就用备选流加以标注，这样的话，备选流就可以是从基本流来的，或是由备选流中引出的。
　　以手机浏览器登录为例。通过场景法可以设计用例如下：

　　1.7 功能图法
　　●功能图法简介：
　　功能图方法其实是一种灰盒测试(因其兼有黑盒和[url=]白盒测试[/url]，所以称为灰盒测度比较体贴)用例设计方法；通常情况一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例
　　●程序功能说明的组成
　　动态说明：描述输入数据的次序或转移次序
　　静态说明：描述输入条件和输出条件之间的对应关系
　　●功能图：
　　由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来表示。一个状态指出数据输入的位置（或时间），一个迁移指明状态的改变，同时要依靠判定表或因果图表示的逻辑功能
　　●功能图法概述
　　用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例,功能图模型由状态迁移图和逻辑功能模型构成
　　●状态迁移图：
　　用于表示输入数据序列以及相应的输出数据；由输入数据和当前状态决定输出数据和后续状态
　　●逻辑功能模型：
　　用于表示在状态中输入条件和输出条件的对应关系。由输入数据决定输出数据。此模型只适用于描述静态说明,功能图测试用例由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满中的一对条件组成
　　●功能图法测试用例生成方法：
　　从状态迁移图中选取测试用例，用节点代替状态，用弧线代替迁移，状态图就可转化成一个程序的控制流程图形式
　　●测试用例生成规则
　　为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来，从功能图生成实用的测试用例，在一个结构化的状态迁移（SST）中，定义3种形式的循环：顺序，选择和重复
　　●功能图生成测试用例步骤
　　1 生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成
　　测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径
　　2 测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。
　　3 测试用例的合成算法：采用条件构造树.

不知道用啥

学习，支持一下