在大型系统开发中，非功能性需求经常出现最重要的，并且实现它们需要大部分开发时间。非功能测试费用高昂而且跑步往往需要很长时间。非功能测试通常无法在正常的连续集成系统周期中运行，因为它们可能需要很长时间才能执行——稳定性测试可能需要两周时间。任何人都可以提出任何好的测试策略，以在连续集成过程中实现非功能测试的手动执行，其中每2小时创建一次自动构建
一些冗长的测试可以（如果是这样的话，它们应该）拆分为几个可以并行执行的较短测试。
在一些情况下，最好花费一些钱来增加测试台的数量，减少甚至消除了长测试持续时间的影响-你仍然可以在（某些）CI系统中使用它-没有人说如果CI管道每2小时启动一次，它们也需要在2小时内完成-只要资源容量允许，它们可以继续并重叠（交错）（或者至少一个像样的CI系统应该支持这种重叠）。
或者，CI系统可以配置为根据其容量选择性地运行更长的任务：例如，对每个管道进行典型的操作（间隔2小时），但每天只运行一次容量为1的测试，每12个管道运行一次，或者只要有用于长时间测试的资源可用（可能选择一个已经通过较短验证的管道->通过较长测试的机会越高，结果就越有意义）（这甚至可以"手动"完成，通过使用CI执行子集中的工件启动较长测试）。
在某些情况下，长持续时间是测试基础设施或实际测试编码限制的副作用，例如，即使不会从根本上影响测试，也无法并行执行任务。在这种情况下，切换到更合适的基础设施，或者分别重写测试以允许/提高并行性，可能会缩短（有时会显著缩短）测试持续时间。
首先，祝贺您理解了非功能需求的重要性，这仍然是不常见的知识！
你已经提到运行测试两周了——这对我来说太长了。持续集成就是即时反馈循环。如果任何测试需要那么长时间，那么在推出后两周，您可能会收到严重问题的通知。如果必须这样的话，我会三思而后行。
应尽可能避免在连续集成中手动执行非功能测试。测试应该在部署后立即自动运行。如果由于某些原因，某些测试不能以这种方式运行（例如，因为执行这些测试需要更长的时间），则应该定期触发它们——当然是自动触发的。
有几个选项可以加快NFT的执行时间：
-
按比例缩小测试-例如，运行100个渐变=x/10的线程，而不是1000个渐变=x的线程。如果你正确地缩放所有必要的参数，你可能会更早地得到准确的反馈。
-
一旦功能测试通过，就可以在多个测试环境中并行执行NFT。如果您使用像亚马逊这样的平台，这应该是完全可能的。如果你为机器的启动时间付费，这不必显著提高成本——总体测试执行时间可能相似。