9.1.4  性能测试的基本过程

　　典型的性能测试过程如图9-1所示。

图9-1  典型的性能测试过程

　　图9-1中的方框区域为可能多次进行的操作部分。

　　下面针对性能测试过程的每个部分进行详细的描述。当测试人员拿到“用户需求规格说明书”以后，文档中将会包含功能、性能以及其他方面的一些要求，性能测试人员最关心的内容就是性能测试相关部分的内容描述。

　　1．性能测试需求分析

　　性能测试的目的就是把客户的真正需求搞清楚，这是性能测试最关键的部分。很多客户对性能测试是不了解的，可能你会为客户提出的“我们需要对所有的功能进行性能测试”“系统用户登录响应时间短于3s”“系统支持10万级用户并发访问”等要求所困扰。不知道你是不是看出了上面几个要求存在的问题，下面让我们逐一分析一下这几句话。

　　每位用户都希望自己公司应用的系统有良好的性能。从客户的角度讲，肯定都希望所有的系统应用有好的系统性能表现，那么是不是所有的功能都要经过性能测试呢？答案当然是否定的，通常性能测试周期较长。首先，对全部功能模块都进行性能测试需要有非常长的时间。其次，根据80-20原则，系统用户经常使用的功能模块大概占系统整个功能模块数目的20%，像“参数设置”等功能模块仅需要在应用系统时由管理员进行一次性设置，因此针对这类设置进行性能测试是没有任何意义的。通常，性能测试是由客户提出需求，性能测试人员针对客户的需求进行系统和专业的分析后，提出相应的性能测试计划、解决方案、性能测试用例等，然后与用户共同分析确定最终的性能测试计划、解决方案、性能测试用例等。性能测试的最终测试内容通常会结合客户真实的应用场景，以及客户应用最多和使用最频繁的功能。所以，“对所有的功能进行性能测试”是不切实际、不科学的做法，性能测试人员必须清楚这一点。

　　·系统用户登录响应时间短于3s。

　　从表面看这句话似乎没有什么问题，仔细看看是不是看出点门道呢？其实这句话更像是一个功能测试的需求，因为它没有指明是在多少用户访问时系统的响应时间短于3s。性能测试人员必须清楚客户的真实需求，消除不明确的因素。

　　·系统支持10万级用户并发访问。

　　从表面看这句话似乎也没有什么问题。在进行性能测试时，系统的可扩展性是需要我们考虑的一个重要内容。例如，一个门户网站由于刚开始投入市场上，目前只有几百个用户，随着广告、推荐等措施的实施推动了系统宣传力度，你在进行系统性能测试的时候，需要对未来两三年内的系统应用用户有一个初步预期，以便在两三年后系统仍然能够提供给用户好的性能体验。但是，倘若对于该系统，日常每天只有几十个用户，在未来的5～10年内，也仅有几百个用户，这是不是需要进行10万级用户并发访问的性能测试呢？建议把这种情况向客户表达清楚，在满足当前和未来系统性能要求的前提下进行测试。这能够节省客户的投入，客户也会觉得你更加专业，真正从客户的角度出发，一定会取得更好的效果。如果系统用户量很大，应考虑到可扩展性需求，则需要进行10万级用户这种情况的性能测试。我们也需要搞清楚10万级用户的典型应用场景，以及不同操作的人员比例，这样的性能测试才会更有意义。

　　2．性能测试计划

