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