EDA・ソフトウエア 強いLSIやボードを設計するための
 

【松尾谷徹が語る】現場力を高めるテスト(1)

松尾谷 徹=デバッグ工学研究所 代表コンサルタント / 東京理科大学 講師
2006/02/23 08:00
印刷用ページ

プロジェクトの大規模化につれて,テストの負担がどんどん大きくなってきた。上流工程をいくら改善しても,バグの探索にかかる時間やコストは変わらない。網羅性と合理性を両立させたテストの技法について解説する。

 組み込みソフトウエアの大規模化と複雑化に伴い,品質問題がクローズアップされるようになってきた。そして「品質セントリック」と呼べるほど,組み込み機器の品質に厳しい目が向けられる中で,最後のとりでが本稿で述べる「テスト」である。

この記事は,「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。詳細はこちら

 組み込みソフトウエアのテストには大きく2つのポイントがある。1つは可能な限り数多くの項目について,漏れなくテストを行う「網羅性」である。もう1つは,テスト項目について必要/不必要をきっちりと押さえる「合理性」だ。つまり開発現場では,できるだけ少ないテスト項目でカバー範囲を可能な限り広げるという相反する要求を満たすことが求められている。こうした状況に対応する工学的なアプローチとして,筆者は「探索理論」に基づく手法が有効だと考えている。

 もう1つ強調しておきたいのは,「人」の問題である。図1に示すように,テストはソフトウエア開発では下流工程に位置する。テスト工程では,単体テストや結合テストに参加する人が,漏れなくテストやデバッグを行わないといけない。つまり,テストとは担当者が総掛かりで取り組む作業であり,チームとしての力が非常に重要になる。この点について,開発に携わる多くの方が頭では理解している。しかし,きちんと実行できているかというと,大いに疑問である。

 それもそのはず。チームとして仕事を進めるというのは結構厄介である。組み込みソフトウエア技術者をはじめ専門家というのは一般に,専門能力は高いが協調性に欠ける面がある。組み込みソフトウエア開発のプロジェクトでは,こうしたプロの集団を集めて仕事を進めなければならない。このプロの集団をきちんと組織化することは,テスト技法に勝るとも劣らないほど重要である。

探索理論に解がある

 組み込みソフトウエア開発は,要件定義から始まって,設計,コーディング,テストへと進む(図1左)。それぞれの工程にどれだけのコストを投じているかを工作機械を例に示したのが図1右である。要件定義はさまざまな調整が必要なので,全体の15%とそこそこのコスト(時間)がかかっているが,設計工程やコーディングのコストは意外に小さい。これはオブジェクト指向技術などのソフトウエア工学の大きな成果と言える。

ソフトウエアの開発工程とコスト
図1 ソフトウエアの開発工程とコスト
要件定義と設計が上流工程,コーディングとテストが下流工程と位置づけられる。テストに要するコストが,全工程の実に70%を占めている。テスト工程の合理化が焦眉の急となっている。図は工作機械の例である。

 組み込みソフトウエア開発のコストにおいて,最大の問題がテストにあることは図1を見れば一目で分かるだろう。実に全体の70%に達するコストを掛けて,上流工程で入り込んだバグをつぶしているのである。

 ソフトウエア工学の鉄則ともいえる「上流工程をちゃんとやれば下流工程はうまくいく」は確かに正しい考え方である。一生懸命テストをしても,バグは次から次へと出てくる。上流工程に原因があるのだから,そこを正すという考え方は当然である。実際,「テスト技法なんかを勉強するより,原因を取り除く技術をちゃんと入れましょう」と1980年代に偉い先生たちに言われ,筆者も「確かにそうだ」と納得した。テストの技法などを勉強したって,きっと定年のころにはなくなってしまう。だったらテスト工程よりも上流工程を勉強しようとなった。こうして筆者は,30年間,技術者人生を過ごした。

 ところが現状は,図1に示すような状況である。テストの問題は全く解決していない。それなら惨憺たる下流工程をもう少しどうにかしようというのが,筆者の考えである。テスト工程を合理化し,バグを効率的に取ることができれば,70%掛かっていたコストが60%なり50%なりに減り,開発現場が抱える問題の解決につながるのではないか。

 ここで注意してほしいのは,上流工程の改善がダメだと言っている訳ではないということである。上流工程でなければ解決しないことはいっぱいある。上流工程は今後も頑張る必要がある。でも,下流工程もちゃんとやらなければいけないというのが筆者が主張したいことである。

