《应用程序性能测试的艺术》第三章 有效性能测试的基础 摘录

项目开始之前需要思考的问题：

1. 开发的应用在发布的时候需要支持多少终端用户？6个月以后呢，12个月，2年以后呢？
2. 应用用户的地理分布是怎样的，他们将通过何种方式连接应用？
3. 预期应用发布的时候会有多少并发用户？6个月以后呢， 12个月，2年以后呢？

上面这几个问题引出更多的问题（两个重要的应用的属性：容量和可扩展性）：

• 每个应用层需要什么配置的机器？
• 这些机器物理上应该如何分布?
• 这些机器需要怎样的网络基础设施支持？

有效地开展性能测试要考虑的因素：

项目计划：

1. 确保应用在性能测试之前足够稳定。这一点特别认同，必须保证应用是正常工作的，正确的，也就是应用的功能已经是通过了Acceptance Critieria验证。常见的问题隐藏点：重度数据传输，性能糟糕的SQL，频繁的网络交互，未检测的应用错误。
2. 为性能测试留出充足的时间。时间因素：准备测试环境，梳理用例和编写脚本，梳理和准备测试数据，解决突发问题（个人认为这是最重要的一点，测试时我们一定要考虑到测试如果发现了问题，修复所花的时间）
3. 在适当的时候冻结代码变更。个人认为在做性能测试的时候应用这一阶段的开发应该是已经完成，单元测试和自动化测试，功能测试都通过之后开始的。

关键的非功能需求：

1. 设计一个合适的性能测试环境，目标是尽量跟生产环境一致的缩量环境：服务器的数量和配置（最主要原因），网络设施的带宽和联通性，分层部署（确保跟生产环境一样的分层），数据库容量。可用虚拟化手段或直接利用PasS平台，需考虑网络部署模型的影响，最后列出一个环境确认表(服务器数量，负载均衡策略，硬件配置表，软件配置表，应用组件表，内部和外部依赖）
2. 设定现实合理的性能目标：所有的相关方必须明确自己的期望和职责，对性能目标达成一致。性能指标有：可用性，并发，吞吐率，响应时间，反应系统容量：（网络利用率，服务器利用率）。

     3. 梳理并编写关键的业务用例脚本：用例检查表，需用文档详细描述用例，保证在编写脚本时没有歧义；确认输入和输出，划分用户种类，确定是局域网还是广域网，确定用例是主动类型还是被动类型（只登录不操作）。用例回放和验证：确认单个用户和多个用户回放均正确。度量目标，登录还是不登录，共存系统问题（单独的系统还是跟其它应用共享资源）。

     4. 提供测试数据，输入数据：用户信息，查询条件，关联文件。目标数据库的大小（测试数据最好跟生产库中的输入一样大），数据清理。会话数据处理（一定要确保脚本的正确性）。注意数据安全。

     5. 构建负载模型。

        性能测试的基本类型有：基准测试，负载测试（施加负载达到预期的并发目标），压力测试（施加负载直到应用的部分功能不能正常工作，容量达到极限），浸泡测试（长时间运行），冒烟测试（集中测试那些有变化的功能），隔离测试（目的是定位和排查问题）。

         负载模型：小数据模型，中等数据模型，大数据模型，简单并发模型，吞吐率模型。     

     6. 准确地进行性能测试方案设计：

          思考时间：终端用户在与应用进行交互时必然存在的延迟和暂停时间。

          步调时间：影响整体吞吐率。

          施压模式配置：大爆炸（所有的虚拟用户同时开始执行），递增（按时间间隔增加），分段递增，分段递增和分段递减，延迟启动（在正式启动压测之前延迟一段时间，用户脚本部署）。

           决定性能测试类型：单用例的负载测试，单用例的隔离测试，组合用例的负载测试，组合用例的隔离测试，组合用例的压力测试，组合用例的浸泡测试，非性能测试。

     7. 梳理关键性能指标：服务器指标（WEB和应用服务器层，数据库服务器层）；网络指标（网络错误，网络延迟，带宽消耗）；应用服务器指标。