| 术语 | 一句话 | 确认或处理的对象 | 主要时机 |
|---|---|---|---|
| リグレッションテスト | 变更后，重新确认未变更的现有功能是否照旧运行的测试 | 未变更的现有功能 | 修改或新增程序之后 |
| 妥当性確認テスト | 确认系统是否符合用户要求、是否做成了所需之物的测试 | 与用户要求、业务需求是否一致 | 系统能够运行使用的阶段 |
| 受入れテスト | 由委托方主导，判断能否接收所交付系统的测试 | 能否接收的合格判定 | 委托范围交付之后、检收之前 |
| 利用者マニュアル | 汇总用户在业务中使用系统的操作步骤的文档 | 业务中系统的用法 | 在验收阶段准备，投入运行后使用 |
| 移行 | 将数据和业务从现行系统切换到新系统，直到在正式环境开始使用为止的工作 | 从旧到新的业务与数据切换 | 开发结束后到正式运行开始为止 |
回归测试（リグレッションテスト，也叫回帰テスト）是在变更程序之后，重新确认未变更的现有功能是否仍照旧运行的测试。
两类测试都没有问题，就把变更发布到正式环境。
修正或新增功能，有时会在意想不到的地方弄坏别的功能。因此，除了测试变更处之外，还要重新执行以前通过的测试，看结果有没有变化。
类比就像请人修好汽车刹车之后，不只试修过的地方，还把车灯和雨刷也挨个试一遍，看是否照常工作。
记法英语 regress 的意思是“倒退”。从名字就能想起：这项测试看的是质量有没有因为变更而倒退。
考点
确认测试（妥当性確認テスト）是检查完成的系统是否符合用户要求和业务需求，也就是是否做成了所需之物的测试。
它与检查是否按设计书和规格做出来的验证（検証）着眼点不同，问的是做出来的东西到底能否在业务中派上用场。这个名称与其说指某个特定工序，不如说表示确认的着眼点。
类比就像试穿定做的西装，看的不是是否照纸样缝好，而是穿去想去的场合合不合适。
记法英语叫 validation，与 valid（有效的）同源，可以记成“看对使用者是否有效”。
考点
验收测试（受入れテスト）是由委托方（用户）主导，在接近实际运用的条件下使用所交付的系统，判断能否接收它的测试。
接收交付的委托方主导使用，决定能否接收。
它在检收（検収，确认交付物后正式接收）之前进行，确认订购时作为规格提出的功能是否都已具备。图中的顺序是受托方负责到系统测试为止时的典型情况。
类比就像取回送修的自行车时，一边听店员说明一边自己骑一骑，满意了再付钱。
记法决定是否“接受”的是接收的一方——名称里就藏着做这项测试的主语。
考点
| 比较点 | 确认测试 | 验收测试 |
|---|---|---|
| 关键名称所指 | 确认的着眼点的名称（是否做成了所需之物） | 工序的名称（委托方决定是否接收的阶段） |
| 结果的用途 | 找出与要求和业务需求之间的偏差 | 判定合格与否，合格则进行检收 |
用户手册（利用者マニュアル）是记载操作步骤、供使用系统的人在日常业务中参阅的文档。
它的读者不是开发者而是使用系统的人，所以写的不是设计内容，而是按画面操作和业务流程排列的步骤。它在验收阶段准备好，也用作用户教育和培训的教材。
类比就像店里为新员工准备的操作说明，按作业分别写清收银怎么操作、退货怎么受理。
记法名称开头的“用户”就是读者。它和制作者阅读的设计书相比，首先读的人就不一样。
考点
迁移（移行）是把数据和业务从现行系统切换到新系统、直到在正式环境开始使用为止的工作。
迁移数据，把业务切换到新系统，开始正式运行。
迁移包括在正式环境中部署和设置软件的软件导入（ソフトウェア導入），以及迁移旧系统数据、把业务切换到新系统的工作。切换方式要比较停止业务的风险和工作量后选择，例如让新旧系统并行运行一段时间。投入运行后对程序的修正和变更称为软件维护（ソフトウェア保守）。
类比就像把店铺搬进新楼：先定好开张日期和负责人，安装货架和设备，把商品运进去，再换上招牌。
记法英语叫 migration，和候鸟随季节更换栖息地的“迁徙”是同一个词，可以想象成连同行李一起换个住处。
考点
从本单元的过去问中选 5 题
开始做确认题