組み込みエンジニアの現場力養成ドリル（8）

野球「マジック」点灯のバグ（その1：問題編）（2/5 ページ）

公開 2018年09月10日 09時00分

更新 2018年10月18日 14時09分

著者

山浦恒央　東海大学大学院組込み技術研究科非常勤講師（工学博士）

[TechFactory]

印刷する連載新着通知を受け取る

高校の期末テストとテストケース設計

　ソフトウェアのテストケース設計は、期末テストのような試験の問題作成方法に似ています。英文法の試験であれば、先生は以下のように想定して問題を作るはずです。

（1）生徒が基本的な英文法を理解しているか？

　例：動詞に「ed」をつけると過去形になる。「I develop a program」の過去形は「I developed a program」になる。

（2）生徒が変則的な文法も理解しているか？

　例：have → hadやtake → tookなど、変則的な変化をする動詞がある。

　先生はまず、生徒が基本を理解していることを確認する問題を作り、その次に、「takeの過去形をtakedと思っている生徒がいるかもしれない」と間違いや勘違いを予測し、それを検出するための問題を作ります。生徒の間違いや勘違いを想像し、予測できないと、テスト問題は作れません。

　ソフトウェアのテストケースも同じ考え方で設計します。まず、正常ケースが動作するか一通りチェックし、続いて、異常ケース、境界ケースを想定します。自分が想像できない予測できないバグは、目の前にぶら下がっていても検出できません。この「想像力」と「予測力」は、品質制御エンジニアの最重要能力だと思います。

本当は簡単なマジック・ナンバーの計算

　今回のテーマは「マジック・ナンバー計算プログラム」用のテストケース設計です。マジックの計算を理解する前に、優勝と引き分けを定義します。これをキチンと決めないと優勝の判定やマジックを計算できません。両者を以下とします（最もオーソドックスな定義でしょう）。

優勝の定義、引き分けの扱い

優勝

　（1）勝率が最も高いチーム

　（2）同率の場合は、勝数の多いチーム

　（3）勝率、勝数とも同じ場合は、直接対決の勝ちが多いチーム

　（4）勝率、勝数、直接対決勝数が同じ場合は、決定戦で決める。

引き分けの扱い

　（1）試合数に入れない（0.5勝0.5敗としない）。

　「プロ野球のマジック・ナンバー計算プログラム」のテストケースを設計する前に、マジックの基本を理解しなくてはなりません。まずマジックの目的ですが、「いろいろなチームの勝敗数と残り試合数から、優勝するチームを簡単に予測する目安にする」ことにあります。これが大前提です。

　マジックの計算は複雑に見えますが、基本は簡単かつシンプルです。点灯の条件は「他のチームが残り試合を全勝しても（自チームは全ゲームで対象チームに負ける）、自チームがある勝ち数をあげれば、優勝できる状態になること」です。

　以下に例を挙げます。A、B、Cの3チームがそれぞれ各チームと50試合ずつ、計100試合を戦うとして、今、下記の状況にあるとします。Aが圧倒的に勝っていますが、既に優勝しているのでしょうか？　あるいは、Bに優勝する可能性はあるのでしょうか？　マジックは出ているのでしょうか？

A、B、Cチームによるリーグ戦

次ページへ優勝可能性の判定

印刷する

組み込みエンジニアの現場力養成ドリル

このコラムでは、組み込みエンジニアが日々の開発で実際に遭遇する「小さなトラブルを」取り上げ、演習形式で解説します。

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

山浦恒央　東海大学大学院組込み技術研究科非常勤講師（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科准教授、2016年より非常勤講師。主な著書・訳書は、「Advances in Computers」（Academic Press社、共著）、「ピープルウエア第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。