組み込みエンジニアの現場力養成ドリル（9）
野球「マジック」点灯のバグ（その2：解説編）（1/3 ページ）
前回に引き続き、プロ野球でおなじみの「マジック・ナンバー（通称：マジック）」をテーマにお届けします。今回は、「第三者が開発した『マジック計算アプリケーション』のテストケースを設計せよ」というお題に対する「形式テスト」と「正常テスト」について取り上げます。
はじめに
今回の講座では、プロ野球でおなじみの「マジック・ナンバー（通称：マジック）」をテーマにしています。
前回は、マジックの定義や計算方法を具体的に紹介しました。マジックの計算は、高性能計算機を使い、複雑な式やロジックを駆使していると思いがちですが、実は掛け算と割り算だけの単純で原始的な方法で算出しています。中学3年生レベルの数学力と思考力があれば、マジックを計算できます。ただし、漏れなくきちんと考えることは容易ではありません。そのためには、システマチックなアプローチが必要です。PCが一般的でなかった昔は、電卓で面倒な計算をしていましたし、電卓が登場するはるか以前の1800年代のアメリカメジャーリーグ時代は、紙と鉛筆と頭だけで計算していました。
今回は、「第三者が開発した『マジック計算アプリケーション』のテストケースを設計せよ」というお題に対する「形式テスト」と「正常テスト」を見ていきましょう。
テストケースの設計の基本
前回も紹介しましたが、ソフトウェアにおける「テストケースの設計」は、高校の英文法の先生が作る期末試験の問題に似ています。英語の先生は、やみくもに問題を作っているのではなく、全ての設問に“意味”があります。おそらく英語の先生は、以下を想定して問題を作るはずです。
- 生徒が、基本的な英文法を理解しているか？
動詞に「ed」を付けると過去形になる。「I develop a program.」の過去形は「I developed a program.」になる - 生徒が、変則的な文法も理解しているか？
have→had、take→tookなど、変則的な変化をする動詞がある
先生はまず、生徒が基本を理解していることを確認する問題を作り、その次に、「takeの過去形をtakedだと思っている生徒がいるかもしれない」と間違いや勘違いを予測し、それを検出するための問題（いわゆる、ヒッカケ問題）を作ります。生徒の間違いや勘違いを想像し、予測できないと、期末テストの問題は作れません。
ソフトウェアのテストケース設計も、英語の先生と全く同じ考え方で設計しますが、さらに“ディープ”です。まず、正常ケースが動作するかを一通りチェックし、続いて、異常ケース、特異ケース、境界ケースを「全て」想定してテストします。英文法の試験の場合、不規則変化動詞を全てテストすることはありませんが、ソフトウェアでは「全件」検証します。ものすごく大変ですね。漏れや想定できないケースがあると、目の前にぶら下がっていても、バグを検出できません。この「想定力」や「妄想力」は、品質制御エンジニアの最重要能力だと思います。
日本のソフトウェア開発業界には、「テスト技術者は、開発エンジニアより技術レベルが低い」と誤解している人がいますが、実際はその反対です。「高校生」がプログラマーなら、「英文法の先生（よりも厳しい先生）」がテスト技術者です。テスト技術者は、プログラマーよりもはるかに高い知識、想像力、予測力と経験が必要なのです。
「漏れのないテスト」は重要ですが、テストケースの数も同様に重要です。必要最小限のテスト項目数にしましょう。ぼんやりとテスト項目を作ると、あっという間に1万件を超えてしまいます。テスト項目数が爆発的に増える原因は、「全ての組み合わせを律義に考慮するため」です。
例えばプロ野球のマジック計算で、「広島が1位の場合」「ヤクルトが1位の場合」「巨人が1位の場合」……と、6球団全てに対し、マジックを正しく計算できるか考える必要はありません。1球団だけで十分です。全部の組み合わせをテストするには100年もかかり、「開発に半年、検証に1世紀」という本末転倒状態になります。40年前からプログラマーに伝わる「同値分割」を適用し、必要最小限のテスト項目数にしましょう。
「異常ケースは漏れなく、組み合わせケースは手抜きで十分」の感覚がつかめると、プロのテスト技術者ですね。この講座が少しでも、「バグにヒットする打率が高いテスト項目を設計」する実践力を身に付ける上での助けになれば幸いです。
テスト項目設計の準備
1．「処理」より「機能」
プログラマーがどのようなロジックや考え方で「マジック計算ソフト」を作るのかは、全く予測できません。「1時間経過したらベルを鳴らす」装置を設計する場合、「1時間」をゼンマイ式の時計で測ったり、電池式のデジタル時計を使ったりと何を使うか分かりません（砂時計、日時計、水時計、線香の時計などかもしれません）。まずは、実装方法（処理方式）を考慮せず、“機能そのもの”をテストしましょう。
2．優勝の定義と引き分けの扱い
今回、A、B、Cの3チームが、他チームとそれぞれ50試合、合計100試合を戦い、優勝を決めるとします。また、優勝の定義と引き分けの扱いは以下の通りとします。
- 優勝
（1）勝率が最も高いチーム
（2）同率の場合は、勝数の多いチーム
（3）勝率、勝数とも同じ場合は、直接対決の勝ちが多いチーム
（4）勝率、勝数、直接対決勝数が同じ場合は、決定戦で決める - 引き分けの扱い
（1）試合数に入れない（0.5勝0.5敗としない）
3．テスト項目の形式
テスト項目は以下のように、具体的な「入力データ（勝敗表と残り試合数）」と、「期待する出力」のペアとします。下記の「勝敗表」があれば、残り試合数も計算できますが、分かりやすくするため「残り試合数の表」も付加することとします。
テストケースの設計で重要なのは、具体的に書くことです。「各チームに自力優勝の目がある場合、『全チームが自力優勝可』と表示するか？」のように、漠然としたテスト項目や、テスト実施者に考えさせるテスト項目ではなく、上記の勝敗表と残り試合数のように、具体的な数字を指定しなければなりません。ソフトウェア工学の授業で学生にテスト項目を設計させると、「データにエラーがある場合、エラーメッセージを表示するか？」と書いてくることもあり、私の頭痛は止まりません……。
Copyright © ITmedia, Inc. All Rights Reserved.
組み込みエンジニアの現場力養成ドリル
このコラムでは、組み込みエンジニアが日々の開発で実際に遭遇する「小さなトラブルを」取り上げ、演習形式で解説します。
この記事の著者
新着ホワイトペーパー PR
-
製品資料
[株式会社 Green AI] AIで脱炭素計画を最適化、初年度からエネルギーコストとCO2を削減する方法 -
市場調査・トレンド
[スマートジャパン編集部] 「ペロブスカイト太陽電池」の普及戦略が公表 政府が目指すコスト・導入量のロードマップを解説 -
市場調査・トレンド
[スマートジャパン編集部] 導入が加速する再エネ・系統向け蓄電システム コスト・収益性の現状分析 -
技術文書・技術解説
[スマートジャパン編集部] いまさら聞けない「ペロブスカイト太陽電池」の基礎知識と政策動向 -
技術文書・技術解説
[スマートジャパン編集部] 「ペロブスカイト太陽電池」の開発動向、日本の投資戦略やコスト目標の見通しは？
関連記事
こんなメディアも見られています
TechFactoryに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
特集
- マテリアルズ・インフォマティクスの動向調査
- 研究・開発職のデジタル活用調査
- 設計・解析業務におけるAI活用
- 3Dプリンタ利用動向調査
- CAD利用動向調査
- つながる工場の現状と課題
- 製造業におけるAI開発および活用の実態
- 設計・製造現場における品質管理
ホワイトペーパーランキング PR
-
1
EE Times Japan×EDN Japan 統合電子版：フィジカルAIが生み出す新たな「設計思想」――電子版2026年8月号
-
2
半導体装置メーカー 業績まとめ【2027年3月期第1四半期】
-
3
新入社員に読んで欲しい鉄鋼材料の基礎知識まとめ（Part4）
-
4
一時は時価総額トヨタ超え キオクシア2026年度の動向
-
5
微細配線間の絶縁劣化をどう捉える？ 先端パッケージ評価の最前線
-
6
新入社員に読んで欲しい鉄鋼材料の基礎知識まとめ（Part1）
-
7
EE Times Japan×EDN Japan 統合電子版：2026年上半期の半導体業界を振り返る――電子版2026年7月号
-
8
新入社員に読んで欲しい鉄鋼材料の基礎知識まとめ（Part3）
-
9
CADツールの見直しは本当に必要？ 切り替えの理由と効果を7つの質問で検証
-
10
新入社員に読んで欲しい鉄鋼材料の基礎知識まとめ（Part2）
TechFactory SNS
@techfactory_itmをフォロー
インフォメーション
注目情報をチェック
TechFactoryをフォロー