【前言】
- 之前的测试用例规范，很多人都做过一些分享了，内容大多集中在测试用例的分析方法（如等价类划分）、书写格式以及测试类型对应的用例选取范围（如冒烟测试对应的用例如何选取）本篇也将涉及这几个方面的内容，但不做特别深层的探讨，因为这部分作为经典的内容，已经有非常成型的内容产出，且传承良久。
- 这里将针对智能手机以及平板电脑的特性，结合在过完几年的移动端测试经验，主要讨论针对移动设备如何进行用例的组织，如何用于执行，如何结合各种测试方法手段，如何把握各种测试深度以及用例的选取。
1. 测试用例分析常用方法
从理论上讲，手机软件规模越大，模块间的关系越复杂，组合的情况越多，测试用例数目占的比例也就越大，因而总是很难设计出“足够”的测试用例。虽然理论上缺陷空间（测试空间上所有可能发生的缺陷构成的集合就是缺陷空间）可以接近无限大，但实际情况中存在的缺陷只是缺陷空间的一个很小的子集。测试中最重要的是要找到已经存在的缺陷，但在没有进行测试前，手机软件中存在多少缺陷却是不知道的。从理论上讲，测试是不能穷尽的，就意味着不存在一种方法能将所有的缺陷都所以找出来，找到缺陷的问题注定是一个概率问题，将那些发生概率较大的缺陷找出来就成了测试的主要任务。测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使测试程序在这种场景下运行并且达到程序所设计的执行结果。设计测试用例首先要考虑以下几个问题：
- 为什么要设计测试用例？
- 谁来写测试用例？
- 这些写测试用例的人的测试技术如何？
- 以及对被测试产品了解有多深入？
- 测试用例写给谁看，多少人将使用测试用例文档？
- 分配给编写测试用例的时间是多长？要安排几个人来写？
- 怎么在测试用例的成本、质量和效率方面达到平衡？
对于测试设计工程师来说，设计测试用例需要考虑以下几个方面：
- 测试用例设计必须考虑有效：容易发现并呈现错误；
- 测试用例设计必须覆盖全面又不冗余：数量上不应有重复的、多余的用例，对软件规格说明书和设计功能点有全面的覆盖，不仅包括功能测试用例，还包括性能测试用例，外场测试、易用性等测试用例；
- 测试用例设计必须明确粒度和测试分类的程度：粒度越细，测试成本就越高，测试周期就越长；分类越多，测试成本相应增加，测试周期就越长；
- 测试用例设计完成后必须经过评审：以帮助进一步补充用例，提高测试覆盖率，提高用例质量。 对于测试执行工程师来说，测试用例的内容应包括以下几个方面：
- 测试用例的测试目标；
- 测试用例的被测功能点描述；
- 测试用例的测试运行环境；
- 测试用例的执行方法（包括测试步骤，输入测试数据或测试脚本）；
- 测试期望的结果；
- 执行测试的实际结果；
- 其他辅助说明。
1.1 等价类划分
如果把所有可能的输入数据分为有效等价类和无效等价类两种，那么可以做出这样的合理假定：如果等价类中的一个输入数据能发现一个缺陷，那么等价类中其他输入数据也能发现同一个缺陷；反之，如果一个输入数据不能发现某个错误，那么等价类中其他输入数据也不能发现这一错误。有效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
与有效等价类恰巧相反，无效等价类是指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。
等价类分析法不但可以针对输入数据，而且可以针对输出数据进行划分。总之，他们发现缺陷的概率是等效的。
等价类划分方法设计用例的原则：
如果输入条件规定了取值范围，或者值的个数，则可以确定一个有效等价类和两个无效等价类；
- 如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可以确立一个有效等价类和一个无效等价类；
- 如果输入条件是一个布尔量，则可以确立一个有效等价类和一个无效等价类；
- 如果规定了输入数据的一组值，则程序要对每一个输入值分别进行处理；这时要对每一个规定的输入值确立一个等价类，并且对于这组值之外的所有值也都确立一个等价类；
- 如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（即遵守规则的数据）和若干无效等价类（从不同角度违反规则的数据）；
- 如果已划分的等价类中的各元素在程序中的处理方式不同，则应进一步划分成更小的等价类。范例，假设需求描述如下图：
Paste_Image.png
则等价类划分结果如下：
Paste_Image.png
1.2边界值分析
边界值分析法基本概念
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。说明程序在边界值上出现错误概率的可能性大。
边界值分析法设计用例的原则
通常边界值分析法是作为对等价类划分法的补充，其测试用例来自等价类边界，每个边界都要作为测试条件。因此，边界值分析不仅考虑输入条件，还要考虑输出产生的测试情况。边界值分析法设计用例的原则如下：- 如果输入条件规定了值的范围，则应该取刚刚达到这个范围的边界值，及刚刚超越这个范围边界的值作为测试数据；
- 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一的数、比最大个数多的数作为测试数据；
- 根据软件规格说明书的每个输出条件，应用上述的原则（1）和原则（2）；
- 如果软件程序规格说明书所给出的输入域或输出域是有序集合，则应该选取集合的第一个元素和最后一个元素作为测试数据；
- 如果程序中采用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试数据；
- 分析软件规格说明书，找出其他可能的边界条件。
Paste_Image.png
1.3 因果分析
等价类划分和边界值分析方法，都是着重考虑输入条件，而未考虑输入条件之间的联系。如果在测试时必须考虑输入条件的各种组合则可能又会产生一些新的情况。检查输入条件的组合不是容易的事情，即使把所有输入条件都划分成等价类，它们之间的组合情况也相当多。如果没有系统性的方法来选择输入条件的一个子集，可能导致低效率的测试。因此，必须考虑使用一种适合于描述这样一种情况的测试用例，对于多种条件的组合相应产生多个动作的形式，这就用到了因果图——实际上是一个数字逻辑电路。因果图是高效的方法，同时也可检查规范中的二义性和不完整性。因果图方法最终生成的是判定表，它适合于检查程序输入条件的各种组合情况。
因果图法的步骤：
- 1、将规范分成若干个可工作的部分（对于大的规范来说因果图难以使用）。
- 2、标识出规范中的原因与结果：
结果是输出条件或系统变换；
每个原因、结果都标上一个编号。
- 3、分析规范的语义内容，将其转换为连接原因和结果的布尔图，即因果图。
- 4、由于语法和环境的限制，存在不可能的原因和结果的组合，对此用约束条件在因果图上加以注释。
- 5、有条理地跟踪因果图中的状态条件，将因果图转换为有限项的判定表，表中每一列代表一个测试用例。
- 6、将判定表中的每一列形成一个测试用例。
范例：有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角 钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押 下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。 - 分析这一段说明，列出原因和结果
原因：
1.售货机有零钱找
2.投入1元硬币
3.投入5角硬币
4.押下橙汁按钮
5.押下啤酒按钮
结果：
21.售货机〖零钱找完〗灯亮
22.退还1元硬币
23.退还5角硬币
24.送出橙汁饮料
25.送出啤酒饮料
- 画出因果图，如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：
- 投入1元硬币且押下饮料按钮
- 押下〖橙汁〗或〖啤酒〗的按钮
- 应当找5角零钱并且售货机有零钱找
- 钱已付清
Paste_Image.png
· 转换成判定表：
Paste_Image.png
· 在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。第16列与第32列因什么动作也没做，也删去。最后可根据剩下的16列作为确定测试用例的依据。1.4 判定表驱动法
因果图方法中已经用到了判定表（Decision Table），它是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期,判定表就已被当做编写程序的辅助工具了。由于判定表测试严 格，能够将复杂的逻辑关系和多种条件组合的情况表达得既具体又明确，针对不同的逻辑条件组合值，分别执行不同的操作，因此，使用判定表能够设计出完整的测 试用例集合。判定表是一种针对存在条件、动作关系或者因果关系的特性测试的用例设计方法。
Paste_Image.png
- 判定表的组成
判定表通常由4个部分组成，如图3-6所示。
1）条件桩（Condition Stub）：列出了问题的所有条件，列出条件的次序没有约束。
2）动作桩（Action Stub）：列出问题规定可能采取的操作，这些操作的排列顺序无关紧要。
3）条件项（Condition Entry）：列出条件桩给出的条件并列出所有可能的取值。针对条件桩的条件和条件项的取值，判断在整个程序模块中的所有可能的情况下其结果的真假值。
4）动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。 - 判定表的建立步骤
判定表的建立步骤如下：
1）确定规则的个数，例如，有n个条件，那么决策表中就有2n个规则（每个条件取真、假值）。
2）列出所有的条件桩和动作桩。
3）填入条件项。
4）填入动作项，得到初始判定表。
5）简化判定表，合并相似规则。
1.5 正交法
主要用于解决组合爆炸问题。通过使用正交分析的收队，对多条件多因素的逻辑进行处理，组合分析出一些典型用例，它们能够覆盖大多数的用例场景，提高测试效率。以手机浏览器设置功能为例，如下图：
Paste_Image.png
因子状态表如下：| 状态/因子 | 字体大小（小/中/大） | 文字间距 （小/中/大） | 显示图片（是/否） | 启动js | 浏览方式 |
|---|---|---|---|---|---|
| 1 | 小 | 小 | 是 | 是 | 简略 |
| 2 | 小 | 小 | 是 | 是 | 缩放 |
| 3 | 小 | 小 | 是 | 否 | 简略 |
| 4 | 小 | 小 | 是 | 否 | 缩放 |
| 5 | 小 | 小 | 否 | 是 | 简略 |
| 6 | 小 | 小 | 否 | 是 | 缩放 |
| 7 | 小 | 小 | 否 | 否 | 简略 |
| 8 | 小 | 小 | 否 | 否 | 缩放 |
| 9 | … | … | … | … | … |
1.6 场景法
从用户的角度来描述系统的运行行为，完全站在用户的视角来描述用户与系统的交互。在场景法中，测试流程是软件功能按照正确的事件流实现的一条正确流程，那么我们把这个成为该软件的基本流；而凡是出现故障或缺陷的过程，就用备选流加以标注，这样的话，备选流就可以是从基本流来的，或是由备选流中引出的。以手机浏览器登录为例。通过场景法可以设计用例如下：
| 基本流 | 使用正确的账号/密码登陆，返回正常的登陆后的页面 | |
|---|---|---|
| 备选流1 | 使用正确的注册的邮箱/密码登陆，返回正常的登陆后的页面 | 场景一：邮箱登陆成功 |
| 备选流2 | 使用正确的注册过的手机号登陆，返回正常的登陆后的页面 | 场景二：邮箱登陆成功 |
| 备选流3 | 使用错误的/未注册的邮箱登陆，提示账号不存在 | 场景三：邮箱错误/未注册 |
| 备选流4 | 使用错误的手机号登陆，提示账号不存在 | 场景四：手机号错误/未注册 |
| 备选流5 | 输入错误的密码，返回页面提示密码错误 | 场景五：密码错误 |
1.7 功能图法
- 功能图法简介：
功能图方法其实是一种灰盒测试(因其兼有黑盒和白盒测试，所以称为灰盒测度比较体贴)用例设计方法；通常情况一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例 - 程序功能说明的组成
动态说明：描述输入数据的次序或转移次序
静态说明：描述输入条件和输出条件之间的对应关系 - 功能图：
由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来表示。一个状态指出数据输入的位置（或时间），一个迁移指明状态的改变，同时要依靠判定表或因果图表示的逻辑功能 - 功能图法概述
用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例,功能图模型由状态迁移图和逻辑功能模型构成 - 状态迁移图：
用于表示输入数据序列以及相应的输出数据；由输入数据和当前状态决定输出数据和后续状态 - 逻辑功能模型：
用于表示在状态中输入条件和输出条件的对应关系。由输入数据决定输出数据。此模型只适用于描述静态说明,功能图测试用例由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满中的一对条件组成 - 功能图法测试用例生成方法：
从状态迁移图中选取测试用例，用节点代替状态，用弧线代替迁移，状态图就可转化成一个程序的控制流程图形式 - 测试用例生成规则
为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来，从功能图生成实用的测试用例，在一个结构化的状态迁移（SST）中，定义3种形式的循环：顺序，选择和重复 - 功能图生成测试用例步骤
1 生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成
测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径
2 测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。
3 测试用例的合成算法：采用条件构造树.
1.8 错误推测法
错误推测法是基于以往的经验和直觉，参照以往的软件系统出现的错误，推测程序中所有可能存在的各种缺陷和错误，从而有针对性地设计测试用例。错误推测法的基本思路是：列举出程序中所有可能的错误和容易发生错误的特殊情况，根据可能出现的错误情况选择测试用例。
例如：
1）单元测试中列出许多在模块中常见的错误、以前产品测试中曾经发现的错误等。
2）输入数据为0或字符为空。
3）各种情况在产品说明中常常被忽视，也可能被程序员遗忘，但是在实际使用中却经常发生。测试人员要站在用户的角度，考虑他们要输入的信息，而不管这些信息看起来是合法的输入还是非法的输入。
2. 2 测试用例组织结构
建议的用例组织方式为，以功能为拆分，通过大功能，小功能，功能点，树状向下分割，在功能点末端，展开相应的测试类型。
Paste_Image.png
Paste_Image.png
示例：
Paste_Image.png
2.1 Basic – 基本功能测试
即MRD到case的转译2.2 Boundary – 边界分析测试
在基本功能的基础上，开始考虑各种输入输出的影响。一般的，基本功能容易在边界附近出问题。主要采用等价类划分方法，边界值分析方法。用例组织上，可以梳理已经产出的基本功能草图，确定哪些部分存在边界问题。并构造测试用例，执行测试工作。• 边界类型数值大小 ，输入的数值的范围
• 字串长短，Null-max-max+1
• 内容有无
• 支持与否，（保留字符，特殊字符，计划外字符。
在此非常郑重的提示各位新同学，写测试用例时，很多都能考虑到边界值分析，但是一般都只是分析输入，而对于我们来说bug真正容易出现的地方是输出。这里是输出是广义的，任何被我们能获得的信息都是客户端的输出，比如字符超长，内容超长，图片超大等等。
Memory – 存储测试
主要测试涉及存储空间读写的部分。最大的问题还是memory leak。用例组织上，主要考虑哪些部分容易发生memory的问题。特别是移动客户端容易出现的问题：• 比如旋转屏幕—响应G sensor，画面需要重新载入，重新载入前的页面可能会发生内存无法释放的问题。移动客户端相对特有的。
• 连续加载页面
• 开多个窗口—比较典型的，如浏览器
• 应用多次的互相调用—应用之间的相互调用，调用传递之间，可能存在问题，另外要特别注意“重入”；所谓重入，是指一个应用A叫起了应用B，但是应用B又可以再次叫起应用A，如message编辑时插入图片可以叫起camera，拍摄之后，camera可以不直接返回message编辑器窗口，而是通过点击分享-message，重入message编辑器，由此产生循环的栈叠加，也容易发生内存问题。
• 多线程下载
Performance – 响应速度，资源占用
考虑方式参考memory的测试思路，注意在判断是否合格或者满足预期上，要参考竞品的表现• 相同移动客户端不同应用；在同一个移动客户端上，被测试应用和benchmark做比对，看选取的核心数据差异性
• 相同应用不同移动客户端；在不同的移动客户端上，被测试应用分别安装，检验被测试应用，在不同平台环境中的表现能力。
Stress – 压力测试
可以简单理解为，在基本功能上的提升负载，速度，吞吐量等性能指标。一般的，移动客户端通过monkey之类的测试工具加以覆盖，以及录制回放工具之类的测试来实现压力检验。Capability – 兼容性测试
移动客户端常见的兼容性测试测项• 网络兼容性测试（各种运行商，各种接入点）
• 平台兼容性测试 （如android，从cupcake到donut到éclair到froyo到gingerbread到honeycomb）
• 分辨率兼容性测试 （各种不同的分辨率）
其他可能会涉及移动客户端兼容性测试测项
• 操作系统兼容性测试 （如实现一个手机到pc的通信工具，则各种pc操作系统需要被检验其兼容性）
• 蓝牙设备兼容性测试 （如果是一款使用蓝牙的应用）
• 存储卡兼容性测试（比如文件管理器）
Interrupt – 中断功能测试
别的应用对当前应用的中断，体现应用的被动型Interaction – 交互功能测试
应用主动叫起其他的应用，体现应用的主动性，比如share via message，比如叫起camera，该部分详细的内容，如何开展交互和中断测试，将另行分享。3. 测试用例书写方法
测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。测试用例的可执行特点：在测试前提符合的情况下，依照测试步骤，每一个测试用例都能够顺利地使程序运行，同时呈现相应的期望结果。
测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
3.1 用例书写技巧
正如上面提到的用例的四个特点，书写测试用例目的执行测试，一方面我们要提高测试用例的全面性，另外一方面，我们要考虑测试用例的可读性，即，用例很容易的被其他执行人员所掌握，执行结果和书写人执行基本一致。举个例子，一个人A去找C同学，发现C同学不在，问B同学说：B同学，怎么不见C同学，
B同学头也不抬：C已经不在人shi了
A同学大呼：我是听说过他要离开人shi，没想到走的这么快
B：虽然他不方便上来找你，但是你可以下去找他呀
你看完这段对话的第一反应是什么，可能很多人的第一反应是，C同学已经撒手人寰了。事实不然，C同学之前和B同学都在楼上人事部工作，后来人事调动，C同学去了楼下行政部。A来找C的时候发现他已经走了，而C工作比较忙，没有时间上楼来见A。
作为测试用例的撰写，我们也要注意这些内容，避免想当然，避免条件的遗漏。特别是初始的条件。
用例撰写一个容易苦恼的地方就是路径可能过长，基于经验，我们一般建议单条case的步长不超过五步，功能点仅涵盖一个。
比如一个音乐播放器，进入文件管理器相关的功能，使文件为空，添加一个曲目，然后查看后续的功能。这三个步骤，但是这三个步骤，可以做拓展，怎么使文件为空，我们可以拔掉SD换一张空卡回来，我们可以格式化SD，我们可以通过文件管理器删除全部，我们可以通过播放器删除全部……，第二步如何添加一个曲目，我们可以通过播放器下载一个，可以通过浏览器下载一个，可以通过蓝牙传输一个，可以通过录音机这个应用录制一个……，第三步对存在但个曲目的操作，是播放，删除，修改，查看详情……，如果按照路径遍历，单纯这几个点，就可以拓展为4X4X4，64条用例。但是事实上，我们并不需要这么做，首先我们会分析依赖关系，对于前一步骤各类操作产生的结果对下一步骤的影响一致，则用例可以被切割，统一成前一类步骤的一个结果为后一步骤的初始条件。所以这个功能会被拆分为三组测试用例，大约十二个。让文件管理器变空的若干条测试用例，然后以文件管理器为空做前提，看接收文件的刷新显示，第三条查看仅有一个曲目时的基本功能。
3.2 如何实现从MRD到测试用例
下图给出的是按照MRD，我们分析需求—转换用例---评审用例—最终生成完整用例的一个过程，下图体现的主要是初稿的撰写流程，突出的是，QA-PM-RD之间在基于测试用例为主线的协作关系。下面我们将从MRD出发，以点连线，说明下测试用例的撰写过程。
通过前面一段的简单分析，我们在项目立项的时候，其实就应该明晰MRD对我们的作用，以及我们要做的功课有哪些，下面我们就这几个部分做一下阐述：
基本需求这里是指，明确的以viso，脑图，文字明确下来的需求。这个概念比较好理解，因为这些内容会相对直白的表达出来，对于这部分，我们需要做的是，以评审讨论的方式了解相关的需求是否正如你对字面的理解那样。因为文字的表达难免会有一定的局限性，每个人的理解都不一样。正如上图中需求分析的部分.
举例，下面是wenku android关于搜索功能的MRD需求
功能需求：
1.【在线】搜索范围是文库
2.【本地】搜索范围是已导入的本地书籍索引。
3.【本地搜索】默认界面，给出已有本地书籍索引
4. 本地搜索无结果时，提示在线搜索，点触立即切换至在线结果。
按照MRD，可以依照UI界面切分为大的功能块，然后在大功能块下再切分小功能块，最后到功能点，在功能点basic的部分，将图像化的，表格化的或者文字化的MRD需求分类逐条填充到basic内容。具体的方法，可以先构造脑图，然后脑图转化为组织构架图的模式，然后按照点逐条转换测试用例。
除了基本需求，我们还有读出MRD之外的隐含需求和扩展需求。
隐含需求指的是不明确写在MRD文档当中，但是作为某一款产品自身的需求，或者某些基本需求的视线，这部分内容必须实现。
对于隐含需求有两种可能，一种称之为约定俗成的需求，一种称之为支撑性的需求。
关于约定俗成的需求，对于某一款产品，必须存在的内容，比如描述做一款音乐播放器，对mp3 wma这样的解码支持虽然没有写在MRD需求文档中，但是你如果不支持这部分隐含未表述的需求，则你做出来的东西可能称不上是音乐播放器。
关于支撑性的需求，多是若实现a，则必须实现b，若b实现上存在问题，则a的功能不完整。有些时候a作为明确的需求写出，但是b不会。举个例子，比如播放器要支持蓝牙线控技术了，那么线控作为MMI的交互功能，在实现上需要更多的支撑，比如支持不同的蓝牙音视频控制协议，比如兼容不同的蓝牙线控设备。因为MRD更多的是面向市场的，所以另外还有一部分的扩展需求是在产品一级的，比如，在文件管理器为空的时候做操作，一般MRD都不会明确定义如何实现，但是需要我们将这部分作为需求转化为测试用例。
扩展需求体现的主要是一部分优化，更多的可能体现一个策略性的东西。比如输入法，针对错误的输入有一个识别过程，比如输入zhognguo可以自动识别成zhongguo，并显示为中国。对于这些模糊输入的逻辑实现，依赖于某个算法，而具体的算法可能是需要扩展的。
一般的需求拆分主要考虑两个方向，一个是宏观的，一个是微观的。
宏观的方式是基于功能块的拆分，按照一定的功能，将需求拆分成若干个大功能块，然后大功能块拆分成小功能块，再逐步柴扉为功能点。
微观的方式主要至考虑功能点的具体实现流程。
如baidu文库在线搜索：我们可以明确，在线搜索，搜索的文库web端的资源，从而我们可以分析出这部分的依赖内容，web端api接口，内容返回，网络连接本身，内容展示……逐点的分析才能确保我们测试用例的准确描述。
另外要借助MRD的评审会，了解具体的需求，从需求中理清楚功能。从源头上减少理解的偏差，才能后续的测试用例撰写减少遗漏。
3.3 如何确认覆盖度
确认覆盖度，首先是确认对需求检验的覆盖度，必要的流程是MRD评审和测试用例评审。通过MRD评审，QA可以充分了解PM对产品的需求以及主观上想要产品的功能，在评审过程中，QA应该提前阅读MRD文档，并在会上抛出自己的问题，以及人为描述遗漏的地方。之后QA进入测试用例撰写阶段，结合前面所述的，先将测试用例撰写为check list，checklist可以理解为测试用例的大纲，并发起测试用例评审，通过集体智慧确保在基本功能测试上，用例能确保全面性。在时间允许的条件下，请组内其他同仁review，特别是老鸟，避免绊倒他们的石头再把你绊倒。
3.4 如何创建测试用例
每个公司和团队都有自己测试用例设计的规范，这个就不说啥了。主要几个要求无外乎以下几点：用例描述（case名称）：简要的对用例的功能进行说明，也就是用例的标题
测试说明：简要说明运行该测试用例后能够达到的目的，这部分内容应来自MRD或者详细设计文档。
初始条件
测试步骤：详细描述该测试用例的执行步骤。
预期结果：按照测试步骤执行完毕后预期获得的结果，是判断测试用例运行成功或失败的准则
3.5 如何修改测试用例
测试用例的修改是必然的，一方面需求总会调整，这个尤其在维护过自动化测试用例的同学会深有体会。另外一方面，用例很难一次就撰写的很完美，需要我们持续的打磨。包括用例评审，需求的再次走查，ET发现的bug，用户反馈的特殊场景等等。这里需要提醒一句：一定要记得，被人给你提的一个意见，用户发现的一个bug都代表你一类型测试覆盖的不足，所以在补充测试用例时，要注意自己是那个方面有缺失和不足。3.6 如何确保描述准确性并提高可移植性
测试用例的撰写过程，类似写代码一样，我们如果每一个项目都从头写一遍，那花在测试用的时间上将非常长，也不利于我们较好的传承其他项目或者之前项目上总结提炼的内容。描述的准确性和用例的可移植性，这看上去其实是一对矛盾的话题。如果再加上测试用例的可执行性问题，那两个case的提升点将更缺乏支撑力。所以这个小结，仅作一个探讨。
关于提高描述的准确性，这个毋庸置疑，需要大家做到的是通过尽量少的描述，尽量快速的让阅读测试用例的人，把握该用例的为什么做，怎么做，做成什么样。但是描述的准确性，往往意味着在交互上，我们更加明确的点出来，如何执行一步一步的操作，但是在后续的应用上，实现类似的功能，也许有完全不同的交互方式。所以单一测试用例的描述准确性，必然降低可移植性。
所以，我们可以尝试，UI一级的测试用例和功能一级的测试用例分离。这会导致测试用例的增加，但是UI一级的测试用例，在多次往复的系统测试中，可以遍历一次后被搁置，在其他系统一级的测试用例保留。总的执行上，应该可以减少执行成本。而功能一级的测试用例，可以被我们做抽象，抽象后的用例，可以在项目的项目升级，或者不同项目的相似功能模块之间复用。
这里需要定义这两个概念，什么是功能级测试用例，什么时候UI一级测试用例。UI一级的测试用例，测试步骤上突出执行的步骤，如点某某按键到实现什么，检查点突出检查的是画面的展现以及页面之间的跳转。功能一级的测试用例，不突出形态，而是就某一项功能是否实现。
也许这里，我们可以借鉴两个概念类和多态。类这个概念，可以被理解成被我们抽象出来的功能模块，这些功能模块对于某一类产品，就特点上是固定的，多态可以被理解成是该功能的展现方式。
打个比方，播放模块可以被封装的功能有：播放-暂停-前一个-后一个-快进-快退-播放进度，这个“类”在被不同的音乐播放器上有不同的展销效果，比如有的播放器可以通过拖拽进度条实现快进快退，有的通过按键点击实现快进快退。
4. 测试用例和补充测试手段
如前文已经提到的，测试用例一定是无法一次性就写得很完整，即便是一只QA老鸟，即便经过了评审和认证，还是会有我们遗漏的问题。就如同积累了丰富的经验，我们仍旧无法预测地震一样。因为在产品实际做出来之前，我们的case撰写本身就是一个闭门造车的过程，即便已经很严密了，仍旧有很多实际问题我们是开始阶段无法想到的。
另外有一些问题，本身我们不可能完全转换为测试用例，因为一些具体的bug一旦描述被抽象后，很难表达给执行人。所以在测试过程中，需要使用一定的补充测试手段，用以补足测试覆盖。
4.1 ad hoc test
Ad hoc test主要在各轮bug验证以及系统测试的补充，在执行ad时主要要考虑三点：- 第一：更改了什么内容，可能引发什么side effect
- 第二：新增了什么内容，那些交互上容易出现水土不服
- 第三：执行测试时的新发现，比如测试执行中，你发现某些可能实现上有可能出现瓶颈的东东，为了防止的思维发飘，可以先记录下来，然后到系统测试结束后，执行ad hoc test。
4.2 User trail
用户体验，在功能大架子完成，基本上没有S0-S1的bug，S2的bug也趋向低水品后，可以发动内测，通过内测去发现更多的问题。内测的排期，通常在项目立项之时就会做好估计，此时QA需要约定好内测触发的版本条件。千万避免版本质量不够好，为了内测而内测，未解决的问题过多，那内测问题重复率将加倍放大，QA PM会在筛选bug上浪费时间，所以必须确保内测版本质量。与此同时也不必过于强求版本质量，而花费太多时间在版本稳定上，造成项目整体时间的不可控。一般建议S0-S1的bug应该是0，S2的bug修复率应该在95%以上，一般的vsm项目，到内测时的bug大约为150个，所以一般最后尚未解决的bug大致在5个左右。注意，此数据仅供参考。在实际执行中，需要灵活处理，合适的调整约束条件，比如有些S1crash的问题，被用户发现的概率非常低，可以降低其修复的优先级，可以暂时接受不修改。
内测阶段，可以通过创建内测群，内测邮件组等方式，第一时间关注内测问题，另外一方面积极关注PM手机的问题反馈，确认属于bug还是建议，bug的部分，那些是未发现的，那些是已经发现的；建议的部分，那些是合理的，合理的建议哪些是需要被采纳的。
在内测阶段，需要注意良好的沟通方式，内测的同学一般都不是专门的QA，书写描述可能不够仔细、翔实。需要沟通问题发生的硬件版本，软件版本，所处的各种相关环境，在一些特有条件下发生的问题，需要特别注意这些。
可以有目的的引导执行内测，覆盖一些我们不容易发现的问题。这可能算是一个比较高阶的问题，困难来自于两方面，如何驱动用户接受你的引导完成你需要的测试；第二个问题是，如何使用整理你需要协助完成的测试内容，无论是测试项还是反馈形式。
很多公司和团队内测完全是放任自由主义，任由自由之花尽情绽放，不过和自然界一样，果树想多长果实，打定摘心的诱导还是必须的。QA就是内测这棵自由之树将来打顶摘心的人。对，我说的是将来。因为展开内测首先以上的两个问题如何解决。第二个和交由新人第一次写测试用例一样，这个可以准备，但是不能苛求全面，在实践活动中，我们才可能充实起来。关键是第一个问题，如果引导内测用户和获得较大的反馈收益，这个具体可以参考后续topic--内测执行建议规范。
大致的流程为：PM收集用户的反馈，并由PM筛选将bug的部分转交给QA，建议和功能改善的部分由PM-UE发起讨论。QA拿到内测反馈的问题，先分析是否为bug，是bug的话是否已经提交，针对未提交的部分，我们需要积极和发现问题的用户做沟通，特别是就在我们周边的同时。分析用户发现这一问题的场景和复现步骤。对可疑拆分为系统测试的内容点，需要转为测试用例，并强化到测试用例集中。在此基础之上，转化步骤，可以参考ad hoc test的后转化动作。
4.3 Project Handover
项目交换，这里讲的不是将项目执行一段时间后，交换负责人，而是在项目的系统测试结束之后。通过半天的时间，由组内甚至组外其他同仁介入做一次ad hoc test。此方法的目的旨在减少个人思维的瓶颈，并利用交流机会，一方面减少测试点遗漏，另外一方面开拓思路。很多团队对测试项目的轮转 -- 这个还没有形成规范，建议在系统测试结束，整体提测试前。
Project handover会由同仁帮忙发现一些疏漏的问题，首先可以以点代面，了解别人的思路，并由此整理测试用例。在此基础之上，转化步骤，可以参考ad hoc test的后转化动作。
