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