敏捷测试策略
在敏捷环境中，我们在短期冲刺或迭代中工作，每个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应该知道如何测试故事，以及是否有任何障碍来测试故事。
防止缺陷
在故事研讨会中， 必须参与PO，BA，Dev和QA。
应该考虑场景（有效，无效和边缘情况）（QA可以通过抽象地思考故事在这里增加巨大价值）并写在特征文件中。
重要的是要注意，在测试产品时会出现缺陷（更重要的是），因此在此活动上花费的精力和时间越多，最终的结果就越好。
由于大多数缺陷都是由于要求不清晰和模糊，这项活动还有助于防止错误行为的实施，因为每个人都应该对故事有相同的理解。
同样，在sprint计划会议中，为故事提供的估算应包括测试工作，而不仅仅是编码工作。QAR（手动和自动化）也必须出现在sprint计划会议中，以提供对故事测试的估计。
发展
开发开始时，新的生产代码和/或遗留代码的修改应该由开发人员编写的单元测试支持，并由另一个开发人员或熟练的SDET进行同行评审。
对代码存储库的任何提交都应该触发从CI服务器执行单元测试。这为开发团队提供了快速反馈机制。
单元测试确保系统在技术级别工作，并且逻辑中没有错误。
开发者测试
作为开发人员，表现得好像您在团队或组织中没有任何QA。诚然，QAs有不同的心态，但你应该尽力测试。
您认为通过快速进入下一个故事节省时间，但实际上，当发现并报告缺陷时，纠正问题需要更长的时间，而不是花费几分钟来确保该功能正常运行。
遗留代码的任何新代码和/或重构都应该具有适当的单元测试，这些单元测试将成为单元回归测试的一部分。
自动验收测试和非功能测试
自动验收测试包括集成测试和服务测试以及UI测试，旨在证明软件在功能级别工作，并且满足用户的要求和规范。
自动验收测试通常用Gherkin语言编写，并使用黄瓜等BDD工具执行。
由于这些测试通常需要通信HTTP，因此需要在已部署的应用程序上执行，而不是作为构建的一部分运行。
非功能测试 （性能和安全性）测试与功能测试同样重要，因此需要在每次部署时执行。
性能测试应检查每个部署的性能指标，以确保性能不会降低。
安全测试应检查从OWASP派生的基本安全漏洞
至关重要的是，这应该是一个完全自动化的过程，只需很少的维护就可以从自动化部署中获得最大的收益。这意味着不应出现间歇性测试失败，测试脚本问题和破坏环境。
故障应仅归因于真正的代码缺陷而不是脚本问题，因此任何不是由于真正故障导致的故障测试应立即修复或从自动化包中删除，以便能够获得一致的结果。
回归测试
不期望发现很多缺陷。他们的目的只是提供我们尚未破坏主要功能的反馈。应该进行非常少量的手动回归测试。
烟雾包 - 不应超过15分钟
此包仅包含高级功能，以确保应用程序足够稳定以进行进一步开发或测试。
例如，对于电子商务网站，此包中包含的测试可能是：
- 产品搜索，
- 产品审核
- 购买物品
- 帐户创建/帐户登录
完整回归包 - 不应超过1小时
此包包含完整的回归测试套件，并包含烟雾包中未包含的所有其他内容。
在这里，目标是通过更多的测试获得快速反馈。如果反馈时间超过1小时，则不会很快。通过使用成对测试技术减少测试数量，根据风险创建测试包或并行运行测试。
UAT和探索性测试
没有理由认为UAT和探索性测试不能与自动验收测试并行运行。毕竟，它们是不同的活动，旨在找到不同的问题。UAT的目标是确保开发的功能具有商业意义并对客户有所帮助。
PO（产品负责人）应运行用户验收测试或业务验收测试，以确认构建的产品符合预期并满足用户的期望。
探索性测试应该关注用户场景，并且应该找到自动化错过的错误。探索性测试不应该找到琐碎的错误，而应该找到微妙的问题。
完成标准
完成上述所有活动并且未发现任何问题后，故事就完成了！
以上是关于敏捷测试策略文档中可包含的内容的一些指导原则。显然，这需要根据您组织的需求进行定制，但希望此模板可以帮助您创建自己的敏捷测试策略文档。