随着我们向持续交付进军，就减少了对如性能测试这样的日常任务。怎样的方法都是进行持续性能测试的最佳方法？

当处理持续性能测试时，有一点很重要，就是时常进行一些日常测试，这样会比什么都不做要好，做什么都比由开发都商店完成好。所有的应用（至少）都需要在用户交互涉及到的最原始的屏幕上的性能测试。持续开发软件团队可以以多种方法，在测试进行的基础上添加有价值的性能测试。

首先，应用的测试性能基于它本身的，没有添加客户的复杂服务回负载参数。稍后，你可以添加负载测试，而不必更新现有的测试案例，因为负载的变化是在服务器上完成的，而不是测试案例。开始进构建小的性能测试，在应用本身上执行；然后再随着性能的报告或修复，再添加它。

如果你的组织有大量的性能测试，却没有持续执行的话，那么就考虑开发一个旋转测试套件。为了使用旋转测试套件，首先要决定实际有多少测试你可以添加到测试周期中，且不会影响发布时间。下一步，优化基于风险的测试，然后把他们分散到套件中。当你把测试分散到套件时，确保要包括一个权衡优先级，以及至少每一个主功能区有一个测试。换句话说，要涵盖基础东西，以及最少数量的人员。在每一个测试周期中，执行不同的套件。应用仍然可以收到性能信息，触及所有领域，但测试却较少。

前面的两个建议假设了性能测试是自动化的。你可以以相同的方式，把人工软件性能测试添加到测试周期中。人工性能测试的主要不同点是，你需要依赖测试人员的知识和技能。测试人员知道他们期望的应该响应速度有多快，无论它是web应用程序还是移动应用程序。使用测试人员的真实消费技能，并结合他们的应用程序知识，来创建小的持续性能测试套件，从而适用于现有的测试周期。另外，如果必要的话，把它们分散到几个测试周期中，通过创建人工测试案例的旋转套件。