怎么写出好的敏捷测试（Agile Tesing）策略文档

敏捷测试策略

在敏捷环境中，咱们在短时间冲刺或迭代中工做，每一个sprint只关注一些需求或用户故事，所以文档在数量和内容方面可能不会那么普遍。

以前咱们得出的结论是，因为时间限制，咱们可能不须要在每一个sprint的敏捷项目中都有一个普遍的测试计划，但咱们确实须要一个高级敏捷测试策略做为敏捷团队的指导。

敏捷测试策略文档的目的是列出团队能够遵循的最佳实践和某种形式的结构。请记住，敏捷并不意味着非结构化。

在这里，咱们来看一个敏捷测试策略样本以及文档中包含的内容。

有关：

测试策略一般有一个任务陈述，可能与更普遍的业务目标和目标相关。

典型的使命宣言多是：

经过提供快速反馈 和 缺陷预防而不是缺陷检测，不断提供知足客户需求的工做软件 。

支持者：

• 在咱们首次定义其验收标准/测试以前，不会为故事编写代码
• 在全部验收测试经过以前，故事可能不被认为是完整的

在敏捷测试策略文档中，我还会提醒每一个人关于质量保证

• 质量保证是一系列活动，旨在确保产品以系统，可靠的方式知足客户要求。

• 在SCRUM（敏捷）QA是每一个人的责任，而不只仅是测试人员。质量保证是咱们为确保新产品开发过程当中的正确质量而开展的全部活动。

测试级别

敏捷测试象限

单元测试

为何：确保代码正确开发

世卫组织： 开发人员/技术架构师

内容： 全部新代码+遗留代码的从新分解以及Javascript单元测试

时间： 一旦编写新代码

地点：本地Dev + CI（构建的一部分）

如何： Automated，Junit，TestNG，PHPUnit

API /服务测试

缘由： 确保组件之间的通讯正常

世卫组织： 开发人员/技术架构师

什么： 新的Web服务，组件，控制器等

时间： 一旦新API开发并准备就绪

地点： 本地Dev + CI（构建的一部分）

如何： 自动化，肥皂用户界面，休息客户端

验收测试

为何： 确保知足客户的指望

世卫组织： 开发人员/ SDET /手册质量保证

内容： 验证故事的验收测试，功能验证

时间： 功能准备就绪并进行单元测试时

地点： CI /测试环境

如何： 自动化（黄瓜）

系统测试/回归测试/ UAT

为何： 确保整个系统在集成时工做

世卫组织： SDET /手册质量保证/业务分析员/产品负责人

内容： 场景测试，用户流程和典型用户旅程，性能和安全测试

时间： 验收测试完成后

地点： 临时环境

如何： 自动（Webdriver）探索性测试

产品积压

软件开发失败的最多见缘由是因为团队中不一样成员的要求不明确和要求的不一样解释。

用户故事应简洁，简洁，明确。做为一个很好的指导方针，最好按照INVEST模型编写用户故事。

一个好的用户故事应该是：

我独立（全部其余人）

N egotiable（不是特定的特定合同）

V aluable（或垂直）

E stimable（很好的近似）

S mall（以便适合迭代）

T estable（原则上，即便尚未测试）

应使用如下格式编写用户故事

As a [role]

I want [feature]

So that [benefit]

重要的是不要忘记“福利”部分，由于每一个人都应该经过开发故事来了解他们所添加的价值。

验收标准

每一个用户故事都必须包含验收标准。这多是鼓励与团队中不一样成员沟通的最重要因素。

接受标准应该在建立用户故事的同时编写，而且应该嵌入到故事的主体中。全部验收标准都应该是可测试的。

每一个验收标准应该有许多验收测试，以Gherkin格式编写，例如

Scenario 1: Title

Given [context]

And [some more context]...

When [event]

Then [outcome]

And [another outcome]...

故事研讨会/ Sprint计划

在每一个故事研讨会中，团队中的每一个人都会了解故事的细节，以便开发人员和QA了解工做的范围。每一个人都应该对故事的内容有相同的理解。

开发人员应该很好地理解提供故事所涉及的技术细节，QA应该知道如何测试故事，以及是否有任何障碍来测试故事。

有关：

• 若是对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣能够175317069，群内会有不按期的发放免费的资料连接，这些资料都是从各个技术网站搜集、整理出来的，若是你有好的学习资料能够私聊发我，我会注明出处以后分享给你们。

