联系我：新浪微博@架构师Jack 或 dongjietest#163.com联系.(#换为@)

减少缺陷漏测的系统方法体系思考（10年经验的反思）

上一篇 / 下一篇  2013-03-22 10:05:45 / 个人分类：测试技术

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

/`7d8B Wra^Y0
   第二步：功能验证—功能测试阶段
            目的：检查功能是否已基本正确实现   
            测试方法 :
基于生命期: 对象创建 -使用- 销毁 的验证
数据测试方法: 静态数据测试方法和动态数据测试方法 (边界值和数据等价类、7因子数据类型)
            减少功能的基本逻辑错误漏测和数据处理错误的漏测

0lN1_0R4rwUv4u0
   第三步：单功能内测试 —功能测试阶段
            目的：发现功能是否存在分支情况、异常情况处理不足的缺陷
            测试方法 :
            功能内子功能的场景插入法
                         重复法设计
                         反叛法设计
                         取消法设计
                        测一送一法设计
                       场景删除法设计
            减少功能内代码的漏测
             
   第四步：多功能间组合测试 —系统测试阶段的用户场景测试
            目的：发现功能间配合工作时存在的缺陷
            测试方法
                基于用户场景的测试 (Scenario Test)
            减少多功能间组合错误的漏测

#_m,z.]2m,h&U0
为什么需要用户场景的测试模型?51Testing软件测试网hiW4azp9~(M"}
     补充多个功能组合的测试用例解决传统正交组合测试后3个及以上功能组合缺陷的漏测51Testing软件测试网$n.kA$R S6lul)[R
     通过常见用户操作序列的场景设计解决数学式穷尽组合爆炸的问题减少组合测试时间和成本，获得最佳投入产出比的组合测试51Testing软件测试网%}$eW9]o3e;i$?3{ ha

"c^c W7GW3mb0用户场景测试的测试步骤 是 不同角色用户最常用的基本操作序列51Testing软件测试网 I{/j:g5AD!]%K;b Q
用户场景的探索测试    是 不同角色用户非常用的操作序列51Testing软件测试网'J l~2jNOTEN
51Testing软件测试网L`m/a7~&oH5T
用户场景的探索测试
在用户场景测试用例执行结束后 , 再用专项时间进行多功能组合的探索测试，补充用户场景测试用例之外的用户操作序列，提高用户操作序列的覆盖面。因为用户最常用的操作序列已在用户场景测试用例中覆盖，但又不能对非常规的操作序列不进行测试，   因此将非常规的操作序列的测试与测试成本进行一个平衡，通过专项的探索测试时间来补充这部分的测试。

Q"Ut8Z,x0
在补充用户操作序列的探索测试中可用的探索测试方法有：
收藏家法
            同时开启多个功能，同时工作。
技术根因
           同时多个功能交互容易出现资源竞争处理的错误。
51Testing软件测试网 n G#f fI w!D
地标法
        改变一系列规定顺序操作的先后顺序。（ A->B->C->D->E）改为 (A->D->C->B->E)
技术根因
      在实际场景中用户因为对操作不熟悉难免会操作的步骤不是标准的步骤顺序，而程序实现时对于这些改变了操作顺序的操作步骤缺乏容错处理则会出现程序错误。

IT_/Xnd0
 混票法
       把最不常用的功能与常用功能进行组合
    技术根因
       在功能测试阶段由于时间及优先级限制，测试人员习惯把常用功能进行组合测试，时间一久就容易忘掉不常用功能与常用功能的组合，而用户的使用习惯中也一定会出现不常用功能与常用功能一起组合的场景

Et4p&c2C0
  
  

收藏 举报

TAG:

test_memory 引用 删除 51fangfang   /   2016-04-19 16:38:15
评 5 分
引用 删除 PPP777   /   2016-04-15 15:24:58
我这样的做功能测试做久了，看了jack的这篇文章特别有共鸣。
引用 删除 PPP777   /   2016-04-15 15:23:40
评 5 分
波波的个人空间 引用 删除 liubo1027   /   2016-04-11 16:01:52
标题很吸引人 但是越往后发现越没有干货了
chen111的个人空间 引用 删除 chen111   /   2016-03-25 09:40:57
评 3 分
突破totop 引用 删除 wycmjrg   /   2016-03-14 00:05:18
我觉得作者提出的方法非常好而且很有道理，但是我觉得这些技术，不同公司是否真正能实施起来重点还是要看领导的重视程度，还有就是项目的测试时间，如果测试时间不充分，基本功能点还没有全部测试完就赶着要先部署实施上线了，还有就是要看是否真正实施起来，因为我看作者写的很多方法在《软件测试实战》史亮老师的书籍里都有详细的说明到，理论性很强，操作性目前在大部分国内公司里实施起来还是有点困难的，还是得从实际出发，实践是检验真理的最好方法！
shmayyou的个人空间 引用 删除 shmayyou   /   2015-07-09 14:23:35
不好意思，点错了，给5分
shmayyou的个人空间 引用 删除 shmayyou   /   2015-07-09 14:22:56
评 1 分
Julymin719的个人空间 引用 删除 Julymin719   /   2015-07-03 14:42:27
都写得这么专业 感觉看完还是不明白说的什么
李老道 引用 删除 sterson   /   2015-06-23 09:55:32
其实总结的不错，我们就是按功能，业务，性能场景去覆盖的，从单一的功能点，到功能组合，到业务场景，到安全测试场景
jj_happy的个人空间 引用 删除 jj_happy   /   2015-06-03 14:29:45
评 5 分
whisky328的个人空间 引用 删除 whisky328   /   2015-05-21 14:21:19
评 5 分
sirme的个人空间 引用 删除 sirme   /   2015-03-09 14:11:27
不错，顶起来
sirme的个人空间 引用 删除 sirme   /   2015-03-09 14:11:08
评 5 分
zepengli的个人空间 引用 删除 zepengli   /   2015-02-11 22:46:42
评 5 分
zhangxd12的个人空间 引用 删除 zhangxd12   /   2014-06-04 10:35:14
不好意思刚才点错了
zhangxd12的个人空间 引用 删除 zhangxd12   /   2014-06-04 10:33:38
评 -5 分
引用 删除 uliyas   /   2014-04-23 10:07:43
第二个问题是，缺乏一些实例的讲解，很多测试方法“功能内子功能的场景插入法”等等，都不容易理解，略显空洞。
第二个问题是，写出了很多测试切入的角度，但没有如何减少冗余的方法，所以只有加法没有加法，就欠缺了实施性上的优势。
总体来讲还是有深度的思考来里面的，不错！
havards的个人空间 引用 删除 havards   /   2013-04-24 09:55:07
任何方法都要考虑实际应用，不知道博主实际是否用过，效果如何？
另外，实际测试的时候，时间都是个问题，如果把您说的都来一遍，我觉得时间来不及。
再者，漏测是黑盒测试的一个必然会出现的结果，因为不可能穷尽测试。

我觉得不用纠结于是否漏测，而是应该把更多的精力放在用户常用的功能，风险高的功能上，其他用户不常用的，风险低的功能只保证正向的就OK，当然这是时间有限的情况下，基于风险的测试永远是必要的。

如果真的要搞漏测的话，单元测试和集成测试才是最需要下功夫的，黑盒测试这种瞎猫碰死老鼠的方法性价比实在不高
xiaoshi_2011的个人空间 引用 删除 xiaoshi_2011   /   2013-03-28 13:21:03
评 5 分
 

评分：0

我来说两句

Open Toolbar