1. 编码环节：从“能跑”到“能维护”
1.1 编码规范为什么不是形式主义
教科书在讲编码的时候，通常会把“编码风格”“命名规范”“注释规范”这些内容放在最开始，很多同学觉得这部分就是“排版要求”，可有可无。但真到了项目里，编码规范直接决定了这个项目能走多远。
我见过太多“能跑就行”的代码，跑起来确实没问题，但三个月后需求一变，没人愿意去改，因为改一个方法要顺藤摸瓜翻七八个文件，变量名全是a、b、data、temp，没有注释，逻辑全靠猜。最后只能推倒重写。这其实就是编码阶段偷懒的代价。软件工程里的编码，不只是“把需求翻译成代码”，更是“把代码写得让别人能看懂、能维护”。
从工程角度讲，编码规范至少解决三件事：
- 降低沟通成本。团队里每个人的习惯不同，如果没有统一规范，你写的缩进和他写的换行都不一样，合并代码时空格差异就能引发几十处冲突，纯粹浪费时间。
- 减少低级错误。比如命名规范里要求“局部变量首字母小写、常量全大写”，这不只是好看，而是让读代码的人一眼就能判断变量的作用域和是否可修改，避免误用。
- 便于代码审查。好的规范让审查者能快速定位问题，不用把时间耗费在“这段代码在干什么”上，而是聚焦“这段代码对不对、好不好”。
有人会问：个人项目也要搞规范吗？我的建议是，哪怕只有自己看，也值得养成习惯。这跟你一个人住要不要整理房间是一个道理——整理不是为了给别人看，而是为了自己找东西的时候不抓狂。我现在接手任何一个新项目，第一件事就是看它的命名风格和目录结构，基本就能判断这个项目的健康程度。
1.2 代码审查：给别人挑错，也被别人挑错
代码审查（Code Review）是编码环节里最容易忽视、但回报率最高的一步。说白了，就是写完代码不要急着提交合并，让团队里其他人看一遍。别小看这个过程，很多隐蔽的问题就是在这一步被拦下来的。
审查主要看几个层面：
- 逻辑正确性：这段代码在不同输入下是不是都能得到正确结果？有没有遗漏边界条件？
- 可读性：换一个人来看，能不能在十分钟内看懂思路？需不需要反复追问？
- 安全性：有没有潜在的崩溃风险？数据会不会被意外修改？有没有资源泄漏？
- 可扩展性：下次需求变化的时候，这段代码是容易调整，还是要推翻重写？
我在实际项目里遇到过最典型的例子：一个同事写了一个批量导入功能，测试用例全过，但在代码审查时发现，如果导入的文件里有一行格式错乱，整个程序会直接崩溃，而不是跳过这一行并继续处理剩余数据。这个bug靠功能测试很难触发，因为测试数据往往都是工工整整的；但真实用户上传的文件千奇百怪，最终这个解决方案是在审查阶段提出并修正的，避免了上线后的重大事故。
代码审查也是新手成长最快的方式之一。你写代码的时候觉得自己思路天衣无缝，但被同事问一句“这个状态如果重复触发会怎样”，往往就能发现自己漏掉的场景。反过来，帮别人审查代码，也能学到很多自己不熟悉的写法和技巧。特别是刚入行的同学，我强烈建议主动申请参与代码审查，哪怕只是旁听，收获也远大于埋头自己写。
1.3 编码完成不等于任务完成：集成环节的认知
很多初学者有一个误解，认为“代码写完、能编译通过、功能没问题”就算完成了。但在软件工程里，编码完成只是第一步，紧接着的集成往往是真正的战场。
集成指的是把各个模块组合到一起，让整个系统跑起来。难点在于：每个模块单独测试都没问题，不代表合在一起就没问题。接口参数不匹配、数据格式不一致、调用顺序依赖、并发冲突——这些问题只有在集成时才会暴露。
举一个我曾经踩过的坑：一个项目里有三个小组分别开发订单模块、库存模块和支付模块，各自测试都通过了。集成联调的那天，订单模块调用库存模块的接口，发现库存服务返回的是JSON格式，但订单模块期望的是XML；支付模块回调订单模块时，因为超时设置太短，导致商城内部分订单在支付成功后被系统误判为失败，又自动发起了退款。这些问题的根源不在单个模块内部，而在于模块之间的约定没有拉齐。
所以现在很多团队都在推行“持续集成”，也就是代码提交后自动编译、自动跑测试、自动部署到测试环境。目的就是在每次代码变动时尽早发现集成问题，而不是等到最后一天合并所有代码，一次性面对一堆无法定位的错误。这个过程在教科书里只是简单提了几句，但它在真实研发流程里占据的时间，往往是编码本身的好几倍。
2. 测试的层次与设计思路
2.1 测试金字塔：从底层到顶层的策略
软件工程里讲到测试，绕不开一个概念叫“测试金字塔”。它把测试分成三个层次：底层是单元测试，数量最多；中间是集成测试；顶层是端到端测试，数量最少。为什么是金字塔形状？因为越底层的测试运行越快、执行成本越低、定位问题越精准，所以要大量覆盖；越顶层的测试虽然更接近真实用户场景，但运行慢、环境依赖重、出了问题也不好定位，所以只能重点覆盖核心流程。
单元测试针对的是“一个函数或一个类”的行为，验证它的输入输出是否符合预期。这就像检查一台机器里的每个零件——螺丝拧好了没有、齿轮转不转得动。集成测试针对的是“多个模块协作”的场景，例如用户下单后库存减扣和订单状态更新是否能正确联动。端到端测试则模拟真实用户从打开页面到完成操作的完整流程，相当于整条流水线跑一遍。
很多团队的误区是一上来就死磕端到端测试，总想着“测试要模拟真实用户”，结果写了一堆又慢又脆弱的用例：网络一抖就失败、界面多一个按钮就全红、跑一次要二十分钟。最后大家都懒得跑了，测试沦为摆设。正确的思路是：把70%的精力放在单元测试和集成测试上，端到端只覆盖最核心的冒烟流程。
2.2 测试用例设计的三板斧：等价类、边界值、判定表
写测试用例是最能体现“工程思维”的环节。不是把所有可能的输入都测一遍——那是不可能的，而是用最少的用例覆盖尽可能多的场景。教科书里常用的方法有三种，我到现在都还在用。
等价类划分：把输入数据按“程序处理方式是否相同”分成若干类，从每个类里取一个代表值测试即可。比如一个模块要求输入“1到100之间的整数”，输入数据可以分为三类：合法整数（1到100）、小于1的数、大于100的数。合法整数这个类里你测10和测77本质上是一样的，那就不需要把每个数都测一遍。
边界值分析是等价类的补充。很多bug就藏在边界的左右两侧，因为程序员写判断条件时最容易大意的地方就是“大于”和“大于等于”只差一个等号。测试1、100这两个合法边界的邻值——0、101——是必须的，有时候还要测一下负数和0这样容易被忽略的特殊输入。
判定表适合处理“多个条件组合决定结果”的逻辑。比如某个优惠活动规则是“满100减20，且仅限新用户，且非生鲜品类”，这三个条件组合下来有八种情况，判定表可以帮你逐条列出，确保没有遗漏。我早年在电商系统里就靠判定表发现了两个条件组合里隐藏的问题：非新用户买生鲜满200本该不打折，但程序误判成打折了。这种问题靠随机测试很难碰到，但如果按判定表去设计用例，一查一个准。
这三种方法不是独立的，实际工作中往往组合使用。先划等价类确定大致范围，再用边界值补边界，最后用判定表梳理条件组合。一套组合拳下来，用例的质量会比“随便点点”高出几个量级。
2.3 覆盖率：数字好看不是目的
覆盖率是衡量测试完整度的重要指标，常见的有行覆盖率、分支覆盖率、条件覆盖率等。行覆盖率指的是被执行的代码行数占总代码行数的比例，分支覆盖率指的是条件判断的真假分支是否都被执行过。
覆盖率当然越高越好，但要清楚一个前提：覆盖率只告诉你“哪些代码被执行了”，并不告诉你“这些代码被验证得是否正确”。换句话说，覆盖率是必要不充分条件。
我遇到过有团队为了凑覆盖率，专门写一堆“跑一下但是不做断言”的用例，用工具一统计，覆盖率90%以上，上报给领导很好看，但实际上啥也没验证。这就有点自欺欺人了。正确的姿势是先保证断言质量，再追求覆盖率。断言才是测试的灵魂——你说一个函数“返回结果正常”，到底“正常”是什么标准？断言就是把标准写下来，程序自动去比对。
对于新项目，我一般建议单元测试覆盖率的目标定为行覆盖率80%以上、分支覆盖率70%以上；核心模块（比如支付、订单、登录）可以适当提高；而那些只是包装调用、没有复杂逻辑的胶水代码，不必强求覆盖率。
3. 自动化测试与常见误区
3.1 从手工测试到自动化测试：如何迈出第一步
手工测试是“人肉点来点去”，自动化测试是“写代码让代码去测代码”。很多初学者一听到自动化测试就觉得很高级，觉得要学一堆框架。其实第一步远没有想象的那么复杂。
我建议从项目里最稳定、最频繁回归的功能模块开始。拿一个登录功能举例，手工测试每次改完代码都要输入用户名密码、点登录、看跳转结果，重复次数多了既枯燥又容易漏。自动化要做的事情就是把这一套动作用代码固化下来：打开页面、输入数据、点击按钮、断言跳转结果与用户信息。
以Python生态为例，接口测试可以用pytest加requests库，UI自动化可以用Selenium或Playwright。起步阶段不需要搭建多复杂的框架，先写一个脚本能自动跑通核心流程，就已经比纯手工前进一大步了。等你发现脚本越来越多、维护成本变高的时候，再考虑引入测试框架、数据驱动、关键字驱动这些进阶手段。
3.2 测试稳定性：最容易被低估的敌人
自动化测试跑起来之后，最让人头疼的不是“测试发现了bug”，而是“测试没发现bug，但自己挂了”。用例失败的原因不是被测系统出问题，而是环境因素：测试数据被上一次运行污染了、某个操作需要等待5秒但脚本只等了3秒、本地网络慢导致页面没加载完就断言了。
这种“测试不稳定”如果处理不好，一定会被团队慢慢抛弃。人都是有惰性的——每次跑测试都有两个莫名其妙的报错，查了半小时发现是环境问题，谁还愿意天天跑？
解决不稳定问题有两条基本原则：
- 保证测试独立性。每个测试用例执行前都应该尽量准备好自己的数据，不要依赖其他用例的执行顺序和结果。
- 显式等待代替固定等待。比如UI测试里“等页面元素出现”要用轮询机制，而不是一味地sleep。固定时间等待看起来简单，但运行环境一变，它就变成了失败率最高的来源。
我早期写过一批单测，本地全部通过，一上CI（持续集成）就有几个失败。排查到最后发现，测试用例之间共享了同一个临时数据库，运行顺序不同，数据状态就不同，导致用例结果不可预期。后来改成每个用例跑前自动重建、跑后自动清理，这个问题才彻底解决。
3.3 测试数据管理：为可重复执行打底
测试数据是自动化测试里的隐形工程。没有一套稳定可控的数据管理策略，测试跑得越多，数据污染就越严重，到最后测试环境里的数据长得像生产环境一样“丰富”，反而无法预判结果。
常用的策略有三种：
- 数据独立准备：每个用例在执行前通过API或者SQL初始化自己需要的数据，执行后清理。适合关键业务链路。
- 数据复用池：准备一批固定不变的基础数据（比如测试账号、商品信息），多个用例共用。适合那些本身不修改数据的只读场景。
- 数据随机生成：每次运行时生成全新的数据（比如随机手机号、随机邮箱），避免重复冲突。适合注册、创建订单这类会落库的场景。
看起来都是细节，但细节决定成败。一套能稳定重复跑的自动化测试，背后一定有一套严谨的测试数据设计方案。
4. 从理论到实践：一个小型模块的编码与测试流程
4.1 示例模块：订单金额计算的核心逻辑
聊了这么多理论，用一个实际例子把整个流程串起来。假设我们要实现一个订单金额计算模块，需求如下：
- 订单包含多个商品，每个商品有单价和数量。
- 订单满100元减20元。
- 新用户额外打95折。
- 以上优惠可叠加。
这个需求看起来简单，但里面藏着不少边界条件。我们按“先设计测试用例，再写代码”的思路来做——这也是测试驱动开发的简单入门方式：先用测试把“正确”的定义写清楚，再让代码去满足这些定义。
4.2 测试用例：先写用例再编码
根据需求，我列出如下核心测试用例：
| 用例编号 | 场景描述 | 输入 | 预期输出 |
|---|---|---|---|
| T01 | 普通用户，商品总额不满100元 | 总额80元，非新用户 | 80元 |
| T02 | 普通用户，商品总额刚好100元 | 总额100元，非新用户 | 80元 |
| T03 | 普通用户，商品总额超过100元 | 总额150元，非新用户 | 130元 |
| T04 | 新用户，商品总额不满100元 | 总额80元，新用户 | 76元 |
| T05 | 新用户，商品总额刚好100元 | 总额100元，新用户 | 76元 |
| T06 | 新用户，商品总额超过100元 | 总额150元，新用户 | 123.5元 |
| T07 | 空订单 | 空列表 | 0元 |
| T08 | 商品单价或数量为负 | 单价-5，数量2 | 抛出异常 |
为什么要先写用例？因为用例就是需求的数字化表达。代码还没写，我们已经把“正确”的标准定下了。后面编码时，每一个用例就是一个验收标准，跑通一个就完成一块，这比把所有功能写完再回头测试要高效得多，因为你能精确地知道哪里对了、哪里还差着。
4.3 编码实现与测试代码的配合
先写一个最初版本的实现逻辑。假设我们用Java来描述：
public class OrderCalculator { public double calculate(List<Item> items, boolean isNewUser) { if (items == null || items.isEmpty()) { return 0; } double total = 0; for (Item item : items) { if (item.getPrice() < 0 || item.getQuantity() < 0) { throw new IllegalArgumentException("单价和数量不能为负"); } total += item.getPrice() * item.getQuantity(); } if (total >= 100) { total -= 20; } if (isNewUser) { total *= 0.95; } return total; } }然后写对应的单元测试。我习惯用JUnit 5来写，每个用例对应一个测试方法，方法名尽量描述清楚场景，方便别人看懂失败时是哪个场景出了问题。
@Test void testNormalUserTotalBelow100() { OrderCalculator calculator = new OrderCalculator(); List<Item> items = Arrays.asList( new Item(30, 2), // 总价60 new Item(20, 1) // 总价20 ); double result = calculator.calculate(items, false); assertEquals(80, result, 0.001); } @Test void testNewUserTotalAbove100() { OrderCalculator calculator = new OrderCalculator(); List<Item> items = Arrays.asList( new Item(50, 3) // 总价150 ); double result = calculator.calculate(items, true); assertEquals(123.5, result, 0.001); } @Test void testTotalExactly100() { OrderCalculator calculator = new OrderCalculator(); List<Item> items = Arrays.asList( new Item(25, 4) // 总价100 ); double result = calculator.calculate(items, false); assertEquals(80, result, 0.001); } @Test void testEmptyOrder() { OrderCalculator calculator = new OrderCalculator(); List<Item> items = Collections.emptyList(); double result = calculator.calculate(items, false); assertEquals(0, result, 0.001); } @Test void testNegativePriceThrowsException() { OrderCalculator calculator = new OrderCalculator(); List<Item> items = Arrays.asList( new Item(-5, 2) ); assertThrows(IllegalArgumentException.class, () -> calculator.calculate(items, false)); }建议仔细看一下第7个用例，即“空订单”的处理。需求里没有明确说明空订单应该返回什么，但真实场景里接口完全可能收到空列表。在设计测试用例时主动思考这些需求没有覆盖到的情况，恰恰是测试人员与普通用户最大的区别。
还需要特别注意的是：测试里用到了三个典型值——80、100、150——分别对应“不满100”“刚好100”“超过100”三种情况，这就是前面说的边界值分析在实战中的体现。特别是“刚好100”这个值，很容易在实现时写成 total > 100，导致等于100时折扣不生效，还好我们通过边界值用例把它拦住了。
4.4 可测试性设计：写代码时为测试铺路
很多人写代码的时候完全不考虑“这段代码怎么测”，结果写出来一个几千行的巨型方法，输入输出泾渭不明，测试根本无从下手。这就涉及一个很重要的工程概念：可测试性。
让代码易于测试，一般有几个方法：
- 函数尽量小而单一。一个函数只做一件事，输入输出明确，测试就很好写。
- 避免大量静态方法和全局变量。它们会让测试之间相互影响，也很难做隔离。
- 依赖通过参数传入而不是函数内部直接创建。比如一个支付服务依赖外部接口，把这个外部接口作为参数传进来，测试时就可以传入一个假的实现，而不用真的去调外部服务。
在设计订单计算模块时，如果把促销规则写死在计算函数里，后面每次规则变化都要改函数、改测试；但如果把规则抽成独立策略，就能针对每种规则写单独测试。思路转变带来的提升，可不是一点半点。
5. 常见问题与排查技巧实录
5.1 测试跑不过的常见原因速查表
日常开发中，测试失败的原因五花八门，但其中大部分都可以归纳到几个固定类型。我把这些年遇到的情况整理成速查表，排查优先级可以按这个顺序来。
| 常见原因 | 典型表现 | 排查方法 | 解决思路 |
|---|---|---|---|
| 测试数据被污染 | 单条用例单独跑通过，放一起跑失败 | 按顺序逐条运行，观察失败是否与执行顺序相关 | 用例前后重置数据，避免共享态 |
| 时间等待不足 | UI测试偶发超时，重跑又能过 | 看失败截图，元素是否未出现在页面上 | 改用显式等待，轮询判断元素状态 |
| 环境配置差异 | 本地通过，CI失败 | 对比本地与CI的环境变量、依赖版本、数据库结构 | 统一环境配置，用容器或配置文件固化依赖 |
| 断言太严格 | 浮点数计算结果不相等 | 打印实际值与期望值，观察差异大小 | 根据计算精度设置误差范围 |
| 并发执行冲突 | 测试并行跑时数据互相覆盖 | 查看同一时间点执行的用例列表 | 数据隔离或串行化相关用例 |
| 需求理解错误 | 代码符合文档但不符合真实场景 | 与产品确认行为预期 | 更新需求文档，修正代码与用例 |
这张表我会贴在工作台旁边，每次测试挂掉先按表逐条排除，而不是盲目地改代码或改测试，能省下很多时间。
5.2 测试代码的维护：不只是被测试代码的事
测试代码也是代码，同样要维护、要重构、要评审。很多团队的新代码没人愿意写测试，很大一部分原因是已有的测试代码写得太烂——几千行的测试类、充满重复逻辑的辅助方法、失败信息完全没有提示的断言，谁看了都不想碰。
我自己维护测试代码有一个原则：如果测试代码的复杂度已经接近甚至超过被测代码的复杂度，那就该停下来重构了。测试的职责是帮助理解系统行为，如果它本身还需要花费大量精力才能理解，那它就没有起到应有的作用。
几个实用的维护手段：
- 公共的测试数据构造方法封装成工厂类，避免每个用例里都写一遍长长的对象初始化代码。
- 断言信息要写清楚。比如 assertEquals(80, result, 0.001)，失败时只显示“expected: 80 but was: 75”，并不直观。如果加上业务上下文信息，就能更快定位问题。
- 及时清理废弃的用例。业务逻辑变了，旧的测试用例如果不再有效，要么更新要么删除，千万不能留着“反正跑不过，先注释掉”。注释掉的测试代码就是技术债，会在未来给你挖坑。
5.3 测试先行还是后补？一个折中的方案
关于“要不要测试先行”，业界争论了好多年。支持测试驱动开发的人认为“先写测试再写实现”能保证代码的可测试性；反对的人觉得这会降低开发速度，尤其是需求不明确时，测试根本无从写起。
按我的项目经验，比较务实的做法是：
- 需求清晰的场景，比如算法模块、工具类、接口协议，采用测试先行的方法非常合适。反正需求就在那里，先写用例能把需求落地得更准确。
- 需求模糊的产品功能，比如前端UI交互，可以先写一小段探索性代码，理清思路后再补测试。
- 最忌讳的是上线后完全不补测试。如果一个核心功能模块上线后还没有任何自动化测试覆盖，后面每次改动都是在走钢丝。
我在实践中还有一种折中的写法：先写“大致的测试”，再写实现，让测试从失败到通过，最后再补上遗漏的边界用例。这样既保证测试的驱动力，又不会因为一开始就追求完美的用例设计而卡住思路。
6. 编码与测试之外：工程化思维带来的额外收益
编码与测试在教科书里是两个独立的章节，但在真实项目里，它们始终是一套组合拳。写代码不是把代码写完就扔给测试人员，而是要把可测性刻进编码习惯里；写测试也不是验证“这段代码对不对”，而是为后续每一次重构和迭代提供安全网。
我自己的体会是：自从养成了“先想测试再写代码”的习惯，编码的返工率明显下降。因为测试用例逼着你去思考边界条件、异常输入和需求的隐藏逻辑，这比闷头写代码再回头调试高效得多。
这里也想给在校生或者刚入行的朋友一个建议：千万不要因为这门课是理论课就忽略它。软件工程里讲的编码规范、测试方法、集成策略，每一节都是用大量失败项目换来的经验总结。你现在在课程设计里认真按规范写代码、认真写测试用例，把这些习惯内化了，等进了公司会省去很多被批改代码的尴尬。反过来，如果现在糊弄过去，这些坑迟早会在痛的工作中重新踩一遍。
关于测试，还有一个很多人不知道的小技巧：当一个bug反复出现且找不到规律时，把怀疑点从“代码逻辑”转移到“数据状态”。大多数看似不可能复现的问题，深挖下去都是因为某条数据处于一种异常状态——比如数据库里有一条total为负数的订单，或者某个用户资料里的字段值是NULL。编码与测试的边界其实不像课本里画的那么清晰，真正到了实战中，你往往既要写代码，也要设计数据，还要自己跑测试，所有技能搭配在一起，才是完整的工程能力。
这一章的知识密度在软件工程课程里不算最高，但它的应用频率绝对是最高的。只要你还在写代码，编码与测试就是你每天都要面对的两件事。把这两件事做扎实，你就已经跑赢了很多“能跑就行”的选手。
