性能测试起始

乍眼一看，你可能觉得这是一个功能需求，怎么和性能有关系呢？但这个确实是性能问题，如果换乘的楼梯修建过窄，会导致大量乘客无法疏散出月台引起事故，而如果修建过宽又会带来不必要的浪费，合适的疏散能力就是性能的吞吐量指标。

　　可能有些朋友会说，我没去过上海，也没坐过地铁，如何知道这个性能是多少呢？确实，很多时候我们对用户所需要的系统闻所未闻，现在需要我们来做性能需求定义性能测试的目标不是无稽之谈么？那么按照这个道理来说，做性能需求分析的人都应该是业务专家，从某些角度来说需求分析本来就是需要业务或技术的专家才能担当，但并不是说没有简便入手的方法，对于这种情况，可以通过以下几个方法来获得系统的性能需求。

　　通过用户提供的数据进行分析

　　用户永远是需求的最后确认人，通过用户介绍和提供的相关数据是分析系统性能需求最直接也是最简便的方式。例如用户想要新建一个系统，来将公司的业务无纸化，那么他会提出相关的要求，例如容量、响应时间、并发量、服务器资源等。而作为实现方，当性能需求分析工程师将用户的需求进行整理后，需要参考以前的项目或相关信息去确定该需求是否合理可实施，进一步和用户协调制定合理有效的性能需求，以达到双赢的结果。

　　通过系统日志

　　当进行旧系统升级的时候，历史数据即系统日志的方式是获得真实用户需求最有效的参考数据。作为常用的Web服务器IIS或者Apache，当用户通过客户端发送请求到Web服务器的时候，IIS或者Apache都会在访问日志中记录下来。

　　……………………略

　　搭建测试环境

　　在编写脚本的同时，执行场景之前需要完成测试环境的搭建工作，这里包括硬件和软件环境的搭建。根据性能测试计划中的测试环境规划，完成对整个测试环境的搭建（请协调开发人员及系统管理员等相关角色帮忙完成环境搭建的工作）。

　　由于性能测试的特殊性，整个测试环境需要在严格的独立监控下管理，避免不受控的情况出现导致性能测试数据的偏差（类似于药品制造中的无菌室概念），而另一方面，在实际应用中很难得到真实的系统环境来完成性能测试。很多时候不可能在研发阶段就在公司搭建出和用户上线时完全相同的测试平台，那么得出来的数据就和真实数据有一定的差距，解决这个问题一般有以下两种解决方式（预估方式均有误差）：

　　1．通过建模的方式实现低端硬件对高端硬件的模拟

　　通过配置测试来计算不同配置下的硬件性能和系统处理能力的关系，从而推导出满足系统性能的真实配置情况，这种模拟需要精确的建模，模型的采样点越多，那么得到的结果越精确，从而将在低端配置下的性能指标通过该模型转化为高端配置下的最终预估性能指标。

　　……………………略

　　6.1.5  分析性能数据

　　当场景运行结束后，通过Analysis组件可以得到对应的性能测试报告，但是光靠这个报告并不能反映任何问题，还需要人为地对这些数据进行分析，便于进行瓶颈定位和下一步优化的参考。

　　性能调优原理

　　性能瓶颈定位和调优是一个复杂的过程，就好像改善春运状况一样，并不是简单地多修几条铁路、多开几部临客就能解决的。对于整个软件系统的性能来说，最终都能反映到单体用户的响应时间上，那么响应时间又是由哪些内容组成的呢？先思考一个问题：我每天早上坐交通工具上班要花费多少时间？这个时间的组成部分有哪些？如何调优？