敏捷测试之迭代开始

敏捷测试之迭代开始第1页，共15页，2023年，2月20日，星期一

为什么要开始迭代迭代模型是RUP（RationalUnifiedProcess，统一软件开发过程)推荐的周期模型。迭代是循环，往复反馈的一个过程。理解：我们大家可以这样想：我们开发一个产品，如果不太复杂，会采用瀑布模型，这样几个月过去了，直到最后一天发布时，大家可以见到一个完整的产品。这种模型周期相对短些，成本相对低些。但这样的方式有明显的缺点，假如我们对用户的需求判断的不是很准确时，你工作了几个月甚至是几年，当你把产品拿给客户看时，客户往往会大吃一惊，这就是我要的东西吗？如果采用迭代模型：假如这个产品要求6个月交货，我在第一个月就会拿出一个产品来，当然，这个产品会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以后，会提出更详细的修改意见，这样，你就知道自己距离客户的需求有多远，我回家以后，再花一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来，给客户看，让他们提意见。就这样，我的产品在功能上、质量上都能够逐渐逼近客户的要求，不会出现我花了大量心血后，直到最后发布之时才发现根本不是客户要的东西的情况。缺陷：那就是周期长、成本很高。优势：在应付大项目、高风险项目时——就比如是航天飞机的控制系统时，迭代的成本比项目失败的风险成本低得多（降低项目风险低，成功率高，特别是大型项目），用这种方式明显有优势。第2页，共15页，2023年，2月20日，星期一迭代的开始1，迭代计划了解细节考虑所有观点书写任务卡片确定工作量2，可测试的故事3，与客户协作4，高层次测试和事例与客户一起审查与开发人员一起审查测试用例作为文档敏捷测试人员在迭代开始时的活动？第3页，共15页，2023年，2月20日，星期一

17.1.1了解细节

理想情况下，产品负责人或者客户团队的其它成员参加迭代计划会议，回答大家的问题，并且提供示例来描述每个故事的需求。如果业务方面的人都无法参加，那么团队中工作与客户紧密相关的成员们可以充当客户的代理，比如分析师。他们会在迭代会议上解释故事的细节，并从客户的角度做决策，或者简单的记录大家的问题以便依次快速回答。17.1迭代计划第4页，共15页，2023年，2月20日，星期一

我们在本书中始终强调，最好通过举例子的方式来帮助团队理解每个故事，并把这些示例写成测试用例来驱动开发。按照故事的优先级为他们排序。

故事应该事先经过评估，以保证每个故事能在几天之内完成。如果我们每隔几天就能拿到可测试的小故事，我们肯定不会把它们压到迭代末期才去完成。

敏捷测试人员以及其他团队成员们都应该警惕“范围扩展”的趋势。如果发现一个故事好像越做越复杂了，无需犹豫，赶紧两处红牌警告。Uesrstory中的Lisa的团队总是特意找出那些华而不实的或者“最好有”的组件，因为他们并非故事的核心功能。这类功能可以最后再做，如果该故事的实际开发时间比计划时间长，他们也可以暂时不做。第5页，共15页，2023年，2月20日，星期一

17.1.2考虑所有的观点

作为测试人员，需要从整体的角度考虑每个故事对系统其它部分可能的潜在影响。就像在产品发布计划会议中那样，站在不同角色立场考虑问题——用户，利益相关者，程序员，技术文档编写者以及每个参与开发功能的人员。

Userstory：在迭代计划会议中讨论为某个Web添加新图片，这是大家的讨论记录：PM：“我们来谈谈那个添加图片的故事吧”RD1:“大家觉得完成它需要多长时间？”（时间）RD2：“很快，可能半天就差不多了”RD3：“那么数据库的变动呢”（数据库）RD2：“我已经计算在里边了”RD1：“那好半天”RD4：“等等，上个迭代里我们发现了几个性能方面的问题，如果我们再添加照片，性能就更差了”（性能，联动因素）RD1：“好吧，看来我们得慎重考虑这个问题了，还有其它方法吗？”RD2：“我建议我们可以做个快速的尝试，添加些图片再做一遍性能测试如何？”（好的建议）会议总结：在故事开始之前，我们做这样一次讨论，让我们搞清楚了我们可能会遇到的问题，这种情形很不错。如果不太确定某个故事会对系统其它部分产生什么影响，或者不了解开发某个功能的难度，都可以并且应该在迭代计划阶段提出来，尽早暴漏不确定因素，为之做更多的研究或尝试以获得更多的信息。基于不同的视角来提问有助于明了故事地方主旨，并且能让团队的工作更有成效。

第6页，共15页，2023年，2月20日，星期一17.1.3书写任务卡片

