一 、 判 断 题 1. 软 件 测 试 就 是 为 了 验 证 软 件 功 能 实 现 的 是 否 正 确 ， 是 否 完 成 既 定 目 标 的 活 动 ， 所 以软 件 测 试 在 软 件 工 程 的 后 期 才 开 始 具 体 的 工 作 。 （ ❌） 分 析 ： 软 件 测 试 人 员 应 在 需 求 阶 段 就 加 入 到 开 发 过 程 中 。 因 为 软 件 的 质 量 问 题 会 随 着 软件 开 发 周 期 的 不 断 展 开 而 不 断 放 大 的 ， 而 更 正 质 量 问 题 的 成 本 也 是 不 断 放 大 的 ， 也 就 是说 在 需 求 阶 段 出 现 的 小 问 题 ， 到 开 发 完 成 后 缺 陷 可 能 成 几 何 倍 数 放 大 ， 而 修 改 所 需 要 的成 本 也 会 不 断 的 放 大 ， 如 果 测 试 工 程 师 能 够 尽 早 的 加 入 其 中 的 话 可 以 尽 早 的 找 出 问 题 ，及 时 发 现 ， 避 免 问 题 最 后 放 大 到 不 可 收 拾 。 2. 发 现 错 误 多 的 模 块 ， 残 留 在 模 块 中 的 错 误 也 多 。 （ ✔） 分 析 ： 开 发 人 员 能 力 参 差 不 齐 ， 当 发 现 某 模 块 bug 数 越 多 ， 修 改 的 bug 越 多 ， 则 引 入 新的 bug 就 会 越 多 ， 那 么 这些新 的 bug 发 现 的 难度要 比修 改 前发 现 bug 要 大 的 多 ， 其 隐藏未发 现 的bug 数 量 就 越 多 ， 那 么 相应 的 模 块 质 量 也 就 越 差 。 代码复用也 可 能 造成 该模 块的 bug 比较多 。 3. 测 试 人 员 在 测 试 过 程 中 发 现 一 处问 题 ， 如 果 影响不 大 ， 而 自己又可 以 修 改 ， 应 立即将此问 题 正 确 修 改 ， 以 加 快、 提高开 发 的 进程 。 （ ❌） 分 析 ： 正 确 流程 应 提交错 误 缺 陷 ， 此时 开 发 组人 员 会 有记录， 并修 改 此问 题 。 如 果 测 试人 员 自己修 改 ， 会 导致开 发 人 员 无记录， 容易出 现 冗余系统版本 ， 并不 清楚哪个为 最 终版本 。 4. 单元测 试 通常应 该先进行“人 工 走查”， 再以 白盒法为 主， 辅...
