开发者测试 作为开发人员,表现得好像您在团队或组织中没有任何QA。诚然,QAs有不同的心态,但你应该尽力测试。 您认为通过快速进入下一个故事节省时间,但实际上,当发现并报告缺陷时,纠正问题需要更长的时间,而不是花费几分钟来确保该功能正常运行。 遗留代码的任何新代码和/或重构都应该具有适当的单元测试,这些单元测试将成为单元回归测试的一部分。 自动验收测试和非功能测试自动验收测试包括集成测试和服务测试以及UI测试,旨在证明软件在功能级别工作,并且满足用户的要求和规范。 自动验收测试通常用Gherkin语言编写,并使用黄瓜等BDD工具执行。 由于这些测试通常需要通信HTTP,因此需要在已部署的应用程序上执行,而不是作为构建的一部分运行。 非功能测试 (性能和安全性)测试与功能测试同样重要,因此需要在每次部署时执行。 性能测试应检查每个部署的性能指标,以确保性能不会降低。 安全测试应检查从OWASP派生的基本安全漏洞 至关重要的是,这应该是一个完全自动化的过程,只需很少的维护就可以从自动化部署中获得最大的收益。这意味着不应出现间歇性测试失败,测试脚本问题和破坏环境。 故障应仅归因于真正的代码缺陷而不是脚本问题,因此任何不是由于真正故障导致的故障测试应立即修复或从自动化包中删除,以便能够获得一致的结果。 回归测试不期望发现很多缺陷。他们的目的只是提供我们尚未破坏主要功能的反馈。应该进行非常少量的手动回归测试。 烟雾包 - 不应超过15分钟 此包仅包含高级功能,以确保应用程序足够稳定以进行进一步开发或测试。 例如,对于电子商务网站,此包中包含的测试可能是: 完整回归包 - 不应超过1小时 此包包含完整的回归测试套件,并包含烟雾包中未包含的所有其他内容。 在这里,目标是通过更多的测试获得快速反馈。如果反馈时间超过1小时,则不会很快。通过使用成对测试技术减少测试数量,根据风险创建测试包或并行运行测试。 UAT和探索性测试没有理由认为UAT和探索性测试不能与自动验收测试并行运行。毕竟,它们是不同的活动,旨在找到不同的问题。UAT的目标是确保开发的功能具有商业意义并对客户有所帮助。 PO(产品负责人)应运行用户验收测试或业务验收测试,以确认构建的产品符合预期并满足用户的期望。 探索性测试应该关注用户场景,并且应该找到自动化错过的错误。探索性测试不应该找到琐碎的错误,而应该找到微妙的问题。 完成标准完成上述所有活动并且未发现任何问题后,故事就完成了! 以上是关于敏捷测试策略文档中可包含的内容的一些指导原则。显然,这需要根据您组织的需求进行定制,但希望此模板可以帮助您创建自己的敏捷测试策略文档。
|