在我们的工作中，为了提高测试效率或者做出测试团队的业绩来，都不得不做很多的自动化，当然这包括测试环境搭建，测试数据构造，测试执行，压力及安全测试等等，但是在各个阶段中，应该怎么样做好自动化满足我们的业务发展需要呢？今天主要谈谈单元和集成测试。
自动化投入产出比
一个被简化的公式:
自动化的收益 = 迭代次数 * 全手动执行成本 – 首次自动化成本 – 维护次数 * 维护成本
或者如果假设迭代次数和维护次数近视相等，这个在某些情况下可以成立，比如一个比较新的产品：
自动化的收益 = 迭代次数 * (全手动执行成本 – 维护成本) – 首次自动化成本
对此公式,我们可以解读一下:
自动化的收益与迭代次数成正比;
自动化收益可能为负,即维护成本和首次自动化成本比全手工执行成本还高的时候;
很多时候首次自动化成本并不比手工测试成本高,但是维护成本很高.
实际上,这个公式的确被简化了,原因是只是关注了其付出的时间,忽略了带来的效果,比如给项目周期缩短上带来的成效,对于质量保障的成效等等,对于项目周期上的评判则可以用以下公式:
缩短周期=手工测试时间-自动化测试时间
而且该周期都是针对同一个已经被自动化的模块评估的.
此外,很多时候我们关注自动化对于质量的贡献时,都是关注其发现了多少个bug,实际上自动化并不能帮我们发现更多的bug,都只是在原先预先设定好的程序上重复执行,所以根本不可能做到100%的自动化,测试人员的经验，逻辑判断和探索性的测试方法都不能被有效自动化.
什么样的项目适合做自动化?
通过上面的公式也可以看出:
一个快速发展,变更频繁的项目不适合做过多的自动化,而处于后期维护阶段,自动化收益会更高;
对于接口类的产品;
手工测试非常费时费力,甚至无法达到测试目的的项目,比如对于大数据量大并发下的压力测试等.
什么时候介入?
如果对于早期,开发设计还未稳定,界面还会经常变化,接口还未明确的情况下,是不适合做自动化的,即使做了,也会频繁的修改,这个时候手工测试可能效率更高,能快速发现问题反馈给开发人员.而如果有了稳定的界面,明确的接口设计,明确的数据结构之后,自动化再介入可以自动化收益.
今天我们重点介绍一下单元测试,集成测试部分.
谁来写单元测试
在一个软件工程团队里,的确没有必要明确到底应该谁来写,比较好的做法是依据团队人员配置而定.单元测试普遍采用白盒测试的方法，离不开深入理解被测对象的代码，同时还需要构造驱动模块、桩函数，因此开展单元测试需要较好的开发知识。从人员的知识结构、对代码的熟悉程度考虑，开发人员具有一定的优势,其最大的优点是快速，且能更好的实现。
但是从单元测试效果的角度考虑，保证测试组参与单元测试也有其优势，这是因为：
首先，从目前国内企业普遍现状来看，测试人员质量意识要高于开发人员，测试人员参与单元测试能够提高测试质量。
其次，对被测系统越了解，测试才有可能越深入，测试人员参与单元测试，将使得测试人员能够从代码级熟悉被测系统，这对测试组后期集成测试和系统测试活动非常有帮助，可以很快速的评估影响范围,进而可以非常准确的制定回归测试策略,而不用满盘回归.
测试组以何种方式参与单元测试，应该结合人员配置情况来定。如果软件组织测试资源充分，测试人员对开发人员的比例较高，那么可以由测试人员独立承担部分重要模块的单元测试工作,比如微软这样的公司,开发测试比1:1,那么测试人员就需要进行较为充分的单元测试;如果测试资源不足，测试人员对开发人员的比例较低，那么单元测试的实现和执行由开发人员来完成,但测试组至少应该参与开发组的各相关设计文档评审，以及code review保证质量。
单元测试的现状
可以把这种现状结合业务情况来看分为两种：
1）在业务快速发展迭代频繁的团队，追求高覆盖的单元测试是一件奢侈而且不可取的事情，毕竟把单元测试做好的话可能需要写比开发代码还要多的测试代码，这就需要持续的投入，包括人力和时间上，这也就是为什么微软有那么多测试同学的原因，对于传统软件而言可能值得这样的投入，也就是软件测试工程中的正三角模型。
2）而互联网时代，短平快是赢得市场的重要理念，为了获得快速的迭代，大家都没有过度的追求单元测试的覆盖率，但是我了解到在百度一些产品线，迭代并不频繁的项目，还是有强制要求对单元测试的覆盖率的，不达到标准是需要打回给开发继续完善单测的，但是我们大多数公司要么是开发一点都不做或者做的不够好，我想这是目前的窘况，这也给我们测试工作量带来了很大的压力，经常会为了项目按期上线加班加点做回归。同时，也有些公司在区分单元测试和集成测试策略和范围时就比较模糊，本应该单元测试解决的放到集成测试了，甚至是单元测试就按照集成测试的思路来做的，包含了很多业务很细的case，那么就成立下面这种情况，而且更多的就是这样的现状:
单元和集成测试并行开展
单元测试更侧重于逻辑代码片段，粒度更细，可能不同的开发人员各自写自己那部分的方法，自己做方法的单元测试，若需要调用别人代码或被调用时，就自己写桩或者驱动函数，把对应的内容mock掉。单元测试不应该关注上层侧重业务的case，也就是说每个user story应该只有少量的case用来做集成测试，把更细粒度的case应该放到单元测试中去做，这样可以避免单元测试和集成测试的重复性工作，为了达到这样很好的组合，就需要开发与测试同学密切配合，提前设计好产品并有文档化的设计资料。如果单元测试和集成测试能很好的区分并且履行好各自职责的话，这对于产品的质量一定能带来非常积极的作用。
那问题来了：
1）这样会不会延长项目周期呢？
在前期，框架不完善，大家对项目都不熟悉的情况下，要想做起来，必然会增加一定工期的，但是在各方面都比较成熟之后，特别是自动化case达到一定量之后，就会缩短项目工期。
2）如果单元测试开展的不够好怎么办？
我想，在目前大多数互联网公司，甚少有把单元测试做的好的，并且迫于较低的测试开发比，测试人员根本没有精力来做单元测试，那在这种情况下，测试人员要想进一步保证代码质量的话，就只有通过设计评审，静态代码扫描和code reivew来保证方法的质量，而测试人员可以把精力放到集成测试或接口测试上,只不过这个时候集成测试就需要把更多更细的case包含进去。
面对现实，随机应变
最后我们不得不无奈的面对现实，如果真的没办法实现正三角形模型的测试架构的话，也不用过于学术化非要按照模型来做，但我们也要竭力避免让系统测试成为我们最大的工作量和包袱。应Google的一句话，大意是当软件产品没有bug的时候，说明它发布的晚了。这也指我们对于产品质量所做的一定妥协，为了业务快速往前，我们何不因此而变呢？
