テストでバグ発見！（4）懐かしい「解の公式」のプログラムからバグを探し出せ：山浦恒央の“くみこみ”な話（146）（3/4 ページ）

4．解答

　今回は、解の公式を用いて、2次方程式の解を求めるプログラムを出題しました。

4.1 問題の意図

　今回の問題は、「仕様に書いてある数値計算が正しくテストできているか」を意図しています。問題のプログラムでは、意識的に間違った数式を記述しました。詳細は以下の通りです。

（1）a＝0かつD＞0の場合、x1の算出結果が正しくない

　a＝0かつD＞0の場合、x1の算出式にバグを入れました。

バグ：x1 = (-b + math.sqrt(D)) / 2 * a #ここのカッコが不正

　正しくは下記です。

正解：x1 = (-b + math.sqrt(D)) / (2 * a)

　プログラミングでは、割り算と掛け算の優先順位は同じです^※2）。その場合、左から順番に計算するため、(2 * a)をする前に分子を2で割ってしまいます。

※2）プログラミング言語によって、異なる場合があります。

（2）a＝0かつb≠0の場合の算出結果がおかしい

　以下のようにわざと逆転させました。

バグ：x1 = b / -c #ここは逆

　この記述だと、4x + 16 = 0の場合、4 / -16となり、プログラムの出力結果は、0となります。正しくは以下です。

正解：x1 = -c / b

（3）メッセージが正しくない

　a＝0かつb＝0かつc≠0の場合、解なしと出力するところが「甲斐なし」となっています。これは、誤字脱字ですね。筆者のワードの変換で「甲斐なし」とでてしまい、そのまま使うこととしました。

4.3 テスト項目作成例

　テスト項目の作成例を表2に示します。

　今回は、数式の記述間違いを検出するテスト項目を例題として作りました。他にも、「3変数の境界値」「出力結果の小数が切り捨てられるか」「小数の入力値（本問題のプログラムではエラー処理をしていないため実行時にエラーが発生します）」などのテスト項目も考えられます。

4.4 バグレポート

　以下に3件のバグレポートを示します（図1〜3）。

図1　バグレポート1（クリックで拡大）

図2　バグレポート2（クリックで拡大）

図3　バグレポート3（クリックで拡大）

4.5 気付き

　気付きとして、以下が考えられます。

• 入力値に不正な値が入ることを本当に考慮しなくてよいのか
• 出力結果が小数の値になるのに、本当に切り捨ててしまってよいのか

　上記以外にもさまざまあるかと思いますので、自分なりの気付きをまとめていただければと思います。

5．おわりに

　今回は、解の公式をテストするプログラムを出題しました。いかがでしたでしょうか。見慣れた数式でも、注意してチェックしないとバグは見つかりません。また、込み入った計算式では、開発担当者が式の書き間違いや計算の優先順位を意識しないでプログラムすることも少なくありません。他にも数値演算では以下を考えるとよいでしょう。

• 演算誤差はないか
• そもそもの仕様の式が間違っていないか
• 数値演算系の標準関数に範囲外の値を入れていないか
• オーバーフローやゼロ除算とならないか

　皆さんが、解の公式のプログラムを作成・テストすることはないでしょうが、上記のようなバグがないかレビューやテストをしておくことが重要です。