問36
頻出度★★★
テスト担当者がソフトウェア結合テストを実施したところ, 実行結果がテスト仕様書の記述と異なっていた。テスト担当者の対応として, 適切なものはどれか。
平成23年度 特別試験 ITパスポート試験 問36
マネジメント系システム開発技術 › システム開発技術
这道题的解析和你的作答记录。
解説
問 36
错误ア
「对包括此前正常结束部分在内的所有测试数据进行重新审查」是错误的。这次发现的是某个特定测试用例与预期结果之间的不符, 首先应该做的是记录这一事实并委托开发人员修改。把已经正常结束的测试用例也一并纳入, 对全部测试数据统一重新审查, 既不能直接查明不符的原因, 也不能直接带来修正, 属于过度的应对, 会浪费工时并让测试进度不必要地拖延。即使确实对整体测试数据的妥当性产生了怀疑, 那也要在原因分析的结果出来之后由负责人判断并下达指示, 而不是测试人员在发现一处不符时就擅自开始的工作。
错误イ
「由测试人员修改测试用例后, 再次执行测试」是错误的。测试规格说明书和测试用例是经过一致同意的基准, 是判断有无缺陷的尺子; 仅仅因为执行结果对不上, 测试人员就擅自改写尺子一方, 那么本应被检出的程序缺陷就会被放过, 结果等于把缺陷隐瞒起来。即使原因确实是测试用例的记述有误, 也应当先记录这一事实, 经过负责人的评审和批准, 在正式的变更手续 (配置管理) 中修订测试规格说明书, 而不是由测试人员自行修改后重新执行。
错误ウ
「由测试人员修改程序, 继续进行测试」是错误的。修改程序是开发人员的职责; 如果由测试人员来做, 测试的人和修改的人就成了同一个人, 测试的独立性和客观性随之丧失。而且, 测试人员在没有记录也没有批准的情况下直接改动源代码, 配置管理 (版本管理) 的管控就会崩溃, 哪个版本加入了什么修改也将无法追溯。即使修改对别的地方产生了副作用也无法察觉, 缺陷的原因分析和质量统计 (故障的件数与倾向) 同样无从留存。发现的问题不要自己去修, 记录下来并退回给开发人员才是原则。
- エ
正解 正确答案是 エ「记录问题, 委托开发人员进行修改」。软件集成测试是把已完成单元测试的多个模块 (程序) 组合起来, 确认模块之间的接口与协作是否按规格运行的工序。这里使用的测试规格说明书中, 针对每个测试用例事先规定了输入数据、执行步骤和预期结果, 因此执行结果与说明书的记述不一致, 就意味着预期结果与实际结果出现了不符, 也就是发现了疑似缺陷 (故障)。此时要求测试人员做的应对有两点。第一, 准确记录事实: 在什么时候、于哪个测试用例中、给出了什么输入数据、预期结果是什么、实际结果如何、复现步骤是怎样的, 整理成故障单 (缺陷报告书、Bug 单) 保存下来。第二, 把该故障单交给开发人员, 委托其进行修改。判断原因究竟是程序的错误, 还是测试用例或规格说明书一方的错误并加以改正, 是开发人员和负责人的职责; 修改之后再由测试人员重新进行确认测试和回归测试。像这样把发现问题的人 (测试人员) 与修改问题的人 (开发人员) 分开的职责分离, 正是支撑测试客观性和质量记录可信度的基础。エ 原样描述了这一流程, 因此是适当的。
ここがポイント
- 在测试工序中, 原则上要把执行测试的人 (测试人员) 与修改程序的人 (开发人员) 的角色分离开。测试人员一旦发现预期结果与执行结果之间的不符, 就要把复现步骤、输入数据、预期结果、实际结果记录到故障单 (缺陷报告书) 上, 委托开发人员修改, 并对修改后的版本进行确认测试和回归测试。不得自己去修改程序或改写测试用例。
- 软件集成测试是把已完成单元测试的模块组合起来, 验证模块之间接口与协作的工序 (流程为 单元测试 → 集成测试 → 系统测试 → 运行测试)。测试规格说明书中规定的预期结果就是判定合格与否的基准, 如果测试人员擅自更改它, 就会导致缺陷被隐瞒。而且一旦没有留下记录, 质量管理和配置管理都将无法成立。
用語