在整个团队都对故事有了清晰的了解之后，可以开始评估并写到任务卡片上了。因为敏捷开发方式通过测试来驱动编码，我们同时编写测试和开发任务卡片。有的团队喜欢把测试任务直接写在其开发任务的卡片上。这是种简单的解决方法，因为很显然一个开发任务只有当它通过了测试之后才能算是“已完成”。这种做法可以避免形成“小瀑布”的趋势，也就是把测试留在最后来做，这通常会让RD觉得既然这个故事已经提交给了QA，它就已经完成了。总之，选择一种适合你们团队的任务卡片编写的方式即可。在写开发任务卡片时，要保证编码任务的评估值包括了写单元测试和程序员要做的其它测试时间。测试人员有责任确保每张卡片的估计值都是合理的。如果估计值的误差达到2倍以上，那么有必要进行再次讨论并重新估值。测试数据是评估测试任务时需要考虑的另一个事项。所以获取测试数据所花费的时间也应该考虑到评估时间里。第7页，共15页，2023年，2月20日，星期一17.1.4确定工作量

身为一名测试人员，我们的职责是保证有足够的测试时间，而且还要不断提醒团队测试和质量是整个团队共同的责任。当团队要决定在迭代中可以交付多少故事时要明确其标准是：“我们能够完成多少编码和测试工作？”。有时候有些故事的代码编写十分简单，但是测试却是很复杂需要花费很多的时间。作为测试人员，要记住重要的是你只能同意将能够完成测试的故事加入到迭代中。如果必须要对迭代中交付的故事作出承诺，就应该作出保守的承诺。第8页，共15页，2023年，2月20日，星期一17.2可测试故事当你研究故事而开发人员开始思考如何实现它们时，请始终考虑如何测试它们。即故事具有可测试性。

Userstory：当团队正在重写多步过程的第一步时，令人意外的是，当开始编写新步骤时，过程的其它步骤都失败了，除非第一步完整的实现了，否则迭代中的任何改变都无法测试（说明此故事不具有可测试性）。在计划故事时没有考虑可测试性。导致了这样的问题。在下一次发布时，他们吸取了之前的教训，RD在页面上创建了一个额外的按钮，允许测试人员选择要么调用新页面或者旧页面以测试其它故事。如果不知道怎么测试某个故事的可测试性，请在迭代计划会中提出来。

第9页，共15页，2023年，2月20日，星期一17.3与客户协作

与客户或者客户代表（如功能测试人员）紧密合作是敏捷测试人员最重要的工作之一。当启动迭代时，客户协作也进入了更高阶段。此时，请求客户提供更高的示例，在白板上讨论，然后将这些示例转化为驱动编码的测试。即使产品负责人和其他客户在迭代规划期间和之前解释说明了故事，有时在迭代开始时简要温习一下也是有帮助的。不是所有人之前都听到过，再之客户可能还有更多的信息。第10页，共15页，2023年，2月20日，星期一17.4高层次测试和事例

我们需要“全局性”的测试来帮助开发人员确保故事的正确方向。通常，我们建议从示例开始，然后将其转化为测试。高层次测试应该表现故事背后的主要意图。它们可能包括预期和非预期行为的示例。分布式团队（不在同一区域）需要通过电子网络方式获得高层次的测试，而在同一区域工作的团队可以通过在白板上画画来合作，甚至与客户坐在一起，在编码时告诉他们的需求在迭代启动时，要注意快速了解每一个故事的基本需求，并在适合团队的情境中表述出来。大多数敏捷团队的最大问题是如何充分理解每个故事一准确发布客户所需的东西。他们的代码可能没有缺陷，但是也许不完全符合客户的预期功能，或者在客户不断澄清自己的需求时，他们在迭代时不得不重复大量工作，并最终导致消耗了时间而无法按时完成故事。第11页，共15页，2023年，2月20日，星期一

17.4.1与客户一起审查持续与客户保持协作关系是非常重要的。与客户审查高层次测试是加强协作与沟通的好机会，特别是对新的敏捷团队来说，在团队中习惯了不断讨论故事，需求和测试用例之后，可能不需要坐下来回顾每一个测试用例。如果团队通过合同开发软件，需求和测试用例可能是必须提供的东西。即使不是，最好通过客户易于自己理解的形式提供测试用例。

第12页，共15页，2023年，2月20日，星期一17.4.2与开发人员一起审查

与开发人员坐下来审查高层次测试和需求，如果与你工作的同仁在外地，想办法安排电话会议沟通。如果团队成员难以理解高层次测试和需求，下次就尝试别的办法。具备良好领域知识的RD能够理解故事并在高层次测试编写前开始编码。即便是这样，最好还是与开发人员从客户和测试人员的角度审查故事。他们对故事的理解可能与你不同，请关注这种区别。测试用例有助于把故事置于应用其余部分的环境中。开发人员可以利用测试帮助他们正确编码。所以才要尽可能在迭代一开始就编写测试——RD开始编码之前。我们通常会询问RD:我们遗漏了什么（Editcase）？代码的高风险区域是什么？他们认为测试应该关注哪些地方？获得更多技术观点有助于设计详细的测试用例。第13页，共15页，2023年，2月20日，星期一17.4.3测试用例作为文档

高层次测试用例，加上