测试杂谈

 

测试作为软件开发领域的一种职业，由来以久，同开发一样她有着自身的很多工程方法与技术，同时有远见的软件公司一般都会有测试相关的技术岗位。随着当今软件复杂度的增加，软件可靠性要求的增长，测试工作显得越来越重要。本文就一些测试方面的技术、职业发展、前沿的一些技术作一些感性的探讨。

1. 关于测试一此可能被大家误会的地方。也许有别的文档探讨过相关的问题，这里说一下我的看法。

1. 测试应当发现所有的软件bug，否则就没有什么价质了。

细看起来这是一个伪命题，因为“所有的软件bug”这个定义就是一个比较难搞的东西。如果把软件bug一般地定义成软件实现与需求的差异。那么搞清“所有的软件bug”的首要条件是搞清某个软件的”所有”软件需求。对于软件需求，当瀑布模型大行其道的时候，我们还可以看到比较成体系（注意，不是比较全）的需求文档。当今特别是在互联网行业敏捷开发模式绝对统一天下的情况下，很多时候所谓需求只是一句话而已，甚至也许联一句话都没有。毕竟敏捷开发模式认为一切试图把所有的问题搞清楚了再行动的思维都不敏捷。“可以交付的工具胜过面面具到的文档”

测试的两大基本输入，除了前面说的” 明确而全面的软件需求”， 还有可能运行的测试输入件。 事实上后者也是模糊的。 一方面绝大部分情况下测试环境同软件真实发布环境是有差异、一些团队在测试过程中（特别是测试周期偏长的团队）在交付压力下在测试过程中刷新版本、软件结构本身的复杂性，特别是分布式微服务场景，环境对测试用例来说上一秒与下一秒之间环境就已经有了很在差异。 这些都是随手可数的被测对象的不确定性

所以，在这样的背景下，希望测试可以发现所有的bug，这明显不现实。可是问题来了，如果不能发现所有的bug，那么测试还有必要吗？ 相当有必要， 至少原因有2：

1. 测试工作的最大意义不是发现bug，而是评估软件质量。 也许软件的最终使用者是最有资格评价软件质量的，但是软件发布前，他们给不了评价，其实客户的评价不一定据有专业性，也许他们只会说”用着还可以”，“总是死机”，“点了没有反应”之类的。测试通过自己精心设计和执行用例，来发现软件bug，通过bug的数量、bug本身的范围和特性来给出软件的质量评价，当然也许不是准的，但却是唯一的。可能会有这样的意见，发现bug，修改了再发布就好了啊。什么质不质量的，没有关系。但是请思考这样一个问题， 假设一个软件其开发的代码行数为100k, 测试在该软件的测试过程中累计发现了200个bug。还是同样一个软件，测试只发现了20个bug。 这里先不讨论bug本身的质量，这两个软件的开发团队的开发能力就会得到体现，而作为团队管理者，前者应当回溯一下是否在开发过程有存在系统性问题。 这两个软件交付市场的表现可以预见也是不一的，后者一定会好一些。因为对软件而bug是有自己的收敛趋势的。200个bug的软件，修改后所遗漏的Bug, 一定会比20个bug的软件修改后遗漏的多。
2. 测试工作是整个开发团队的信心。当今的软件，特别是2B的软件，高额收入的同时，背后是软件失效时的巨额惩罚。开发和测试正常情况是分开的两个团队，测试的结论可以为决策者提供可靠的信息， 当然这些信息是决策者的信心。这一点很容易理解，比如，没有作过必要的可靠性测试，决策者就不能对外承诺多少个9的可靠性。否则这就不是在赚钱，而是在玩命。

 

1. 测试在为开发打工，打杂。

一般有这样看法的人的原因，主要是因为，很多时候时候测试要找开发澄清需求，划定测试范围。所以给人的映像是测试要测什么来自于开发。 事实上这样的理解是错误的，以这样的思路来设计和执行测试用例本身也会有问题。测试用例的依据是产品需求，因此测试需要找对产品需求最为了解的人来获取产品特性的知识，他可以是开发，可以是产品经理，可是以标准协议技术文档…  当然最为关键的时，为获取到的需求的正确理解和加工，这样才能输出有效的测试用例，简单地开发怎么说，我怎么测试，这是测试设计上偷工的表现。

