[SA-3 組み込みシステムの試験と検証-OS、コンパイラ、ネットワーク]

会場の広さ：180席
参加者数：40人

----------------------------------------------------------------------------
（以下，敬称略）

司会：
この分科会に何を期待するか？

A:
OSの試験はいるのか？そこに関して，一般的なメリットはあるのか？
できたものは固めてしまって，本来ユーザはその上で動くソフトを作るのでいいの
ではないか？

司会：
自動車なら自動車で，顧客側が仕様を決めているが，OSに関しては,顧客側でどこま
でやってほしいか仕様を決めていないことが多い．
MicrosoftのOSで困っていないなら，困っている人がその仕様を決めればよい．
JAXAさんはその仕様を決めようとしている．それをクロスビー側がTOPPERS検証プロ
ジェクトに投げられていて大丈夫か？

B:
OSの試験は全体の一部として必要．15年くらい自分の研究室で仕様を決めて作った
が，使えるまで3,4年かかった．ある線引きをしてそれ以上は触らないようにするの
はユーザ側の賢い選択．

司会：
hamana打ち上げプロジェクトではどうか．

C:
どれだけテストすればいいのかという話では，わからない部分をテストするには，
何年もかかった．テストを使ってみたいのという興味はあるが，どう使っていい
かわからない．

司会：
飛んでいる間地上と通信はするのか．通信するなら，通信系のテストはどうして
いるか．

C:
通信ではなく，向こうから放送するため，通信系のテストはしていない．

司会：
この分科会に何を期待するか？

D:
OSとコンパイラとデバッガを作る仕事をしていて，
作る側からのこんなものというのはもっているのが，使う側はどう思っているのか？

司会：
Linuxに対してPOSIXのテストだけだと不満だという話が合ったが，それ以上のテスト
はどうしたらいいか？

D：
メモリのリードやライトをどのようにすればいいかテストしている．
各社それぞれのノウハウがある．

E：
（本の紹介）内容は，テストとは何かということを書いた本．携帯の話を入れたり，
テスト計画書の話を載せたりしている．
テストのスタンスは携帯電話向けの交換機のテストなどをしていた．

司会：
携帯電話のトラブルは結構聞かれているが，何のテストをするか？

E：
中国等に持っていってテストをしている．
ヘビーユーザが使うと致命的なバグが見つかったりする．
お客さんが知らないうちにファームウェア書き換えができるので，あまりバグがみつ
からなくなった段階で出荷して，後で直すという方法がある．

司会：
状態遷移表を変えてみて，どれだけイレギュラーなことをすればバグが発見できるか
というのを，各社持っている．

F：
先ほど出ていた話はどのような話か？

司会：
OSの話が出ていた．

F：
Linuxを組み込みシステムに適用する際に，何とかしてCPUの使用率を変更する．
ブロックシェアスケジューリングということで，理論的にはできるということになっ
ているが，より現実的でかつ概念的な，有効的な方法ができたらいい．

司会：
CPUのシェアをしているとパフォーマンスはどれくらい落ちるか？

F：
１％くらい．CPUが早いのもあるが，スケジューラ自体のオーバヘッドはそれほどない．

司会：
対象アプリケーションは？

F：
画像を再生する装置．

C：
試験の目標は品質向上．実際に試験だけでは絶対にできない．宇宙開発だと部品選定
など，一つ一つ積み上げる．普通のソフトウェアと基本は一緒．

G：
postscriptなどのプリンタ言語から画像を作るのが専門．
画像を勝手に作っているが，テストするほうからは嫌われている．

司会：
Microsoftではプリンタでもかなり厳しい仕様を決めているが，クリアできるものなのか？

G：
好きな人は試験は通っている．その辺はノウハウ．

司会：
そのOSの水準をクリアするにはノウハウ以外のものはないのか？

G：
プリンタ言語をテストするツールは売っているので，それを通している．
Micorsoftは，クレームがすべて自分に来るからそれなりの品質を要求している．

