自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編） 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。お読みのページは後編です。 大規模なテストをどうやって実行しているか 続いて、大規模なテストについて。 1000万件のテストパターンを作っても、それぞれのテスト結果の正解を人手で作っていたら追いつきません。なので、別々に運賃計算ソフトウェアを作って、その答えを突き合わせてチェックしよう、という話です。 例
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（中編） － Publickey
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（中編） 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。いまお読みのページは中編です。 自動改札機の制御は1000件くらいのテスト さて、次は間違えない自動改札機の話です。ここからソフトウェアの話になります。 1つは運賃計算。この切符はこの駅で降りられるのか、というもの。そしてもう1つは自動改札の制御。ランプを光らせるとか、切符を回収するとかです。 まずはその
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
【西康晴が語るソフト品質・第4回】テストの間引きが下手な企業は，品質事故が多発
この記事は，「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。詳細はこちら。 次に，テスト・レビューの基本を解説しよう。実は，テストとレビューで考えるべきことは，かなり共通している。テストでは，テストを実施する前に，テスト項目をきちんと設計しなくてはならない。レビューでも，レビューを実施する前に，指摘項目をきちんと設計すべきである。行き当たりばったりのテストやレビューをしている限り，少ない手間で危険なバグを早くたくさん検出できるようにはならないし，テストやレビューの改善にもつながらない。 テストのやり方にはいくつかの工夫がある（図4）。まず，なるべく網羅性を落とさずに手間を減らし，たくさんバグを検出する方法がある。直交配列表を用いる方法や，All-pair法などが知られている。
故障モード影響解析（FMEA）とは？
大規模ソフトウエアの保守・拡張開発で起こる問題 大規模ソフトウエアの保守・拡張開発で起こる問題の多くは、中小規模の開発でも存在します。しかし、中小規模では目をつむっていられるものでも、規模が大きくなるにつれ、対処できないほどの問題になります。今回取り挙げる問題点は、大規模ソフトウエアを長期間保守・拡張していれば、どの開発でも遭遇するものです。 保守開発・拡張開発では、既存機能との整合性をとるためのコストが既存機能の規模に比例して大きくなります。簡単な機能拡張であっても、既存機能への影響度合いを設計時点で検討する必要があります。当然のことながら「今回はちょっとした拡張なので、拡張部分しかテストしていません」といってリリースするわけにはいきません。テストに必要な工数は既存機能の規模に依存します。 また、規模が大きくなると、中小規模ではあまり問題にならなかった開発体制が大きく影響してきます。1人
バラツキの概念と標準偏差について
１．データのバラツキ（分布）はチェックシートやヒストグラムを使って視覚的に把握するのがよい． ２．バラツキを数値で表すには，標準偏差（シグマ）を使う． ３．バラツキは必ずしも”悪”とは限らない！（お急ぎの方は，コラム２ バラツキは悪か？が面白い！） １．データの分布を調べる． 天気予報専門の会社が公開しているホームページのひとつに，Cyber Weather World というのがありますが，ここで見つけた昨年の「夏休みお天気情報」から，一部のデータを借用しました．(URL http://www.wni.co.jp/cww/) 表１(興味のある方はクリックして下さい)に示した昨年夏の東京と札幌における日中(9:00, 12:00,15:00)の気温を図１にチェックシート方式で東京と札幌に分けてプロットしたものを示します． 温度区分は，２℃間隔にしてありますが，あまり細かくしないで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf