LoginSignup
2
5

More than 3 years have passed since last update.

1. 記事作成の理由

・職場で結合テストをアサインされたが、人員に限りがあるため、適切にテストケースを絞り込む必要がある。
・仕事で、初めてのテスト設計とテスト実施に取り組んでいるため。

2. 参考文献

以下の図書を参考に本記事を作成。
高橋寿一 著、株式会社翔泳社、「知識ゼロから学ぶソフトウェアテスト」、2013年12月
AmazonのURL:https://www.amazon.co.jp/%E7%9F%A5%E8%AD%98%E3%82%BC%E3%83%AD%E3%81%8B%E3%82%89%E5%AD%A6%E3%81%B6%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88-%E3%80%90%E6%94%B9%E8%A8%82%E7%89%88%E3%80%91-%E9%AB%98%E6%A9%8B-%E5%AF%BF%E4%B8%80/dp/4798130605/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1581396780&sr=8-1

3. 内容

3. 1. 目次

参考文献の目次を以下に示す。

1章:はじめに
2章:ソフトウェアテストの基本(ホワイトボックステスト)
3章:エンジニアが最もよく使う手法(ブラックボックステスト)
4章:探索的テスト
5章:機能あらざるもののテスト、最難関のテストに挑む(非機能要求のテスト)
6章:ソフトウェアテスト運用の基本(テスト成功の方程式)
7章:ソフトウェア品質管理の基本(ソフトウェア品質のメトリックス)
8章:テストの自動化という悪魔(なぜ自動化は失敗するのか)
9章:それでもテストがうまくいかない人へ

3. 2. テスト担当者心得

a)

バグを全部見つけるのは無理だと心得よ(Cem Kaner)

ソフトウェアは十分複雑な工業製品。
b)

バグは特定の部分に偏在している。

一説にはバグの47%は、プログラムの4%に偏在しているという。
c)

ソフトウェアで重要なのは、どの部分にバグが出やすいのか、
そこにどのようなテスト手法を適用すれば
十分な品質を得られるかを知ることである。

闇雲にやるのではなく、バグが起きそうな場所を重点的にやる。

d)

「品質向上のための投資は、投資額が修正にかかる費用を超過するか、『もっとマシなことをすべきだ』と誰か言い出すまで増加し続ける。」

完璧なソフトウェアは作れないが、適切な品質を担保することで「十分な」品質をもつソフトウェアを作る。

e)

テストコードを書ききるのは学生でもできるが、テストケースを書き切るのは難しい。

以下のプログラムを例に、テストケースを書き切れるかどうかが重要。

<例題>
「このプログラムでは、ユーザーが三つの整数を入力します。この三つの値は、それぞれ三角形の三辺の長さを表すものとします。
 プログラムは、三角形が
  不等辺三角形
  二等辺三角形
  正三角形
のうちのどれであるかを決めるメッセージを印字する。
このプログラムをテストするのに十分と思われる一連のテストケースを書いて下さい。」

答えは、参考文献を参照ください。

3. 3. テスト基本(ホワイトボックステスト)

・プログラムの論理構造が正しいかを解析するテスト
・制御パステストは、カバレッジ率をとるために使われるテストであるため、基本的に実施。
  ステートメントカバレッジ・・・処理単体のテスト。実施は簡易だが、条件漏れなどに対応しきれない。
  ブランチカバレッジ・・・分岐をテスト。テストケース数が増えるのが欠点。
・カバレッジ基準を設けて、テスト計画を立てる。目処は以下の通り。
 a) 通常の商用テストならば60~90%。
 b) ヒューレットパッカード社の調査では、高いと80%。低いと20%。

3. 4. よく使われる手法(ブラックボックステスト)

・ソフトウェアは、以下の四つから構成される。
 a) 入力処理
 b) 出力処理
 c) 計算
 d) データ保存

・同値分割法と境界値分析は、a)入力処理とb)出力処理をチェックできる。
・複雑な入出力のためのテストとして、ディシジョンテーブルテストがある。
 全ての入力の組み合わせを表にし、その入力に対する動作もしくは出力を明記する。

 表には、
 1.状態
 2.ルール(状態の組み合わせ)
 3.動作(アクション)

・状態繊維テストは、GUI、オブジェクト指向ソフトウェア、通信プロトコルテストに有用。
・テストでのバグの発見率は60%程度が現実。とっとと60%のバグを見つけて、そのほかのバグがなぜ発生したか、そしてどうやって防止するかに時間を費やすのが有用。

3-5. テストプランの書き方

・テストプランのテンプレートは、「IEEE 829」を使われることが多い。
・テストケースは、再現性が高くないとダメ。ツールを使うと楽。
 ツール例:Testlink
・テストケース数は、10~15行に一つ程度が多い。(日立ソフト)

3-6. 品質管理の基本

・サイクロマチックメトリクスは有用。

4. まとめ

・教科書を読み切った結果、テストだから100%のカバーをしなくてはいけないと肩に力が入っていたが、適度に力が抜けた。

2
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
5