[入門] ソフトウェアテスト （メモ）

ブラックボックステスト

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. 内容

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

１章：はじめに
２章：ソフトウェアテストの基本（ホワイトボックステスト）
３章：エンジニアが最もよく使う手法（ブラックボックステスト）
４章：探索的テスト
５章：機能あらざるもののテスト、最難関のテストに挑む（非機能要求のテスト）
６章：ソフトウェアテスト運用の基本（テスト成功の方程式）
７章：ソフトウェア品質管理の基本（ソフトウェア品質のメトリックス）
８章：テストの自動化という悪魔（なぜ自動化は失敗するのか）
９章：それでもテストがうまくいかない人へ

1. 1. テスト担当者心得
      a)バグを全部見つけるのは無理だと心得よ（Cem Kaner）
      ソフトウェアは十分複雑な工業製品。

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

c)ソフトウェアで重要なのは、どの部分にバグが出やすいのか、
そこにどのようなテスト手法を適用すれば
十分な品質を得られるかを知ることである。
闇雲にやるのではなく、バグが起きそうな場所を重点的にやる。（２:8の法則）

d)「品質向上のための投資は、投資額が修正にかかる費用を超過するか、『もっとマシなことをすべきだ』と誰か言い出すまで増加し続ける。」
完璧なソフトウェアは作れないが、適切な品質を担保することで「十分な」品質をもつソフトウェアを作る。

e)テストコードを書ききるのは学生でもできるが、テストケースを書き切るのは難しい。
以下のプログラムを例に、テストケースを書き切れるかどうかが重要。

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

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

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

2. 4.　ブラックボックステスト
   ・ソフトウェアは、以下の四つから構成される。
   　a) 入力処理
   　b) 出力処理
   　c) 計算
   　d) データ保存

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

　表には、
　1.状態
　2.ルール（状態の組み合わせ）
　3.動作

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

3-5.　テストプランの書き方
・テストプランのテンプレートは、「IEEE 829」を使われることが多い。
・テストケースは、再現性が高くないとダメ。ツールを使うと楽。
　ツール例：Zephyr
・テストケース数は、10~15行に一つ程度が多い。（日立ソフト）

3-6. 　テスト自動化
　　・MS-TEST:　自動化というのは、テストの仕事の成果をアピールする上で非常にわかりやすいメリット
　　・ただテスト自動化で何を正解として解を求めるか人間が意思決定するので知識・判断が問われる。

　
3-7. メモ
　　・テスト標準化：ISTQB（International software testing qualifiactions board)
　　・ https://www.istqb.org/
　　・テストプログラム儀淳団体から勉強するとわかりやすかった。

4.まとめ
学生ながらにソフトウェアテストとはどのような取り組みなのか実験的にアクションすることができました。バグにもレベル分けする習慣化やサンプリングテストの手法を習慣的に行うことでソフトウェアテストを意識した開発ができると思いました。まだまだ、慣れないことばかりでわからないので日々失敗し学んでいきたいです。