ソフトウェアのテストが大変なことになっています

自動車もソフトウェアで動く

あきらかにコンピュータが動いてるとわかるものから、一見なんのためにコンピュータを使っているのかわからない製品まで、近頃はなんでもかんでもソフトで動くようになりました。

後者の代表格として自動車があります。最近の自動車は効率よく(=燃費よく)走るために、アクセルの踏み加減や現在の速度などさまざまな要素を加味して、プログラムによってガソリンと空気の混合比率を逐次最適化しながら走行しています。ブレーキも、人間が急にペダルをベタ踏みしても、タイヤがロックしないように、プログラムが間に入って効き具合を調整しています。

このような⁠機能⁠は、ECU(Electronic Control Unit)と呼ばれる小型コンピュータにプログラムとして搭載されます。ECUの数は年々増加傾向にあり、いまでは100を超える車種もあります。

組み合わせテストは爆発だ!

ソフトウェアで実装されたさまざまな機能は、最終的には複数の機能同士が正しく連動しなくてはなりません。つまり、⁠あれとこれを組み合わせて正しく動くか」ということを確認する必要があります。これを一般的に、組み合わせテストなどと呼びます。

さて、ここにYes/Noの2つしか値を持たない10個の機能を搭載した製品があるとします。テストの組み合わせは1024通り(2の10乗)です。1つのテストが3分で終わるとすれば、51時間ですべてのテストが実行可能です。余裕、余裕。

では、30個の機能ではどうでしょうか。組み合わせ数は10億を突破します。10億というのは、不眠不休で1回のテストを1秒で処理し続けて32年弱、という数字です。100のECUが搭載された自動車のテストの組み合わせは…、数えたくもありません。

テストオペレータからテストエンジニアへ

このような「組み合わせ爆発」に代表されるように、単純な力押しではソフトウェアのテストをこなすことは不可能となっています。そこで、専門的な知識(テスト技法)やノウハウによって、効率的なテストを設計/実施できるエンジニアが求められています。

本書は、そのようなテストエンジニアとしての第一歩に最適の一冊です。