敏捷转型
缺陷驱动的测试自动化
阅读:
缺陷驱动的测试自动化
团队在开始使用自动化测试时需要指导方针。不仅测试的开发在开发时间方面是昂贵的，而且持续的测试维护也会消耗开发时间。构建测试策略的一个选择是使用缺陷报告来定义软件使用模式。就像所有软件开发一样，我们的目标是在一个能带来最大收益的领域构建测试。
测试智能:当团队基于多次报告的缺陷构建测试时，策略是为每个缺陷构建一个单元测试。这个概念是当团队找到一个缺陷时，他们为预期的行为编写一个测试，并看到失败。接下来，他们编写一个修复程序，使测试通过。这种方法肯定会增加测试覆盖率，并产生一个可以使用的自动化测试套件。然而，您如何知道您在编写自动化测试方面做出了最好的投资呢?
关注使用:来自客户的类似的缺陷报告经常指出一个特性的共同使用，它将从自动化测试中受益。例如月报中的舍入误差。即使为了构建这个缺陷的自动化测试而涉及到大量的重构工作，由于使用的关系，还是有回报的。内部质量团队发现的缺陷或缺陷的单一实例可能表明没有大量使用的特性，这样同样的重构工作就不会对整个代码库产生很大的影响。
感知质量:考虑到只有大约40 -60%的代码会被使用,只有20 - 40%是使用频繁,把你的测试工作在最常用的部分代码会导致最大的回报和显著增加顾客对产品质量的认识。分析客户报告的缺陷以生成添加测试的指导方针，是构建更高质量代码的一个工具。
评论(5)
Rob Hooft
在许多情况下，单元测试是为了防止缺陷。根据我的经验，它们可以快速地节省开发时间，因为它们可以更容易地跟踪代码不按预期方式运行的原因。
当然，任何通过并在发布的软件中结束的缺陷都应该作为测试添加，但是这些是“回归”测试，并且可能更有效地作为功能测试而不是单元测试来实现。
我错过什么了吗?
感谢您花时间来写作。我想我的开场白不够清楚，但我考虑的是现有软件与新的自动化工作的意义。在这种情况下，定义从哪里开始需要团队的指导方针。任何时候软件在生产中都会有缺陷报告。大多数情况下，这些并不一定是错误，而是行为上的改变。
利亚
有趣!因此，我们正在开发一个新的应用程序(HTML5)，并随着新功能的添加创建自动测试——到目前为止，这工作得很好。然而，新事物会自己出现(例如缺陷)，我们现有的测试并不总是能捕捉到它们。所以我必须问自己，我们的测试已经达到了最好的水平吗?它们能做得更好吗?我是否应该在我们的测试中包含这一细微差别，以便在未来能够捕捉到同样的漏洞?或者我应该编写一个新的、独立的测试来专门捕捉这个错误?或者，我不应该基于缺陷自动化任何测试吗?我不想陷入创建测试来捕获每个缺陷的兔子洞中——无论如何这都是不可能的——即使这样，您在哪里划清界限呢?我喜欢上面的感知质量规则——这很有帮助。
请允许我问一下，你对这个案子怎么看?
我们有一个日历应用程序，用户可以在上面记录他们的锻炼。一天可以有很多锻炼。在任何一天的标题，你可以Ctrl+C复制一天，Ctrl+V粘贴到另一个。这工作得很好。几周后，突然出现了一个缺陷，现在Ctrl+V触发了两个粘贴事件(例如，训练被加倍)。我们现有的测试，如果快捷方式工作，不会发现这个bug。问题-我是否应该创建一个新的自动化测试，以确保在粘贴事件中只出现一个实例?还是说这是在浪费资源?亚傅体育app你对这类事情有什么看法?
感谢您的投入(提前!)
利亚
利亚,
感谢您花时间来写作。首先，我想解决你的日历应用程序的问题。重复的问题是计数。它可能是由于不同的原因被多种方法发射的粘贴，这是不能被现有的测试捕获的。这个条件指向了重构的机会，但是您需要一个失败的测试来验证重构是否有效。所以简单地说，您需要编写一个测试。编写这个测试可能消除了对第一个测试的需要，您可以放弃第一个测试。
为覆盖良好的代码的每个缺陷编写测试不是一种浪费。将测试代码视为有价值和昂贵的观点，是为了推动构建一种可以很容易地就如何最好地利用测试投资进行沟通的策略的想法。您的测试套件就像您的代码库需要被修饰和维护一样，这样它也很容易更改。作为一个开发团队，我们应该寻找像你上面的例子那样的机会来删除旧的测试，并用我们已经了解到的更好的测试来替换它们。
谢谢,
Jann