不久前，参加Thoughtworks组织的一场自动化测试的分享，同事由于出差国外不能参加，特意嘱托我提问两个问题：
那么自动化测试最佳的实行时间是在什么时候？如何推行最有效的自动化测试？
以下谨代表个人观点：
个人整理了一些测试最佳实践并参考查阅了一些测试理论的书籍，又综合了个人工作经历的一些经验，总结了以下几点：
1、测试人员尽可能早的进入产品或项目的相关工作(这里指的产品或项目，指的都是从头开始的)，从产品的计划、需求调研、评审工作的开始测试人员就进行参与，这么做的目的有如下几点：a.让测试人员尽可能多的了解需求、了解业务，积极的提出问题，b.在下一步系统架构和接口设计之后，测试人员可以进行尽早设计系统的接口测试用例，c.还可以为下一步编码工作的单元测试做一个良好的铺垫，在后期设计单元测试用例的同时，懂代码的测试人员可以直接的检查开发人员的代码逻辑和业务逻辑是否符合要求，这也就实现了用最少成本“双人编程”。
2、综合一些实际情况考虑：根据一些实际调研，一般开发与测试的比例在1:6--1:10左右，能达到1:6的已经很不容易了，暂时不去讨论这个比例问题，因为这个需要根据项目的实际情况来看，个人看来：一些大型的互联网公司是不差钱的，所以他们会尽可能的在测试方面多投入或者说投入较高的，还有一些公司是不愿意在测试方面多投入但是又想多做测试的，还有一些就是尽可能少投入的，其实这些都可以调整，调整的依据是两个方面：一是确保公司对这个项目的重视和公司是真正的做测试，如果没有领导的支持，准确的说没有大领导的支持，测试工作是很难有效推进的，二是有效的安排测试人员，就是在项目的不同阶段安排不同测试人员，在测试不是很多是时候，可以使用半个人或者更少的测试人员，实现这一点的方法就是让一个测试人员去服务多个项目即可，当然这个多个也是有数量限制的，因为一个人的精力也是有限。
3、从第前2条提出来的一个疑问：作者一直提倡让测试人员尽可能早的接触产品和项目，这样能让测试人员充分了解项目，那么如何让一个人服务于多个测试项目？首先：明确一点，不是测试人员不从项目的开始就介入，测试人员就不能了解需求、不会测试。对于一个有经验的测试人员来说，快速的熟悉项目的需求并不是一件难事，如果说项目的各种逻辑真的是很复杂，项目经理也可以根据用户故事或者进行一些更为细致的安排来让这些协调过来的测试人员开展测试工作。一人服务于多个项目，这种事情在国内应该是屡见不鲜的。
4、如何安排人员也是一个如何花钱的问题：这种体会最深的就应该是外包公司，是先花钱还是后花钱还是超支还是项目失败，想必外包公司对这方面算的是最细的了。早期发现问题早解决问题，后面的压力就会小，不能早期的发现的问题，后面的团队压力就会像滚雪球一下越来越大。早期的测试投入看成一份成本的话，用这一份成本，来提早的发现问题的降低风险，后期才开始投入测试的话，也算是用一份成本，但是如果发现问题，开发人员就追踪、修改的成本是要远远大于初期的，项目的庞大和不稳定是让开发人员准确定位问题最大的困扰，还有测试人员做测试验证、回归测试、自动化脚本的修改这一切成本。
5、在项目的中后期如何做好自动化测试工作？在项目中期的时候，问题会逐渐积累，测试的东西也会越来越多，开发和维护的东西越来越多，维护是指测试人员测试出来的bug需要修复，但是又不能因为修复bug就停止项目开发工作。随着项目的推进，测试的效率保证是一个关键问题，这个时候自动化的推进和效率却成了一个矛盾的问题。原因有三：1.自动化代码需要编写和调试 2.自动化代码测试结果需要和手动测试结果进行比对 (自动化测试结果和手动测试结果不一致会有发生)3.自动化测试代码需要维护，尤其是在需求变更和设计变更的时候，手动测试只需要肉眼对比，而自动化测试可能会将代码进行较大改动。这三个问题大大降低了测试效率，这是手动测试必须成为项目的主导。解决这一问题的办法就是在项目测试集中的阶段调整手动和自动测试人员的比例，自动化人员测试的范围需要有一个合理的规划，必须定时的提交自动化测试代码，在手动测试完成后必须尽快的补充自动化测试代码，在完成测试工作的同时也自然的与手动测试的结果进行了比较，相当于进行了1次回归测试。也就说还是全部由手动测试人员进行第一轮全面覆盖的测试。
