敏捷测试与传统的结构化测试有何不同？
问问题
833 次
5 回答
1
敏捷项目通常会更加强调自动化测试、集成和验收测试以及单元测试，因为手动测试很快就会变得太慢而无法频繁发布。
TDD 方法将重点从“测试以发现缺陷”转变为“测试作为一种设计技术”。
思维方式可能非常不同——敏捷项目使用测试来实现快速重构和更改——你可以毫无畏惧地进行重大更改，因为测试会告诉你什么是有效的。传统项目害怕改变；他们的测试可能不会以相同的方式构建，并且可能会抑制变化。
于 2012-09-28T22:35:56.373 回答
1
当然，这取决于您如何定义“传统结构化测试”和“敏捷测试”......
这是我在对我见过的最有效的敏捷团队进行测试时倾向于观察到的。
- 没有单独的测试组。测试人员在开发团队中工作——而不是与它分开。
- 测试是在整个开发过程中发生的持续过程，而不是在开发后的单独阶段发生的事情。
- 测试由整个团队完成，而不仅仅是测试人员。最明显的例子是 TDD 产生的测试——但它也发生在其他地方（例如，产品所有者经常参与帮助定义围绕正在完成的故事的更高级别的验收测试）。
- 测试人员充当整个团队/为整个团队进行测试的教育者和促进者——而不是控制所有测试的瓶颈。
- 测试人员和非测试人员之间的关系往往更具协作性/协作性，而不是对抗性。
- 一般来说，我发现测试人员在敏捷团队中得到更多尊重。
- 测试人员更早地参与到流程中，从而更容易确保生成易于测试的系统。
于 2012-09-29T21:41:15.623 回答
0
我认为包括测试软件的实际部分可能非常相似。
最大的不同是你到达那里的方式。通常，在敏捷环境中，您从事的小部分开发工作会很快进入生产相关性。这可能是一个月到两周的时间。
这些较小的故事和更快的截止日期需要由整个团队决定的更轻量级的要求和更小的开发部分。测试人员没有时间花时间编写测试策略文档。较小的迭代允许测试人员只专注于测试。
鼓励每个人都在同一页面上通常会减少返工量。随着每个人都在处理较小的部分，通常会更频繁地构建和部署软件。这导致了对构建良好的 CI 环境的高度重视。CI 是 600 页的主题，所以我会把它留给你进一步研究。
对我来说，最大的不同是球队的心态。每个人都在共同努力发布软件。敏捷在消除开发人员与测试人员的僵局方面做得很好。与其争论谁有过错（糟糕的测试、糟糕的代码、糟糕的需求等），不如让团队一起解决问题。公司必须通过消除缺陷计数或其他妨碍团队合作的统计数据来鼓励这种情况自然发生。
于 2012-10-01T01:17:24.743 回答
0
无论您采用何种方法，产品质量的基础都是相同的。从瀑布式到敏捷的变化在于，测试在冲刺的早期就开始了，以及测试的执行方式。随着 TDD 等实践的发展，测试的重点也得到了改善。
从单元测试到系统测试和验收测试，所有这些测试都以新的方式进行。例如：现在在开发过程中，Tester 可以参与诸如“show me sessions”之类的会议，他可以提供早期反馈。
冲刺工作促使我们在每个周期中进行回归测试，并在演示之前进行验收测试。所以事情是如何从敏捷变成瀑布的（结构化测试）
于 2012-11-28T09:28:14.537 回答