写了第一篇关于软件测试的文章,觉得还是有读者的,让我觉得特别欣慰。
我自己对软件测试的了解不算深入,文章也很入门级,起初的感觉最好的是写测试用例(TestCase),特别是使用mindmanager+excel,写出感觉的时候那真是分分钟的事儿。不过写出用例后问题来了,用例执行时间与用例数量基本是成正比的,往往执行用例会很耗时,那时就要开始合理的删减用例了。
整理用例常用的方法无非是什么等价类、边界值、因果图、判定表、正交法等常用的,究其根本,是通过一些逻辑推理的方式将相同路径的用例合并,从而达到事半功倍的效果。不过这里有坑,因为写用例时,大部分测试人员基本不了解开发实现的过程,这也会导致看上去可以合并的用例背后逻辑有所区别,从而引发漏测。而一旦漏测的点属于关键路径,触发几率高,那么产生的线上问题足够整个团队喝上一壶了。另一方面,如果项目前期测试与团队的沟通不足,很有可能出现推卸责任的问题,虽然从职业素养上不提倡,但关系到个人或小组利益时,往往不得已而为之。
以上的内容有点暗黑,但是并非不存在。
自己接触软件测试的理由比较“单纯”,开发能力不行,代码勉强读懂,毕业时看着软件工程的一些理论知识,眼前一亮——“就是他了!!!”
现在再观察一下国内的软件企业,对于80%的企业软件测试岗位更像个鸡肋。没有的话觉得特别low,产品质量怎么保证呢?说产品高质量自己都心虚啊。但有了又能怎样?所有的测试平台、测试流程都要自行搭建,没几个资深的测试架构人员还真搞不定。那这测试岗位搞不搞呢?个人认为大公司得搞,而且得结合自身条件狠狠搞,几十人的小团队就值得考虑了,产品质量是不是重点,流程未规范的时候,专门招聘测试的成本可不低。
对于谈论很多的开发测试比,实际使用时却有点上纲上线了。对于具体的数值,没有定论,也别觉得1:1就是好6:1就是差。这与开发测试的能力息息相关,一个牛逼的白盒测试工程师也许能抵10个普通的黑盒测试工程师,这也是为何开发转测试so easy的原因。通过接口测功能也许只要10个用例,但是被添加了上层逻辑之后,也许就需要100个用例。每个测试都向往着google的开发测试比1:1,却不知测试工程师的能力比开发工程师还要出众。
对于企业来说,普通的测试工程师的数量怎么都觉得多;对于普通的测试工程师来说,数量怎么都觉得不够。没有对错,所站的角度不一样而已。
网友评论
当我去确认测试结果时,看到的测试软件都不怎么好用,我也在知乎上提问有没有什么好用的测试产品?ps:曾用过HP QC,禅道,TD,JIRA等,这在国内是不是很缺?亲可以做个介绍文章!