15、软件测试与容量规划：保障系统高效运行

软件测试与容量规划：保障系统高效运行

1. 为何要进行测试

曾经有位美国政府官员经历了一个重大项目的失败。他试图推出一款已开发五年的新应用，在教室向约二十位高级用户展示并试用。然而，展示几分钟后就发现系统慢得无法使用，本应服务一千用户，却连最初的二十个都应付不了。

应用出现如此严重问题的原因在于测试不足，这涉及政治和技术两方面问题：
- 技术问题 ：性能测试技能稀缺。虽然开发者在单元测试中可能发现性能严重不佳的功能问题，但很多性能问题需要在有现实数据量和流量强度的环境中才能检测到，而许多开发者缺乏模拟生产环境的技能。
- 政治问题 ：在项目后期预留足够时间进行充分测试十分困难。不仅要为测试预留时间，还要考虑修复测试中发现的需求、设计和代码错误所需的时间。测试越晚进行，所需时间越长，且前期项目阶段的进度和成本超支往往会压缩后期测试阶段的时间和预算。

解决方案如下：
- 创建额外测试，测量在具有现实数据量和流量强度的系统上各功能的执行时间。
- 让开发者在编写代码时能访问这些测试，以便他们能及时发现问题。

测试的目的是了解应用的每个功能在繁忙系统上的运行速度，及时发现系统的薄弱环节并加以改进。规划不能替代测试，测试也是练习运行真实系统的机会，系统管理员应使用与生产环境相同的跟踪和分析工具进行测试。

2. 风险的定义

“风险”不只是对可能出错的计划的定性标签，它还是一个正式的、数学定义的术语，有助于项目经理和投资者计算决策的预期价值。风险是概率和成本两个因素的乘积，概率是事件发生的可能性，成本是事件发生时所遭受的损失。可从四个象限来总体考虑风险，左上角是最值得探讨的区域，例如：
- O型环在寒冷天气可能失效，危及飞行器、机组人员和项目，但这种可能性很小。
- 2号发动机的风扇盘可能解体并切断机身顶部的液压管路，导致飞机失去控制，但发生的概率有多大？
- 花费500万美元开发的应用可能在教室中连二十个用户都无法支持，但这种情况不会发生，对吧？

3. 破坏性测试

假设认为系统需支持1000个用户，创建了具有尽可能真实的数据量和流量强度的测试，且测试中系统表现良好。但测试数据可能使测试条件比实际应用面临的条件更宽松，并发工作负载可能未揭示应用在实际中会遇到的所有一致性延迟和排队延迟，从而增加风险。

可通过破坏性测试降低风险，例如若认为系统需支持1000个用户，不要仅将用户数量增加到1000，而是持续增加直到系统崩溃。了解系统在多少用户时崩溃，能明确不同的风险状况。同样，对于数据，不断增大表的大小，直到应用崩溃或测试到足够大的规模，以确定系统的余量。

还应使用能预测系统崩溃点的模型，将好的模型与测试结合可获得强大的预测能力。波音公司在设计飞机时会进行破坏性测试，用液压千斤顶弯曲机翼直到其断裂，以了解机翼超出正常使用预期极限的余量，并为工程师验证数学模型提供数据。破坏性测试使决策更简单、可靠。

4. 测试不应仅作为一个阶段

将所有测试都安排在项目结束的单独阶段是不明智的。测试应是一个对抗性过程，测试人员应尽力发现缺陷并创建可重现的测试用例，且应贯穿项目始终。在项目结束时仅运行一次新系统以证明其正常工作，这只是演示，并非真正的测试。

在项目结束时进行测试存在时间方面的重大问题：
- 修复十个月前编写的程序比修复昨天编写的程序要花费更多时间，需要重新熟悉上下文，还可能要处理十个月中出现的新依赖关系。
- 项目的最后阶段会受到整个项目生命周期中积累的超支所导致的时间挤压，甚至可能完全没有时间进行测试阶段。

若没有足够时间应对不理想的测试（或演示）结果，会产生不良后果，如高管可能会施加隐性压力要求减少发现问题的数量，这虽能暂时降低报告的缺陷率，但会将更多缺陷留给最终用户，损害用户利益并降低声誉。修复项目后期的缺陷比早期要昂贵得多。

5. 自动化测试

自动化软件测试是二十一世纪的重大进步。没有自动化测试时，测试是一个重大事件，一大群人聚集“测试应用”，每个用户按大文档中的规定运行应用并记录功能是否正常执行，开发者和管理者因担心未被检测到的附带损害而不敢轻易更改代码。

