|
blog.mypm.net
在我们新的增量测试模型中 Confirmative 测试包含对需求的静态测试，开发人员做的单元测试，以及 Build 验证测试，功能测试(仅限于对当前迭代功能)和重要的其他类型测试。通过了 Confirmative 测试的产品 Build 就可以作为在迭代结束时发布了。而为了产品拥有更好的质量，也为了完成对那些较低优先级的质量验证的需求得以确保成功的实现，我们需要针对性的做系统测试，压力，并发，安全甚至全球化的测试，这部分我们把它叫做 Investigative 测试。还需要强调的是，为了保障产品的最终稳定，为了产品不会出现在代码重构后的质量回归现象，我们将回归测试(Regression Test)放在这个阶段，用以涵盖对以往关键功能的再度验证。项目管理者联盟
静态测试项目管理者联盟
在笔者的测试模型里，confirmative 测试增加了“静态测试”，本人认为这部分测试是对测试人员最具挑战的部分。一个好的测试人员能够第一时间找到需求分析、设计中的模棱两可，遗漏，错误的地方，能够促进团队前期工作的高效完成，将很大程度降低将来产品的质量缺陷的数量，积极影响了敏捷开发的最终输出。这部分工作是测试团队，开发、设计团队最默契合作的阶段，交流非常频繁，正是通过积极的沟通和及时的修正与团队目标“误差”使得团队更加明确其方向，更有凝聚力和也得以发挥了团队的最佳战斗力。在笔者的项目经历中，往往这个阶段会需要一个迭代周期 1/4 左右的时间。这同时也说明了静态测试在敏捷测试类型中的重要性。项目经理圈子
在敏捷开发过程的静态测试即项目迭代开发前期测试人员的最主要工作。值得再次强调的是，在这段时期测试人员的工作重心是认真了解需求和用例设计，并针对设计的可行性，可用性进行验证，确认设计是对需求的准确实现，最佳实现。项目管理者联盟
图 6. 静态测试需要的 Strategy Thinking项目管理者联盟
blog.mypm.net
对于静态测试的方法，我们在这里需要推广 RUP 的 Use Case，这是个很好的分析需求的方法，也是测试人员作为静态测试的使用的方法之一。对产品长期战略和业务的熟悉可以帮助测试人员更好的理解团队的用例设计，视图、模块等，也能够通过对比分析，直接找出某些设计中的缺陷，以提高设计的质量。项目的开发前期阶段，设计是占有非常重要的比例，而设计是直接影响产品质量的环节，因而确保这一阶段的质量对产品的品质提高起到决定性作用。针对开发出来的用例，设计者对用例的描述通常故事情节比较简单，缺乏完备和逻辑的缜密。而开发和测试需要的是详细的设计，这个用例设计和各种辅助的逻辑应该将用例定义的清晰和明确，例如边界条件，例外条件，数据的格式和其他性能指标的界定等等都需要涵盖。因此，测试人员应该领导团队帮助明确出用例更多的细节。比如，在一次设计用例讨论中，设计者提出“我需要一个 Overlayer”。那么测试人员应该要问：“如何打开这样一个 Overlayer，如何关闭?”“这个 Overlayer 需要多大平面尺寸，是否支持调整，是否支持对屏幕大小的自动适应”，“Overlayer 的打开和关闭是否需要有动态渐变的效果?”，“Overlayer 的是否需要滚动条?”，等等。项目管理者联盟文章
这个过程能够帮助团队发现早期的设计缺陷，通过发现问题，并定制新的设计方案，团队也通过这个过程，更好的了解了测试的重要性，也摒除了可能存在的对需求的种种“假设”，因而更加明确了团队的目标和方向。这是个非常关键的过程。尤其是对测试人员而言，任何“假设“都是有害的，所以一定需要把不清楚和模棱两可的问题从一开始就理清楚。项目管理者联盟
敏捷测试的计划与管理项目管理者联盟
做好了测试的思想准备，并了解如何从需求开发出测试用例，敏捷测试人员接着需要做的就是参考产品需求和团队的设计制定和计划测试任务和各种测试活动，即测试策略和测试计划的制定。每个迭代敏捷开发都将关系产品的功能点和非功能点的需求作为产品的 Backlog 编入待开发的序列，敏捷团队从中会选择适量的 Backlog 项目来作为当前迭代的 Backlog 去实现。测试人员同样根据需要制定出相应的测试工作，并罗列于团队的 Backlog 项目中，承诺了在迭代结束时可以做好的足够的测试工作。项目管理者联盟
对于测试计划中的 confirmative 测试，这部分必须做到高质量的按时完成。而对于 Investigative 部分，我们应该适量的计划到当前迭代中，切忌不要做 over commit。项目管理者联盟
图 7. 计划测试 Backlog 项目项目管理者联盟
service.mypm.net
接着，测试人员需要撰写测试用例和测试脚本了。测试用例的撰写和传统测试基本没什么差异，按照已有的模式撰写就好了。笔者的测试团队，使用了 XML 文件格式保存所有测试用例，原因主要是沿用了测试团队原有的习惯，而同时也因为 XML 测试用例能够更好的匹配自动化测试的需要，并且便于更新。测试脚本是自动化测试的产物，敏捷开发周期短，变化多，很难拿到一个稳定的产品再开始做自动化。而自动化脚本的设计自然要避免去测试不稳定部分，开始的迭代周期几乎百废待兴，自动化作用不大，到了中期，笔者的团队自动化测试才稍成气候。项目管理者联盟
测试人员需要的是在根据测试策略开发出这相应脚本和用例，需要把握测试范围，与计划和测试策略一致，测试也要量力而行，做到足够的测试，保障迭代的正常退出就很好了。项目管理者联盟
图 8. 依据 Business Scenario 制定测试策略项目管理者联盟
项目管理者联盟
敏捷测试的活动时间表项目管理者联盟
通过实施上述的敏捷测试原则，测试团队可以逐渐形成符合自身特点的敏捷测试流程、敏捷测试最佳实践，久而久之形成独立的敏捷团队文化。以笔者所在团队为例，历时 1 年，经历 12 个迭代后，我们逐渐形成了一套可以遵循测试活动时间表。我将他放到文章的最后，这张表包含了敏捷测试团队的各项活动安排和必要的前提与进入条件。在这张表中，测试团队较早的涉入，较早的开展测试，以及各项相关工作，并与设计和开发人员紧密的合作，它确保了测试团队乃至整个敏捷团队的工作的按期完成，是值得向大家推荐一种最佳实践。因为篇幅关系，这里仅对其做简单的描述。项目管理者联盟
图 9. 敏捷测试 Work Flow 最佳实践项目管理培训
第一周的工作如先前所讲，做静态测试，确定测试策略和制定可行的测试计划，划定测试范围。这个阶段的前提是敏捷团队确定了当下迭代周期内需要完成的 Backlog 项目。项目管理者联盟
第二周的工作是准备开始测试的执行，因此要准备好测试用例和测试环境。特别的是，测试人员是根据需求和团队讨论、设计出的用例来开发测试用例的。虽然测试用例的细节程度不能与传统开发中针对已经开发完的产品、产品开发文档开发的测试用例相比，相反，许多细节，尤其是还未由团队最终确定的内容仍是待定状态;但是，这些细节并非影响测试的用例设计，相反它不但简洁、易懂，也拥有很好的灵活度，它能够实时响应各种变化。而且，测试用例记录了大量的待定部分，它时刻在测试人员的脑中，测试人员用这种方式简单的告知团队，我们还有未完成的设计和未定的方案，测试用例帮助团队对产品的理解同步于此。项目管理者联盟
第三周的第三天，第一个可以执行的 Build 已经能够发布了(这个前提需要开发人员的密切配合)我们开始功能测试了。到第三周周末，一部分功能测试已经完成，大部分关键功能得到验证。项目管理论坛
|
