点击“搜狗测试”可关注我们！
【前言】
(本文阅读时间约7分钟，忽略灰字删除线部分不影响阅读体验)
大头入行已经3个年头
自认也是一名测试老司机了
一直负责安卓端的项目做的也是手到擒来，如鱼得水
可这天大头竟然被一个用例整蒙圈了
【翻车现场】
“用例评审的会议室预定好了吗？”
“记得带笔记本电脑”
“这次用例评审别出岔子啊”
大头的领导阿导不放心的叮嘱了一番，对于大头的马虎阿导还是心有余悸。
“订好了！”
“没问题！”
“放心吧！”
大头对这次用例准备的还是很细心的，毕竟三年测试老司机
评审开始：
... ...
“shift大小写是按键弹泡功能的影响因素
所以，
用例1：设置shift为大写状态，点击按键“A”，检查按键“A”的弹泡为大写显示；
用例2：设置shift为小写状态，点击按键“A”，检查按键“A”的弹泡为小写显示；
没问题吧？”
大头唾沫横飞慷慨激昂的讲解着用例
“等等，
你的影响因素不全吧？
多次点击shift键的case是不是要补充上？
用例3：shift键多次点击，为大写状态后，点击按键“A”，检查按键“A”的弹泡为大写显示；
用例4：shift键多次点击，为小写状态后，点击按键“A”，检查按键“A”的弹泡为小写显示。”
同事小毛发出了疑问
“影响因素是shift键的状态，它只有大写和小写两种状态呀，所以只需要作为预置条件大写和小写两条用例就行了”
大头感觉自己没毛病。
“但是你怎么知道shift键功能正常呢？
万一测试人员漏测多次点击，实际上点击了多次后，shift键显示【大写状态】，但按键弹泡接收到的是【小写状态】，甚至按键弹泡接收到的是【null】？”
小毛连珠炮似的问了一通。
“作为一个测试人员，如果漏测肯定是自己的责任；如果按这个逻辑，只要相关联的功能，均需进行重复测试。
在此处，仅测试按键弹泡这一个功能，其他的影响因素均为确定项，大写状态就是大写状态，不能给一个不确定性的影响因素，”
“那么，假如shift键给了按键弹泡一个【null】也是一个case吧？bad case？”
“emmm...，好像有点道理”大头有点懵
“但是总觉得哪里不对”大头拍了拍脑门
“看来这个争议短时间无法解决，但现在时间宝贵，用例评审完咱们测试组小会期间再继续探讨，得出结论后公示全组”阿导及时出面暂时中断了争论。
这个车可谓翻的猝不及防，3年间用例从未做过增删改的(吹牛了奥)大头在众多产品和开发怀疑鼓励的目光下，完成了剩余的用例评审
... ...
【修车现场】
(以下为修车过程精简版...)
“首先确认的是shift的点击会影响弹泡中字母显示。所以在检查字母弹泡时，需要考虑几个场景：点击一次大写；点击一次小写；多次点击这几种场景下弹泡是不是正常显示。”小会上小毛首先理了一下浓密的黑发后才发表了自己的看法
“测试是有边界的，shift的功能是否有效不在测试范围内，shift如果出现null信号，概率大小姑且不论，至少不是我们关注的，不然shift失灵了，我们怎么处理呢，而且又怎么保证它失灵时是null，而不是undefined，或者其他信号呢”大头果断还击
“对，shift的功能是否有效是在检查shift功能的时候检查的，不需要在此关注。”阿导也进入了探讨，喝了一口八二年的雪碧后补充道：“但不要忽视小毛的说法，shift的点击会影响弹泡中字母显示。因为shift健多次点击后，可能会导致弹泡接受到的参数异常，弹泡显示错误，至于传参是什么我们不关注。嗝~”
“阿导，虽然你只比我帅上一点点，但是(虽然很爱听，还是要删除)我还是有个疑问”大头感觉抓到了问题的咽喉关键“shift键功能毕竟类似总控开关，离弹泡的ui变化，还隔了一层，是不是没必要考虑频繁切换的问题？”
“这个就需要把控测试力度了”阿导推了一把滑到下巴上的眼镜“这两个功能存在关联性，所以建议执行完原本用例后，简要确认下相关联的功能是否OK。不会出现你会上所说的‘只要相关联的功能，均需进行重复测试’的极端情况。还有什么疑问吗？嗝~”
“嗷嗷嗷，那么当前提为当两个功能之间互相有影响时，比如：功能1的结果会影响功能2
得出结论：
1.当检查点为功能1时，在各影响因素下，若只检查了功能1是否生效，
需要在检查功能2时，将以上各影响因素重新测试一遍
2.当检查点为功能1时，在各影响因素下，将相关联的功能1、功能2都测试到了，则不需要重复测试
原则：
1.测试不仅要保证各功能模块正常，也需要进行集成测试，保证各功能关联后的功能正确
2.测试用例编写是灵活多变的，当某个影响因素会影响多个检查点时，可同时进行测试。”
“好，其他人如果没有别的疑问，大头就发邮件公示结论吧！嗝~”大头对问题刨根问底的态度还是很让阿导欣慰的“这82年的雪碧就是给劲儿昂，嗝~”
THE END
375
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