司会：
C社さんはそのあたりは？

H：
プリンタに関わったことはないのでわからない．

司会：
ネットワークを通じてプリントする場合と，パラレル等でプリントする場合の違いは
あるのか？

H：
WindowsXPがサーバになっているのと，プリンタがサーバになっているのがあるので，
その手順によって評価が違う．ネットワークの場合，どこかのPCが何かの理由でダウ
ンすると，プリンタ自体リセットされることがあった．
テストの仕方はノウハウの蓄積でされている．

司会：
整合性のテストは？
２つの組み合わせのテストツールはあるのか？

H：
例えば，FAXについては，FAXの通信をずっとしている人の団体がノウハウを持って
いて，その人たちが持っているテストを通すと，一般的に通る．
専門家のノウハウが大事な世界だと思う．

I：
先ほどからノウハウということばをよく聞くが，それは何を意味するのか？

司会：
過去にトラブル経験などで，形式化してないものをノウハウという．

I：
何故形式化しないか？

司会：
会社からお金が出なかったり，時間がもらえなかったりする．

H：
弊社では，形式化してるが，門外不出．
企業が利益を追わなくて，それを世に広められるなら少しは役に立つと思う．

C：
話をOSに戻すが,OSだと動かすたびに違う結果になる．その場合はどうするか．
そういう話を聞きたい．

J：
Linuxを使うなら，ライセンスの問題があることが言われるが，Linuxでなくて
も，NETBSDなどがある．何故Linuxなのか？

司会：
BSDライセンス問題でもめてるときに，Linuxにライセンス問題がなかったから．
それから，Linuxが問題になってきた．

E：
BSDライセンスでもGPLにしても，配布に関する規定であって，使用する人に関
する規定の話が出ていないような気がする．例えば，ソフトを作って不具合が
出て，お客さんから損害賠償が来た場合，GPLのソフトだと逃げることができ
ない．不具合が出たときの責任問題を聞きたい．

K：
３年くらい前からNETBSDを使っているが，組み込みにUNIXを使ってバラ色の世界，と
いうわけではなかった．UNIX上のアプリケーションの開発はハードディスクがあって，
VMという領域でキャッシュされるが，組み込むとどんどんメモリを食ってしまう．
結果として思ったよりもメモリを食うことがある．また，フォントを物理領域に置いて
おいて，直接参照できなかったりと，手間がかかる．メモリプロテクトのあるOSとない
OSではリソースのつくり方がかなり違う．

司会：
２種類作るしかないのでは？

L：
ブラックボックステストやホワイトボックステストをしなさいと言われているが，
どのレベルでやればいいのか，効率的にテストをやる方法を知りたい．

司会：
制約条件からテストができないか？

M：
小さいレベルからテストというのがあるとが，ノウハウというのもそこにあると思う．
どんどんノウハウを作っていって，テスト時間を節約できるようにするのが手近な
解決法だと思う．みなさんはそういうノウハウを蓄えているか？

司会：
S社さんにテストについて聞いてみたところ，膨大な資料をもらったが，S社では
ちゃんとテストしてると見ていいのか？

M：
設計仕様からバグが入る余地があると思うので，そういうものもきちんとすれば膨大
な仕様にならなくてすむのではないかと思っている．

B：
今テストの量は制御可能は範囲に収まっているのか？
もうちょっとしたら収拾がつかなくなりそうな段階なのか？

M：
入力を全部入れてやれば，完璧なテストになると思うが，それは既に爆発している
ので，それをいかに減らすか．

司会：
今は制御できるが．何か発見がないと難しくなるというのか？

M：
今の時点で既に制御できていない．

N：
ちゃんとテストしているとか膨大な資料とかを数字にすればどうか．
テストの数値化に興味がある．要求とか信頼性に対する何らかの数値化はできない
のか？

O：
ソフトウェアなら入力が膨大になるので，カバレッジツール等を使って数値化する
しかないのではないか．

