从2011年版本到2012年版本直到2013年终于优化完善出了自己的功能测试方法体系，没想到居然在软件测试行业从业近10年时才搞明白了10年前就开始的问题。过去的5年通过实践补充了自己在缺陷预防领域的技能和认知、可测试性设计领域的技能和认知、产品可靠性测试（稳定性测试）领域的技能和认知，直到2年前才开始真正介入功能测试方法改进。最后才意识到原来我们不少漏测的问题，不是性能测试可以发现的，也不是稳定性测试可以发现的，更不是自动化测试能发现的，现有的功能测试用例及方法也发现不了－－多功能组合下和不同用户操作序列下才发生的bug。怎么办？以及如何解决组合爆炸的问题－－我们一直都在回避。

如何让我们投入测试时间最多的功能测试用例该多的地方多，该少的地方少？搞了半天，原来测试领域最基本的工作都没做好，然后就开始疯狂追踪上层建筑，或是简单实行拿来主义拿来一些工具或方法，虽然所拿来的这些工具或方法对局部的确是有优化作用，但你知道自己的全局全貌在哪里吗？知道全部漏测的测试根因在哪里吗（而不是产品技术根因）， 如果不知道则容易陷入盲目乐观与更加保守的状态。听说有个工具或方法能发现很多bug－－于是开始盲目乐观引入，希望能从此解决完所有测试漏测的问题，结果确实能发现一部分问题但是还是有不少漏测，结果－－开始更加保守，对新工具和新方法不再相信和信任，从此对漏测问题放在一边交给其他人去关心。那我就是那位被迫要去关心和解决漏测问题的非主流测试工程师，幸运的是经过过去几年的思考与学习，如今随着个人稳定性测试模型和功能测试模型方法体系的完善，终于让我有信心有知识去应对任何软件的漏测问题， 可以阶段性的结束对漏测问题领域的专注思考，投入更多精力于其他测试技术和方法体系了， 故写此文阶段性纪念下。下面分享一部分如何减少功能缺陷漏测的干货吧，与各位共勉：

功能缺陷的测试方法流程

第一步： 功能测试分析 —功能测试阶段

目的：提取功能测试对象，准备功能测试数据， 减少因为功能测试对象遗漏的漏测。

第二步：功能验证—功能测试阶段

目的：检查功能是否已基本正确实现  。

测试方法：

• 基于生命期: 对象创建 -使用- 销毁 的验证
• 数据测试方法: 静态数据测试方法和动态数据测试方法 (边界值和数据等价类、7因子数据类型)

减少功能的基本逻辑错误漏测和数据处理错误的漏测

第三步：单功能内测试 —功能测试阶段

目的：发现功能是否存在分支情况、异常情况处理不足的缺陷。

测试方法 ：

• 功能内子功能的场景插入法
• 重复法设计
• 反叛法设计
• 取消法设计
• 测一送一法设计
• 场景删除法设计

减少功能内代码的漏测

第四步：多功能间组合测试 —系统测试阶段的用户场景测试

目的：发现功能间配合工作时存在的缺陷

测试方法：

• 基于用户场景的测试 (Scenario Test)

减少多功能间组合错误的漏测

为什么需要用户场景的测试模型?

• 补充多个功能组合的测试用例解决传统正交组合测试后3个及以上功能组合缺陷的漏测。
• 通过常见用户操作序列的场景设计解决数学式穷尽组合爆炸的问题减少组合测试时间和成本，获得最佳投入产出比的组合测试。
• 用户场景测试的测试步骤：是不同角色用户最常用的基本操作序列。
• 用户场景的探索测试：是不同角色用户非常用的操作序列。

用户场景的探索测试

在用户场景测试用例执行结束后 , 再用专项时间进行多功能组合的探索测试，补充用户场景测试用例之外的用户操作序列，提高用户操作序列的覆盖面。因为用户最常用的操作序列已在用户场景测试用例中覆盖，但又不能对非常规的操作序列不进行测试，   因此将非常规的操作序列的测试与测试成本进行一个平衡，通过专项的探索测试时间来补充这部分的测试。

在补充用户操作序列的探索测试中可用的探索测试方法有：

• 收藏家法：同时开启多个功能，同时工作。
  技术根因：同时多个功能交互容易出现资源竞争处理的错误。
• 地标法： 改变一系列规定顺序操作的先后顺序。（ A->B->C->D->E）改为 (A->D->C->B->E)。
  技术根因：在实际场景中用户因为对操作不熟悉难免会操作的步骤不是标准的步骤顺序，而程序实现时对于这些改变了操作顺序的操作步骤缺乏容错处理则会出现程序错误。
• 混票法：把最不常用的功能与常用功能进行组合。
  技术根因：在功能测试阶段由于时间及优先级限制，测试人员习惯把常用功能进行组合测试，时间一久就容易忘掉不常用功能与常用功能的组合，而用户的使用习惯中也一定会出现不常用功能与常用功能一起组合的场景

转载自：51testing