防止缺陷

在故事研讨会中， 必须参与PO，BA，Dev和QA。

应该考虑场景（有效，无效和边缘状况）（QA能够经过抽象地思考故事在这里增长巨大价值）并写在特征文件中。

重要的是要注意，在测试产品时会出现缺陷（更重要的是），所以在此活动上花费的精力和时间越多，最终的结果就越好。

因为大多数缺陷都是因为要求不清晰和模糊，这项活动还有助于防止错误行为的实施，由于每一个人都应该对故事有相同的理解。

一样，在sprint计划会议中，为故事提供的估算应包括测试工做，而不只仅是编码工做。QAR（手动和自动化）也必须出现在sprint计划会议中，以提供对故事测试的估计。

发展

测试自动化金字塔

开发开始时，新的生产代码和/或遗留代码的修改应该由开发人员编写的单元测试支持，并由另外一个开发人员或熟练的SDET进行同行评审。

对代码存储库的任何提交都应该触发从CI服务器执行单元测试。这为开发团队提供了快速反馈机制。

单元测试确保系统在技术级别工做，而且逻辑中没有错误。

开发者测试

做为开发人员，表现得好像您在团队或组织中没有任何QA。诚然，QAs有不一样的心态，但你应该尽力测试。

您认为经过快速进入下一个故事节省时间，但实际上，当发现并报告缺陷时，纠正问题须要更长的时间，而不是花费几分钟来确保该功能正常运行。

遗留代码的任何新代码和/或重构都应该具备适当的单元测试，这些单元测试将成为单元回归测试的一部分。

自动验收测试和非功能测试

自动验收测试包括集成测试和服务测试以及UI测试，旨在证实软件在功能级别工做，而且知足用户的要求和规范。

自动验收测试一般用Gherkin语言编写，并使用黄瓜等BDD工具执行。

因为这些测试一般须要通讯HTTP，所以须要在已部署的应用程序上执行，而不是做为构建的一部分运行。

非功能测试 （性能和安全性）测试与功能测试一样重要，所以须要在每次部署时执行。

性能测试应检查每一个部署的性能指标，以确保性能不会下降。

安全测试应检查从OWASP派生的基本安全漏洞

相当重要的是，这应该是一个彻底自动化的过程，只需不多的维护就能够从自动化部署中得到最大的收益。这意味着不该出现间歇性测试失败，测试脚本问题和破坏环境。

故障应仅归因于真正的代码缺陷而不是脚本问题，所以任何不是因为真正故障致使的故障测试应当即修复或从自动化包中删除，以便可以得到一致的结果。

回归测试

不指望发现不少缺陷。他们的目的只是提供咱们还没有破坏主要功能的反馈。应该进行很是少许的手动回归测试。

烟雾包 - 不该超过15分钟

此包仅包含高级功能，以确保应用程序足够稳定以进行进一步开发或测试。

例如，对于电子商务网站，此包中包含的测试多是：

• 产品搜索，
• 产品审核
• 购买物品
• 账户建立/账户登陆

完整回归包 - 不该超过1小时

此包包含完整的回归测试套件，并包含烟雾包中未包含的全部其余内容。

在这里，目标是经过更多的测试得到快速反馈。若是反馈时间超过1小时，则不会很快。经过使用成对测试技术减小测试数量，根据风险建立测试包或并行运行测试。

UAT和探索性测试

若是对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣能够175317069，群内会有不按期的发放免费的资料连接，这些资料都是从各个技术网站搜集、整理出来的，若是你有好的学习资料能够私聊发我，我会注明出处以后分享给你们。

没有理由认为UAT和探索性测试不能与自动验收测试并行运行。毕竟，它们是不一样的活动，旨在找到不一样的问题。UAT的目标是确保开发的功能具备商业意义并对客户有所帮助。

PO（产品负责人）应运行用户验收测试或业务验收测试，以确认构建的产品符合预期并知足用户的指望。

探索性测试应该关注用户场景，而且应该找到自动化错过的错误。探索性测试不该该找到琐碎的错误，而应该找到微妙的问题。

完成标准

完成上述全部活动而且未发现任何问题后，故事就完成了！

以上是关于敏捷测试策略文档中可包含的内容的一些指导原则。显然，这须要根据您组织的需求进行定制，但但愿此模板能够帮助您建立本身的敏捷测试策略文档。

感兴趣的小伙伴能够来加群：747981058，你们一块儿来交流，讨论~