Opinion : テストという辛気くさい作業 (2015/12/21) 　 自分は仕事で函館に行っていた 2015/11/30 に、E235 系が営業運転を始めた。と思ったら、いきなりトラブルを起こしてしまった由。 と、そこで名前が出てきたのが INTEROS (INtegrated Train communication networks for Evolvable Railway Operation System)。そもそも、E235 系の報道公開があったときにはデジタル サイネージばかり注目されていたけれど、最大の変化は INTEROS なのである。 後になって、INTEROS で使用しているソフトウェアの不具合という話が伝えられた。最近では、以前と比べるとソフトウェア制御の比率が高くなっているから、「難しさは増しているよなあ」と思った次第。なにも電車に限った話ではないけれど。 で。 このトラブルが起きた後で、「鉄ヲタをいっぱい集めれば超過荷重のテストができる」という話が TL に流れてきた。一見したところではまっとうそうな話に聞こえるし、実際、「テストに参加するボランティア募集」といえばワッと人は集まりそうだ。 でも、実際にテストをするとなると、そんな簡単な話じゃない。ワッと集まった人達が、それに耐えられるかどうかというと、ちょいと疑問に感じるところはある。つまり「人をいっぱい集めて乗せて、それで電車を動かしてみればいいんでしょ ?」ぐらいに考えていやしないかと。 たとえば、定員乗車状態での動作をテストする、と考える。編成全体で定員乗車というテストケースだけとっても、「すべてのハコにそれぞれ定員乗車」「ハコによって乗車率がばらついた状態だがトータルで定員乗車」の 2 種類が考えられる。 さらに後者は、「電動車に多く人が乗った場合」と「付随車に多く人が乗った場合」があり得るし、さらに細かいことをいえば、号車ごとに乗せ方を変えてみないといけない。編成の端の方に荷重が偏った状態 (×2 パターン) も、編成の中央付近に荷重が偏った状態も、それぞれテストする方がよかろう。 また、「超過荷重になったら動作がおかしくなった」ということであれば、「どれぐらいの超過荷重になったらおかしくなるのか」を割り出さないとテストにならない。すると、人を乗せたり降ろしたりしながら、いろいろな状態をテストする必要がある。 なぜかといえば、正常に動作する場合と正常に動作しない場合の境界、閾値が分からないと、原因の究明ができないから。バグ出しで重要なのは再現手順と再現条件。「再現しない」といわれるのはテスト担当者の恥。 なんでこんな話を書くのかといえば、たとえばデータベースのソフトウェアで「データ件数が 16,777,216 件を超えたときだけバグが出る」みたいな話は起こり得るから。 つまり、ただ単に人をいっぱい乗せて動かしてみれば OK、という単純な話ではなくて、事前に設定した大量のテストケースに合わせて、人が乗ったり降りたり移動したりしないとテストにならないわけである。興味本位で人がワッと集まっても、そんな辛気くさい作業に付き合ってくれる人がどれだけいるだろう。 でも、テストってそういうものなのである。そしてコンピュータ制御のものが増えるに従い、テストケースを設定してひとつずつ試す作業は、ますます辛気くさくて面倒で手間がかかるものになっている。 機械なら、眼で見れば動作は分かるけれど、それだっていろいろな条件を設定してテストするのは同じこと。それが、眼で見ても分からないソフトウェアなら、なおのこと。さまざまなテストケースを設定して、いぢめ抜かないといけない。 たまたま「つかみの話題」として E235 系を使ったけれど、MRJ でも F-35 でも事情は似たようなものであるはず。たとえば、飛行機につきもののフラッター試験ひとつとっても、飛行諸元を少しずつ変えながらテストを積み重ねていかないといけない。 これが軍用機になると外部兵装の搭載という話が出てくるから、一気にテストケースが増える。搭載するモノの陣容だけでなく、どこに何をどれだけ搭載するかという問題もあって、順列組み合わせはべらぼうに多くなる。 でも、そういう「テストにつきものの辛気くささ」って、あまり世間一般には認識されていないような気がした。

Contents HOME Works Diary Defence News Opinion About

| 記事一覧に戻る | HOME に戻る |