敏捷开发与敏捷测试

1、敏捷开发与敏捷测试摘要：敏捷开发是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。本文主要阐述了敏捷开发和敏捷测试的概念，敏捷开发测试的原则和敏捷开发的理念，着重介绍了敏捷测试用例设计，敏捷开发以及敏捷自动化测试。关键字: 敏捷开发、敏捷测试、敏捷原则、敏捷理念、敏捷测试用例设计Agility tests and Agile developmentGuolei Liu(China University of Petroleum (East China) College

2、 of Computer and Communication Engineering, Qingdao 266555)Abstract：Agile development is a process, not an event. It is a continuous application principle, mode and practice to improve structure of software and the readability of the process. It is committed to maintaining system

3、 design in any time as far as possible simple, clean and expressive.Key words：Agility tests 、Agile development 、Agile principle 、Agile concept、Agile test case design引言：敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑模型与快速原型法的影子，也许还有多改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合

4、取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。在敏捷开发的过程汇总，通常都会用到一些可以交流工作的软件，它主要是利用非常短的循环，使终端客户可以及时、快速地看到软件的的构建成果。1.敏捷开发与敏捷测试的相关概念敏捷开发：敏捷开发是递增式的、迭代的、不断调整的开发模式。我们逐渐地建立起软件系统，能看到系统在成长，能展示进度。通过多次发布或项目的阶段检查点，每一次都比上一次靠近目标。迭代包括需求的开发和测试。目标随着从上一次的迭代中学到的东西、反馈以及商业机会而调整。在敏捷开发中，工作被分解成“故事”，也叫特性或用例，组合成任务分派给不同的程序员。定义好接受标准，开发直到单元测试和接受

5、测试通过才算完成。 敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。 在敏捷开发中不存在回退，讲究持续地集成，单元测试（通常使用测试驱动的开发方式），持续地进行回归测试。故敏捷开发有一下特点： 1. 敏捷型开发方法是“适配性”而非“预设性”。传统型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法不具有普适性。而敏捷型方法能在软件开发的过程中实时性的进行调整。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。2. 敏捷型开发方法是“面向人”的 (people-oriented) 而非“面向过程”的 (proc

6、ess-oriented)。 它们试图使软件开发工作顺应人的天性、以人为中心。它强调软件开发应当是一项愉快的活动。敏捷测试：敏捷测试的原则与上下文驱动测试（Context-Driven Testing）的原则有交集，两者都强调人的作用。敏捷测试是遵循敏捷宣言的一种测试实践： 1、强调从客户的角度，即是从使用系统的用户的角度，来测试系统。 2、重点关注持续迭代的测试新开发的功能，不再强调传统测试过程中严格的测试阶段。 3、建议尽早开始测试，持续进行回归测试保证之前测试过内容的正确性。2.敏捷开发和敏捷测试的理念和遵循的原则敏捷理念：个体和交互比过程和工具更有价值； 能工作的软件比全面的文档更有价

7、值； 顾客的协作比合同谈判更有价值； 及时响应变更比遵循计划更有价值敏捷原则：敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，而XP中的一些原则又是源于众所周知的软件工程学。 核心原则：主张简单 当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建 （overbuild）你的软件。 图一 敏捷开发拥抱变化 需求时刻在变，人们对于需求的理解也时刻在变。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。 你的第二个目标是可持续性 可持续性可能指的是系统的下一个

8、主要发布版，或是你正在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。 递增的变化 没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型。这就是递增的思想。 令Stakeholder投资最大化 你的project stakeholder为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。stakeholder应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的

9、资源。如果是这些资源是你自己的，你希望你的资源被误用吗。 有目的的建模 对于自己的artifact，首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。多种模型 开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面， 图二 敏捷开发考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术。高质量的工作 没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。 快速反馈 从开始采取行动，到获得行动的反馈，二

10、者之间的时间至关紧要。和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。 软件是你的主要目标 软件开发的主要目标是以有效的方式，制造出满足project stakeholder需要的软件，而不是制造无关的文档，无关的用于管理的artifact，甚至无关的模型。任何一项活动（activity ），如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。 轻装前进 你建立一个art

