质量保障体系--测试设计

作为一个测试，最核心的工作是保障产品/服务的质量；不管是通过流程，手工测试，还是脚本工具，都是为最终目的服务的，我写这篇文章的最终目的，是为了测试设计能成为一个标准作业；测试一个产品/需求的标准链路如下：

大纲

• 收集信息
• 分析信息
• 测试设计
• 测试执行
• 归纳并标准化
  • 各单功能的标准件

收集信息

要保证充足的测试，仅仅依赖需求和设计文档是不够的；尤其是我们的需求往往是不够完善的；可参考的信息来源如下，其组织形式也体现了信息收集和提炼过程：

分析信息

分析信息是将收集到的信息，提炼、重组、输出成测试大纲的过程；快速信息提炼可用SFDIPOT方法；但一般还是会用MFQ方法来建立测试大纲；具体如下：

• SFDIPOT模型
  
• SFDIPOT实例
  
• MFQ模型：M指单功能、F指单功能间的交互、Q质量属性（非功能）
  
• MFQ实例
  
• MFQ中，Q质量属性，参考大纲
  
  以上模型，其实是信息组织方式；具体的分析策略如下，供参考：

  尽早尽快：问题发现的越早越好，信息获取的越快越好；
  获取的信息越多，信息源越多越好；
  疑问；收集疑问，解决疑问，很有价值，质疑一切；
  仔细阅读，关注关键字，多思考；
  寻找矛盾、漏洞和容易被误解的东西；
  除非式探索 —— 在你的产品、流程或者模型的任何你关心的表述后面加上 “除非……”。然后看看新增的部分引导你到了那些方面；
  要和业务结合，脱离实际是不行的；
  相关性判断 —— 你认为它重要吗？其他人认为这很重要吗？会变得重要吗？用户是否会对这个问题感到不安/恼火？
  假设问题；如果…怎么办？–就可能发生的事情或经验进行头脑风暴；
  横向思维 —— 人工分离，类比，寻找替代品，相反方面，随机刺激 — 任何有用的东西都可以做；
  关键点；——让自己暴露在你认为能产生好想法的信息/情境中；
  拉近拉远 —— 放大或缩小详细程度，并检查内容；
  图/立体信息组织；以重要的方式将不同的知识、细节和大局结合起来；什么值得仔细研究？让信息变的更立体，更容易理解；
  建模；利用测试方法分析，如等价类、因果图、流程等；得到实例；
  挖掘隐藏的信息；用户的隐藏需求。隐藏的问题等；
  多样性；从多个方面考虑问题；
  松弛式探索 —— “让你自己分心吧……因为你永远不知道你会发现什么……但是要定期根据任务来评估你的状态 “
  投入并退出 —— 从最困难的部分开始，看看会发生什么，想退出就退出；
  拉姆斯菲尔德式探索 —— 调查已知的未知，考虑未知的未知；
  不要停下来 —— 当你找到你要找的东西时，多想想看是否有更好的东西等着你；
  总是暂停 —— 分析（和设计）是一个连续的活动，是不是暂停一下；
  由他人完成–找出由他人执行的测试类型；您可以跳过或轻松覆盖它们（复用）；
  上下文分析 - 找出当前情况下哪些因素可以指导你的测试工作。
  测试框架 —— 将你的测试活动与你的测试任务联系起来，并了解更多信息（整体联系）；
  我做了什么假设 —— 解释你的测试活动，并提出质疑（质疑自己）；

  以上分析过程都是围绕着‘理解什么是重要的’展开的

  测试设计

  测试设计一定要基于上下文、基于风险，有的放矢的；常用的测试设计方法有（等价类/边界值/流程图/状态转换法/组合（因果图+判定表、正交实验法）/错误推导法）

等价类：输入数值，有多种类型时；分类取值，用局部代替整体实现覆盖；注意既要覆盖有效等价类，又要覆盖无效等价类；
边界值：常和等价类一起使用，取各类数据的边界值或极值，以覆盖极限情况；
流程图：画流程图覆盖业务的所有流程，通常要覆盖主要流程/次要流程/异常流程等；
状态转换法：列出需求的所有状态、并整理转换关系；以实现对所有状态关系的覆盖，如登录；状态转换和流程法的主要区别是，流程的链路方向是固定的，状态转换的方向是可逆的；
正交实验法：是一种在众多组合输入数据中，取样本的方法；以实现样本（均匀且全面）表示整体；具体操作制作‘混合’正交表。表的列为输入参数，列的值为参数值；行为执行次数，每一行为该次执行的参数组合；当参数不够时为空；
错误推导：根据收集/推测的可能错误，验证是否存在相关错误；（参考常见错误list）
因果图+判定表法：两种方法常一起使用，根据因果关系生成判定表；在根据判定表进行测试；因果图是这样的，利用输入的组合关系、多个输入及多输出各自的逻辑关系（常见的逻辑关系有等/非/或/与/异或/包含/排他等），来画因果图，并生成判定表；判定表的列即为测试用例,因果图法和判定表如下；

判定表

