サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ドラクエ3
blues.se.uec.ac.jp
JaSST’05 in Osaka 直交表を活用したソフトウェアテストの効率化 直交表を活用したソフトウェアテストの効率化 - HAYST法の活用 - HAYST法の活用 - 2005年 7月15日(金) 富士ゼロックス株式会社 秋山 浩一 Kouichi.Akiyama@fujixerox.co.jp ソフトウェアテストは必要!? 上流工程でちゃんとすれば良い? 要求仕様作成時 ユースケースを作成 → 要求の背景を理解 → システムの内と外の明確化 要求を満たしたと言えるテストケースを定義 → 要求の曖昧さを排除 設計/コーディング時 xUnitでテストファーストを実施 → I/F仕様の明確化 → 自動テストを繰り返し実施しデグレートを防止 上流工程に手を打つことは非常に重要で効果も大である <これだけで良いか?> 2 現実の開発では… 上流工程
テストによく似た用語に、V&V(Verification and Validation)があります。「検証と妥当性確認」と翻訳されることが多いですね。さて、どう違うのでしょう。今回は、SWEBOK(Software Engineering Body Of Knowledge)の記述を参考にしながら考えてみましょう。SWEBOKはIEEEを中心にアメリカでまとめているソフトウェアエンジニアリングの体系です。邦訳はオーム社から「ソフトウェアエンジニアリング基礎知識体系」として出版されてます。英語版はフリーですので、英語が読める人は気軽に読んでみてください。SWEBOKは、テスト技術者が体系的に視野を広げてステップアップにつなげるのに適した、とても良い本だと思います。ちなみにSWEBOKのテストの章を書いているのは、イタリアが誇るソフトウェアテストの権威Antonia Bertolinoおばさま
ソフトウェアテストに関する情報を掲載するサイトです。 † 日本におけるソフトウェアテストの情報を網羅的に掲載することを目的とした情報サイトです。swtest.jpと呼んでください。 企業などへのリンクが多く掲載されていますが、特定の企業を優遇することはありません。公明正大がポリシーです。 まだ抜けがたくさんあると思いますので、にしまでお気軽に催促してください。すぐに対応できないかもしれませんが。 RSSはこちらです。ただしコメントが増えても更新扱いになりますのでご注意を。またTEF内部ページの更新も報告されます。 ↑
皆さんは、テストケース、と聞くと何を思い浮かべますか? 例えばWebアプリのログイン画面を思い浮かべて下さい。「ログインする」がテストケースだと答える場合もあれば、「○○というユーザ名、××というパスワードでログインする」と答える場合もあります。同時にログインしているユーザが何人いるか、もテストケースに書くと考えた方もいるでしょう。ユーザ名の入力とパスワードの入力の順序を考えた方もいるかもしれません。もしかしたら、GUI自動操作ツールのスクリプトを意味する場合もあるかもしれませんね。 このように、テストケースには色々と細かさのレベルがあります。このレベルのことを、テストケースの「粒度」と私は呼んでいます。粒度は粗すぎても細かすぎてもいけません。 例を挙げましょう。「ログインする」というテストケースを、テスト実施担当者(テストオペレータ)に渡したとします。テストオペレータは、テストケースにア
テストケースの粒度の話を覚えていますか。「○○というユーザ名、××というパスワードでログインする」というテストケースに対して、「ログインする」というテストケースは粒度が粗い、という話でしたね。 仮に自分の組織のテストケースが前者の粒度だったとしましょう。もしユーザ権限が4つあった場合は、それぞれの権限に合わせたアカウントで、最低でも4種類のテストケースを作成することになります。では逆に、権限の異なる4つのテストケースをレビューすることになったら、皆さんはどうしますか? まず4つのテストケースの違いを考えますね。ふむふむ、ユーザ名が違うなぁ、なぜ違うんだろう、と考えながら仕様を思い出したり、仕様書をめくったりします。なるほど、ユーザ権限が異なるわけか、では必要な権限は網羅されているかな、なんて考えながらレビューしていくと思います。面倒ですね。 では、4つのテストケースに対して「すべての権限の
テストの計画を立てる時の第一歩は、テストのフェーズを決めることです。それなりの規模のシステムに対して、デバッガ上で動かすテストから本番環境での負荷テストまで、あらゆるテストをごっちゃにして行おうとすると、並みのマネジャーでは計画通りにいきません。それどころか、破綻してしまいます。すべからく仕事を上手に行うためのコツは、似たような仕事をまとめて行うことですね。 テストのフェーズで最も有名なのは、単体テスト、結合テスト、システムテスト、受け入れテストの4つのフェーズです。Boehm御大が1979年に書いた"Guidelines for Verifying and Validating Software Requirements and Design Specifications"という論文が初出でしょうか。 単体テストは、モジュールを対象としたテストです。C言語では関数、Javaではメソッド(
テストが単純作業だと思っているマネジャーは、今でも少なくありません。新人でも使えない奴でもいいから、とにかく人員を投入して残業をさせろ、という指示を出すタイプですね。こうしたマネジャーの興味を強く惹くのは、大きくわけて2つの誘惑です。一つは、とにかく安い外注を使うこと。パートでも、オフショアでも構いません。外注を叩いて叩いて、同じ予算でなるべく多くの人員を投入しようとします。もちろん技術力の評価など二の次で、せいぜい過去に同種のプロジェクトをこなしたかどうか程度しか確認しません。 もう一つは、テストの自動化です。テストツールを買いさえすれば、ノウハウいらずで大量のテストができるようになるのではないか、という発想ですね。皆さんの周りには、こうしたマネジャーはいらっしゃいませんか? しかし、テストを自動化するだけでテストが楽になる、というのは幻想に過ぎません。最近はテストツールのベンダやリセラ
テストツール情報サイト † 不具合からの脱却!テスト自動化ツール研究 / 「テスト自動化ツール」選定の厳しい視点(無償の会員登録が必要) 2008/7/14 キーマンズネット / IT製品解体新書 http://www.keyman.or.jp/3w/prd/51/30002651/ (引用)Webシステムの品質に対する意識は高まってきているが、十分なテストの実施はそう容易なことではない。また、ソフトウェアは社会生活の中に奥深く入り込むようになったことから、その不具合がもたらす社会的・経済的損失は深刻さを増すばかりだ。こうした背景のもと、最近の開発プロジェクトではテスト工程を分業することが重要視されるようになり、ソフトウェアテストの自動化ツール効果的な利用に注目が集まるようになってきた。そこで今回はソフトウェアテストの自動化ツールにスポットを当てその基本から最新動向までをわかりやすく解説す
ソフトウェアテスト技術者交流会とは † 情報交換や技術向上を目指した、ソフトウェアテスト技術者の交流会です。ソフトウェアテストに携わっている技術者の方なら、どなたでも入会できます。みなさんの参加をお待ちしております。 ↑ なぜ交流会が必要か † ソフトウェアはどんどん複雑になってきています。その一方で、納期は短くなっているのも現状です。コストも下げなくてはなりません。そこで、テスト技術者が無償で気軽に情報交流できる場が必要となります。そのためにソフトウェアテスト技術者交流会(TEF: Testing Engineer's Forum)を設立しました。どんどんこの交流会を活用して、テスト技術を高めていきましょう! ↑
テストとは何か? blogを更新するのも、ずいぶん久しぶりだ。調子に乗って仕事を受けすぎてしまったり、さまざまな活動にコミットしたりしていると、どうしても筆が遅くなる。しかしたまには、どうしても書きたいことがあるものだ。 平鍋さんのblogは含蓄が深いので愛読している。しかし9/8のエントリ「分析とは何か、設計とは何か?」を読んで、ガッカリしてしまった。極めて短くまとめると、テストというのは現実領域での問題と解との突き合わせ作業を指しているのだそうだ。 もちろん問題と解との突き合わせには、苦労がつきものだ。問題そのものが変化することもあれば、問題の記述が不足していたり矛盾していたりすることもある。問題と解との突き合わせる手段が難しいこともあれば、どういう指標を用いればよいか分からないこともある。確かに、テストにとって問題と解との突き合わせは重要な作業であり、困難な作業である。 しかしテスト
テストをしていて一番悩むのが、どこまでテストすればよいのだろうか、という点です。勘と経験と度胸で終了判定を行っている組織もあれば、独自の方法を編み出している組織もあるようです。また信頼度成長曲線(Software Reliability Growth Model: SRGM)を始め、昔から研究テーマとしてもよく取り上げられます。しかし、これを考えれば万事オッケーというような、万能の判定基準はありません。信頼性を判定する指標も同様です。テスト対象やテストそのものの様々な側面を総合的に把握する必要があります。 その一つの側面が「カバレッジ(coverage)」です。どれくらい網羅したテストなのか、という指標を意味しています。最も有名なのはコードカバレッジでしょう。C0、C1などという用語を聞いたことはありませんか。もしくは命令網羅や分岐網羅、ノード網羅やリンク網羅という呼び方かもしれません。基
テストの進捗を妨げる最大の原因は何でしょう。操作ミスをしてしまい、テストケースどおり実施できないことでしょうか。テストツールが使いこなせないことでしょうか。それとも担当者が失踪することでしょうか。 多くの組織でテストケースが消化できない最大の原因は、テスト対象のソフトウェアにバグが多すぎることです。テストをする度にバグが発生していては、いつまで経ってもテストが終わりません。試しに、バグの発生しない(OKの)テストケースと、バグの発生する(NGの)テストケースの両方について、テストケースあたりの実施時間を測定してみて下さい。圧倒的にNGの場合の方が時間がかかるでしょう。 NGテストケースの方が実施時間が長いのは、現場にいらっしゃる方なら肌でお分かりのことと思います。少なくとも不具合報告書(バグ票)を書く時間はかかりますね。OSごと落ちてしまうバグの場合は、再起動の時間がかかります。ファイルや
このページを最初にブックマークしてみませんか?
『Nishi Laboratory - Home』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く