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

lsekfe

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

从测试的角度
　　测试的是为保证产品质量，这个角色就决定了它不会有直接产出。或者说测试的产出不好衡量。
　　如一个系统没有测出bug，有两种解释。
　　1、开发的质量很高，所以没有bug；并不是测试不行。
　　2、测试水平不行，所以没有测出bug；并不是开发质量高。
　　如果一个系统测出了许多bug，也会有两种解释。
　　1、开发质量很低，所以写了很多bug。并不是测试多厉害。
　　2、测试非常厉害，所以测试了很多bug。并不是开发质量很低。
　　如果一个系统很快就测完了，也会有两种解释。
　　1、测试能力很强，这么快就测完了。并不是测试不认真。
　　2、测试不认真，这么快就测完了。并不是测试能力强。
　　如果一个系统并未按规定时间测完成，也会有两种解释。
　　1、测试能力不行，所以，这么久都没有测完。并不是测试很认真。
　　2、测试很认真，软件质量问题太多，所以这么久都没有测完。并不是测试能力不行。
　　测试不像开发一样可以很轻松的通过单一维度（实现功能）去衡量工作。所以，测试需要大量额外的产出。
　　· 编写测试计划
　　· 编写测试用例
　　· 记录并统计bug数量
　　· 编写测试报告
　　...
　　从某种意义上讲，自动化测试没有报告就像你发现了许多bug却并没有记录下来，那和这个bug从来没出现过没有什么区别。
　　所以，自动化测试报告。
　　· 证明你做过测试
　　· 证明你更快的做过测试
　　· 证明你不仅更快的做了测试，而且还很漂亮。
　　请欣赏以下三张报告。



我要告诉你，三张测试报告和面上显示的信息密度是一样的。从功能的角度上他们是一样的。
　　我还要告诉你，上面的日志是pytest单元测试框架生成的，下面的报告是基于unittest生成的，从框架的功能丰富度上来讲，unittest在pytest面前就是个弟弟。
　　“可是，我用 pytest + allure” allure可以让你更快的编写用例吗？可以让测试运行的更快吗？可以让测试更加稳定吗？发现问题更快速的定位吗？都不能，他只是好看。报告好看就说明自动化做的很厉害！

Miss_love

图三报告挺美观