加V:19841731,领 MTSC 大会历届 PPT

【原创】一块抹布引发的关于测试策略的思考

上一篇 / 下一篇  2018-09-07 17:34:50 / 个人分类:测试基础


其实,这篇文章最开始的标题是《如何用一个抹布一次清理完一个落满灰尘的工位》,读来读去觉得有点绕,写到最后也发现,哇,这个抹布好惨呀,就把标题改为《一块抹布引发的惨案》,又感觉有标题党的嫌疑,最终就确定了目前这个标题。
言归正传,不知道读到这的同学里面有没有杠精,做测试的话,我相信肯定有,不管怎样,我先解释一下,本次主要是讨论测试策略的话题,比如如何尽早发现严重程度比较高的 Bug,有人会说,这和抹布有什么关系?别着急,继续看。
我一直觉得,测试不只是单纯的技术输出型工种,有时候发挥好软技能,会起到事半功倍的效果。
就本次「如何用一个抹布一次清理完一个落满灰尘的工位」这个问题,我们可以想象下,落满灰尘的工位,肯定比较脏,除了桌面,还有电脑显示器、主机、柜子等需要清理。
如果一块抹布,我们拿来就上手,会发现桌子还没擦完,抹布就得洗洗啦,那么要想一次清理完,我们需要这个抹布可以多擦几次,那我们要如何才能让一个抹布可以尽量多擦几次呢?
经常做家务的(男)同学,这时候就比较有经验了,我可以正面擦一次,反面再擦一次呀!
对,所以前提是,不能拿来抹布随手就开始擦,而是先要平展开,规则的使用单面,这样至少可以用两次啦,但是两次也不一定够呀,怎么办?如何让只有两面的抹布出来多个有规则的面?
可能已经有人想到了,把抹布对折一下呗。
你看,折一次之后就是四个面,折两次就是八个面啦,一个抹布擦八次和擦一次,这反差效果还是挺大的吧。
咳咳,又有杠精来了:「理论上可以八次,实际上已经很脏了,越到后面效果越差呀。」
嗯,这是当然,所以除了折叠,我们还需要规划好擦拭的优先顺序,比如显示器这种不好擦又贵重的物品,可以优先擦,桌面就留到最后啦,这样虽然后面效果会差,但也是可以接受的啦。
好了,一个抹布我们说了这么多,感觉到惨了没?其实我主要想表达的还是,合理调整测试策略,可以让测试执行事半功倍。
看,抹布终于和测试扯上关系了哈,不过我们还是举个测试的例子再详细说明下吧。
比如有个项目,写了 100 条用例,现在大家要帮忙做第一轮覆盖的测试执行,常规来说只需要把用例从上到下、从前到后执行就行啦,但是呢,有可能出现跑到第 80 条用例时,突然发现一个 P1 的 Bug,然后一通捣鼓和定位,发现是技术架构的问题,如果修改,前面的所有付出全部白费,囧吧。
那基于前面抹布的惨案,我们可以想象一下,如果执行人员中有一个对测试策略有一定了解的人,那么他拿来用例的第一反应并不是立刻执行,而是先看看需求涉及的关键修改点,然后看看用例和需求的对应关系,并按照需求关键点的顺序把所有 P1 + P0 的用例重新做个排序,并按照这个顺序优先执行 P1 + P0 的重点用例,这样,或许就能第一时间发现这个潜在的 P1 级别 Bug 了。
当然这样的话,对执行人员的要求就比较高了,那我们再想象一下,如果主导该项目的项目负责人,在分配任务的时候,告知了哪部分功能的重要程度比较高,并且把所有用例按优先级顺序标注好,具体执行时也明确要求先执行优先级高的用例,只要执行人员能听明白,也同样可以尽早发现这个 P1 的 Bug。
那有同学说了,P1 级的用例,我们肯定都是优先执行的,这个例子不恰当呀,好吧,那 P2 的也可以这么来呀,当然,P2 的用例一般都比较多,那么策略还可以继续优化下,比如两个人执行的话,一个从上往下执行,一个从下往上执行,如果多个人的话,每个人可以划分出自己优先执行的范围,自己负责部分执行完了再去覆盖其他的部分。
总的原则就是,重要性高的用例优先覆盖,尽可能早的完成第一次的完整覆盖。
好了,这就是我早上清理工位时突然想到的,哈哈,脑洞是不是有点大?你觉得有道理不?欢迎留言讨论。



TAG:

引用 删除 Diane_   /   2021-05-22 10:40:03
5
 

评分:0

我来说两句

sylan215

sylan215

加V「19841731」,领 MTSC 大会历届 PPT。

日历

« 2024-03-23  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 109015
  • 日志数: 91
  • 图片数: 1
  • 建立时间: 2018-07-03
  • 更新时间: 2021-11-11

RSS订阅

Open Toolbar