敏捷测试/传统测试方法

什么是敏捷测试方法？什么是传统的测试方法？这样就没有“敏捷测试方法”，只有在敏捷环境中进行测试。即使它们存在，也不能在瀑布组织中成功使用“敏捷测试方法” - 所以你的概念在那里有点错误。无论如何，为了给你一些建设性的反馈，测试函数可能与瀑布一样，但在敏捷环境中，以下内容可能有所不同：氛围和文化将更具协作性（更多的面对面互动），测试人员的参与会很早，团队将编写代码进行测试，而不是先编码，然后创建测试计划，您将具有跨职能性，因此您可能需要编写代码或进行需求收集，并且您将与客户密切合作，你会在2到4周的迭代中工作，你会不断改进你的测试程序你不会有QA /测试部门您的角色将是“拥有最多测试经验的团队成员”，而不是“测试人员” 传统方法大多是上面检查表的确切对立，严重。

碧肮械淌设

在传统测试中，假设瀑布流程，测试发生在开发阶段之后。测试人员根据项目开始时收集的要求创建测试。在陈规定型的意义上，大型组织有一个QA部门完全与开发部门分开，在那里他们交给最终的应用程序和文档来编写测试用例。在敏捷环境中，测试与开发异步进行，以便在开发人员完成任务时对其进行测试，以便在迭代结束时，利益相关者知道任务是完全正常的并且经过测试。如果揭示了错误，它们可以在循环的早期修复，而不是在最后的延伸中修复。这并不是假设每个团队使用TDD甚至是对/极端编程进行编写。敏捷的目标之一是改善团队成员之间的沟通。测试人员包含在迭代计划和审核会议中，使他们能够更深入地了解要完成的任务。这将有助于他们编写超出有时模糊的黑白要求的测试。我不同意敏捷不会扩展到包含QA部门的大型项目这一概念。是的，在许多情况下，在一些作者的建议中，敏捷团队的成员不到10个，但测试是提供高质量项目不可或缺的一部分。企业墙限制进展的挑战是如何进行。如何在我的会议或团队中获得测试人员？我们如何让QA更加参与，以便客户满意？等等

荤碗

如果有任何敏捷特殊的“测试方法”，我并不感到害羞。当然有“testdriven”（tdd）和“behaviordriven”（bdd）开发，但我不认为这些是“测试方法”。单位测试对敏捷或传统并不特殊。正如@khachik所提到的那样：当（在开发过程中）测试被设计并应用时，存在巨大的差异。传统=瀑布或V-Modell：最后完成测试（如果有的话）敏捷：应该在编写代码之前编写测试。

怪酞撩匹

您的问题有点不清楚，但如果我将其改为“敏捷环境与瀑布式环境的测试方法有何不同”，您可以获得以下方面的答案：在敏捷环境中，测试至少是在常规迭代（sprint）中完成的。在瀑布式环境中，测试往往在开发完成后执行。在敏捷环境中，测试通常以测试驱动开发（TDD）的形式包含在开发中。在瀑布环境中，测试是一个单独的实现阶段。在实践中，这是一个深刻的主题，对如何进行开发和测试有着复杂的认识。 TDD是一个前期思维过程，理论上不需要终端测试人员。一些人认为，无论定义的验收标准和测试用例的数量如何，仍然需要熟练进行探索性测试的人员。你的问题甚至我的改述中的挑战是软件测试不是一个简单的东西，适合在一个地方，也没有一个形状。至于它是如何实际完成或应该完成的，有关于该主题的数千篇文章有很多意见。

淑灯

我建议你查看Bret Pettichord关于软件测试不同学校的演讲，作为一个开始。不仅有两所学校 - 敏捷与传统，但至少有五所。这是一个很棒的总结，可以为您提供快速概述。 Lisa Crispin和Janet Gregory上面发布的敏捷测试链接很好，但我也强烈建议： Elizabeth Hendrickson - 去年的Pask奖得主。敏捷测试员。为什么你没有点击该链接呢？另外值得一读的是：Context-driven测试原理

蹦吃舷弦

在传统方法中，首先将进行整个开发，然后开始测试，无论发生什么错误都由开发人员修复。在敏捷方法论中，测试是一个连续的过程，它与软件组件的开发同时进行。对于回归视角，这种类型的测试将更有效。与传统技术相比，敏捷测试是一个快速的过程。

渐首洽陈染

（遵循敏捷软件开发原则的做法称为敏捷测试。）在一个外行人的术语中，测试可以被称为通过使他们处于紧张状态来揭示一个人或一个组织的能力;具有挑战性的。它也可以被称为首先制定计划，实现目标，估计和规划所有程序和所涉及的风险，然后测试 - 是否正在朝着既定目标前进。如果没有，那么敏捷有助于改变和制定计划并修复障碍，以便最终实现目标。通过敏捷测试，现在很容易检查过程之间的工作方式，而不像瀑布方法。敏捷是一种迭代开发方法，需求通过客户和自组织团队之间的协作发展，敏捷使开发与客户需求保持一致。

敏捷测试/传统测试方法

7 个回复

发起人

问题状态

敏捷测试/传统测试方法

与内容相关的链接

7 个回复

发起人

问题状态