不懂性能测试，被面试官挂了...( 二 )

可靠性/可恢复测试
可靠性测试或恢复测试用于验证应用程序在出现故障或异常行为后，是否能够恢复到正常状态，以及恢复阶段需要经过多长时间。
例如在某线交易站点出现故障，致使用户不能在一天的某个点(高峰时间)买卖股票，但在一两个小时后用户能够进行在线股票交易，我们就可以说该应用程序是可靠的，即有能力从异常行为中自行恢复。
性能测试流程
大部分测试工程师们在面对功能测试进展规划时游刃有余，而当被问起如何开展性能测试时，往往陷入沉默。
究其原因不外乎两点：

几乎无实战经验
缺乏对性能测试的整体认知

下面将为大家系统性地介绍性能测试规范化流程：
性能需求收集&分析
性能需求的收集与分析至关重要，这直接影响到后续的性能测试活动是否能有效开展。
对于有性能测试需求的项目，企业内部通常都会有专职的性能测试工程师，或者性能测试团队(即便人数不多，亦或是临时组建) 。
性能测试工程师直接或间接参与客户方针对系统/应用程序的性能需求调研会议，以识别和收集应用系统实现技术和业务方面的需求。
这包括获取有关应用程序的架构、技术和使用的数据库、目标用户、功能、应用程序使用情况、性能测试需求、硬件和软件需求等方面的信息。
性能测试工具选择
一旦确认了性能测试需求，接下来就到了性能测试工具选取的环节，如果之前没有类似的经验，企业也没有硬性规定必须使用的工具，那么在这个节点上，我们可以将可用工具逐一罗列。
分别从工具的成本、应用程序使用的协议、用于构建应用程序的技术、我们为测试而模拟的用户数量等等对可用工具列表进行筛选，选取一款合适当前项目情况的性能测试工具。
选定测试工具后，我们需要为关键业务创建脚本，并在 10-15 个虚拟用户中执行，这就是所谓的(POC—— Proof Of Concept ，这是在有限范畴内，对用户实时活动的一种演示) 。
性能测试计划&设计
根据第一个阶段收集的寻求信息，我们需要对性能测试进行整体计划和设计。测试计划旨在明确性能测试该如何进行，即性能测试环境、工作负载场景的设计、相关硬件配置等等。
这个阶段的输入是测试需求分析，输出是测试策略文档(包含了整个性能测试计划，设计) ，关于测试策略文档，在下文中将会以实例呈现。
性能测试用例研发
①基于 POC 的测试用例研发：根据上述测试计划中确定的测试范畴及核心业务功能，开始着手设计编写性能测试用例;这些初始的测试用例通常是在 POC 期间基于所选的性能测试工具来记录被测试业务的步骤。
②基于 POC 的测试用例评审：性能测试用例的评审最好能将客户代表纳入以获得他们的认可，确保被测业务每个步骤的准确性。
③测试用例优化：基于 POC 的测试用例一旦通过评审，我们就可以逐步优化测试用例，例如参数化，等待，集合点等的设置。
④环境同步：在创建优化性能测试用例脚本的同时，需要设置测试环境(软件和硬件) ，从而确保性能测试脚本在特定环境下执行(尽可能模拟真实的线上环境) 。
⑤真实用户 VS 虚拟用户：如果性能测试在真实的客户环境下执行，性能团队还需要考虑如何避免实时用户及虚拟用户同时在线的情况，一般而言这类情况可以选择避开实时用户大量在线且活跃度相当高的情况。
性能测试建模
为测试执行创建性能负载场景模型，该阶段主要目的是验证给定的性能指标(来自性能需求)在测试期间是否达到。
性能测试执行
在指定的场景下执行性能测试脚本，性能测试场景是根据上述负载模型设计的，测试执行通过虚拟用户数递增模式进行。