07｜需求提炼（一）：单体应用要测什么？

柳胜

你好，我是柳胜。
通过第一模块价值篇的学习，我们已经掌握了自动化测试效益的量化思维。理解思路还不够，我们在设计篇这个新模块，会把自动化测试里的各种类型、策略和实现技术都梳理一遍，把上个模块学到的知识应用起来，通过科学设计达到测试效益整体最优的目标。
为了让学习过程更接地气，尽可能贴近你日常的工作应用，我们这个模块会围绕一个具体的订餐系统项目，逐一分析它的需求、接口、用户场景，然后制定相应的自动化测试方案。掌握了这套推演逻辑，对单元测试、接口测试和系统测试，哪个层面的测试应该做什么、工作量分配比例是多少，你都能胸有成竹。
今天这一讲，我们的目标是整理出清晰、完整的测试需求，这是所有测试工作开始的第一步。有了这个基础，后面才能制定计划、设计自动化测试用例，完成测试代码开发。
FoodCome 的单体系统我们现在有一个名为 FoodCome 的应用。它刚开发出来的时候是一个单体系统。
这里要解释一下，什么是单体系统。一般的理解是，单体系统是一个整体，用一种语言开发，一次构建所有代码，产生一个部署实体，在运行态下是一个进程。比如常见的 Web 应用，就是一个 war 包。
这个 FoodCome 就是一个 Web 应用，它为用户提供点餐功能。用户可以通过手机下单点餐，订单生成后，餐馆可以接单，厨房制作完成，转给物流交付给用户。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文介绍了单体应用的测试需求提炼过程，通过六边形架构法和用户故事的方式，详细分析了FoodCome单体系统的用户接口和适配器接口的测试需求。作者通过具体的例子和语法关键字模版，展示了如何将功能需求转化为可测试的场景，为后续的验收测试奠定了基础。同时，还介绍了接口契约的概念，以及如何在软件设计阶段定义契约，实现代码，以及测试阶段验证双方是否按照之前定义的契约进行交互。总结了三种方法：六边形架构法、User Story三要素，Gherkins feature表达方法和接口契约，并强调了测试需求的格式化和文档化的重要性。文章还提出了两个思考题，鼓励读者参与讨论。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《自动化测试高手课》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(4)

最新
精选

一默
老师您好，我理解这篇核心基础就是在设计阶段定义契约，我所在的公司是做项目的，在项目初始阶段比较忙，而且只是做了一个架构设计，没有设计阶段，都是凭着开发人员对需求文档的理解直接开发的，没有定义契约，而且需求改动也会比较频繁，请教老师，我们这个时候该如何更有效的运用自动化完成工作。谢谢老师。
作者回复: 从你描述来看，你的公司应该是领域性较强的软件产品，而不是技术性强的产品。在技术性的领域，完全可以在设计阶段进行建模，达成契约，这也是为什么技术性公司像google，amazon，Devops做得好的原因。对于领域性较强的软件产品，混乱和不清楚，是因为软件人员对需求把握不了，甚至需求人员或者客户都无法把需求整得很明白。我的建议，如果你的团队是刚开始做这样的产品，那你就不要自动化，可以用ROI的角度来讲给你的领导，为什么不适宜自动化测试。如果你的团队这样的状态已经持续了很长一段时间，先解决业务设计，领域建模，接口设计这些问题。而从ROI角度来看，可以考虑做单元测试（我知道这在国内公司有点困难）和接口测试自动化（根据情况，适度），谨慎考虑UI自动化测试（不做或少做一小部分）
2022-05-28
2
6
lisa
感觉这块如果仅作为测试团队，我建议基于场景用例，测试用例按照BDD的方式来写。然后结合前面学习到的内容，哪些需要在手工/UI自动化上去覆盖、哪些需要在接口自动化层、哪些需要在单元测试层去覆盖。当然更好的方式我理解是去影响产品团队去给出BDD的文档，但是这要求可能有点高需要一步步的去影响。
作者回复: 说得很好！
2022-04-06
2
4
Sarah
目前公司实践，也是以BDD的思想来落地，开发团队和测试团队一起完成AC的输出，并与产品团队进行review。在这个阶段AC，优先级，测试策略都讨论清楚，产品确认之后进行开发和自动化开发(实践中)。这些AC也被用作常规的测试用例使用，所有角色focus 在这些成果上，所有变更维护都从这些AC开始修改。
作者回复: 谢谢分享！可以看出，你们团队是一个成熟的团队！
2022-04-19
2
2
ifelse
学习打卡
2024-02-11归属地：浙江



收起评论