敏捷测试和传统测试方法

Question

敏捷测试与传统的结构化测试有何不同？

Answer 1

没有“敏捷测试”这样的东西，但经常被认为是敏捷方法论的关键组件的是unit testing，它早于敏捷。这与“传统的结构化测试”有何不同，取决于你所说的意思。

在敏捷和单元测试的上下文中经常出现的可能会引起您混淆的其他事情：Test driven development和continuous integration。

Answer 2

敏捷项目通常会更多地强调自动化测试，用于集成和验收测试以及单元测试，因为手动测试很快就会变得太慢，不能允许频繁发布。

TDD方法将重点从“测试以发现缺陷”转变为“将测试作为一种设计技术”。

想法可能非常不同-敏捷项目使用测试来实现快速重构和更改-您可以毫无畏惧地进行重大更改，因为测试将告诉您什么是有效的。传统项目害怕变化；他们的测试可能不是以相同的方式构造的，并且可能会抑制变化。

Answer 3

当然，这取决于您如何定义“传统结构化测试”和“敏捷测试”……

这是我在我所见过的最有效的敏捷团队上进行测试时倾向于观察到的。

• 没有单独的测试组。测试人员在开发团队中工作，而不是与之分离。
• 测试是一个持续的过程，整个开发过程中都会发生--而不是在整个团队完成development.
• Testing之后的单独阶段中发生的事情，而不仅仅是测试人员。最明显的例子是测试驱动开发产生的测试--但它也发生在其他地方(例如，产品所有者经常参与帮助定义围绕正在完成的故事的更高级别的验收测试)。敏捷teams.
• Testers测试人员在整个团队/为整个团队充当测试的教育者和促进者-而不是控制所有测试的瓶颈。
• 测试人员和非测试人员之间的关系倾向于更多的协作/大学关系，而不是敏捷测试人员的关系我发现测试人员在过程中更早地参与到敏捷teams.
• Testers上得到了更多的尊重，更容易确保生产出易于测试的系统。