认识达内从这里开始

只要有软件开发，那么就一定有对应的软件测试，而今天我们就一起来了解一下，关于敏捷开发软件测试都有哪些测试原则是需要我们掌握和熟练运用的。

1、我们重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

3、经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。

5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

6、不论团队内外，传递信息效果好效率也高的方式是面对面的交谈。

7、可工作的软件是进度的要度量标准。

8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10、以简洁为本，它是极力减少不必要工作量的艺术。

11、好的架构、需求和设计出自自组织团队。

12、团队定期地反思如何能提高成效，并依此调整自身的举止表现。

这12条原则中没有一条直接谈到测试，那是否说明没有敏捷测试呢?有开发就有测试，只是原来参加敏捷宣言的17人，基本是清一色程序员，没有在原则中单独阐述一下测试的原则。但其中一些原则和测试的关联性很强，例如：

1、软件测试如何支撑或协助“持续不断地及早交付有价值的软件”?如何在非常有限的时间内进行充分的测试?这就是我们经常在敏捷测试中强调的“自动化测试”，如果没有自动化测试，就没有敏捷，就不能持续不断地及早交付有价值的软件，而且还要“使客户满意”。

2、“欣然面对需求变化，即使在开发后期也一样”和传统的开发原则是不同的，传统的开发希望有严格的需求变更控制，越到后期控制越严。而敏捷开发拥抱变化，那么测试如何适应这种变化?如何快速地完成回归测试?这可能要依赖于开发做好单元测试，或全员参与测试，以及全面支持系统级的、端到端的回归测试的自动化测试执行。

3、传统的开发也要求“业务人员和开发人员必须相互合作”，但存在一定的阶段性，例如前期需求评审、期间产品走查(productwalk-through、、后期验收测试等要求有紧密的沟通与协作。但敏捷开发更强调“项目中的每一天都不例外”，在这样的原则下，如何去做敏捷测试?这样可以减少测试文档，刚开始也没必要把测试计划写得很详细，而是写一页纸测试计划就可以，将来再持续的完善和调整。

4、“可工作的软件是进度的要度量标准”，不再是测试计划完成情况、完成的测试用例数目、测试脚本量等，而是如何及时验证每天完成的功能特性。开发的工作量也不能按代码行来衡量，而是看多少个具体的用户故事(功能特性、被实现了(done、。某个开发说已完成了某个用户故事，要么是通过他自己的验证，要么是通过测试人员的验证，谁做的测试不重要，关键是要有准备好的测试，随时验证已完成的工作。

5、“坚持不懈地追求技术卓越和良好设计”，一方面要求测试的技术要不断提高，在处理每个测试任务时，都应该找到有效的办法;另方面，在前期要更多地参与设计评审，及时发现设计的问题。只有良好的设计，才能更好地支持系统的功能扩充和不断的重构。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!