有了自动化测试，情况大不相同：
- 测试几乎不算事件，只需输入如“build test”的命令即可启动，每个开发者每天至少会运行部分测试套件几次。
- 开发者和管理者可随时更改代码，因为他们相信任何意外的副作用都会立即以测试失败的形式被检测到，开发者可根据这些信息修复附带损害或协商修改规范并记录到测试套件中。

创建自动化测试套件需要大量工作，从项目开始就要构建测试基础设施，测试用例从软件的初始需求分析阶段开始一直持续构建到项目结束。数千个自动化测试的代码行数可能与实际应用本身相当。自动化测试虽听起来昂贵，但实践中能让公司以更高质量、更小团队和更低成本完成更多工作。

6. 预防问题

灭火比防火更具吸引力，但预防问题同样重要。可在项目早期通过构建具有现实数据量和流量强度的测试系统，使用与生产环境故障排除相同的“观察法”（方法R）来预防问题，具体步骤如下：
1. 列出业务需要解决的症状。
2. 将列表按业务优先级排序。
3. 对于排序后的列表中的每个症状S：
- 当进一步解决S是首要任务时：
- 观察S（观察它！），理想情况下是在其出现异常时。
- 找出异常的原因C。
- 通过解决C来缓解S。

与生产环境故障排除一样，在步骤1和2中需要融入对业务的理解，这可能一开始会觉得不便，但有助于使测试优先级与业务优先级保持一致。随着时间推移，使用测试系统的人员会感受到与生产系统类似的自然压力，理想情况下，在软件生命周期早期通过测试系统模拟足够的压力，上线时就不会有意外情况。

7. 容量规划的启蒙：Mrs. Utley的问题

Mrs. Utley是作者三年级的老师，她教大家进行容量规划。例如有这样一个问题：假设你有1美元，从以下物品列表中写出三种购买方式，且至少留下25美分的零钱，并记录剩余零钱的金额。
| 物品 | 价格 |
| ---- | ---- |
| 汽水 | 15美分 |
| 糖果棒 | 10美分 |
| 泡泡糖 | 1美分 |

解决这个问题需要掌握以下几点：
- 理解用一种资源交换另一种资源的整体概念。
- 进行美元和美分之间的单位转换。
- 进行加减运算，若想更快完成还需用到乘法。
- 制定一种方式将答案传达给老师，以便老师评估学习情况。

这些能力正是进行容量规划所必需的。

8. 容量规划的模型

容量规划很复杂，尤其是CPU规划，很难预测从未在现实中运行过的应用会消耗多少资源。好在如今有弹性云技术，如亚马逊和甲骨文等供应商可按需提供和调整CPU容量。

以下是一个帮助在系统全局上下文中分析程序的模型：
| 物品 | 数量（运行/小时） | CPU秒/运行 | 总CPU秒/小时 | 占比 | 建议 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| WENUS报告 | 1 | 3600 | 3600 | | |
| TPS报告 | 4 | 200 | 800 | | |
| 图书订单 | 1200 | 0.8 | 960 | | |
| 其他 | 1 |? |? | | |
| 总计 | | | 5360 | | |
| 剩余 | | | 9040 | | |

这个系统的总容量为4 CPU × 60秒/分钟 × 60分钟/小时 = 14000 CPU秒/小时。“运行/小时”列包含业务在周一下午2点高峰时段希望每个业务功能运行的频率；“CPU秒/运行”列是通过跟踪得到的价格数据；“总CPU秒/小时”列是每个业务功能消耗的总CPU时间，通过“运行/小时”乘以“CPU秒/运行”计算得出；“剩余”是总CPU容量减去业务功能消耗的容量；“占比”列将总容量消耗表示为百分比；若知道该时段的实际CPU利用率，可使用Excel的“目标搜索”功能调整“其他”的“CPU秒/运行”值，使总利用率与观察值匹配；“建议”单元格可提供避免流量强度过大导致排队延迟严重的建议。

通过这个模型可以直观地看到系统中运行的各项业务功能及其对CPU容量的消耗，有助于决定哪些程序最值得优化。优化的方法始终围绕两点：
- 减少事件数量。
- 减少每个事件的平均持续时间。

通过合理的测试和容量规划，可以提高软件系统的性能和可靠性，降低风险，为业务的高效运行提供有力保障。

9. 容量规划的重要性及应用

容量规划在软件系统的管理和优化中具有至关重要的地位。以CPU规划为例，由于难以预测新应用在实际运行中的资源消耗，合理的容量规划可以帮助我们更好地分配资源，避免资源浪费或不足的情况发生。

