论自动化测试报告的多样性

　　从开发的角度

　　单元测试不是开发的主要工作，开发的主要产出是功能代码，大多数开发并愿意写测试代码，因为它的直接产出价值是0。也就是说没有功能代码，写再多测试代码都是没用的。那为什么还写单元测试呢?单元测试可以让开发出错之后更容易被发现，不信你可以试着拿起纸和笔来写一段代码，出错的几率是很大的，那怕是写了十几年代码的老司机，IDE可以及时提示我们很多低级的代码错误。同样，人在面对一个足够复杂的系统时，想理清所有引用和调用关系也是很困难的，你很难确定你的代码改动的影响范围，假设有单元测试，它可以非常容易的帮我们发现代码是否正常的。所以，对于开发来讲，单元测试是自己贤内助，好不是好不重要，主要是能打理好的自己的小日子。日志足够了。

　　从测试的角度

　　测试的是为保证产品质量，这个角色就决定了它不会有直接产出。或者说测试的产出不好衡量。

　　如一个系统没有测出bug，有两种解释。

　　1、开发的质量很高，所以没有bug;并不是测试不行。

　　2、测试水平不行，所以没有测出bug;并不是开发质量高。

　　如果一个系统测出了许多bug，也会有两种解释。

　　1、开发质量很低，所以写了很多bug。并不是测试多厉害。

　　2、测试非常厉害，所以测试了很多bug。并不是开发质量很低。

　　如果一个系统很快就测完了，也会有两种解释。

　　1、测试能力很强，这么快就测完了。并不是测试不认真。

　　2、测试不认真，这么快就测完了。并不是测试能力强。

　　如果一个系统并未按规定时间测完成，也会有两种解释。

　　1、测试能力不行，所以，这么久都没有测完。并不是测试很认真。

　　2、测试很认真，软件质量问题太多，所以这么久都没有测完。并不是测试能力不行。

　　测试不像开发一样可以很轻松的通过单一维度(实现功能)去衡量工作。所以，测试需要大量额外的产出。

　　· 编写测试计划

　　· 编写测试用例

　　· 记录并统计bug数量

　　· 编写测试报告

　　...

　　从某种意义上讲，自动化测试没有报告就像你发现了许多bug却并没有记录下来，那和这个bug从来没出现过没有什么区别。

　　所以，自动化测试报告。

　　· 证明你做过测试

　　· 证明你更快的做过测试

　　· 证明你不仅更快的做了测试，而且还很漂亮。

　　以上内容为大家介绍了自动化测试报告的多样性，本文由多测师亲自撰写，希望对大家有所帮助。了解更多自动化测试相关知识：https://www.aichudan.com/xwzx/