距离上一篇已经过去很长时间了，中间写了一些内容，但是忘了没有往这边贴。

　　过了一些时间，我碰到个机会，转去了系统测试部门，并且慢慢的成为一个组的leader。从那时候起就开始接触到了一些自动化和性能测试方面的内容。那时候的系统测试有很多时是去写一些接口代码。然后用这些接口代码去过用例，然后通过接口代码去做性能测试。其中也是有一些总结：

　　1.什么时候做自动化比较合适？

　　（续）关于自动化测试，在这个领域里面已经是老生常谈的一个问题了，很多人夸夸其谈自动化能带来生产效率的提升，能怎么怎么样。我不全面反对，但是也要看公司的发展阶段和项目的发展阶段。就我目前经历的而言，在一般项目里自动化其实相对来说成本是非常大的，因为需要的必备条件很多：1.我的测试团队得有设计自动化的能力 2.我需要人去编写新的自动化代码的同时，维护老的回归代码 3.需要和有人对整套自动化体系有比较深刻的认知和理解。4.产品或者项目已经到了一个稳定的阶段，在大的方面不会怎么改动。5.项目给予我比较宽裕的时间

　　综上所诉，当公司发展到一定规模，可以有一定资金和时间成本，且项目已经稳定到一定阶段或者正好碰到一些比较合适的项目再去做这个自动化效果是最好的。如果真的做成了对团队的提升，甚至对公司的技术层面的形象是很有帮助的。

　　不过换一种方式，我觉得可以两者兼备。在团队不大，项目不稳定的情况下，其实可以做单一几个点的自动化，仅仅是手工测试的补充和扩展。这样不成体系的自动化在前期带来的时间成本可能不会很高，但是后期一旦项目稳定下来。将几个点整个到一起，就可以作为一个完整的自动化测试体系了。我在很多个项目中都这样来做，要求测试工程师在重复工作的几个点，写成相对独立的测试代码。在锻炼工程师的代码能力和自信心的同时，为后期做整体回归做了一部分准备。后期等项目进入维护阶段，找几天时间整合这些分散的点，集成在Hudson中。后面的回归全部通过这个测试去做，外加一些手工的回归，这样后期回归的成本可以降低很多。

　　自动化也是不是全部，很多情况下自动化只能是一种补充，还是有很多东西要靠手工测试去做的。在我看来接口的测试，完全自动化还是比较可行的。一来它本来就需要编写一些测试代码去做测试，2来他不像页面甚至终端会出现一些复杂的操作，他仅仅是一些数据的输入和输出。

　　自动化测试团队的根本还是测试团队，目的还是保证项目和产品质量的。所以测试的知识逻辑还是最重要的，我宁愿要一个不会写代码的但是测试逻辑清晰的自动化工程师，也不愿意要一个代码能力强但完全没有测试概念的。其次还需要有自动化的一些基本的知识，包括如何去写一个有效的测试，一个可复用的测试，如何在研发代码提交后去集成测试，怎么样去维护这个测试，维护你的测试环境。除了这些之外，其他部门的支持，领导的支持当然也不能少。

　　关于性能测试，我这里就随便扯一扯吧。我个人虽然不想把性能测试，压力测试，负载测试这些分的很清楚，但是不得不说确实是因为目的不同做的不同内容的测试，不过有时候他们其实是类似的，是目的不同的相同类型的测试，所以暂且就允许我统一叫性能测试吧。性能测试肯定是在功能全部完成，系统已经趋于稳定的基础上做。性能测试的目的：1.确认产品是否达到了预期的性能要求，是否会有性能方面的bug，是否可优化2.确认在某个负载情况下，对硬件网络等的消耗情况，对后期生产环境的搭建和运维提供可用数据。3.系统能稳定承受的最大压力是多少，在该负载情况下，系统运行情况，是否可扩展来解决。

　　总的来说它的目的是为了运营和运维做数据支撑，和确认产品目标已经完成。所以要做这个类型测试前的准备也和这个相关：

　　1.确定产品的性能的指标性数据，一般产品说明书上都会确认这个数据，产品规模啊、日访问量 等等

　　2.在以上数据、应用特性、业务分布等多种数据基础上，建立测试模型。打个比方：某系统存在两种业务类型，一种登陆，第二种登陆后自动上传或者下载数据。产品要求日访问量在1000万，日吞吐数据500万。一般情况下移动互联网应用的日最高点击量是日均点击的3倍（像这种数据来源一个是靠业界的一些统计数据，另外一个来源可能来自运维团队的一些运维经验），也就是说我们系统性能指标是    1000W/3600*3 的登陆性能标，和同样的数据上传下载性能指标。 而压力测试和负载测试的时候也必须得考虑这些场景的混合场景。

　　3.了解未来生产环境的情况，如网络情况、机器硬件情况等。确保你做的测试更实际情况类似，提供的数据可参考。

　　4.完成以上工作后，才会做着手测试。不管用LR，Jmeter或者啥，只要能达到目的就可以。

　　5.发现问题去排查问题。找到瓶颈调优，提供数据和建议 从而完成测试。这个环节就要靠知识的积累了，很多同学第一次做性能测试，最后发现问题全部在基础的一些基础数据调优甚至压力机的问题上，所以出来的数据不可用。

　　整个过程最关键是在建立测试模型和排查解决问题的时候。

　　所以性能测试需要很多的专业知识，包括一些数据分析啊，产品业务剖析啊，系统和网络的知识，还得对系统架构啊，甚至某一项语言的特性等等有了解。性能测试经验丰富的工程师，甚至可以在产品设计之初就会发现设计中存在可能出现的性能问题。这些都靠积累了。

　　后来跳槽换了一家公司，因为之前公司的名声在外，所以那时候跳槽换个管理职位还是相对容易。我也一样很容易拿到一个测试主管的职位。从那时候起慢慢就开始不去做一些技术方面的东西，很多时间是在培养新人，带团队等等事情上。这个阶段我反而对一些最更本的东西感兴趣，不再去花很多时间去钻研技术方面的，更多的是把之前的东西完善巩固，然后在自己的部门里面实施，甚至更多是去思考员工的问题。