　　性能测试计划是性能测试的重要过程。在对客户提出的需求认真分析后，性能测试管理人员需要编写的第一份文档就是性能测试计划。性能测试计划非常重要，在性能测试计划中，需要阐述产品、项目的背景，将前期需要的测试性能需求明确，并落实到文档中。指出性能测试可参考的一些文档，并将这些文档的作者、编写时间、获取途径逐一列出，形成一个表格。这些文档包括用户需求规格说明书、会议纪要（内部讨论、与客户讨论等最终确定的关于性能测试的内容）等与性能测试相关的需求内容文档。因为性能测试依赖于系统正式上线的软、硬件环境，所以测试计划还包括网络的拓扑结构、操作系统、应用服务器、数据库等软件的版本信息，以及数据库服务器、应用服务器等具体硬件配置，如CPU、内存、硬盘、网卡、网络环境等信息也应该进行描述。系统性能测试的环境要尽量和客户上线的环境条件相似，在软、硬件环境相差巨大的情况下，性能测试的结果与系统上线后的性能会有一定偏差，有时偏差甚至更大。为了能够得到需要的性能测试结果，性能测试人员需要认真评估在本次性能测试中应用哪个工具，该工具是否能够对需求中描述的相关指标进行监控，并得到相关的数据信息。性能测试的结果是否有良好的表现形式，并且可以方便地输出，项目组中的性能测试人员是否会使用该工具，工具是否简单易用等。当然，在条件允许的情况下，把复杂的性能测试交给第三方专业测试机构也是一个不错的选择。对于人力资源和进度的控制，需要性能测试管理人员认真考虑。很多失败的案例告诉我们，由于项目前期的研发周期过长，项目开发周期延长，为了保证系统能够按时发布，不得不缩短测试周期，甚至取消测试，这样的项目质量是得不到保证的，通常，其结果也必将以失败而告终。因此要合理安排测试时间和人员，监控并及时修改测试计划，使管理人员和项目组成员及时了解项目测试的情况，及时地修正在测试过程中遇到的问题。除了在计划中考虑上述问题，还应该考虑在性能测试过程中有可能会遇到的一些风险，并考虑如何去规避这些风险。在性能测试过程中，有可能会遇见一些将会发生的问题，为了保证后期在实施过程中有条不紊，应该考虑如何尽量避免这些风险的发生。当然，性能测试计划中还应该包括性能测试的准入、准出标准以及性能测试人员的职责等。一份好的性能测试计划为性能测试成功打下了坚实的基础。所以请读者认真分析测试需求，将不明确的内容搞清楚，制订出一份好的性能测试计划。然后，按照此计划执行。如果在执行过程中结果与预期不符，请及时修改计划，不要仅仅将计划作为一份文档，而要将之作为性能测试行动的指导性文件。

　　3．性能测试用例

　　客户的性能测试需求最终要体现在性能测试用例设计中，性能测试用例应结合用户应用系统的场景，设计出相应的性能测试用例，用例应能覆盖到测试需求。性能测试人员可能会遇到客户需求不明确，对客户应用业务不清楚等情况。这时，你就需要同公司内部负责需求、业务的专家和客户进行询问、讨论，把不明确的内容搞清楚。最重要的是明确用户期望的相关性能指标。在进行用例设计时，通常需要包括测试用例名称、测试用例标识、测试覆盖的需求（测试性能特性）、应用说明、（前置/假设）条件、用例间依赖、用例描述、关键技术、操作步骤、期望结果（明确的指标内容）、记录的实际运行结果等内容。当然，上面的内容可以依据需要适当进行裁减。

　　4．测试脚本编写

　　性能测试用例编写完成以后，接下来就需要结合用例的需求，进行测试脚本的编写了。

　　在编写测试脚本的时候，你还需要注意编码的规范和代码的编写质量问题。软件性能测试不是简单的录制与回放。作为一名优秀的性能测试人员，你可能经常需要自行编写脚本。这一方面需要你提高自己的编码水平，不要使你编写的脚本成为性能测试的瓶颈。很多测试人员由于不是程序员出身，对程序的理解不够深入，经常会发现申请的内存不释放、打开的文件不关闭等情况，却不知这些情况下会产生内存泄漏。因此我们要加强编程语言的学习，努力使自己成为一名优秀的“高级程序员”。另一方面，要加强编码的规范。测试团队少则几人，多则几十人、上百人，如果大家编写脚本的时候标新立异，脚本的可读性一定很差，加之IT行业的人员流动性很大，所以测试团队必须有一套标准的脚本编写规范。同时在多人修改维护同一个脚本的情况下，应该在脚本中记录修改历史。好的脚本不仅自己能看懂，别人也能看懂。

　　经常听到很多同事追悔莫及地说：“我的脚本哪儿去了？这次性能测试的内容和以前的一模一样啊！”“以前便写过类似脚本，可惜被我删掉了！”因为企业编写的软件在一定程度上有着类似的功能，所以脚本的复用情况会经常发生，历史脚本的维护同样是很重要的一项工作。建议将脚本纳入配置管理，配置管理工具有很多，Visual Source Safe、Firefly、PVCS、CVS、Havest等都是不错的。

　　5．测试场景设计

　　性能测试场景设计是以性能测试用例、测试脚本编写为基础的。脚本编写完成后，需要在脚本中进行一些处理，若需进行并发操作，则加入集合点；若要考查某一部分的业务处理响应时间，则需要插入事务；若要检查系统是否正确执行了相应功能，则要设置检查点；若要输入不同的业务数据，则需要进行参数化。测试场景设计的一个重要原则就是依据测试用例，把测试用例设计的场景展现出来。