11、ifact，然后决定要保留它，随着时间的流逝，这些artifact都需要维护。 补充原则：内容比表示更重要 ;了解你的模型 ;了解你的工具 ;局部调整;开放诚实的沟通 ;利用好人的直觉;3.敏捷测试1.公式化的典型的自动化测试过程 1、 购买一个昂贵的GUI测试执行工具（例如 Rational、Mercury、Compuware等） 2、 定义很多测试用例 3、 招聘一个自动化测试组实现每个测试用例的自动化执行 4、 构建一个完整的测试库和框架 5、 不断地完善和修正 2.敏捷自动化测试的原则 1、测试自动化意味着使用工具支持测试项目的各个方面，不仅仅是测试执行方面。 2、当测试自动化得到指定

12、的程序员（toolsmiths-“工具铁匠”）支持时，会不断地顺利进行。 3、“工具铁匠”由测试员领导。 4、“工具铁匠”收集并应用各种各样的工具来支持测试。 5、“工具铁匠”帮助实现可测特性并“打造”工具以便利用这些可测特性。 6、 组织实现测试自动化是为了完成某个短期的目标。 7、 避免盲目进行长期的自动化测试任务，而不是基于业务场景的分析。 3.工具支持测试 1、 测试创建（数据和脚本的产生） 工具可以产生特定的数据，例如：随机的Email信息，或产生数据库，或产生组合参数来覆盖我们的测试。 2、 系统配置 工具可以保持或重现系统参数，把系统设置到某个特定的状态，或创建或回滚到一个“gh

13、ost”的磁盘 3、 模拟 工具可以为测试模拟一些不具备的环境条件，这些环境可能会很难出现或提供起来很昂贵。 4、 测试执行 工具可以操作软件系统本身，模拟用户的GUI操作或绕过GUI层直接使用某些测试接口。 5、 问题分析 工具可以使某些不可见的东西可见。稳定地分析产品或分析log文件，或监视系统参数。 6、“预言” “预言”是通过某些机制来判断错误或成功。工具可以自动地判断产品的某些类型的错误条件。 7、记录和覆盖分析 工具可以帮助记录测试过程覆盖的地方和未覆盖的地方。 8、 试管理 工具可以记录测试结果，组织测试用例。 4.“工具铁匠”的任务 1、 快速响应测试员的请求并提供协助 2、

14、查找影响测试效率的问题 3、 调查测试员关心的问题的可能的解决方案 4、 应用技术改进测试过程 5、 提供产品的可测性功能特性 6、 研究工具并学习怎样使用 7、 收集开发人员或测试员创建的工具 8、 对产品进行评审以便计划自动化的可能性 4.敏捷开发过程中的7种测试类型1.自动化回归测试（Automated regression test） 运行自动化测试代码来验证当前的修改没有破坏已有的功能。 2.单元测试（Unit test） 验证单元级别的代码工作是否正常。 3.公共API测试（Public API test） 验证被第三方开发人员调用的API可正常工作，并且得以文档化。 4.私有AP

15、I测试（Private API test） 验证内部使用的API工作是否正常。 5.命令行测试（Command-line test） 验证在命令行输入的命令工作正常。 6.用户界面测试（User interface test） 验证界面层的功能是否正常。 7.“狗粮”测试（Dog-food test） 这里用了一个有趣的名字“Dog-food test”，自己的“狗粮”自己先尝尝！在企业内部使用自己开发的产品，通过这种实际地使用来确保功能正确，满足使用要求。 5.基于敏捷开发的大型软件自动化测试架构（agile testing）1.敏捷开发给自动化测试带来的挑战：敏捷V.S软件质量可信度变化V

16、.S 测试进度不可控简单V.S 很多“设计”缺陷协作V.S 职责不清楚测试认同感(identity)降低个体化V.S 管理难度加大2.敏捷测试的分类图三 敏捷测试分类3. 测试架构虚拟化节省成本低碳实验室简化管理快速部署失败点调查硬件模拟持续集成集成测试环境部署在生产环境中测试6.敏捷测试用例设计并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认为很多方法、很多地方都可以应用敏捷的思想，实现敏捷的管理。 测试用例的设计是其中一项。 测试用例的粒度 测试用例可以写得很简单，也可以写得

17、很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。 测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。 测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用

18、例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。 大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。 软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工

19、作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。基于需求的测试用例设计 基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。 要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your Testing Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。 不要认为测试用例的设计是一个阶段，

20、测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。 测试用例的评价 测试用例设计出来了，质量如何，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。 测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。 除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是