至于方法怎么使用，这需理解这些方法的价值；方法其实是一种套路，用来解决特定问题的；因此每种方法都有最适合的场景；重点是我们要明白场景的特征和方法的匹配关系；具体如下：
注意不同方法覆盖率计算特征不同，但总归都是覆盖率=覆盖场景/所有场景；这种覆盖率只是相对覆盖率

等价类+边界值（数据）：最适合的场景是，输入之间彼此独立，且输入可能有多种类型时，试用它；
流程图（流程）：场景是分步骤的流程时，考虑用流程法覆盖；
状态转换法（状态）:如果场景是包含多个状态，且状态直接能互相装换，那状态转换法就比流程法适用；
因果图+判定表（规则）：适用于多参数组合的场景，且参数间存在逻辑关系；先画因果图，在做判定表；
正交实验法（组合）：使用输入参数众多，但参数间相对独立，且需要组合输入的场景；

如何找到需求的特征呢：基于经验，通过收集到的信息；查找关键词、抓住核心功能、围绕既定目标、尝试其他特征的方式判断；注意一个场景，往往有多个特征，抓主干，同时在一个特征无法保障覆盖时，可以覆盖多个特征。

测试设计（建模），往往得到的是测试点，需要我们进一步把测试点具体成可执行的测试用例；在测试分析过程中可参考的经验如下：

所有的分析启发法都可以用作设计启发法；
信息要及时更新—— 尽可能的保持测试的规范细节为最新。事情都会发生变换，你会从最新的信息中了解更多；
各样的半度量方式 —— “与其完美地进行一两种测试，不如在相当好的水平上进行更多不同类型的测试。”
越快越好 —— 这样你就可以从产品中获得更多信息；
“把所有应该自动化的测试都实现自动化。”—至少完成一次测试后，你会更清楚这一点；
不玩花活：
  使用简单的测试也能达到目标；
  你不必使用花哨的测试技术，特别是在不需要的时候；
复杂度：
  复杂测试能够让你更有效率；
  在设计复杂的测试时不能太小心；
自由覆盖 —— 通过一次测试，就可以覆盖很多不同的内容。利用质量特征的持续性测试想法，将这些方法保留在你的意识深处，关注异常的发生；
适当的粒度 - 考虑测试的详细级别，以提高可评审性；
最具代表性–使用最常见、最容易出错、包罗万象、最重要的示例；
重要性原则 - 将大多数测试集中在主要目的上，但要寻找其他目的和可能的错误；
偶然性——如果测试能发现我们不知道的重要事情，那就更好了；
可以丢弃 —— 不要害怕丢弃你不再相信有相关性的测试；
实践出真知——试一下这个软件，你就会感觉到什么是重要的，什么是容易出错的，以及如何测试它；
直觉——“当你在思考难以预测的事情并且信息很少的时候，相信你的直觉。”
从软件测试中收获课程的五个例子 —— “在边界测试…测试每个错误消息…测试不同于程序员的配置…执行设置很烦人的测试…避免冗余测试。”
与信息目标保持一致—测试是否可以针对不同的信息目标进行调整？
良好的测试 —— 强大、有效、有价值、可信、可能、非冗余、激励、可执行、可维护、可重复、重要、易于评估、支持故障排除、适当复杂、负责任、性价比高、易于理解、能够实现偶然性；
改变策略——如果你的测试没有揭示新的、有趣的信息，那么是时候改变策略了；
用在别处？ —— 这个伟大的测试想法能否用与于领域的测试？
谁能做到？–你可能会包含你无法执行的测试想法。
多样性审查（结对）——如果审查者提供新的内容，请找一个想法更为不同的人。
未读测试设计 —— 如果开发人员没有阅读你的高等级的测试设计，请询问他们原因。
最喜欢的技巧 —— 你最好的测试设计技巧可能不是完美的匹配，但它可能会给你最好的结果；
任何与探索性测试、基于经验的测试或错误猜测相关的技能都是有用的；
元问题 —— 对于棘手的设计问题，您可以使用诸如 CIA Phoenix 清单之类的问题；

测试执行

测试执行阶段，也存在着信息获取；纠错的过程；当然获取信息-决策-反馈-优化是贯穿质量活动始终的； 在执行活动中关注的较多的‘覆盖’和‘用例有效性’的问题；判断的依据是‘风险（风险发生的概率/后果）’，虽然每种模型都有一定的覆盖率，但同时任何模型也无法保证100%的覆盖率(测试是一个混沌工程)，因此在执行时，我会尝试覆盖所有被认为重要的东西

覆盖率模型–广度/深度判断

覆盖率模型–执行价值

测试执行可参考的经验：

