1. 性能测试的基本过程：

    性能测试需求分析 -> 性能测试计划 -> 性能测试用例 -> 测试脚本编写 -> 测试场景设计 -> 测试场景运行 -> 场景运行监控 -> 运行结果分析 -> 系统性能调优 -> 性能测试总结

    红色字体处可能会多次进行。



性能测试需求分析：

  1. 性能测试的目的就是把客户的真正需求搞清楚，这是性能测试最关键的过程。

  2. 根据80-20原则，通常系统用户经常使用的功能模块大概占用系统整个功能模块数目的20%。

  3. 性能测试通常耗时比较长。根据80-20原则，客户常用的系统应用只占20%，所以，对所有的功能进行测试是不切实际也是不科学的做法。

    通常，客户提出需求，性能测试人员对其进行系统和专业的分析后，提出测试计划、解决方案、性能测试用例等，并与客户共同确定最终的计划、方案、测试用例。最终的测试内容通常结合客户的真实应用场景，客户应用最多，使用最频繁的功能。

  4. 性能测试人员必须知道客户的真实需求，消除不明确的因素。

  5. 系统支持10万用户并发访问？ 面对客户的这个要求，需要问清楚，未来几年，系统是否真的有10万用户并发访问的可能。 如果不是，为了节省客户的投入，建议不必进行10万级用户并发访问测试。


性能测试计划：

  1. 在性能测试计划中，需要阐述产品、项目的背景，将前期的需要测试性能需求明确，并落实到文档中。

  2. 性能测试也是依赖于系统正式上线的软、硬件环境的，所以包括网络的拓扑结构、操作系统、应用服务器、数据库等软件的版本信息、数据库服务器、应用服务器等具体硬件配置，如CPU、内存、硬盘、网卡、网络环境等信息也应该进行描述。 测试环境要和客户上线的环境相似，这很重要。


性能测试用例：

  1. 性能测试用例 应该结合用户应用系统的场景，设计出相应的性能测试用例，用例应能覆盖到测试需求。

    当你对性能测试用例设计束手无策时，你需要考虑以下几个方面问题：

    (1) 是否更加关注于工具的使用，忽略了性能测试理论知识的补充。

    (2) 是否对客户应用该系统经常处理哪些业务不是很清楚。

    (3) 是否对应用系统的用户数不是很了解。

    (4) 是否没有性能测试人员可以交流。

    ... ...

  2. 用例设计，通常需要编写如下内容：测试用例名称、测试用例标识、测试覆盖的需求(测试性能特性)、应用说明、(前置/假设)条件、用例间依赖、用例描述、关键技术、操作步骤、期望结果(明确的指标内容)、记录实际运行结果等内容。


测试脚本编写：

  1. 协议的正确选择。 关系到脚本是否能够正确录制与执行。

  2. 测试脚本不仅可以使用性能测试工具来完成，还可以使用其他语言编程来完成同样的工作。

  3. 通常，在应用工具录制或者编写脚本完成以后，您还需要去除脚本不必要的冗余代码，对脚本进行完善，需要加入集合点、检查点、事务以及对一些数据进行参数化、关联等处理。

  4. 在编写测试脚本时，还需要注意编码的规范和代码的编写质量问题。

  5. 将脚本纳入到配置管理中。对以往使用和修改的脚本进行历史纪录。 配置管理工具有Visual Source Safe、Firefly、PVCS、CVS、Havest等。


测试场景设计：

  1. 在性能测试用例、测试脚本编写完成后，需要在脚本中进行如下处理：如果需要进行并发操作，则加入集合点；考察某一部分业务处理响应时间，则需要插入事务；为检查系统是否进行正确的执行相应功能而设置的检查点；输入不同的业务数据，则需要进行参数化。

  2. 把测试用例设计的场景展现出来。

  3. 性能测试工具有很多：开源性能测试工具(Jmeter,OpenSTA,DbMonster,TpTest)，免费性能测试工具(Microsoft Application Center Test, Microsoft Web Application Stress Tool)，商业性能测试工具(HP LoadRunner, IBM Rational performance Tester)。

  4. 性能测试工具都是用进程或线程来模拟多个虚拟用户。 用线程来模拟，因为不用重复加载同一驱动程序，所以内存消耗更少，每个生成器可以运行更多的Vuser。

  5. 场景设计，如果有执行次序依赖关系的脚本，则不能将顺序搞错了。

  6. 场景的相关设置项也是需要重点关注的。 比如应用了集合点，则需要点击Rendezous菜单项，进行集合点策略设置。



测试场景运行：

  1. 要保证负载的测试机能够跑设定的虚拟用户数。 如果不够，使用多台负载机分担负载。

  2. 在性能测试前，应该对应用服务器进行“预热”，即先运行一个应用服务器的功能。

    语言翻译成机器语言，计算机才能执行高级语言编写的程序。翻译有两种：编译和解释。

  3. 有条件的情况下，尽量模拟用户的真实环境。 保持测试环境的独立性。不要测试与研发同用一个环境。

  4. 同一个性能测试用例，在时间充足时，最好执行3次，然后分析结果。如果结果相近，才能说明此次测试成功。


测试运行监控：

  1. 测试运行监控，可以在场景运行时决定监控哪些数据，便于后期分析性能测试结果。

  2. 场景运行监控时需要注意以下几点：

    (1)性能测试负载机可能有多台，负载的时钟要保持一致，保证在监控过程中的数据是同步的。

  3. 测试运行监控，需要对监控的数据指标、测试工具很熟悉。


运行结果分析：

  1. 搜集相关性能测试数据，性能测试执行，这些数据会存储到数据表或其他文件中。 为了定位系统性能问题，我们需要分析这些系统性能测试结果。

  2. 目前，被广泛使用的性能分析方法就是“拐点分析”。


测试性能调优：

  1. 测试系统。 系统调优由易到难：硬件问题，网络问题，应用服务器、数据库等配置问题，源代码、数据库脚本问题，系统构架问题。


性能测试总结：

  1. 性能测试总结让我们了解到如下内容：性能测试需求覆盖情况，性能测试过程中出现的问题，我们又是如何去分析、调优、解决的，测试人员、进度控制与实际执行偏差，性能测试过程中遇到的各种风险是如何进行控制的，还可以描述经过该项目/产品的性能测试后有哪些经验和教训。

  2. 总结应该包括如下内容：

    (1) 阐述产品/项目的背景，明确前期的性能测试需求，并落实到文档中。

    (2) 指出性能测试可参考的一些文档。 并将这些文档的作者、编写时间、获取途径逐一列出，形成一个表格。这些文档包括：用户需求规格说明书，会议纪要等。

    (3)网络的拓扑结构、操作系统、应用服务器、数据库等软件的版本信息，数据库服务器、应用服务器等具体硬件配置(CPU、内存、硬盘、网卡等)，网络环境等信息。