从接触软件测试工作开始，相信所有人都希望减少软件测试后漏测的问题（tester希望，开发经理希望，老板希望），但事实是一直以来都没有很好的真正解决产品漏测的问题以及如何减少功能组合爆炸的问题。过去几年因为工作任务的缘故，我在历经几年自动化测试、系统测试和缺陷预防工作后，又回到测试的本源开始思考功能缺陷的测试应该如何做好？从2011年版本到2012年版本直到2013年终于优化完善出了自己的功能测试方法体系，没想到居然在软件测试行业从业近10年时才搞明白了10年前就开始的问题。过去的5年通过实践补充了自己在缺陷预防领域的技能和认知、可测试性设计领域的技能和认知、产品可靠性测试（稳定性测试）领域的技能和认知，直到2年前才开始真正介入功能测试方法改进。最后才意识到原来我们不少漏测的问题，不是性能测试可以发现的，也不是稳定性测试可以发现的，更不是自动化测试能发现的，现有的功能测试用例及方法也发现不了－－多功能组合下和不同用户操作序列下才发生的bug。怎么办？以及如何解决组合爆炸的问题－－我们一直都在回避。如何让我们投入测试时间最多的功能测试用例该多的地方多，该少的地方少？搞了半天，原来测试领域最基本的工作都没做好，然后就开始疯狂追踪上层建筑，或是简单实行拿来主义拿来一些工具或方法，虽然所拿来的这些工具或方法对局部的确是有优化作用，但你知道自己的全局全貌在哪里吗？知道全部漏测的测试根因在哪里吗（而不是产品技术根因）， 如果不知道则容易陷入盲目乐观与更加保守的状态。听说有个工具或方法能发现很多bug－－于是开始盲目乐观引入，希望能从此解决完所有测试漏测的问题，结果确实能发现一部分问题但是还是有不少漏测，结果－－开始更加保守，对新工具和新方法不再相信和信任，从此对漏测问题放在一边交给其他人去关心。那我就是那位被迫要去关心和解决漏测问题的非主流测试工程师，幸运的是经过过去几年的思考与学习，如今随着个人稳定性测试模型和功能测试模型方法体系的完善，终于让我有信心有知识去应对任何软件的漏测问题， 可以阶段性的结束对漏测问题领域的专注思考，投入更多精力于其他测试技术和方法体系了， 故写此文阶段性纪念下。下面分享一部分如何减少功能缺陷漏测的干货吧，与各位共勉：

　　功能缺陷的测试方法流程

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

　　目的：提取功能测试对象

　　准备功能测试数据

　　减少因为功能测试对象遗漏的漏测

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

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

　　测试方法：

　　● 基于生命期：对象创建 -使用- 销毁 的验证

　　● 数据测试方法：静态数据测试方法和动态数据测试方法 （边界值和数据等价类、7因子数据类型）

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

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

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

　　测试方法：

　　● 功能内子功能的场景插入法

　　● 重复法设计

　　● 反叛法设计

　　● 取消法设计

　　● 测一送一法设计

　　● 场景删除法设计

　　减少功能内代码的漏测