司会：
OSの基本機能だけでどれだけのテストをすればいいのか，推定くらいは出せないこ
とはない．テストの数値化より品質の数値化のほうが難しい．信頼性95％といって
も，何を基準に95％かわからない．

P：
決めてる例があるかどうかが知りたい．バグが何件以下だったら，とか．もしくは
数値ではなく，テスト関係者がOKといえばOKなのか．

司会：
たとえばプリンタなら富士通さんが，バグ曲線を書いて，発表してるものはそこ
そこある．

R：
数字は話せないが，フェーズがあって，設計から生産に移るときに，設計部の仕様
を聞いて，商品テストし，何回か同じようなテストを繰り返し，バグ発生率が何パ
ーセント以下が何回か続けばＯＫ．

P：
バグ収束率だけで測られているのか？

R：
バグのデータ化とテストの仕方のカーブの状態を見て．今出ているバグの出方を見
て，バグの出方が今まで自分たちが見てきたのと一致してるかを見て決めている．
条件がどこでも使えるのではない．
メトリックスにはいろいろあるが，各社各様で違う．
どこかの会社の数値を聞いてそれをそのまま使えるのではない．それがノウハウである．
だから，門外不出になる．
メーカーに閉じた話ではなく，メーカーが集まってメトリックスを決めようとしている．

P：
数値ではなく，単位が知りたい．

司会：
何を調べるかによっても単位が違う．だから，単位も出ない．
自動車であれば何にする，ロケットであれば何にする，等があり，何をするかによって
単位が違ってくる．

P：
スケールによって違ってくるのか？

司会：
スケールの違いというものでもない．

Q：
OSを出荷するときに，どれだけの品質があるか，というのはどうやって知らせるのか？

司会：
ランク分け，分類をして，どれがどれだけあるか，というので知らせる．

Q：
各社いろんな単位を使っているが，それで足りているのか．

司会：
ペースメーカーなら何万人に一人でも止まってしまうと困る，というのがあれば、それ
から何らかのものが出せる．

Q：
みなさんはどういう基準でテストを終わりにしているのか？

司会：
物による．パッケージ製品か，特定顧客への製品かでもちがう．特定顧客なら，顧客が
満足すれば出せる．何の話をすればいいか特定しないと決まらない．

Q：
プロジェクタの話に特定する．

司会：
接続時の不具合が多い．そういったことをちゃんとテストせずに出荷してるものが多い．
顧客がそれを要求しないからそうなっている．顧客側がどれだけテストしなさいとか
指定しないと仕様がない．プロジェクタ出してる会社さんは？

H：
そんなに無責任にやってるわけではなく，今まで通してきたテストは通している．
現状の製品はネットワークを通してファームウェアをアップデートすることができるのた
め，後で直すということで何とかなるため，完全なテストをしなくても良いと思っている
のではないか．

司会：
セッションのまとめをCさんにお願いします．

C：
まず１つはオープンソースのソフト．検証といってもいろいろ取り組み方がある．
いろいろな企業でプロダクトラインとかのキーワードをベースにしてプロダクト
依存のものと非依存のものに切り分けて考えていく必要がある．オープンソース
ならプログラムが開発されているが，テストケースが公開されていないのを疑問
に思っている．

テストケースがあれば，テストをかなりクリアにできる．
テストケースがわかれば発散することがなく，プロダクト依存と非依存を分けて
検証することができる．自分たちが手を加えるところでどういうテストをするか，
というバランスがトレードオフになってくる．
検証をどこまで自分たちで求めるか，その前段階がどれだけ必要かを検討するべ
き時に来ている．

--------------------------------------------------------------------------------

記録者感想：
テストに関してあまり知らない立場での参加でしたが，聞いているうちにテスト方法が
如何に重要かということを感じることができました．
会社，製品，対象によって異なるテスト方法，基準があり，また，テストに対するいろ
いろな考え方があるということは興味深い内容でした．