| 术语 | 一句话 | 进行时机 | 主要产出 |
|---|---|---|---|
| コーディング | 把详细设计用编程语言写出来，并确认其中没有错误的工作 | 紧接软件详细设计之后 | 源代码 |
| コードレビュー | 不运行源代码、通过阅读来检查的活动 | 代码写完之后 | 指出错误和规范违例 |
| 共同レビュー | 立场不同的相关方一起检查交付物的活动 | 需求定义、设计等各个工序 | 发现与需求的偏差并达成共识 |
| デバッグ | 查明缺陷原因并加以修正的工作 | 发现缺陷之后 | 修正后的程序 |
| ホワイトボックステスト | 依据内部结构设计测试用例的测试技法 | 主要在单元测试中 | 走通内部路径的确认结果 |
编码（コーディング）是把详细设计中确定的处理步骤按照编程语言的语法写出来、形成源代码的工作，也叫编程（プログラミング）。
逐个运行写好的程序，用单元测试进行确认。
把详细设计书中写明的处理流程和数据处理方式逐行换成指令，并确认所写步骤没有错误，都属于这项工作。团队会事先制定统一命名方式、缩进等的编码规范（コーディング規約），让任何人写出的代码都易于阅读。易读的代码能减少之后评审和维护的工夫。
类比就像对照组装说明书把家具组装起来。纸上的尺寸和步骤，被一步步换成实际的部件。
记法code 意为“符号”。从词义联想：把人的想法换成机器能读懂的符号。
考点
代码评审（コードレビュー）是不运行写好的源代码、通过阅读找出错误、规范违例和难懂写法的检查。
由作者以外的人来读，更容易发现作者因先入为主而漏看的错误。缺陷在运行前的阶段发现得越早，需要修改的范围就越小，返工成本也越低。
类比就像提交前请同事读一遍原稿，用红笔标出错字和不好懂的地方的校对。
记法review = re（再一次）+ view（看）。从词的构成记住：把写好的东西“再看一遍”。
考点
联合评审（共同レビュー）是开发者和用户等立场不同的相关方一起确认交付物，检查内容是否符合需求并达成共识的活动。
检查对象是需求定义书、设计书等各工序产出的交付物。有使用方参与，更容易发现仅靠开发者难以察觉的与需求不一致之处。
类比就像盖房子之前，业主和设计师一起摊开图纸，逐个房间确认格局是否符合期望的碰头会。
考点
| 比较点 | 代码评审 | 联合评审 |
|---|---|---|
| 检查对象 | 源代码 | 设计书、代码等各工序的交付物 |
| 关键参与人员 | 主要是开发者之间 | 用户与开发者等立场不同的相关方 |
| 目的 | 找出代码中的错误和规范违例 | 确认是否符合需求并达成共识 |
调试（デバッグ）是针对测试等发现的缺陷，查明原因所在位置并修正程序的工作。
对修改的部分及受其影响的部分再次进行测试。
通过逐行跟踪程序的运行，或显示中途变量的值，来缩小错误所在的范围。修好之后，要对修改的部分和受其影响的部分再测试一遍。
类比就像家里的灯不亮时，依次检查灯泡、开关和线路，找到故障处后把它换掉。
记法bug 是“虫子”。加上 de-（去除），从词源记住：把钻进程序里的虫子清除出去。
考点
白盒测试（ホワイトボックステスト）是一边查看程序的内部结构（指令的排列和分支）一边设计测试用例的技法，主要用于单元测试。
运行，确认结果是否与预期一致。
测试用例要按照内部路径需走通到什么程度的覆盖标准（網羅の基準）来设计。例如，让每条指令至少执行一次的是语句覆盖（命令網羅），让每个分支的真和假都至少走一次的是分支覆盖（分岐網羅）。
类比就像拿着迷宫地图，挑出想确认的岔路实际走一遍，检查有没有死胡同或错误的出口。
考点
| 比较点 | 调试 | 白盒测试 |
|---|---|---|
| 关键目的 | 查明已发现缺陷的原因并修复 | 以内部结构为线索找出缺陷 |
| 工作重心 | 修改程序 | 设计并执行测试用例 |
| 进行时机 | 发现缺陷之后 | 编码之后，主要在单元测试中 |
从本单元的过去问中选 4 题
开始做确认题