S2-3-2
「ソフトのテストとハードの検証。
なにが違って、なにが一緒？（チュートリアル編）」
B会場、40人程度
----
「ソフトウェア編」片山さん
組込みソフトウェアは急激に大規模化が進んでいる
携帯：500万LOC（Lines of Code）
開発規模：2.4兆円、ソフトだけで40％
開発者：17万
組込みソフトウェアで不具合が多発。
品質向上が急務。
不具合の原因はソフトウェアの不具合が1番多い。
組込みソフトウェア開発に課せられている課題の1位は設計品質の向上。
ソフトウェアのバグが、アメリカに年間7兆円の損害を与えている。
テストの目的は？
-プログラムの誤りを見つけること(正しいことを確認するつもりでやっては誤りを見つけられない)
-誤りを見つけないまでも、プログラムの正しさに対する確信を増すこと
先人たちのお言葉：
「テストでバグの存在は示せても、バグが存在しないことは示せない」
「テストはエラーを見つけるつもりでプログラムを実行する過程である」
「プログラム開発グループは、自分たちのプログラムをテストしてはいけない」
「ソフトウェアテスティングとは、期待されるビヘイビアを求めて、適正に選定された有限のテストケースを用いて、プログラムビヘイビアの動的検証を行うことである」
静的でもよさそうだけど。
テストはコードが出来てから行う（最近はそれだけではない）。
回帰テスト：修正確認用のテスト
ソフトウェア開発にかかるテスト費用
1位：運用と保守（67％）
2位：テスト（15％）
出荷前までの費用ではテストが46％、開発におけるボトルネック
テストの視点
-要求ビュー：ユーザの要求を満足しているか
-仕様ビュー：仕様どおり実装しているか
-設計/実装ビュー：ロジックが正しいか
-バグ・ビュー：プログラムを見てバグがきちんと見つかったか
上2つはブラックボックステスト。
下2つはホワイトボックステスト。ソースコードが見える状態でテスト
テスト作業に付きまとう問題点：
・見つけたバグが最後のバグかわからない。いつまでテストすればよいか？
・テストによって正しいことを示せない。全ての入力でテストできない。
だからテストの設計が重要。
・より少ないテストケース
・より多くバグを見つける
・漏れがないように網羅
テストの順番。途中で時間切れになった時に重要なテストが済んでいること。
テスト容易性。テストで頑張るのではなく、テストしやすい設計をする。
入試や試験のためにテスト勉強をするのと一緒。テスト前に準備しましょうという話。
システムテスト：機能テスト（仕様どおりか）のテスト
システムテストの種類
ストレス、セキュリティ、パフォーマンス、ユーザビリティ
非機能要求のテスト
拡張性、再利用性、性能、信頼性、ユーザビリティ
モデル化やリストアップが困難
テストの終了条件
・実施されたテストの評価（カバレッジ、テストすべき項目中のテスト済み項目の割合）
-テストすべき項目の例）プログラム中の行数
カバレッジ ＝ テスト済みの行数 ÷ プログラムの全行数
・プログラムの評価
-メトリクス
・リスクベースドテスト
-障害発生の可能性、影響（被害）によって重要な部分を集中的にテスト。
メトリクスの例）コードの複雑さ、健全性、信頼性、・・・
メトリクスでテスト前後の比較は出来るが、「80になったらOK」というようには使えない。
モデルで設計、コードの自動生成をするなら、モデルを使ってテストできる。
全部モデルで記述できるか？非機能要求の取り扱いが問題。
でもモデル上でできることはまだまだありそう。
テストファースト
テストを先に作成、テストを通るようにコーディングする。
網羅性、非機能要求などが問題。
テストの自動化で膨大な数のテストが出来る、コスト削減。
自動テストの罠
・戦略なしの自動化
・過度な期待
・誤った使い方
自動化すべき項目と手動でやるべき項目を分ける。
どちらでも出来る項目が議論になる。
自動テストが向いているテストは、
・ストレステスト（1万回クリックする）
・タイミング（0.01秒後にボタンを押す）
・ビルド検証テスト
・夜通しテスト
・トレース（再現性）
回帰テストは向いている？
グラフィックス、サウンドは？
組込みシステムの場合
リアルタイム性、並行処理、割り込み
同期、タイミングのバグには注意
安全保護系のテストが必要。誤作動したときに自動停止する機能など。逆にエレベータの場合は電源を落としたら落下する。
まとめ：
テストの目的は誤りを見つけること。
テストはソフトウェア開発工程の一部だが、ソフトウェア技術者全員に共通する基礎知識にした方が良い。
----
Q「組込みシステムの場合、ファームウェアがある。バグった場合、メカが悪いのかファームが悪いのかソフトが悪いのか。」
A「ボード上だから、という考えはない。ソフトに問題があるならこの方法で何とかなる。このボードならこういうテストがあるのでは？というのはハード屋さんがやって」
Q「ボードになるとアドホック。バグの原因がハードかソフトか、双方で一緒になって考える必要がある。ハードかソフトかを切り分けるのに時間がかかる。それに関するテスト容易性」
Q「検証の重要さを分からずに就職してしまう。どのように検証の重要さを教育しているか」
A「全国的に見てテストを教えていることはほとんどない。私の大学では大学院の授業でテスト工学をやっている。教えるべきミニマムセット以外のことを教える余裕がないから難しい。」
----
「ハードウェア編」赤星さん
多少話を大きくして、「だからソフト屋さんはダメだ」という風に進める。
ハード編で扱う範囲をディジタルに限定する。
実装レベルで見るとRTLレベルが重要。
ハード設計のステップ
要求仕様作成—実行可能な仕様＋自然言語による仕様（MIL-STD-490A等）
↓ ↓
アーキテクチャプラン ←→ 検証プラン—テストケースの抽出
↓ ｜
設計—レビュー、リントチェック
↓ ↓
検証—テストケースの確認—この作業の割合が増大している
↓
論理合成
↓
レイアウト合成
基本的にワーニングはなくなるまで先に進まない。
ものによって5〜9割が検証。主観ではだいたい8割ぐらいだと思う。
最初のシリコンの成功率は35％。莫大なコスト。
再設計/製造による金銭的ロス、時間的ロス。
ハードのテスト：チップが設計どおりに出来たか（ゴミなど原因）
ハードの検証：ハードの仕様通りにRTLが記述出来ているか
ハード検証は実機からシミュレータに、ソフトのテストは実機を使用。すれ違ってしまたのでは？
シミュレータでバーチャルにやるのがポイント。
無理やりな設定でシミュレーション出来る。使い勝手が良い。
しかし遅い。シミュレーションをハードウェアデバイスで加速する（FPGAなど）
動的検証ツールの進歩
・シミュレーションの高速化
・言語面、検証言語
静的検証ツールの進歩
・リントチェック
・等価性検証
・モデルチェック
動的ツールより網羅性が非常に高い
言語面での進歩：
Cベース設計言語。Cで不足している「時間」「ビット幅」を加えてSystemC。
検証言語。ハードウェア記述言語はシミュレーション用で、それを無理やり合成している。検証能力が不足。「モデル能力」「チェック機能」などを高めてSystemVerilog,e,OpenVera,PSL,
検証の改善：1．コードカバレッジ、2．
コードカバレッジ：{State, Path, expression, FSM, Toggle} coverage
アサーションの種類：呼ばれた時にチェック（即時アサーション）、ある処理に注目して経過状況をチェック（並列アサーション）。OKかNGかはツールにやらせる。
アサーションはハードに近い言語で書ける。
シミュレーション、モデルチェックでそのまま両方使える。
モデルチェックである程度エラーを見つけ、それ以外をシミュレーションで。
ピンの数など波形の限界、修正時に設計者が画面に張り付くなどの問題を自動化で解決。
入力値から期待値を計算し、設計したものの出力と比較。
波形データから、合っている/間違っているのテキストデータへ。
ムーアの法則。残業では指数オーダーに対応できない。人海戦術でも無理。
制約付ランダムテスト：入力データをランダム生成、シミュレーションし、アサーションでチェック。制約付ランダム生成は数万パターン/秒作成できる。
ランダム生成の検証はいつ終わる？カバレッジやアサーション。
機能カバレッジ：何をチェックするか定義。コードにないものもチェック可能。
FIFOの検証・・・バッファがfull,emptyの場合に問題が発生しやすい。コードカバレッジでは無理。
検証環境の再利用
・オブジェクト指向言語
・アスペクト指向言語
・現在はメソトロジがHOT
メソトロジ例：VMM
・ランダム生成、部品化の促進、自動チェックの推進、カバレッジによる終了判定
おわりに
・戦うべき相手の認識が必要（相手は指数オーダー）
・正しい武器を使おう（掛け合いで戦えない）
・頭を使う部分と自動化する部分の選択
----
Q「テストパターンの生成手法は？」
A「どういうシーケンスかは検証者が決める。その中の細かいばらつきをランダムで埋めていく。全体の流れは作りこむ」
Q「ランダムでの生成ではカバレッジはどの辺まで？」
A「100％。ランダムで出来なかった残りの部分を手で入れてカバレッジを上げる」
Q「等価性チェックやモデルチェックは現場でどの程度使われている？」
A「等価性チェックは実用レベル。モデルチェックは導入しようと頑張っているところと、拒絶しているところがある。」
Q「ハードだと同値を見るか？」
A「僕は同値は見ない。同値がきかない場合もある。Cソースコードを持っているからそれをHDLに流す。」
Q「機能カバレッジについて。機能をどこまで評価するかを設計者の能力に大きく依存。客観的な評価ができない。」
A「ハードでメモリアクセスする場合。メモリアクセスをチェックする。作業するからチェックする。コードカバレッジで取れるものは取れる。取れないものは機能カバレッジで取る。設計手順で考えていって、イレギュラーな部分を機能カバレッジで。言ってみればレビュー。」
Q「FPGAのエミュレータを使っている。ボードレビューだと全部載せることが出来ない。」
----