********************************************************************** セッションS3-A 分科会2 テーマ:ソフトのテストとハードの検証。もっと一緒に考えよう! コーディネータ:片山徹郎(宮崎大学)、赤星博輝 日時:平成19年8月31日 10:40-12:20 参加人数:60〜70人 ********************************************************************** 10:42 開始 K氏 ソフト屋さんがよく聞くのは、テストをいつまで、どこやってらいいのかと いうこと。 原因としてはテストすることが多いとかテストの設計のやり方がわからないとか。 ハードではどうですか?ここまででよいという基準はありますか。 A氏 ないですね。いいかげんな検証ならテストはしないほうがいいです。 K氏 今世間で出回っている不具合はソフトのほうが多いですね。 A氏 ハードのバグは改修しないといけないので、ソフトに任せている部分があるの も原因ですね。 K氏 会場の方でテストをどこまでやればいいのか疑問に思う方はどれくらいいますか。 ・・・ A氏 自分が作るものにたいしてはコントロールがききますが、買ってきた物は 難しいですね。 バグはどこまでしなければ行けないのかというのは難しい問題だが、 使用する部分だけでよいと思う。 全部やろうと思っても無理です。 会場A たとえばコンパイラではどのようなデバッグすればよいか。 A氏 製品として成立する範囲で。 会場A すべての入力を検証するわけにはいかないがどこまでやればいいか。 A氏 インテルの浮動小数点のミスがありましたね。 あれでもインテルさんは検証のスペシャリストを雇っていたんですよね。 でも、ああいう問題になった。 日本で検証のスペシャリストを雇うことはありませんよね。 会場B どこまでやって良いかわかりませんとか何を作ったらいいかわかりません。 とりあえず思いついたものを全部やってみようと思うと、作ろうとする全体像 が把握していないとできない。 テスト部隊に丸投げするのがいけないのだと思うが、みなさんはどう思うか。 自分がなにをつくっているか分からなくなる。 K氏 テストがよくわからなくなるのは、自分が何を作っているのか分からなくなって いるからだということですね。 会場C テストする人っていうのは、何を作っているのかわからないままテストして いるのがいけない。 全体を把握していない人に何を作っているのかということを伝えるシステム がないのが問題。 ソフトウェア監査の体場から言うと、論理的な立場からの検証じゃないと納得 できない。 A氏 自分たちでつくったものであればカバレッジでもバグはとれると思う。 会場C 検証テスト評価も含め、何をどの精度までやれば合格なのかというのが、 客観的な根拠が見れない。 カバレッジしても、OKを出す基準がはっきりしない。経験で把握している気 がする。 それが悪いとは言わないが、成長曲線のようなものをもっている上で行わない といけないと思う。 A氏 そうですね。単発のテストや検証ではうまくいかないと思う。 バグがでた原因が解析できればいい。 K氏 ソフト屋さんの会話でよくでる「またこのバグでちゃったよ」ていうのは学習 できていない証拠。 フィードバックをかけて次に生かさなければいけない。 A氏 テストって結構細かいこと、境界値だとかを見ちゃうけど、もっと本質的なもの を見なきゃいけない。 ハードの場合はソフトより自由度が少ない。出来ることが限られるので検証 することも限られる。 大きな何をテストをしないといけないのかということが重要で、それがわかれ ば後は走るだけだと思います。 K氏 テストをやっている渦中の人は、カバレッジだとかに囚われがち。 会場D ハードのほうが検証が簡単だという話がある。私はCPUとOSの研究をして いる研究室にいるが、ハードの検証しようとすると、1秒シミュレーションし ようと思うと1時間2時間かかる。 A氏 検証項目としてはハードのほうが少ない。 ソフトはハードの上で動くからより複雑なのは当然。 会場D ソフトというのは論理が正しければ確実に動くが、ハードはチップにしたとき を考えると・・・。 A氏 ソフトでも割り込みや時刻同期とかややこしいことがある。 会場D 直感的に、CPUとOSを作っている立場から言うとCPUのほうが難しいと 思います。 A氏 CPUがバグっているときはソフト屋さんは大変ですね。 CPUのバグはソフトに投げられるのがいけないね。 どっちも難しい。 会場D ありがとうございました。 会場A どっちが難しいなんて議論はどうでもいいと思います。 A氏 そうですね。 というのは、ソフト屋とハード屋でコミュニケーションが足りないのではないか。 K氏 ハード屋さんは前工程でソフト屋さんが尻ぬぐいというか、をしている。 ソフト屋さんでハード屋さんからこういう情報がほしいという何かありますか。 A氏 本当に必要ですかね。 会場A ハードの情報はある程度カプセル化して欲しい。 一緒に開発しているのなら、もちろん必要だが 何でもかんでも情報を与えられても困る。 A氏 パターン化されていないくて、ハード屋さんも何をなげたらいいかわかっていない。 ソフト屋さんとハード屋さんでテンプレートがあればいいですよね。 K氏 実際ソフト屋さんとハード屋さんで会話がないですよね。 こういう機会にコミュニケーションしていただければ どなたか意見ありますでしょうか。 ソフト屋とハード屋がいっしょにやるために何が必要か。 A氏 ハードの仕様は3〜4年まえに固めなければいけない。 ソフト屋ははやく進めたい。 これをどうしたらいいのか K氏 システムのスペックを切り分けるイメージを 一緒に考えなきゃ行けない。 A氏 システムをハード、ソフトに分割しないとお互い進められない。 早めにプロトタイプを作るとか。 それで実際のチップを待つ。 こうやってタイムラグを埋めるしかないのではないか。 シミュレーションベースのソリューションしかないのではと思う。 K氏 たしかに、ソフト屋は割と待ってる部分のある。 A氏 その場合って発注側にもあると思う。 ソフトウェアのテストの機会が変わる良い機会ではないか。 中国の人海戦術でいい。日本のメリットでは早く品質の高いもの。 K氏 動くものをつくらないと仕事をしたきにならないというものが問題だと思う。 会場B やっぱり何をテストしたらいいかわからないのが問題。 境界値とかはどうでもよくて、自分が何を間違えるのかを知ればそれをピンポ イントに治せばいい。 すべてがそろってからでないとダメというのは思考停止だと思う。 テストも検証も一気にやるのはソフト屋の指向パターンだと思う。 会場E ソフトの立場からいうと、一人の人がひとつのシステムを作るときはそうかも しれないが。 実際は複数人で仕様を考える。複数でコードを書く。技術レベルバラバラ。 そういう部分でバグが生まれれる。 何をつくっているのかわからないという部分もあるかも知れないが。。。 会場F だましだまし作っていかないと凡人は作っていけないのではないか。 会場G さきほど、実機のソフト開発ではこれからやっていけないと思う。 シミュレーションでやっていけない。 でもFGPAでもRTOSありき。ある程度抽象度を上げたところで考えない といけない。 レジスタインターフェイスがわかっていればそれでいい。 K氏 縦のフローも横のフローもあるといいということですね。 会場H 質問です。ハードがなければソフトが何も出来ないというのは本当ですか? 何ができないんですか? K氏 最終的には必要だと思います。 会場H たしかにそれはそうですが。ハードがなくてもできることを整理しないといけない。 できないんじゃなくてやらないんじゃないかと思う。 会場I みなさんにお聞きしたいんですが、実機がないとわからない不具合、実機が無 くてもわかる不具合はどれくらいですか。 実機がないとわからない不具合が5割を超えるという人。2〜3人ですね。 会場A 実機でやったほうが遙かに早いしコストも少ない。 会場O シミュレーションを使わないといけないソフトじゃ駄目。 実機でやったほうが楽だというのはわかるが、 全体的なコストを考えるとそれはどうか。 実機がないときに先にシミュレーションでやった方が全体的にコストが下がる のではないか。 会場I 絶対に実機じゃないとわからないというのは一定あると思う。 良い物をつくるにはデベロッパーフレンドリーが必要。 会場J 実機じゃないとわからないというのは、テストがわかってない。 実機でテストしてもどっちが悪いのがわかりにくい。 区別するにはそれぞれが独立してやらなきゃいけない。 会場A わたしは実機でやったほうがはるかに楽という分野もあるということが 言いたかっただけです。 A氏 古い仕様の書き方を使い続けるのがバグが生まれる元だと私は思ってます。 下で出た情報が上にあがっていない。 下請けで派遣の人がやって情報が散っている。 K氏 自由意見で何かありますか。 会場K テストを刷るべき項目かそうではないかのどこに基準を設けるかが難しい。 それだったら、何をつくるのかわからないけどテストが出来る方法を考えたら どうか。 ひとりでやったほうが一貫性がある。 何をやったらいいかわかるスペシャリストが一人いればいいのではないか。 会場I たしかに規模によってはそうかもしれない。 テストだけで10何人もいるようなシステムをどうするかが今の課題。 会場L テスト部隊だけで100人だけの仕事がある。仕様もわたされないままテストさ せられる場合もある。 上流リバース力が必要。 テスト専門部隊は上流から関わるべき。 バグを治したらそれを忘れるのが問題。 会場C ハードとソフトのV字が並行ししているとすると、プロセス間のインタフェー スをしっかり固めないといけない。 K氏 ハード屋さんもV字で書くんですか。 A氏 書かないです。 K氏 そろそろ時間なんですが、なにか意見ありますか。 会場 仕様の書き方などで意見がありましたがハード屋さんにとってソフト屋さんに 言いたいことは。 A氏 ソフト屋さんがハードをどのように使うかを知りたい。 ムダなテストをしてしまう。 K氏 やっぱソフトとハードでコラボレーションが足りないですね。 ソフト対ハードではなくて、やはり良い物をつくるにはお互いがシステムに対 する形がいいと思います。