Software Testing - Columns: テストカバレッジ
テストをしていて一番悩むのが、どこまでテストすればよいのだろうか、という点です。勘と経験と度胸で終了判定を行っている組織もあれば、独自の方法を編み出している組織もあるようです。また信頼度成長曲線（Software Reliability Growth Model: SRGM）を始め、昔から研究テーマとしてもよく取り上げられます。しかし、これを考えれば万事オッケーというような、万能の判定基準はありません。信頼性を判定する指標も同様です。テスト対象やテストそのものの様々な側面を総合的に把握する必要があります。 その一つの側面が「カバレッジ（coverage）」です。どれくらい網羅したテストなのか、という指標を意味しています。最も有名なのはコードカバレッジでしょう。C0、C1などという用語を聞いたことはありませんか。もしくは命令網羅や分岐網羅、ノード網羅やリンク網羅という呼び方かもしれません。基
ソフトウェアの安全性を考える - rabbit2goのブログ
日経ものづくり2010年8月号に、プリウスのブレーキ制御の問題を取り上げた「ソフトが揺さぶる製品安全」という記事が載っていた。プリウスの問題については既に様々な媒体で取り上げられているけれど、原因を簡単に言ってしまえば仕様と検証の漏れという点だろう。記事では、システム構成の変更をソフトウェアの改変で対応させたものの、その時に安全性が損なわれてしまった状況が説明されている。決してメジャーとは言えない機能において、不具合の種が残ったままになってしまったのだ。 プリウスで不具合が起きるのは、主に滑りやすい路面上で機能するアンチロック・ブレーキ・システム(ABS)が動作した場合だ。こうした使用頻度の低い機能では制御に関する仕様の詰めや検証が甘くなりがちで、不具合が残りやすい。ソフトで実現する機能が大幅に増えたために、それぞれの機能について安全を作り込むのが難しくなってきており、そのしわ寄せがABS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