然而可怜的是这样的偷工会产生两个不好的结果，一方面可能把某此开发对需求的错误理解延续下去，进而造成bug遗漏。另一方面也是在无意中丧失了测试工作的独立性，把自己变成开发的附庸。

要不要成为附庸，这个同职业本身好像并没有决定性的问题。打一个不太合理的比方，在古代很多大臣做得比皇帝还要牛，把皇帝玩于股掌之间。在现代，很多从事AI开发的未来的朝阳程序员却硬生生把自己搞成了python库的调用op。作为测试工程师，我们至少要保持自己的独立性，这是职业基本要求。

 

1. 测试没有技术，只是重复。

测试本身是有技术的，这从测试需要解决的问题就可以体现。当有一天，你要是觉得测试没有技术的时候，也许你可以想一下，我这里简单枚举的问题你是否都已经很好地解决了。测试要解决的很多问题都有这样的特性：其实你不解决也不会怎么样

1. 测试用例需要管理

这里要解决的关键问题是，如果想要测试某个特性，能快速地从上万个用例中把以之相关的用例挑选出来。进而快速继承执行。

不同版本间测试时标记用例覆盖度，执行率，通过率。

如何将用例进行分类分层， 以满足不同的测试需求。

所幸的是这部分知识同业务相关性并不大，因此有很多通用的工具，公司也有相应的平台来做这部分事，但问题是，你用起来了吗？做好用例管理其实并不是一件容易的事，用例如果很少，问题并不凸显，但是用例很多的时候，用例管理的重要性就会凸显出来。

1. 测试用例需要设计与维护

同开发的代码一样，测试用例需要设计，在产品特性变更时，用例也需要做相应的变更。从需求到用例，其中有很多的测试工程方法。

原始需求-》开发需求-》特性设计-》实现 

原始需求-》测试需求-》用例设计-》测试执行  这是有很大的可类比性的。其中最大的区别是对于开发过程中的东西，如果做得不好，会立即体现到交付的软件上。但是如果测试过程中的东西，如果做得不好，用例质量会有问题，直接表现是测试发现不了bug，或者bug的质量不高，可是要命的是测试的这些问题并不会直接影响产品发布，甚至会造成产品质量非常不错的假象。可是问题是，两个流程中的问题给产品带来的损失却是一样的。

遗憾的是当前很多测试人员已经淡漠了测试需求的概念，很多时间已经不做测试需求分析了。我这里所说的测试需求分析，未必要搞一个测试需求分析的文档，但是测试需求分析要解决的问题，是在做测试时一定要考虑的。

抽象一点说测试需求分析解决的是测什么的问题，而测试设计解决的是怎么测的问题。换而言之，我们在做测试需求分析的时候是考虑要测试怎么的问题，讲到这里你也许觉得这完全是废话了，要测什么，不就是按开发需求来做就可以了吗？  但事实并非如此，你需要特别是从测试类型，测试继承方面来考虑，从而得出需求中的特性要不要进行安全测试，性能测试，长稳测试等待，然后才是这些测试类型的详细用例设计

在明确了测什么以后，就是怎么测的问题了。这里要考虑的是如果用例甚至接口参数来覆盖测试点。

好的测试用例目的通常只明确为一个。用例间独立性较好，用例发现产品bug的比例高。相应的你所看到的坏的用例是同一个东西反复在测试，用例同质化成度严重，其中一个用例发现问题后，其它用例成了摆设。较差的用例设计，结果是较低的用例有效性，进而增加用例的维护成本。

 

1. 测试效率需要提升

很少有只发布一次的软件，敏捷迭代开发，要求进行快速回归，用例自动化是敏捷开发的必然要求。市场上关于测试自动化方面的书箱多如牛毛，原因是就很多人看来，这是最能体现测试价质与技术的地方。

但是测试自动化的本质其实就是测试开发，也就是要求测试人员开发出能够激励产品进行各种行为的控制脚本，同时也要能开发出能检测这些行为的检测脚本（或者工具）。要做好这两样活，都相当有技术难度。

 

d、测试环境需要管理

测试环境需要将被测对象进行发布，需要将环境独立开来分配给不同的测试人员使用。 这同生产环境的运维是有区别的。

要考虑隔离，恢复，导流等等。。。

 

e、专业测试场景需要模拟

性能测试需要工具将业务进行高并发模拟，

故障注入测试需要模拟软件系统或者硬件系统的各类故障，当前还要提供这些故障的恢复手段

在些产品组件需要mooc，以保证测试的覆盖度。