持续集成中非功能测试用例的测试策略

时间:2015-06-23 18:07:06

标签: continuous-integration agile continuous-deployment continuous-testing

在大型系统开发中,非功能性需求经常出现 最重要的,实施它们占用了大部分的开发时间。非功能性测试很昂贵 并且通常需要很长时间才能运行。非功能测试经常无法在正常的持续集成系统周期中运行,因为它们可能需要很长时间才能执行 - 稳定性测试可能需要两周时间。任何人都可以提出任何好的测试策略来实现在持续集成过程中手动执行非功能性测试,其中采用每2小时创建的自动构建

2 个答案:

答案 0 :(得分:3)

一些冗长的测试可以(如果是这样的话)分成几个较短的测试,可以并行执行。

在某些情况下,最好花一些钱来增加测试台的数量,从而使整个测试带/容量允许多个测试相互重叠,减少甚至消除长测试持续时间的影响 - 你仍然可以在(某些)CI系统中使用它 - 没有人说如果CI管道每2小时开始一次,它们也需要在2小时内完成 - 只要资源容量允许它们(或者至少)它们可以继续和重叠(交错)一个体面的CI系统应该支持这种重叠。)

或者,可以将CI系统配置为根据其容量选择性地运行更长的任务:例如,为每个管道(相隔2h)执行典型的操作,但是每12个管道或每当运行一次,每天运行一次测试长期测试的资源是可用的(可能选择一个已经通过较短验证的管道 - >更高的通过较长测试的机会,更有意义的结果)(这可以做到甚至"手动",通过射击使用来自CI执行子集的工件的长测试。)

在某些情况下,持续时间较长是测试基础设施或实际测试编码限制的副作用,例如,即使不会从根本上影响测试,也无法按顺序执行任务。在这种情况下,切换到更合适的基础设施或分别重写测试以允许/改善并行性可能会缩短(有时显着)测试持续时间。

答案 1 :(得分:0)

首先,祝贺了解非功能性要求的重要性,这仍然是不常见的知识!

你已经提到过运行2周的测试 - 这对我来说似乎太长了。持续集成是关于即时反馈循环。如果任何测试花了这么长时间,您可能会在引入后2周内收到严重问题的通知。如果必须这样,我会三思而后行。

应尽可能避免在持续集成中手动执行非功能性测试。测试应在部署后自动运行。如果由于某些原因某些测试不能以这种方式运行(例如因为它们需要更长的时间来执行),它们应该定期触发 - 当然是自动触发。

有几种方法可以加快NFT执行时间:

  1. 缩小测试范围 - 例如而不是1000个螺纹上升= x的螺纹,运行100个螺纹,斜坡上升= x / 10。如果您正确地扩展所有必要参数,您可能会更早得到准确的反馈。

  2. 一旦功能测试通过,就可以在多个测试环境中并行执行NFT。如果您使用像亚马逊这样的平台,这应该是完全可能的。如果您为机器的运行时间付费,则无需显着提高成本 - 整体测试执行时间可能相似。