从开发的角度
单元测试不是开发的主要工作，开发的主要产出是功能代码，大多数开发并愿意写测试代码，因为它的直接产出价值是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可以让你更快的编写用例吗？可以让测试运行的更快吗？可以让测试更加稳定吗？发现问题更快速的定位吗？都不能，他只是好看。报告好看就说明自动化做的很厉害！
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
