如何在智能告警平台CA触发测试告警
773
2022-11-12
软件测试之发现和解决bug
这个阶段的思路基本上尽可能发现更多的bug,见一个灭一个,来两个灭一双。发现bug,解决后验证bug,没有任何根源性的推动,或者推动的效果不好。
- 更高效的发现bug,考验测试设计的能力。
这方面有非常多的方法和技巧,以及经验,这里不细说。
- 发现bug之后如何清晰的描述,定级,以及跟进和验证。
这个看似简单,但是你会发现很多测试工作做了几年的人这样的基本功还是不够扎实。也可能没有受到过很好的训练或者一直没有人指导。
- 对业务和架构的理解能力。
没有这方面的能力,很难发现一些深层次的bug。而这样的能力对于快速学习和一些技术基础也有不低的要求。
- 发现bug之后如果举一反三的尽早发现更多类似的bug。
大家看到的很多经典的测试书籍讲的基本都是这个阶段做的事情,比如Software Testing,How We Test Software at Microsoft,以及探索性测试相关的书籍,都是专注在如何更高效的发现缺陷。
上面这些东西都是一个业务测试人员的基本功。看似简单,但是做好并不是一件容易的事情。也许这些事情一点都不cool,不sexy,甚至去做职级评审的时候不占优势,但是对于系统质量的提升,是切切实实带来很大帮助的,其工作的价值应该得到认可。但是如果一直停留在这个阶段,就陷入到上面例子中说的扫马路的阶段,因为如果没有其他方面的改变,每次都有那么多的bug。
不过很多时候,我们的测试停留在这个阶段也是因为现状,考虑下这样的情况:
- 开发基本不自测,甚至没有自测的环境,特别是涉及多个系统的对接。
- 提测后很多基本的功能都不能正常使用
- 项目管理比较混乱,但是最终的发布日期又被老大们定死,所以测试时间常常被压缩
而且,而且没有对于开发人员的质量方面的考核,那么很长一段时间,我们的测试将处于这个初级阶段。
(这也是该公司目前的一个现状啊)
我相信目前还有不少的团队是处于这样疲于应对的情况下,不只是小公司,可能一些大公司的部分项目也是如此。随着整个研发体系的发展和深入,我们应该有更高的追求。
发表评论
暂时没有评论,来抢沙发吧~