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