之前看了一些互联网公司的测试经验和技术介绍。最近又翻出来重新看了一遍,感触还是挺多的,可能也是由于工作时间长了后有了一些新的感悟。

主要有百度,腾讯,阿里下属的几个子公司,内容比较杂,有介绍测试经验和测试技术的,也有介绍自己的测试工具和自动化平台的。

总结了一下,主要优点体现在以下几个方面:

第一,尽早测试;
第二,尽可能深入,测试从最底层开始,逐步上升集成;
第三,尽量减少手工执行用例的工作量,大量使用自动化测试;
第四,各种测试工具的开发和应用;
第五,测试人员可以直接接触到线上系统和最终用户,这个渠道是畅通的。

第一点:尽早测试

这个是测试行业公认的准则,一个 BUG 发现的越早,修复的成本就越低(说到这里,我非常佩服《软件测试的艺术》这本书的作者们,这些大师们在上个世纪提出的思想现在依然适用)。

最快最省事的就是程序员在编码阶段中发现并修改的,这个在目前最主要的保证手段就是单元测试。

看了好几家公司的介绍,对单元测试都非常看重,甚至在淘宝网的文档中有一个表格,专门对代码质量从各个角度进行打分,其中单元测试的覆盖率就是一项很重要的指标。

另外在以前听一个讲座的时候也讲到,一个正确的测试体系应该是金字塔形状的,单元测试是最底层,同时占测试的比例也是最大的,大量的基本功能和编码错误应该在这个阶段就暴漏出来,而不是延迟到后端。

第二点:尽可能深入

测试从最底层开始,逐步上升集成。

这个其实和第一点有类似的地方,同样也是强调单元测试的价值和重要性。除此之外又强调把测试的工作和思想融入到整个开发过程中,这其实又包含了全功能研发团队的思想。

开发人员在编码时就开始考虑如何测试并进行测试,测试人员从单元测试开始,依次到白盒测试,模块级别的接口测试,系统级别的集成测试,场景级别的验收测试。

在每个级别有不同的测试策略和侧重点,越向上测试的角度越高,同时发现的问题也应该越少,如果到集成测试或者验收测试还发现有基本功能问题,那是应该好好分析下原因了。

我始终坚持一个观点:测试人员应该深入了解产品,深入到代码级别,只有这样才能够发现产品的潜在问题,或者说才有资格去和开发人员 PK。只是做黑盒测试,很多场景是考虑不到的,很多问题也是无法想到的。

这一点上和我们的领导有冲突,他们认为测试应该站的层次更高,视野更开阔。我只想说,我觉得我们现在欠缺的是基本功,阅读代码,分析代码,理解业务,先把这些能力培养起来再说,如果基本功能都保证不了,何来的高大上?

第三点:尽量减少手工执行用例的工作量

大量使用自动化测试

这些自动化测试框架有业界通用的如 jenkins,RF 等,也有自己开发的平台。目标和功能基本都是相同的,周期性的有持续集成的版本。

代码修改和提交后能够第一时间启动构建验证正确性,绝大部分的回归测试自动化执行。

甚至有篇文档中说验收测试是唯一需要手工执行用例的阶段,虽然我不太相信这样是否真的可行,不过也可以看出他们对自己产品质量和自动化测试能力的自信。

第四点:各种测试工具的开发和应用

我印象最深的有两个,一个是自己开发的持续集成,自动化执行用例并输出测试报告的平台,类似于 jenkins。

另一个是支付宝开发的外部支付系统的模拟器,为了模拟各种不同银行的支付场景,方便测试。这个模拟工具和我之前开发并且一直在用的模拟器比较像,都是被测产品和外部系统有强交互关系,而外部系统又无法控制。

所以自己开发工具来模拟这些外部系统,来方便构造各种真实环境中存在,但是研发过程中又很难产生的场景。

第五点:测试人员可以直接接触到线上系统和最终用户

这个渠道是畅通的。这个真的非常重要,像我们现在的产品,将来发布出去如何部署,用户的使用场景是什么,整个研发内部都是很模糊的,仅有的一些信息都要经过好几层中转,往往是已经用到现场出现问题了以后,这才知道用户原来是这么用的。

而像淘宝,他们的研发人员自己就是自己产品的用户,可以直接接触到线上系统,直接对线上系统的运行状态和日志进行分析,这样可以最真实的了解到产品的使用场景和最终用户的需求,更好的完善优化产品。

最后还有一点,测试人员的价值体现在什么地方呢?有一篇文档中说的很好,原话我记不太清了,大概意思是:测试人员的价值体现在发现设计和编码人员思维狭隘的地方,帮助他们修正这个期间产生的错误,提出自己的建议,还有提前识别可能的风险和问题,预防缺陷的产生。

从这个角度来讲,测试人员的工作不仅仅是发现 BUG,向后一步包括如何修改 BUG,向前一步包括如何预防 BUG。


↙↙↙阅读原文可查看相关链接,并与作者交流