技术文章

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

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

单元测试方面的专业知识通常涉及模拟、依赖关系反转或其他将测试与这些外部依赖关系分开的技术。完成所有操作后，各个单元测试将在开发人员的桌面、CT 管道或其他任何需要的地方以同样丰富的信息运行。

性能测试通常显示截然不同的配置文件。当性能测试使资源约束紧张时，以及当它们类似于生产环境时，它们最有用。在生产环境中诊断严重情况的相同代码在开发人员的集成开发环境 （IDE） 中可能根本无法测量任何内容。

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

测试节奏

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

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

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

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

只有自动化和相关的 CT 工具才能充分帮助使性能测试具有应有的系统性和重要性。是的，现有的工具在单元测试中得到了更多的实践，得出的结论是：

    assert operation.result == expected_result

不过，只要稍加练习，写起来就变得很自然了：

    assert within_range(elapsed_time, expected_time, agreed_tolerance)

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

面向 QA 和开发团队的现代测试用例管理软件

免费试用 TestRail

态度的转变

将性能测试和 CT 结合在一起得出的最大结论是，正确的态度可以清楚地表明它是多么的“胜利”。您可能会认为性能测试比单元测试更难集成，并决定将其排除在外。但是，当您将注意力转移到将性能测试集成到 CT 中来提高质量时，跟进并完成该集成会变得更具吸引力。

亲自尝试一下，让我知道将 CT 扩展到性能测试如何为您工作。

一体化测试自动化跨技术 |跨设备 |跨平台