欢迎访问自动发外链网站,大量seo自动发布外链工具与案例

黑盒测试体系建设 二 方法

作者:jcmp      发布时间:2021-04-20      浏览量:0
一、方法-测试方法是一切的基础在工作中看

一、方法-测试方法是一切的基础

在工作中看到过很多有趣的现象,比如很多测试岗的员工,其实并不能熟练应用测试方法,造成的后果就是漏bug,神奇的是项目经理每次问测试,得到的回答都是测完了,拿着一点办法没有,你又不能自己再测一遍,后面出现bug也不能嫩死他。有一份比较老的数据,表明“单元测试能找出10%到50%的漏洞,系统测试找出20%到60%的漏洞,剩下的40%要么通过技巧发现,要么最终被用户发现”,可见技巧是多么重要。这种水分比较高的测试,通常都无法提供有数据支持的测试覆盖率;再比如一些企业组建测试部门,先招人,再上缺陷管理工具,然后就开始搞事情,一段时间之后发现,项目质量并没有提高多少,反而进度和成本飙升,如果发生这种情况,多半是测试部门的建设跳过了从人到工具的中间几个阶段,包括方法,规范和流程,此时最好不要拖,认真分析当前到那个阶段了,再一步步做起来。

一座金字塔,下层不依赖上层,但是上层依赖下层。测试体系也是这样,没有测试人员对方法的应用作为基础,后面的规范,流程,工具都是空中楼阁。反过来,如果测试方法打得牢,规范流程工具并不是必须的,只不过到了那个阶段,团队自己就会去做规范找工具,这其实是一个自然而然的过程。

二、方法-等价类,边界值

三、方法-判定表,场景法,正交法

测试人员对方法不熟练,也体现在无法根据自己面对的情况,选择最合适的方法。碰到过很多次,对于多条件判断的情景,测试还是选择用等价类去设计,就造成他自己和别人面对一堆东西手足无措,很不清晰,执行和沟通都有很大问题。判定表在多条件的情况下是非常好的设计,沟通和表现形式。正交法适合多条件时使用。场景法适合在多事件流的情况下用。

四、方法-探索性测试

之前把探索性测试叫ET。项目后期的常规测试通常又累又无趣,常常一天要上QC跑200条case,而ET只用写8到10条就行了。所以每次到启动ET的时候,我跟孙银曼就赶紧承包下来,偶尔收工的时候我们会交换case看看,而我总能从他那学到一些东西。 讲解ET这是一篇比较好的文章 。

五、方法-关于case

首先,测试用例管理,是个很大的事情,投资回报率比较高,但是投资回收期却很长。跟需求工程里的需求跟踪很类似。我倾向于完善测试体系后,再回头处理case管理。

其次,在团队熟练应用测试方法的情况下,是否真的有必要写case,可能是个很有争议的问题。eStation的时候QC的用例库有几十万条case,而CMI的时候我们一条都没写过,这两段时期,质量并没有明显的差异。所以我看到的情况是写case跟产品质量并没有直接关联,最关键的问题还是在人和方法上。所以写不写case,还是看测试团队处于什么阶段,对方法掌握不熟练的时候,写case更多是在教和练,所以前面提到至关重要的第一个高级测试;测试体系后期,写case更多是在为case库做准备;其他阶段我觉得并没有太大必要写。即使要写,也尽量选择用户故事备注的方式,具体可以参考《用户故事与敏捷方法》。

最后,碰到过一些企业,对case采用审核的方式。这本身也是没问题的,有问题的关键就在审核团队,如果是测试写完case,然后拉开发,产品,项目经理一伙人审核,大部分情况都是浪费成本,测试用例的审核必须由高级测试做,这里也涉及到前面提到的至关重要的第一个高级测试。当时我们的QC有一个专门的平台管理团队,三四个人,我想他们就是干这个事的。

在这个阶段,一定不能着急,金字塔能搭多高,依赖于基础有多厚。

上一篇:黑盒测试体系建设一 | 人员

下一篇:黑盒测试体系建设三 | 规范