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