我们有一个缺陷,即在某种情况下,应用程序的状态变为不希望的状态。已修复,我们添加了一个测试:


设置状态
触发了错误状态更改的操作
检查状态仍与setup 等待几秒钟
检查状态仍然不变并且没有任何变化

我的问题是:我们需要等待多长时间才能使测试不产生假阳性结果?

在某些情况下,如果测试环境重新启动服务,则会在几秒钟的时间内冷启动。理论上,由于服务的异步性质,触发状态更改的事件队列可能会超载。

理论上,由于服务的异步性质,状态在一分钟后仍可能更改,但是我不想添加一个测试总是等待一分钟或更长时间,因此我的问题是。我们是不正确地对此进行处理还是有其他选择?

#1 楼

大问题Niels。

鉴于这将取决于给定的情况,因此我将考虑将其作为数据收集活动。我将研究许多重复运行的正态分布。如果99%的时间在1分钟后仍保持正确(即在
1分钟后不再更改),并且企业认为1%的失败(并重新运行)率是可以接受的,那么我会使用那。相同的计算需要等待10秒。让企业确定正确的答案。

通常,我希望通过轮询等待而不是固定等待来解决此问题,但是在这种情况下,这无助于潜在的答案在最初已经正确的情况下从正确变为错误。

还有一个想法-这可能属于一类问题,这些问题可用于生产监视而不是开发测试。如果在生产中确实发生了此问题,请设置监视以捕获发生的情况和发生的频率。有了更多的数据,您也许能够制定出更好的计划或减轻该问题的方法和/或更改测试方法以实现此目的。

评论


感谢您的想法。我想我将尝试衡量在典型情况下过渡需要多长时间。以此为基准+一些差异。然后对失败的情况进行快速失败轮询,以便在状态错误时不希望出现这种情况。我同意将生产监视作为一种解决方案,我可能想添加A / B测试监视,因为在我们的情况下,此缺陷将存储部分调查答复,研究人员甚至可能不会注意到。

– Niels van Reijmersdal
19-10-3在7:47

这个答案表达了我对质量检查的很多看法-大多数重要,冒险的决定都没有交给我们!

– Tim
19-10-4在0:21

#2 楼

在开发服务器上的这种情况下,我希望从系统本身获取一些信息,以告诉我它什么时候完成了某件事。

我希望排队系统保留以下记录:队列中有哪些项目以及它们现在处于什么状态。

最简单的方法是在排队系统中找到一个密钥,该密钥允许您在队列中链接队列项目。数据库到您正在使用的测试帐户。这样,您可以检查该帐户的任何队列项目是否未处于“完成”状态。如果没有任何尚待处理的项目,并且应用程序中的状态符合您的预期,则可以合理地假设不会自动产生新的队列项目。

没有密钥,您可以检查两次之间是否有任何不在“ DONE”中的队列项目。这种方法更容易出现问题,因此设法将特定队列项标识为属于您的测试是一种更好的方法。

如果您想双重确定,也可以创建一个系统,用于检查是否为先前的一组自动化测试中使用的帐户创建了任何其他队列项目。然后,您可以在主要测试完成后的某个时间运行该系统,这是一种偏执的“如果出了什么错,它将在X分钟后创建另一个队列项”。我不确定我会走的那么远。

#3 楼


触发状态更改的事件队列可能会超载。


我希望事件队列可以排序;也就是说,按顺序(1、2、3)进入队列的事件以相同的顺序(1、2、3而不是2、1、3)从队列中弹出。

第一个事件不应触发更改,我将在相同的画布上编写两个测试,每次按下第二个事件都会触发不同的更改;该测试实际上将进行以下操作:


推动事件X(无变化)和事件W。
确保没有任何变化...
直到W触发变化

您可能希望也可能不希望在X和见证事件之间稍作停顿。

使用两种效果不同的测试的目的是确保您不会意外重叠也就是说,X不是导致W产生预期效果的事件。


更好的是带外信号。

这是您的开发团队应该能够提供的。例如,您可能有一个带有ID的Sequence事件,在处理ID时会报告带外-而不是带内报告以避免噪声/扰动。

然后您的测试就可以变为:


发送Sequence(0)。
等待直到报告为0,表示系统已启动。


或超时,如果启动时间太长。


发送命令。
发送Sequence(1)。
等到报告为1时,表示命令已被发出已处理。


或超时,如果等待时间太长。


检查Command是否具有预期的效果。

这种排序可以真正帮助测试异步系统,尤其是减少测试的脆弱性。它假定所有异步流都已同步,因此在报告之前,同步需要在所有子系统中循环。

理想情况下,您应从随机数开始序列,然后将其增加为你去。

如果应用程序支持“心跳”以监视其在生产中的响应速度,则“心跳”应包含已经与查询/响应匹配的序列号。确保序列正确后,便可以将其用于序列测试。

#4 楼

我想说这样的案例是白盒测试的不错选择。

如果开发人员确定导致问题发生的原因,则可以根据白盒技术对解决方案进行分析,并可以设计测试以验证假定的算法是否确实以其原本的方式实施。设计。

评论


如果您控制整个软件链,这将起作用。在这种情况下,我们会从第三方获得事件。他们更改了实现方式,从而为我们不想处理的情况生成了类似的事件。

– Niels van Reijmersdal
19-10-3在7:50