テストとは,詰まるところ「探す技術」

 どうすればテスト工程を合理化できるのだろうか。合理化するなら上流工程と同じように,ソフトウエア・エンジアリングの裏付けをもってテストの合理化も進めたい。

 ところが,ここで困ったことがある。テストの技術は,ここ何年もさほど進歩していないのである。25年前に翻訳されたGlenford J. Myers氏の『ソフトウエア・テストの技法』が,いまだにベストセラーの一角を占めているほどである。1990年代になって,Boris Beizer氏の教科書が登場したが,読むのに1年くらいかかるほど分厚いし,読んでもよく分からない。細かい技術はいっぱい載っているが,現場の実態に必ずしも即していない。現場が求めているのは,単体テストや結合テストにブラック・ボックス手法が使えるのか,使えないのかといった実利的なヒントだ。しかしこうした実践的なところは,ほとんど議論されていないのが現状である。

 じゃあ,どうすればよいのか。テストの本質は,ものを探すところにある。さまざまなところに隠れているバグを探すことこそ,テストの神髄であり,ここに難しさがある。

 コンタクト・レンズが広い部屋に落ちているとしよう。落ちている個数は分からない。“5個くらい”とあいまいだ。それを全部探さないといけない。探すのには,かなりの時間がかかる。では5個が3個に減ったらどうだろう。探す時間は5分の3になるだろうか。そうはならない。落ちているコンタクト・レンズの数は,“3個くらい”とやはりあいまいだから,3個で打ち切ればよいという話ではない。くまなく探す必要がある。“5個くらい”も“3個”くらいも,探す時間は変わらない。

 ここにテストを合理化することの難しさがある。バグを見つけるにはくまなく探さなければならない。見つけたバグを改修する作業は,入っているバグの数に比例するが,探す作業はバグの件数には関係ない。ちなみに,上流工程を頑張るということは,改修するバグの件数を減らすことを意味する。網羅的に探す手間は,上流工程の優劣とは関係ない。こんなことは少し考えれば分かることだが,なかなか気付かれなかった。つまり,上流工程におけるバグ含有率や含有件数を減らす努力とは別に,バグを探す技術をきちんと確立しなければならないのである。(つづく

【9月18日(金)開催】
高精細映像時代に向けた圧縮符号化技術の使いこなし方
~H.265/HEVCの基礎から拡張・応用技術とその活用における心得~


本セミナーでは高品質、高信頼、高効率に製品化するために標準化された高圧縮符号化技術、H.265/HEVCについて、その基盤となった符号化技術の進展から映像・製品特性に適切に圧縮符号化技術を使いこなす上で知っておきたい基本とH.265/HEVCの標準化、実装、製品化に向けた基礎及び拡張技術の理解と活用の勘所等について詳解します。詳細は、こちら
会場:中央大学駿河台記念館 (東京・御茶ノ水)

マイページ

マイページのご利用には日経テクノロジーオンラインの会員登録が必要です。

マイページでは記事のクリッピング(ブックマーク)、登録したキーワードを含む新着記事の表示(Myキーワード)、登録した連載の新着記事表示(連載ウォッチ)が利用できます。

協力メディア&
関連サイト

  • 日経エレクトロニクス
  • 日経ものづくり
  • 日経Automotive
  • 日経デジタルヘルス
  • メガソーラービジネス
  • 明日をつむぐテクノロジー
  • 新・公民連携最前線
  • 技術者塾

Follow Us

  • Facebook
  • Twitter
  • RSS

お薦めトピック

日経テクノロジーオンラインSpecial

記事ランキング