18｜测试策略（一）：功能上下文划分
徐昊
你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
上节课，我们展示了按照测试驱动开发（Test Driven Development，TDD）的节奏，与大语言模型（Large Language Model，LLM）结对编程（Pairing Programming）的过程。还展示了我们如何使用这样的方式，在保证质量的前提下兼顾速度，获得实打实的效率提升。
然而，我们上节课展示的例子非常的简单，是一个仅仅包含一个类的工具类代码。因而针对它的测试策略也非常的简单。换成更复杂的场景，我们就需要构建有效的测试策略，才能保证通过测试策略得到顺畅的开发节奏。
使用测试四象限构造测试策略
提到测试策略，很多人会不自觉地想到测试金字塔（Testing Pyramid）。这是 2009 年 Mike Cohn 在他的著作《Succedding with Agile》提到的一个隐喻，借助金字塔结构描述不同层次的测试。比如 Mike Cohn 自己就给出了一个三层的金字塔结构，分别对应单元测试（Unit Tests）、服务测试（Service Tests）和用户界面测试（User Interface Tests）。
然而测试金字塔这个隐喻，主要想说明的是自动化测试的分布，以及不同层之间的对应关系。良好的自动化测试，应该符合金字塔式的分布，也就是能够提供快速反馈的细粒度测试占据多数，而缓慢昂贵的粗粒度测试应该只有一小部分。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
1. 测试策略的重要性：构建有效的测试策略是保证软件开发质量的关键步骤，尤其在复杂场景下需要有效的测试策略来保证开发节奏。 2. 测试四象限框架：测试四象限是一个重要的测试策略框架，通过将测试按照目的和受众划分成四个象限，即支持团队和评价产品的技术导向和业务导向测试。 3. 测试四象限的作用：测试四象限框架有助于理解不同种类的测试的作用，帮助设计测试策略，选择合适的测试类型并放置在不同象限中。 4. 验收条件构造支持团队的测试：验收条件对应一组功能测试（Q2象限测试），TDD的任务分解对应一组组件测试（Q1象限测试），通过这种方式可以有效建立Q1和Q2象限测试的关联。 5. 功能上下文的划分：下节课将讨论功能上下文的划分方法，这是构建支撑团队测试的关键问题。 6. 重点总结：构建支撑团队的测试（Q1象限和Q2象限）是至关重要的一步，Q1象限的测试能够撑起上层Q2象限的测试，通过验收条件和TDD的任务分解能够帮助有效建立这两套测试的关联。 7. 问题提出：留言区欢迎分享划分功能上下文的方法，编辑将置顶优质回答供大家学习讨论。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《徐昊 · AI 时代的软件工程》，新⼈⾸单¥98
《徐昊 · AI 时代的软件工程》，新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(4)
- 最新
- 精选
范飞扬1、Q1 象限测试，直接叫“单元级别功能测试”不是更好么？我有三个理由。第一、叫组件测试的话，忽略了类和函数。第二、 光和别人说组件测试，别人也可能理解成是Q2的测试。第三、老师在自己的 TDD 课里就是把 Q1 的测试称作“单元级别功能测试”。 2、那么，很自然的，Q2象限测试叫功能测试就不合适了。难道Q1的测试不是功能测试么？Q1也是功能测试，粒度更小罢了。所以，Q2的测试可以称作“系统级别功能测试”，这样就和Q1的“单元级别功能测试”对应上了。 3、不过，Q2 测试更好的名字可能是 Acceptance Test. 很巧，就在老师说的《Succeeding with Agile》里，Mike Cohn推荐了一本书叫《Test driven: TDD and acceptance TDD for Java developers》。这本书里就提到，ATDD (Acceptance TDD) 帮助开发者构建满足商业需要的软件，而 TDD 帮助开发者保障了软件的技术质量[1]。那么，很自然的，Q2的测试可以称作 Acceptance Test. 4、International Software Testing Qualifications Board (ISTQB) 对于 Acceptance Test 的定义是“验证系统是否满足验收条件的测试”[2]。 从这个定义可以看出，Acceptance Test 直接和验收条件相关联，那么，很自然的，Q2的测试可以称作 Acceptance Test. 5、对于熟悉徐昊老师的TDD课程的同学，Q1 和 Q2 的测试还可以有另一套命名。可以看出，本文需求分解的图片和 TDD 课程里的图片极为相似，就是把功能点称作了验收条件。那么，很自然的，Q2 测试可以称作功能点测试，Q1 测试可以称作功能上下文测试。 6、接着第 5 条，通过和本文的图片进行比对，可以发现当年 TDD 课程里的图片其实漏画了 Q2的测试，应该补上。 7、接着第 5 条，那思考题就很简单了，老师讲过。 思考题：你觉得有哪些划分功能上下文的方法？ 方法一、可以通过预先设计（Upfront Design）的架构愿景（比如 MVC）划分功能上下文。这对应了 TDD 的伦敦学派。 方法二、可以通过演进式设计（Evlutionary Design）提取或梳理架构愿景，再划分功能上下文。主要方法是重构，特别是重构到模式（Refactoring to Patterns）。这对应了 TDD 的经典学派。 注释： [1] : Acceptance test-driven development(acceptance TDD) is what helps developers build high-quality software that fulfills the business’s needs as reliably as TDD helps ensure the software’s technical quality. [2]: https://en.wikipedia.org/wiki/Acceptance_testing2024-04-17归属地：浙江15
王达菲测试的四象限困扰我很久了，主要是几个概念，何为业务？何为技术？比如说安全性，这是业务还是技术。所谓支持团队该如何理解？感觉Q1和Q2是偏向于功能测试，验证功能设计与实现的一致性，那么是不是意味团队就只关注于功能验证？问题有点多，烦劳徐老师解惑2024-04-18归属地：陕西
Gojustforfun> 每一个可测试的任务都对应着一组组件测试（Q1 象限测试） “任务”最终都要落实到代码层面,由代码中的工作单元(抽象模型)即结构体、方法、类、函数等提供功能来完成该“任务”. “可测试的任务”, 相当于在说, 你在设计模型/工作的单元的时候, 除了要提供功能以完成“任务”还要考虑其可测试性——以容易编写测试的方式来设计并实现该模型/工作单元. 先写测试会倒逼你朝着可测试方向设计模型/工作单元. “组件测试”其实也是工作单元/模型的功能测试, 为什么是一组呢? 因为要覆盖正常情况、边界情况和异常情况2024-04-17归属地：北京- Gojustforfun在老师的TDD课程中介绍TDD流程时 https://time.geekbang.org/column/article/496703 有类似的图片, 但用“功能点”替代了这里的“验收条件”. 当然,TDD课程中也说了, “首先将需求分解为功能点，也就是将需求转化为一系列可验证的里程碑点” 是不是可以这样理解: 1. 需求分解的产物就是功能点集合/列表即各个用户故事的验收条件的集合/列表 2. 功能点就是某个用户故事的验收条件 2. “可验证的里程碑点”, 是不是可以理解为, 当某个用户故事的所有验收条件(功能点)都实现了,并且将代码提交后, 此时软件就可以工作、验证的状态.2024-04-17归属地：北京
收起评论