敏捷测试/传统测试方法

Question

敏捷测试方法是什么？那么传统的测试方法是什么呢？

Answer 1

什么是敏捷测试方法？那么传统的测试方法是什么呢？

没有“敏捷测试方法”本身，只有在敏捷环境中进行的测试。即使它们存在，你也不能在瀑布组织中成功地使用“敏捷测试方法”--所以你的概念有点错误。

无论如何，给你一些建设性的反馈，测试功能很可能与瀑布一样，但在敏捷环境中可能会有所不同：

1. 的氛围和文化将更具协作性(更多面对面的互动)，
2. 测试人员的参与将提早，
3. 团队将对测试进行编码，而不是先编写代码，然后创建测试计划，
4. 您将跨职能，因此您可能必须编写代码或进行需求收集，并且您将与客户密切合作，

< code >H111您将在2-4周的迭代中工作，测试员procedures

1. you将不再担任QA/Testing department
2. your角色将成为“具有最丰富测试经验的团队成员”，而不是“
3. ”

严肃地说，传统的方法大多与上面的检查表完全相反。

Answer 2

在传统的测试中，假设waterfall过程，测试发生在开发阶段之后。测试人员从项目开始时收集的需求创建他们的测试。在固定的意义上，大型组织有一个与开发部门完全分开的QA部门，在那里他们被交给最终的应用程序和文档来编写测试用例。

在agile环境中，测试与开发是异步进行的，因此当开发人员完成一项任务时，将对其进行测试，以便在迭代结束时，涉众知道该任务是一个功能齐全且经过测试的任务。如果bug被发现，它们可以在周期的早期修复，而不是在最后阶段。

这并不是假设每个团队都使用TDD甚至pair/extreme编程进行编写。

敏捷的目标之一是改善团队成员之间的沟通。测试人员被包括在迭代计划和评审会议中，使他们能够更深入地了解给定任务要完成的内容。这将帮助他们编写测试，超越有时模糊的黑白需求。

我不同意敏捷不能扩展到包含QA部门的大型项目的观点。是的，在许多情况下，在一些作者的建议中，敏捷团队的成员少于10人，但测试在交付高质量的项目中是不可或缺的。挑战在于，当公司的围墙限制了进展时，如何继续进行。我怎样才能在我的会议或我的团队中找到测试人员？我们如何让QA更多地参与进来，让客户满意？等。

Answer 3

我不是舒尔，如果有任何“测试方法”是特殊的敏捷。

当然还有“测试驱动”(tdd)和“行为驱动”(bdd)开发，但我不认为这些是“测试方法”。

单元测试并不是敏捷或传统的特殊测试。

正如@khachik提到的那样:当(在开发过程中)设计和应用测试时，通常会有巨大的差异。

传统=瀑布或V-Modell:测试在最后完成(如果有的话)

敏捷:测试应该在代码编写之前编写。