开发与测试：确保我们的信息与通信技术（ICT）系统真正运行顺畅！（教学大纲第 7.3 节）
各位未来的 ICT 专家，大家好！欢迎来到系统生命周期中最关键的阶段：开发与测试（Development and Testing）。想象系统开发就像烘焙一个复杂的蛋糕。分析阶段是挑选食材，设计阶段是编写食谱，而开发阶段则是实际把它烘焙出来的过程。
但在端出蛋糕（执行实施）之前，您必须先“试吃”（测试）！它熟了吗？味道对吗？会不会散掉？在 ICT 中，测试就是我们在系统交给真实用户使用前，找出并修复所有错误（程序缺陷/Bug）的过程。让我们深入探讨如何打造稳固、可靠且零错误的 ICT 系统。
1. 测试的必要性
为什么我们必须费心进行测试？教学大纲明确指出：在系统实施前必须进行测试。
为什么测试是不可或缺的：
• 捕捉错误（Bug）：所有程序都有错误。测试能在这些错误对用户或机构造成严重后果前，将其找出来。
• 确保符合需求：测试能确认新系统的运行是否与客户在分析阶段提出的要求完全一致。
• 系统可靠性：经过严格测试的系统，在上线后较不容易崩溃或产生错误数据。
• 建立用户信心：如果系统从第一天起就运行完美，用户会立即信任它。
您知道吗？ 1996 年阿里安 5 号火箭（Ariane 5）因软件错误导致价值 3.7 亿美元的失败，追溯源头竟是软件中一段未以极限数据进行测试、未受处理的数据转换错误。切记一定要测试！
快速复习：测试的目的
测试的主要目的很简单：确保系统产生的实际输出结果（Actual Outcomes）与设计阶段定义的预期输出结果（Expected Outcomes）完全吻合。如果不一致，我们就要修复错误！
2. 测试策略与范畴
您无法一次测试所有内容。教学大纲指明了测试策略的三个关键层次：
测试每个模块（单元测试，Unit Testing）
此策略涉及将系统的每个单独部分、组件或“模块”拆开来进行独立测试。
• 什么是模块？一个独立的代码块或子系统，例如数据库表结构、单一表单或计算子程序。
• 优点：处理一小段代码时，更容易隔离并找出错误的准确来源。
类比：如果您正在建造一座乐高城堡，模块测试就是在将所有墙壁组合在一起之前，先确认每一小段墙面都组装正确。
测试每个功能（Testing Each Function）
此策略会检查系统中的每一项特定功能或操作运行，以确保它准确执行其预期工作。
• 什么是功能？一项特定任务或操作能力，例如搜索客户记录、计算总销售税、打印收据或验证密码。
• 目的：验证客户指定的每项独立需求在触发时是否都能产生预期输出。
测试整个系统（集成测试，Integration Testing）
当所有模块与个别功能都能单独正常运行后，我们就要测试整个系统如何协同工作。
• 这能确认数据是否能正确地从一个模块与功能流向另一个（例如：输入表单能否成功将输入的详细信息传输至数据库结构中并产生摘要报告）。
• 这提供了全面的测试，确保所有部分在真实环境条件下作为一个统一系统协同工作。
重点总结：测试策略的进程：测试每个模块 → 测试每个功能 → 测试整个系统。
3. 设计测试计划
测试计划（Test Plan）是一份正式文档，详述了将要执行的每一项测试。它确保测试过程是有结构、完整的，并为补救措施（Remedial Action，即修复问题的方法）提供明确步骤。
良好测试计划的组成要素：
对于每个测试用例（Test Case），您必须定义四个关键要素：
1. 测试数据（Test Data）：您将输入系统的数据（输入项）。
2. 预期结果（Expected Outcomes）：系统应该产生的结果。这是预先手动计算或预测出来的。
3. 实际结果（Actual Outcomes）：输入测试数据后，系统实际产生的结果。
4. 测试后的补救措施（Remedial Action Following Testing）：若实际结果与预期结果不符时所采取的行动（例如：“调整验证程序”或“检查文件结构定义”）。
记忆小窍门：您可以将测试计划记为 T.E.A.R. 表格：Test Data（测试数据）、Expected Outcome（预期结果）、Actual Outcome（实际结果）、Remedial Action（补救措施）。
4. 测试数据的类型：寻找极限
为了妥善检查系统，特别是其验证程序，我们必须使用不同类型的数据。
4.1 正常数据（Normal Data）
特性：数据是有效的、符合预期的，且在指定的合理限制（范围）内。
用途：检查系统是否能准确处理标准、正确的输入。
示例：如果表单要求年龄在 16 到 60 之间，正常数据可以是 35。
4.2 极限数据（Extreme Data / Boundary Data）
特性：数据是有效的，但刚好位于可接受范围的上限或下限（边界）。
用途：确保系统能正确处理边界条件。程序员常会犯边界比较错误（例如误用 < 而非 <=）。极限数据能抓出这种错误。
示例：如果年龄范围是 16 到 60，极限数据就是 16 和 60。
4.3 异常数据（Abnormal Data / Invalid Data）
特性：数据是无效的，理应被系统的验证检查拒绝。这包括超出范围的数据、错误的数据类型或格式错误。
用途：测试系统验证程序和错误提示信息的稳固性。我们测试系统是否能阻挡错误数据进入。
示例：
• 超出范围： 年龄 5 岁或 75 岁。
• 类型错误： 在数字年龄字段输入文本“Thirty-Five”。
• 过短/过长： 要求十位数的电话号码却只输入两位数。
常见错误警示！
请勿混淆极限数据（有效的且会被接受）与刚好超出边界的数据（异常的且会被拒绝）。
如果范围是 10 到 20：
• 正常：15
• 极限：10, 20
• 异常：9, 21, "cat"
4.4 使用真实数据（Live Data）
在测试阶段的后期，特别是如果从旧系统迁移数据时，您可能会使用真实数据（Live Data）。
定义：这是曾经由既有（旧）系统处理过的真实数据。
用途：它提供了高度真实的测试环境，因为它模拟了系统正式全面运行后会遇到的实际数据量、多样性和复杂性。
注意：使用真实数据时，必须确保新系统的运行方式不会影响既有系统的运行，也不会损坏真实且宝贵的数据。这通常在并行运行（Parallel Running）（一种实施方式）期间进行。
5. 测试特定的系统组件
您的测试计划必须确保您特别测试了在设计阶段所设计的组件：
测试数据结构与文件结构
这能确保数据库表与文件结构设置正确。您必须检查：
• 字段长度（Field lengths）是否合适（例如：姓名字段够长吗？）？
• 数据类型（Data types）是否正确（例如：“价格”是否设置为数字/货币而非文本？）？
• 主键（Primary Keys）与外键（Foreign Keys）是否能正常维护表之间的关系？
测试输入与输出格式
这是检查用户界面与报表格式：
• 输入格式：检查数据捕获表单和屏幕画面是否直观、易于导航，并能准确捕获所有必要的数据。
• 输出格式：检查报表、屏幕布局和打印文件是否显示正确数值、使用适当标题，且格式正确、排版良好。
测试验证程序（Validation Routines）
系统化地验证所有编写的验证规则是否能拦截无效输入：
• 范围检查（Range Check）：确保数据落在指定的数字或日期边界之内。
• 类型/字符检查（Type / Character Check）：确保数据仅包含允许的字符（例如：电话号码中仅限数字）。
• 长度检查（Length Check）：确保输入项具有精确或允许的字符数量。
• 存在检查（Presence Check）：防止关键字段被留空。
• 格式检查（Format Check）：确认数据符合预定的模式（例如：邮政编码的 LLNN NLL）。
• 校验位（Check Digit）：通过重新计算校验和来验证数字代码（例如条形码或 ISBN）。
重点总结：开发与测试是密不可分的。您开发一小部分，然后使用正常、极限和异常数据彻底测试它。一份结构化的测试计划，就是通往成功、零缺陷系统上线的路线图！