本文主要是介绍敏捷测试的启示，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
敏捷测试的启示
陈能技
2007-9-7
最近，好像整个软件开发界都在讨论和实践敏捷方法，做什么事情都要敏捷，开发要敏捷，测试也要敏捷。
什么是敏捷？
敏捷宣言：个体和交互比过程和工具更有价值；能工作的软件比全面的文档更有价值；顾客的协作比合同谈判更有价值；及时响应变更比遵循计划更有价值。- www.agilemanifesto.org
敏捷开发是递增式的、迭代的、不断调整的开发模式。在敏捷开发中，工作被分解成“故事”，也叫特性或用例，组合成任务分派给不同的程序员。敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。在敏捷开发中不存在回退，讲究持续地集成，单元测试（通常使用测试驱动的开发方式），持续地进行回归测试。
敏捷测试是指在敏捷开发模式中的测试。敏捷测试包括单元测试（通常由程序员完成）和可接受性测试（通常由测试人员完成）。
如何应对敏捷？
敏捷来了，测试人员何去何从？有人认为在敏捷的团队中，在实行极限编程方式的团队中，测试员应该被“废掉”！有人认为，测试员应该拥抱敏捷，不要管什么测试计划、不要测试报告！
对于第一个论点，我们很容易就能推翻。即使是在一个完全采用XP方式的团队中，测试员还是必不可少的。只不过是测试员在XP中扮演的角色与传统软件开发模式中扮演的不大一样了。
在敏捷开发中，测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。测试人员不再作出发布的决定。测试员不保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标。
对于第二个论点，我们要分析一下，问一下自己，你现在是在一个怎样的团队中工作的，工作得怎样？如果你是在一个传统开发模式的团队中工作，而且工作得挺好的，则第二个论点对于你来讲是错误的。
因为在传统的软件开发模式中，项目文档不仅仅是驱动项目前进的必要条件，而且很多企业的客户，尤其是软件的军方客户，对于产品的最终配套文档，还有阶段性文档都是很看重的；另外，对一些外包的软件也需要有完整的文档。而敏捷模式抛弃文档的做法在这些企业是行不通的。
传统的开发模式中，测试人员可能要兼任测试和质量保证、甚至配置管理的工作。那么按照谁负责谁决定的原则，则你作为质量方面的负责人，必须对产品的质量把关，做好“守门员”，对产品的放行有绝对权威的发言权。
敏捷测试的启示
对于我们测试员来说，如果你是在一个敏捷的团队，采用完全的XP方法，则你应该按照敏捷测试的原则，调整自己的角色，让自己成为一名真正的敏捷测试员。在敏捷的团队中，测试工作的核心内容是没有变的，就是不断地找BUG。只是你要调整好自己的心态，一切以敏捷的原则为主。更多的采用探索性测试方法，更多地采用上下文驱动的测试方法论，更多地采用敏捷自动化测试原则。
如果你是在一个传统的开发团队中，你不可能背叛整个团队的一贯做法，自己去“拥抱敏捷”，毕竟很多公司按照ISO、CMM的做法也在不断地成熟。那么我们需要做的是多吸收一些敏捷的思想，优化一下自己的测试流程。
敏捷提出的用户故事的说法，其实是把需求规格说明书敏捷化了，那么其实它是指出了需求文档冗长和管理不当的问题，那么通过一些控制工具是否能解决问题呢？同时也给我们一个启示，敏捷测试为什么能在缺乏文档的环境下工作？我们为什么就非要依赖文档呢？测试员是否能自动地寻找和挖掘更多的关于软件的信息来指导我们的测试呢？探索性测试，这种强调同时设计、测试和学习被测试系统的测试方式是我们可以借鉴的。
敏捷讲求合作，其实是指出了我们传统工作方式沟通上的毛病，开发人员与测试人员往往都比较对立，我们传统的方式过分依赖书面的沟通，文档驱动，缺乏很多面对面的交流，我们能否主动点，多与开发人员聊聊需求、讨论设计、一起研究BUG出现的原因呢？
敏捷测试认为要持续地测试，不断地回归测试，快速地测试。其实是指出我们传统的测试阶段过于冗长、没有根据项目的上下文作出调整，速度太慢，过分依赖手工测试。那么我们能否多点借鉴上下文驱动测试的方法，适当自动化我们的测试呢？
这篇关于敏捷测试的启示的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