所有的分析启发式和设计启发式都可以用作执行启发式；
基本的启发 —— 如果它存在，我想测试它；
重要问题优先——先找出最重要的问题；
主干——如果方便的话，首先看看大的功能工作是否正常；
更宽泛的区分——如果 “这个” 可以或不可以，我们可以跳过 “那个”；
多信息源——使用比需求更复杂的 “文档”；
再做一件事——另外做一些容易出错的、大众的或者用户可能会做的事情。不要想太多，做点什么，看看会发生什么；
死亡蜜蜂启发 - 如果我改变了一个数据文件，发现我正在测试的应用程序不再发生崩溃，下一步我要做的就是再次改变它，这样我就可以再次看到崩溃；
隆隆作响——当产品做了奇怪的事情，一个大灾难可能会发生；
慢慢挪动——以一种刻意过度精细的方式做某事；
用户错误——研究无意（典型）错误；
行动方法——成为一个 “真正” 的用户；
二分法——当有奇怪的事情发生时，去掉 “一半”，直到找到必要的成分；
可翻转性启发——尝试从意外使用中获得价值；
基本配置矩阵——确定跨越 “边界” 的几个平台；
并发测试执行——同时运行多个测试想法以获得新的交互和想法；
似曾相识的启发式方法——当遇到错误消息时，多重复一次（如果不完全相同，代码是可疑的）；
看看很多地方——测试结果可以通过几个地方来解释；
其他地方是否存在问题——发现的问题是否存在于其他地方？
直觉 - “相信你的直觉。尝试任何感觉有希望的测试”
结对测试——协同测试执行激发新的更快的思考；
测试辅助——有工具可以立刻帮助我吗？
极性动态——在谨慎与快速、嬉戏与严肃、客观与主观等之间切换；
现在——“我现在能做的最好的测试是什么？
情绪——运用你的感官。
新视角发现失败——看看新的东西；让别人看看你的东西；
即兴表演
（不）确定性问题——总是有问题，但它们可能并不重要
我可能用错了启发——如果我发现许多问题，可能是我的模型是错误的；

快速测试 :

用一些快速的，并不总是有效果的测试来刺激你的执行（这些测试来自 Kaner/Bach 等.);
鞋子测试——找到一个输入字段，将光标移到它上，将鞋子放在键盘上，然后去吃午饭;
边界测试——测试边界值因为边界的错误编码是一个常见的错误。
Whittaker 攻击
  输入：强制错误消息、默认值、浏览数据、溢出缓冲区、查找交互、重复多次。
  输出：强制不同、无效、属性更改、屏幕刷新。探索存储的数据和计算。填充或损坏文件系统；无效/不可访问的文件。
干扰测试——取消、暂停、交换、中止、后退/下一步、竞争、删除、注销。
跟踪最近的变化——意外的副作用。
探索数据关系——利用依赖关系，跟踪数据，干扰，删除。
变化之旅——尽可能在各个维度上变化;
复杂度之旅——查找最复杂的功能和数据，创建复杂的文件。
示例数据之旅——尽可能使用任何示例数据。越复杂越好。
持续使用 - 测试时，不要重置系统。打开窗口和文件。让磁盘和内存使用量增加。你希望随着时间的推移，这个系统会自己打结。
调整 - 将某些参数设置为某个值，然后在以后的任何时间将该值重置为其他值，而不重置或重新创建包含的文档或数据结构。
Dog Pilling——一次运行更多进程；同时存在更多状态。
减弱——当系统处于适当的状态时开始使用一个函数，然后将状态部分更改为不适当的状态。
错误消息处理——使错误消息发生。重点测试错误被忽略后的情况。
点击狂热——测试不仅仅是 “敲击键盘”，但这句话并非空穴来风。试着敲击键盘。试着到处点击。
多个实例——同时运行应用程序的许多实例。打开相同的文件。
功能交互——发现各个功能交互或共享数据的位置。寻找任何相互依赖的关系。浏览他们。给他们压力。
便宜的工具！–了解如何使用 InCtrl5, Filemon, Regmon, AppVerifier, Perfmon, Task Manager, Threadhijacker, Zed Attack Proxy, Color Oracle（所有这些都是免费的）
资源匮乏——逐渐降低内存和其他资源，直到产品优雅得降级或不优雅得崩溃。
执行 “作者说”——查看联机帮助或用户手册，找到有关如何执行一些有趣活动的说明。做那些动作。然后即兴表演。
疯狂配置——在安装产品之前或之后以非标准或非默认方式修改 O/S 配置。
摸索——找到产品中产生大量数据或执行某些操作非常快的方面;

归纳并标准化

以上的过程，就是一个完整的‘测试过程’；其中每一步都是独立的，但都有其价值；无论如何，测试本质都是基于‘上下文’和‘风险’的活动；获取信息-分析-决策-反馈-优化，永远贯穿质量活动的始终，本节的目的是让较小的单功能/独立的功能，测试活动，能实现标准作业；这个想法的依据是由于，任何产品功能都是大同小异的，都是由相似的各个小功能组成的，本节考虑输出各小功能的checklist来实现标准作业

标准作业实例

• ‘大富翁游戏’

看到这是不是有种感觉，测试工作流程，越来越像工厂的流水线；这其实就是互联网的发展方向，未来估计行业的发展趋势也会和制造业趋同；不知是行业的幸运，还是个人的不幸！！！

探索性测试

在基于guide word（引导词）测试思维方面，引申到了探索性测试模型。以上的测试思维很大程度上借鉴了探索性测试模型，并落地，因此很有必须看下史亮介绍的探索性测试模型HTSM(启发式测试策略模型)

启发式测试策略模型