敏捷测试的方法和实践.docx
《敏捷测试的方法和实践.docx》由会员分享，可在线阅读，更多相关《敏捷测试的方法和实践.docx（16页珍藏版）》请在冰点文库上搜索。
敏捷测试的方法和实践
敏捷测试的最佳实践，第2部分:
方法与实践
前言
如果您已经阅读过敏捷测试系列文章的第一篇，敏捷的实质，您应该已经了解敏捷的定义，了解什么样的团队是敏捷的团队了。
而您也可能早已开始思考，什么是敏捷测试的实质？
敏捷的测试团队又是如何形成自我管理、自我发展的组织呢？
测试团队又是如何安排日常工作呢？
敏捷测试活动与传统测试活动有很大差异吗？
为了进一步让您了解如何将敏捷原则运用到活生生的日常测试活动中，我们为您推荐敏捷测试系列文章的第二篇——敏捷测试的实践。
在敏捷活动如火如荼的推广运动中，我们显然无法预知如何在您的特定的复杂环境中您能否最后达成所愿，也无法为您预测出前进道路的分岔口可能唯一的正确的线路，我们却可以为您点起一盏明亮“街灯”，在这迷雾中驱除黑暗。
我们将为您提供一个可以借鉴和可供参考的成功的敏捷测试实践案例。
我们将逐一向您介绍、分析这个案例中的敏捷团队的组织结构，主要的敏捷测试行为，迭代的测试模型和一套以四周为周期的敏捷测试活动时间表。
请您运用您已具备的敏捷实质、敏捷原则的知识，并结合您的独特项目环境、带着您的问题，与笔者一起再度分析这个案例，希望您最终也能得到满意的答案，并随后开始实施部署敏捷测试。
回页首
敏捷测试的实质
测试不仅仅是测试软件本身，还包括软件测试的过程和模式。
产品发布后才发现很多问题，很可能是软件开发过程出了问题。
因此测试除了需要确保软件的质量，即软件做了正确的事情，以及软件做了应该做的事情以外，敏捷的测试团队还要保证整个软件开发过程是正确的。
敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续的响应客户的频繁反馈。
敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
敏捷测试人员因而需要在活动中关注产品需求，产品设计，解读源代码；在独立完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论，团队决策。
作为一名优秀的敏捷测试人员，他（她）需要在有限的时间内完成更多的测试的准备和执行，并富有极强的责任心和领导力。
更重要的是，优秀的测试人员需要能够扩展开来做更多的与测试或许无关，但与团队共同目标直接相关的工作。
他（她）将帮助团队其他成员解决困难、帮助实现其预期目标，发扬高度协作精神以帮助团队的最终获取成功。
需要指出的是，团队的高度协作既需要团队成员的勇敢，更需要团队成员的主动配合和帮助。
对于测试人员如此，对于开发、设计人员，其他成员也是如此。
回页首
敏捷测试的方法与实践
是的，敏捷测试也需要高度迭代工作、频繁得到STAKEHOLDER、客户的反馈，需要动态调整测试计划、测试的执行。
并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。
是的，“人”才是敏捷的实体，敏捷测试也是以人为本的。
不难理解，“敏捷”的一切都围绕着人展开，如敏捷鼓励直接，平行的沟通；敏捷需要持续的客户反馈以及敏捷活动的设计，方案和决策需要团队协同制定等等，敏捷测试需要一支非同寻常的团队，不同于以往传统开发模式下的团队结构。
关于敏捷团队、敏捷测试团队的组成和介绍，将是我们讲述敏捷测试实践的第一步。
“人”是重心，方法、策略是辅。
为了适应不同的团队结构，不同的项目环境，敏捷项目和敏捷活动的实践也应该因“人”而异，但是，并不是说可以天马行空，我行我素。
一旦脱离了正确的敏捷方法、和敏捷原则的指导，我们的敏捷活动就好比摸黑前行了。
这正是我们需要学习前辈和敏捷主义大师们的经验意义所在了，笔者在过去的实践中受益颇多的也正是前人的实践经验和方法。
因此，学习前人的经验和方法，并运用这些最佳实践来帮助敏捷开发团队，甚至是传统团队来解决时下重要的问题是十分有意义的事情。
笔者不敢妄自尊大将自己的一般实践纳入经典方法范畴，但经历了两年的研究和改进，笔者提出的敏捷测试的原则也得到了业内同僚和“大师”的普遍认可。
经过多次和其他项目团队的经验交流，我们也不断的改进着我们的原则、方法。
因此，笔者要非常感谢参与讨论的同僚们，没有你们的热情参与，也不会有今天的笔者信心百倍的执笔了。
正如笔者在借鉴了前人的成功案例中的经验和方法之后定制了符合项目需求的测试原则一样，相信，读者们在阅读了笔者的敏捷测试原则和方法后，同样也会有所收获。
而对笔者经历的敏捷实践活动中的方法和测试模型的讲解将成为我们讲述敏捷实践的第二步，也是本文的重点。
综上所述，笔者将运用本文的主要篇幅为大家讲解这个敏捷实践。
它们是：
1.敏捷团队组织构成，敏捷测试团队的任务和使命；
2.敏捷开发团队以测试为驱动的开发方式——测试驱动开发，这是种独特的测试？
还是开发？
3.递增型的迭代测试，它首先是对敏捷测试过程活动和生命周期模型的介绍，通过学习经典的敏捷增量测试模型，我们将敏捷测试的各类活动有机的组合到了一起。
在此之上，对定制后的独特敏捷增量测试模型的分析和理解，帮助我们理解测试活动的规划和管理；
4.以及需要特别关注的递增型迭代测试的关键活动之一——“静态测试”；这也是笔者认为的最高难度、最具影响力的敏捷测试活动。
它将测试团队最早的引入产品开发环节，测试人员以第一用户的角度判断设计的有效性，此活动较早的暴露了设计缺陷、避免了团队对目标的不一致理解等，是测试活动中最有创造性价值的部分；
5.最后，笔者将谈谈测试活动中的测试计划和管理，即关于测试任务估计，测试活动计划，各个重要测试活动时间分配与安排的介绍。
然而，敏捷测试不是一蹴而就的，做到真正的敏捷，无论是从传统测试模式向敏捷测试的过渡，还是组建全新的团队都是需要循序渐进的，同时也需要团队成员的通力合作和不断的实践来完善敏捷测试的实践原则和方法。
回页首
敏捷团队
考虑到敏捷团队的组织结构，让我们以笔者亲身经历的项目为例来说明。
笔者曾共事的整支产品开发团队被划分成4个相对独立的敏捷开发队伍，而每支队伍拥有相同配置的7名成员，他们分别具有不同的职能属性。
如图1所示，每支敏捷队伍组成成员角色包括1名UCD（UserCenteredDesigner），主要负责产品的主要设计，其工作主要包括界面设计、用户的用例设计等等；1名VisualDesigner，主要负责产品界面的色彩搭配、控件的外观设计和UCD界面设计方案的初步实现和美化；1名InformationDeveloper，主要负责产品中信息的编辑和重要文档的撰写工作；3名开发人员，主要负责产品的实现。
和1名QA，主要负责产品质量的保障。
（更多的我们将QA定义为具有相比于测试人员拥有更多责任的一个职能，在本文中，为了简便起见，我们仍称之测试人员）。
4支敏捷的队伍拥有相同的SCRUMMASTERSTAKEHOLDER。
通常会在同一时间进入一个迭代周期，制定各自的敏捷计划，并在同一时间退出，发布各自功能实现。
而4支队伍的劳动果实被集成到一起就形成了可发布的产品了。
图1.敏捷开发团队的组织结构
因为敏捷团队中只有1名测试人员，因此需要一臂承担测试策略的制定，测试计划，测试脚本，测试用例设计以及测试的执行，帮助团队发现潜在问题，并协助解决问题的工作。
敏捷团队的敏捷原则也是测试人员敏捷活动的规范，测试也需要拥有和团队的良好沟通，高度迭代的活动和不断的获得STAKEHOLDER的反馈。
那团队的结构与敏捷本身有什么直接关系呢？
与敏捷测试又有多少关联呢？
谈到这里，想起曾经有朋友向我咨询有关敏捷团队的某些职能的人力配备的问题。
其实，笔者也无意论证7个人为什么是最佳组合，为什么不是17个，20个人的组合。
但是，敏捷原则告诉我们敏捷团队是高度协同、民主和平等的团队，为了让团队中每个人充分高效的工作。
相同职能下的组员至多不好超过3名，最佳配置也是不同职能下配置1个人头。
因此、在这样一个小型、平行的组织结构里，沟通更加易于建立，沟通复杂度也相对较低，相比17、20人的团队组织，沟通的代价也小很多。
相反，很难想象在一个敏捷团队中会拥有诸多不同风格的执行者，决策者将是个怎样的混乱情况。
此外，经历过敏捷测试的体验，我们发现一个单一的敏捷团队最好保持较小的“尺寸”。
这是因为拥有很多测试人员的敏捷团队通常不但需要更大的实际工作量来匹配庞大的机体而导致团队任务量更巨大，更复杂，失去自我管理的信心，而每个测试人员也将要花费大量精力和时间投入到内部沟通，和可能因为内部缺乏一致而导致的更加频繁的反复沟通中。
每名敏捷的测试人员需要和其他敏捷团队成员保持频繁而必要的沟通以保证对目标，需求、设计的充分正确的理解，对需求变化能够迅速的做出反应。
另外，还需要与职能队伍中的其他测试成员保持一致性。
如此一来，沟通代价激增了，它将占到测试人员的工作中的较大比例。
而这种内部沟通、协调，却不能定义为敏捷的Backlog项目来计入团队整体的工作输出。
因此，整体的测试效率并不一定随着人力资源的投入而递增。
非但没有实现敏捷原则，而恐怕因为团队的组织结构变得更加庞杂。
所谓的“自我管理、自我发展”的团队只能因而依靠传统的管理和规划了。
笔者认为，除了因为特殊阶段，特殊时期，敏捷团队需要“聚合”更多资源来一并解决存在的高优先级的体力型问题外，敏捷的团队应该尽量保持着较小的“尺寸”。
果真项目投入了很多的人力资源，无论设计还是实现、测试团队拥有较大的人数，那么我们应该考虑将这样的团队可以分得更小些，工作量也相应分得更精细些，直至接近我们建议的最佳组合。
至少我们认为要做好敏捷测试，就要确保敏捷团队中的每一个职能拥有足够清晰的职责范围和一定程度下自由空间和在这个空间内的充分授权。
因此，但从人数和职能构成上，敏捷团队的构成一定是不可忽略的重点。
正像我们前面提到的，确认软件开发过程的正确性也尤为重要，因此作为敏捷的测试人员，更要了解敏捷的过程，比如说，测试人员需要帮助UCD和开发人员确定需求的可行性，测试人员要督促开发人员及时发布build，以保障迭代结果最终能够在通过足够的测试后成功发布等。
在build发布后，测试人员要首先验证当前迭代的任务是否已经完成，其次才是验证产品功能的正确性。
也为了能够在日后重复性和体力型劳动中解放出宝贵的时间去覆盖测试更加紧要的内容，如可用性，全球化等，测试人员需要自动化一部分测试，创新的、灵活的工作。
敏捷团队是自我管理的团队，高度协作的团队，质量目标即是测试团队也是整个开发团队追求的目标，因此开发团队应将做好单元测试，设计团队将帮助测试团队设计好测试用例作为计划内的一项工作。
这里我们推广、建议开发人员采用、普及测试驱动开发模式。
回页首
测试驱动开发
测试驱动开发表现出迭代开发的最核心的就是开发人员自己能够第一时间确认其需求得到了正确实现，而当单元测试覆盖了更多的内容，代码质量也将得到提高。
测试驱动开发的指导思想就是让开发人员在编写功能代码之前，先根据需求编写测试代码。
先思考如何对将要实现的功能进行验证，并完成单元测试脚本的编写，然后编写足够，仅仅足够的功能代码满足这些测试用例，直至通过测试。
按照这个方法，递增的在迭代中增加新功能的单元测试和功能代码编写，直到完成全部功能的开发。
在单元测试活动中，测试人员也被鼓励参与到单元测试的设计中来，不但可以帮助开发人员构思出更多的单元测试用例来扩大单元测试的覆盖率，还可通过学习如何使用单元测试，如何复用单元测试用例到回归测试和功能测试，以达到最大化利用有效的资源（如下图）和节约成本的作用。
同时，在回归测试和用户接收测试（UserAcceptanceTest）中如能将单元测试脚本有机的关联起来，并自动化其执行，更能够进一步提高测试的成效并降低测试成本。
单元测试脚本因随需求、设计的变化随时更新。
需要开发人员站在全局的立场，开发始终坚持先修改测试脚本，再修改产品原代码。
此时，也建议测试人员参与单元测试脚本的改进，帮助开发人员合理的变更单元测试脚本，同时着手修改测试计划和测试策略。
图2.测试驱动开发
回页首
递增的迭代测试
测试驱动开发的原则应该运用于每一迭代周期的开发中。
但是，测试驱动开发的单元测试仍然是以开发为目的的活动，虽然自动化测试，回归测试和用户的接收测试（UserAcceptanceTest）可以通过复用单元测试脚本提高以后的测试工作的效率，但单元测试不是我们敏捷测试讨论的重点。
敏捷测试活动的主要承载者还是敏捷测试人员。
测试人员如何运用敏捷原则指导测试活动还是笔者在敏捷测试实践一文中要讲述的重点。
以下，笔者将通过两个迭代测试模型来帮助了解测试人员如何结合敏捷原则实践敏捷的测试活动。
经典敏捷增量测试模型
测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。
ScottW.Ambler认为就整个产品的敏捷开发生命周期可以分为4个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目建设阶段中，测试被分成两个部分，Confirmatory测试和Investigative测试。
1 下面，我们来讲讲迭代的测试的这两个方面。
图3.敏捷测试生命周期
Confirmative测试就是对build的有效性和关键的功能是否正确进行验证，测试人员依据测试用例和测试脚本的完整测试是工作的重心。
原文中的Confirmative测试包含了开发人员的单元测试（必不可少的重要开发活动）和被称之为AgileAcceptanceTesting的测试部分，这段时间的测试任务用来保障迭代的必须输出的质量。
基本的功能、非功能的任务，但凡是在迭代开始时制定的计划中承诺的高优先级需求，哪怕是很繁琐的细节工作都要被充分的测试和验证。
Investigative测试是对Confirmative测试的补充和是更广泛的测试活动，测试团队在完成Confirmative测试后的时间用来做这部分测试，它包含功能测试，文档测试和系统测试以及和其他产品、环境之间产生的必然的Integration测试，还有个非常有趣的测试活动叫做Exploratory测试，笔者认为这部分测试是测试人员创造性的采用多种不同途径去尝试测试产品。
就好比“猴子敲键盘”一样，测试员使用各种手段来考验build和产品的稳定和正确性等。
图4.敏捷测试的IncrementalTesting
自定制的敏捷增量测试模型
我们在敏捷项目开发的过程中使用了定制的测试流程，我们同样有相同的两部分测试，即Confirmative和Investigative两部分。
不同的是，我们原则的将这两部分测试都放在当前迭代的计划内完成。
原因是，敏捷测试团队针对当前迭代的任务计划本应服务于当前的产品，过去的迭代产物，或者因为需求变更不再适用，又或者因为未解决的质量缺陷使得实际测试效果不佳。
而同时，因为ProductOwner和STAKEHOLDER的期望是团队能够高效的完成当前迭代的任务，完成更高优先级的工作，每个迭代的考核亦非常清晰。
为了完成服从当前的高优先级任务，计划，也为了STAKEHOLDER更好的关注和帮助当前问题的及时解决，测试人员对以往Build的测试应应合理的计入先前迭代的任务而不是当前迭代计划。
倘若真要测试以往的产品而不是最新的，敏捷测试的管理也将变得有些困难，同时测试团队所关注的问题也只能是过时的，只能成为团队的低优先级的问题。
这不是与团队整体的目标背离吗？
因此，我们建议测试团队使用我们改进后的敏捷增量测试模型，即在当前迭代仅仅完成当前迭代的计划，而所有测试都需要围绕最新的产品Build进行。
图5.定制的IncrementalTesting
在我们新的增量测试模型中Confirmative测试包含对需求的静态测试，开发人员做的单元测试，以及Build验证测试，功能测试（仅限于对当前迭代功能）和重要的其他类型测试。
通过了Confirmative测试的产品Build就可以作为在迭代结束时发布了。
而为了产品拥有更好的质量，也为了完成对那些较低优先级的质量验证的需求得以确保成功的实现，我们需要针对性的做系统测试，压力，并发，安全甚至全球化的测试，这部分我们把它叫做Investigative测试。
还需要强调的是，为了保障产品的最终稳定，为了产品不会出现在代码重构后的质量回归现象，我们将回归测试（RegressionTest）放在这个阶段，用以涵盖对以往关键功能的再度验证。
静态测试
在笔者的测试模型里，confirmative测试增加了“静态测试”，本人认为这部分测试是对测试人员最具挑战的部分。
一个好的测试人员能够第一时间找到需求分析、设计中的模棱两可，遗漏，错误的地方，能够促进团队前期工作的高效完成，将很大程度降低将来产品的质量缺陷的数量，积极影响了敏捷开发的最终输出。
这部分工作是测试团队，开发、设计团队最默契合作的阶段，交流非常频繁，正是通过积极的沟通和及时的修正与团队目标“误差”使得团队更加明确其方向，更有凝聚力和也得以发挥了团队的最佳战斗力。
在笔者的项目经历中，往往这个阶段会需要一个迭代周期1/4左右的时间。
这同时也说明了静态测试在敏捷测试类型中的重要性。
在敏捷开发过程的静态测试即项目迭代开发前期测试人员的最主要工作。
值得再次强调的是，在这段时期测试人员的工作重心是认真了解需求和用例设计，并针对设计的可行性，可用性进行验证，确认设计是对需求的准确实现，最佳实现。
图6.静态测试需要的StrategyThinking
对于静态测试的方法，我们在这里需要推广RUP的UseCase，这是个很好的分析需求的方法，也是测试人员作为静态测试的使用的方法之一。
对产品长期战略和业务的熟悉可以帮助测试人员更好的理解团队的用例设计，视图、模块等，也能够通过对比分析，直接找出某些设计中的缺陷，以提高设计的质量。
项目的开发前期阶段，设计是占有非常重要的比例，而设计是直接影响产品质量的环节，因而确保这一阶段的质量对产品的品质提高起到决定性作用。
针对开发出来的用例，设计者对用例的描述通常故事情节比较简单，缺乏完备和逻辑的缜密。
而开发和测试需要的是详细的设计，这个用例设计和各种辅助的逻辑应该将用例定义的清晰和明确，例如边界条件，例外条件，数据的格式和其他性能指标的界定等等都需要涵盖。
因此，测试人员应该领导团队帮助明确出用例更多的细节。
比如，在一次设计用例讨论中，设计者提出“我需要一个Overlayer”。
那么测试人员应该要问：
“如何打开这样一个Overlayer，如何关闭？
”“这个Overlayer需要多大平面尺寸，是否支持调整，是否支持对屏幕大小的自动适应”，“Overlayer的打开和关闭是否需要有动态渐变的效果？
”，“Overlayer的是否需要滚动条？
”，等等。
这个过程能够帮助团队发现早期的设计缺陷，通过发现问题，并定制新的设计方案，团队也通过这个过程，更好的了解了测试的重要性，也摒除了可能存在的对需求的种种“假设”，因而更加明确了团队的目标和方向。
这是个非常关键的过程。
尤其是对测试人员而言，任何“假设“都是有害的，所以一定需要把不清楚和模棱两可的问题从一开始就理清楚。
回页首
敏捷测试的计划与管理
做好了测试的思想准备，并了解如何从需求开发出测试用例，敏捷测试人员接着需要做的就是参考产品需求和团队的设计制定和计划测试任务和各种测试活动，即测试策略和测试计划的制定。
每个迭代敏捷开发都将关系产品的功能点和非功能点的需求作为产品的Backlog编入待开发的序列，敏捷团队从中会选择适量的Backlog项目来作为当前迭代的Backlog去实现。
测试人员同样根据需要制定出相应的测试工作，并罗列于团队的Backlog项目中，承诺了在迭代结束时可以做好的足够的测试工作。
对于测试计划中的confirmative测试，这部分必须做到高质量的按时完成。
而对于Investigative部分，我们应该适量的计划到当前迭代中，切忌不要做overcommit。
图7.计划测试Backlog项目
接着，测试人员需要撰写测试用例和测试脚本了。
测试用例的撰写和传统测试基本没什么差异，按照已有的模式撰写就好了。
笔者的测试团队，使用了XML文件格式保存所有测试用例，原因主要是沿用了测试团队原有的习惯，而同时也因为XML测试用例能够更好的匹配自动化测试的需要，并且便于更新。
测试脚本是自动化测试的产物，敏捷开发周期短，变化多，很难拿到一个稳定的产品再开始做自动化。
而自动化脚本的设计自然要避免去测试不稳定部分，开始的迭代周期几乎百废待兴，自动化作用不大，到了中期，笔者的团队自动化测试才稍成气候。
测试人员需要的是在根据测试策略开发出这相应脚本和用例，需要把握测试范围，与计划和测试策略一致，测试也要量力而行，做到足够的测试，保障迭代的正常退出就很好了。
图8.依据BusinessScenario制定测试策略
敏捷测试的活动时间表
通过实施上述的敏捷测试原则，测试团队可以逐渐形成符合自身特点的敏捷测试流程、敏捷测试最佳实践，久而久之形成独立的敏捷团队文化。
以笔者所在团队为例，历时1年，经历12个迭代后，我们逐渐形成了一套可以遵循测试活动时间表。
我将他放到文章的最后，这张表包含了敏捷测试团队的各项活动安排和必要的前提与进入条件。
在这张表中，测试团队较早的涉入，较早的开展测试，以及各项相关工作，并与设计和开发人员紧密的合作，它确保了测试团队乃至整个敏捷团队的工作的按期完成，是值得向大家推荐一种最佳实践。
因为篇幅关系，这里仅对其做简单的描述。
图9.敏捷测试WorkFlow最佳实践
第一周的工作如先前所讲，做静态测试，确定测试策略和制定可行的测试计划，划定测试范围。
这个阶段的前提是敏捷团队确定了当下迭代周期内需要完成的Backlog项目。
第二周的工作是准备开始测试的执行，因此要准备好测试用例和测试环境。
特别的是，测试人员是根据需求和团队讨论、设计出的用例来开发测试用例的。
虽然测试用例的细节程度不能与传统开发中针对已经开发完的产品、产品开发文档开发的测试用例相比，相反，许多细节，尤其是还未由团队最终确定的内容仍是待定状态；但是，这些细节并非影响测试的用例设计，相反它不但简洁、易懂，也拥有很好的灵活度，它能够实时响应各种变化。
而且，测试用例记录了大量的待定部分，它时刻在测试人员的脑中，测试人员用这种方式简单的告知团队，我们还有未完成的设计和未定的方案，测试用例帮助团队对产品的理解同步于此。
第三周的第三天，第一个可以执行的Build已经能够发布了（这个前提需要开发人员的密切配合）我们开始功能测试了。
到第三周周末，一部分功能测试已经完成，大部分关键功能得到验证。
第四周我们要结束测试，包括Confirmative的测试部分和Investigative的测试。
在迭代验收之前团队要通力合作解决各种能够解决的问题，保障Backlog的如期完成。
这里有一个问题值得再次提出来和大家讨论，或许曾在敏捷项目中的许多人也都遇到了，那就是出现了一些质量缺陷没有来得及在迭代退出前完全解决的现象。
那是不是说明测试不能够退出呢？
笔者的回答是“不”。
迭代的验收时间即是迭代退出时间，也是测试团队必须退出的时间。
在实施中，我们将这些来不及解决的质量缺陷分成三类，一类是“希望能够解决”的质量缺陷，这部分未解决质量缺陷将要成为新一轮迭代的“将做事宜”，甚至可能作为新一轮迭代的需求做到Backlog里。
第二部分是“必须解决”，这部分因为直接关系到最基本，最关键的功能，这样的质量缺陷必须被立刻解决，否则就必须承认本次迭代的失败了。
第三部分是“不再重要的”质量缺陷
升级会员 