敏捷测试和传统测试方法

Question

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

Answer 1

没有“敏捷测试”这样的东西，但是经常作为敏捷方法的关键组成部分出现的东西是unit testing，它早于敏捷。这与“传统的结构化测试”有何不同取决于你的意思。

在敏捷和单元测试的背景下经常出现的其他因素可能会引起您的混淆：Test driven development和continuous integration。

Answer 2

敏捷项目通常会更加重视自动测试，集成和验收测试以及单元测试，因为手动测试很快就会变得太慢而无法频繁发布。

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

mindet可能非常不同 - 敏捷项目使用测试来实现快速重构和更改 - 您可以毫无顾虑地进行重大更改，因为测试将告诉您哪些工作正常。传统项目担心变化;他们的测试可能没有相同的结构，可能会抑制变化。

Answer 3

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

通过对我见过的最有效的敏捷团队的测试，我倾向于观察到这一点。

• 没有单独的测试组。测试人员在开发团队中工作 - 而不是与之分离。
• 测试是一个贯穿整个开发过程的持续过程 - 不是在开发后的单独阶段发生的事情。
• 测试由整个团队完成，而不仅仅是测试人员。最明显的例子是TDD产生的测试 - 但它也发生在其他地方（例如，产品所有者经常参与帮助定义围绕正在完成的故事的更高级别的验收测试）。
• 测试人员充当整个团队的测试教育者和推动者 - 而不是控制所有测试的瓶颈。
• 测试人员与非测试人员之间的关系往往更具协作性/合作性而非对抗性。
• 一般来说，我发现测试人员对敏捷团队更加尊重。
• 测试人员在此过程中更早参与，使得更容易确保生成易于测试的系统。

Answer 4

我认为包含测试软件的实际部分可能非常相似。

最大的区别在于你到达那里的方式。通常在敏捷环境中，您可以处理快速进入生产相关性的小型开发。这可能是一个月到两周的任何时间。

这些较小的故事和更快的期限要求更轻量级的要求和由整个团队决定的较小的开发项目。测试人员没有时间花时间编写测试策略文档。较小的迭代允许测试人员专注于仅测试。

鼓励每个人都在同一页面上，这通常会减少返工量。随着每个人都在处理较小的部分，通常会更频繁地构建和部署软件。这导致强调强大的CI环境。 CI是600页主题，因此我将留给您进一步研究。

对我来说，最大的不同是团队的心态。每个人都在共同发布软件。敏捷在消除开发人员与测试人员的僵局方面做得很好。而不是争论谁是错误的（错误的测试，错误的代码，不良的要求等）该小组共同努力解决它。公司必须通过消除缺陷计数或阻止团队工作的其他统计数据来鼓励这种情况自然发生。

Answer 5

您遵循的方法是什么，产品质量的基础是相同的。从瀑布到敏捷的变化是，测试是在sprint的早期阶段开始的，以及如何进行测试。并且TDD等实践改进了测试的重点。

从单元测试开始到系统测试和验收测试，所有这些测试都以新的方式进行。例如：在开发过程中，Tester可以参与像“给我演讲”这样的会议，他可以尽早给出反馈。

在sprint中工作促使我们在演示前的每个周期和验收测试中进行回归测试。那么事情是如何从敏捷变为瀑布（结构化测试）