在上述提到的模型中，我们可以通过对各项业务功能的CPU消耗进行分析，来评估系统的整体性能和资源利用情况。以下是一个具体的分析流程：
1. 数据收集 ：收集各项业务功能的运行频率（运行/小时）和每次运行所需的CPU时间（CPU秒/运行）。
2. 计算消耗 ：根据“总CPU秒/小时 = 运行/小时 × CPU秒/运行”的公式，计算每个业务功能的总CPU消耗。
3. 评估剩余容量 ：用系统的总CPU容量减去各项业务功能的总消耗，得到剩余容量。
4. 分析占比 ：计算每个业务功能的CPU消耗占总容量的百分比，以便直观地了解各功能的重要性和资源占用情况。
5. 优化决策 ：根据分析结果，决定是否需要对某些业务功能进行优化，例如减少运行频率或降低每次运行的CPU消耗。

通过这个流程，我们可以清晰地了解系统的资源使用情况，及时发现潜在的性能瓶颈，并采取相应的措施进行优化。

10. 测试与容量规划的协同作用

测试和容量规划是保障系统高效运行的两个重要环节，它们之间相互关联、相互影响。

10.1 测试为容量规划提供数据支持

在测试过程中，我们可以收集到各项业务功能的实际运行数据，包括运行时间、资源消耗等。这些数据可以为容量规划提供准确的依据，帮助我们更精确地预测系统的资源需求。例如，通过性能测试，我们可以了解到不同业务功能在不同负载下的CPU消耗情况，从而为容量规划中的“CPU秒/运行”参数提供参考。

10.2 容量规划指导测试方向

容量规划可以帮助我们确定测试的重点和范围。根据系统的容量需求和业务优先级，我们可以有针对性地对关键业务功能进行测试，确保其在高负载情况下仍能正常运行。例如，如果在容量规划中发现某个业务功能的CPU消耗较大，那么在测试过程中就需要重点关注该功能的性能表现，进行压力测试和负载测试，以确保其在系统达到容量极限时不会出现性能问题。

10.3 协同工作的流程

为了实现测试和容量规划的协同工作，我们可以采用以下流程：

graph LR
    A[需求分析] --> B[容量规划]
    B --> C[测试计划制定]
    C --> D[测试执行]
    D --> E[数据收集与分析]
    E --> F{是否满足要求}
    F -- 是 --> G[系统上线]
    F -- 否 --> B[容量规划]

1. 需求分析 ：明确系统的业务需求和性能要求。
2. 容量规划 ：根据需求分析的结果，制定系统的容量规划，确定各项业务功能的资源需求。
3. 测试计划制定 ：根据容量规划的结果，制定详细的测试计划，包括测试用例、测试环境、测试工具等。
4. 测试执行 ：按照测试计划执行测试，收集各项业务功能的运行数据。
5. 数据收集与分析 ：对测试过程中收集到的数据进行分析，评估系统的性能和资源利用情况。
6. 决策判断 ：根据数据分析的结果，判断系统是否满足容量规划的要求。如果满足要求，则可以将系统上线；如果不满足要求，则需要重新进行容量规划和测试。

通过这个流程，我们可以确保测试和容量规划的协同工作，提高系统的性能和可靠性。

11. 总结与建议

11.1 总结

软件测试和容量规划是保障系统高效运行的关键环节。测试可以帮助我们发现系统中的缺陷和性能问题，及时进行修复和优化；容量规划可以帮助我们合理分配资源，避免资源浪费和不足的情况发生。两者相互关联、相互影响，只有将它们有机结合起来，才能实现系统的最佳性能和可靠性。

11.2 建议

为了更好地进行软件测试和容量规划，我们提出以下建议：
- 重视测试 ：将测试贯穿于项目的整个生命周期，不仅仅是在项目结束时进行简单的演示。采用自动化测试工具，提高测试效率和准确性。
- 提前规划 ：在项目开始阶段就进行容量规划，根据业务需求和性能要求，合理分配资源。在项目实施过程中，不断对容量规划进行调整和优化。
- 协同工作 ：建立测试和容量规划的协同工作机制，确保两者之间的信息共享和沟通顺畅。通过协同工作，提高系统的整体性能和可靠性。
- 持续优化 ：系统的性能和需求是不断变化的，因此需要持续进行测试和容量规划的优化工作。定期对系统进行评估和分析，及时发现问题并采取相应的措施进行改进。

通过以上建议的实施，我们可以有效地提高软件系统的质量和性能，为业务的发展提供有力的支持。