技术文章

连续测试（CT）通常用单元测试来描述。但性能测试也应该在 CT 中进行。虽然性能测试面临挑战，但正确的理解不仅可以将性能纳入 CT，而且可以充分利用这一位置。

CT 在性能测试中面临的挑战及其解决方案需要一些解释。单元测试通常应该是 快速的、独立于外部资源、确定性的、客观的、风格良好的，以及其他理想的品质。单元测试组合中的一个常见挑战是对脱离主机资源（例如数据库）的依赖。

单元测试的专业知识通常涉及模拟、依赖倒置或其他将测试与外部依赖项分开的技术。全部完成后，各个单元测试可以在开发人员的桌面、CT 管道或任何其他需要的地方运行，并提供同样丰富的信息。

性能测试通常会显示出截然不同的情况。当性能测试对资源限制产生压力并且类似于生产环境时，性能测试最有用。在生产环境中诊断严重情况的相同代码可能在开发人员的集成开发环境 (IDE) 中根本无法测量任何结果。

例如，性能测试可能对内存布局的细节或大容量存储的检索速度很敏感。请注意与单元测试的对比，单元测试的大部分设计是小型的、透明的和可预测的。

测试节奏

尽管存在这些差异，CT 仍可以进行调整，以包括性能测试以及 CT 中更常见的测试。第一个调整是为性能测试引入不同的节奏。CT 通常会对每次提交启动单元测试，并根据单元测试的结果将提交评定为成功或失败。由于性能测试的运行时间要长很多倍，因此这种安排对他们来说并不实用。

然而，CT 仍然可以安排性能测试按照可预测的时间表运行，可能每小时甚至每天运行。当提交碰巧在性能测试中引入失败时，至少会在接下来的一小时或一天内检测到该失败，而不是在最终的质量保证审查期间。人们普遍认为，早期检测编程故障（“左移”测试）对于快速修复此类故障有很大帮助。

有效的性能测试可能需要其他调整才能适应 CT。也许它们应该只在非高峰时段运行，即当网络负载、磁盘活动或服务利用率足够轻以允许进行有用的测量时。也许他们需要具有受限授权的资源。

性能的“及格分数”可能类似于“测量 $M 在基线的 7% 以内”，其中单元测试通常断言“$V 的值恰好是 $R”。一些观察家看到了这些差异，并认为它们是使性能测试远离 CT 的原因。事实上，它们都是扩展 CT 以包含性能测试的原因。

只有自动化和相关的 CT 工具才能充分帮助性能测试达到应有的系统性和结果性。是的，现有的工具更多地用于单元测试，其结论是：

    断言操作.结果==预期结果

不过，只要稍加练习，就可以很自然地写出：

    断言范围内（经过时间，预期时间，商定的容差）

认识到后者的替代方案是可能在质量保证截止日期附近完成的某种手动主观测试。即使是通过 CT 一致安排的不完全自动化的性能测试也远远优于此。