ソフトウェアテスト技法ドリルを読みました
最近、担当している機能のリリースしたのですが、リリース後のバグが多く…
テスト設計やテストケースの洗い出しがきちんとできていなかったと実感しました。
会社のテストエンジニアに相談したらソフトウェアテスト技法ドリルをおすすめしてくれたので読んでみました。
個人的に重要だと思ったところ&知らなかったことをまとめてます。
どんな本
- テスト技法の正しい使い方が実践的に学べる
- テスト技術者向けに、テスト設計および実施のノウハウを披露し、解説している本。
- 誰が読んでも理解ができ、すぐに実践できることを目標にソフトウェアテスト技法を一連の流れで説明
- 一連の流れとは、テストの視点・観点といった「点に注意を向ける」といった話から、テストの目的の一つである品質に関する情報を提供する「多次元の品質」まで
目的
テスト技法の正しい使い方や一連の流れを学ぶことで、実践的にテスト設計できるようになる。
1章 点に注意を向ける
怪しい点に向けるテストについての章
- 仕様書を読むときは3色ボールペンを使うことをおすすめしてた
- 仕様書で曖昧なところは具体的なデータを示し、そのデータを見て、「間」「対称」「類推」「外側」を考える癖をつける
- 思っきり意地悪になってテストデータやテスト手順をつくる
- 過去の経験を活かすこと
テストの大部分は、仕様書を読んで怪しいところを見つけて確認する
テストの大部分を占める怪しいところをテストする方法の章
2章 線を意識する
連続して変化する数値や文字コードについてテストする方法について
同値分割と境界値分析
同値分割 入力される可能性があるデータをすべてテストするのはたいへんなので入力をグルーピングしてそれぞれのグループから代表となる値を選びそれだけをテスト 同値分割した各々のグループのことを「同値クラス」と呼ぶ
境界値分析 代表となる値を選ぶときにそれぞれのグループの端っこを狙う 境界値に関係するバグは数が多い
- 境界値、端っこにはバグが隠れている可能性が多い。(図に描いて問題を正しく理解するように)
- 異常値は他の異常値を隠す
- 線を意識することで、端っこ以外の点をテストから除外し効率化することができる
3章 面で逃さない
- 1〜2章は主にデータに焦点を当ててテストを減らす方法について
- ソフトウェア自体はデータからなるのではなく、ロジック(論理)の塊から構成されている。
- ロジックとは入力の組み合わせによる特別な動作。ソフトウェアの入力が系統的にロジックを網羅し、正しく動作することをテストするテクニックを身につける必要がある。
ドメイン分析テスト
関係性がある複数の変数を同時にテストする方法
on/off/in/out
on : 着目している境界値のこと
off : onポイントに対して境界値分析をしたときに見つかる隣接したもう一つの境界値のこと
in : ドメインの内側の値
out : 外側の値
多くの変数があった場合は、着目する一つの変数についてon offを変化させ、他の変数についてはすべてinにしておけばその変数のon/offポイントを確実に評価することができる。 Binderのドメイン分析テストマトリクス
方法
- まず変数を探す
- それぞれのon/off/in/outについて考える
- ドメイン分析テストマトリクスを作成する
ドメイン分析テストは、関連性がある(特に数式で結ばれている)複数の変数をテストするときに基本となるテクニック(範囲を扱うとき等)
3.2 デシジョンテーブル
デシジョンテーブルで扱う変数は倫理式で結ばれている
- AND
- OR
- NOT
if文やswitch文はすべてデシジョンテーブルにできる
3.3 原因結果グラフ
条件が多くなると大きなデシジョンテーブルを作成する必要がある。
プールグラフから単純な規則を使ってデシジョンテーブルを作成する ソフトウェアのテストで利用するブールグラフのことを原因結果グラフという
3.4 CFD法
CFD(Cause Flow Diagram)法
複雑な論理関係の仕様から重要なテスト条件を漏らさない技法 「原因の集合」と「原因どうしのつながり」に着目し、流れ線でつなぐことによって仕様を図式化し、そこからデシジョンテーブルを作成する技法
原因を集合で表現することで明示的に補集合についてテストの視点が届く
まとめ
- ドメイン分析
- on/off/in/out
- デシジョンテーブル
- 論理的な関係をテストする基本となる表
- 同じロジックをまとめるテクニック(デシジョンテーブルを圧縮)
- 原因結果グラフ
- 論理関係を目で見える形で表現したもの
- CEGTestで具体的な事例を解いてみる
- CFD法
- 原因結果グラフの欠点である難しさを改善したテスト技法
- ロジックを設計するときに使用すれば、ロジックの問題点が見つかる
- 図式化されているのでレビューがしやすい
4章 立体で捉える
- 新規機能追加機能によってこれまで表にでてこなかった母体のバグが魔物のように目を覚まし、バグとなって顕在化することがある
- 関連性を効率的にテストしていく必要がある。
- ソフトウェア自体は3章と同様に2次元で考えて、そこに組み合わせるべき「要因を選ぶ目線」を追加し立体で考える。
- 要因を選ぶ目線
- ソフトウェアの利用者である顧客の視点(6W2H)
4.1 HAYST法
仕様上は機能と機能の間には関連がないことが前提になっいるテスト(直交している) 直交している機能を組み合わせたときに、本当に問題が起こらないことを効率よく確認する方法
4.1.1 HAYST法を使う意義
一般にソフトウェアは各機能に対して、それぞれを独立してつくろうと努力し開発されるもの。 実際はどこかで意図しない関連性が生まれてしまう。
そこでHAYST法を用いてテストをすることが重要になる
4.1.2 因子と水準の抽出
怪しい因子を見つけて、それをHAYST法、またはペアワイズで表に組み上げてテストすることが重要
- 因子: テスト対象の項目(判定または条件)
- 水準: 因子の取り得る値
- 強さ: 因子の組み合わせ数
どうすれば、有効な因子と水準が見つかる?
6W2Hで考える - When - Where - Who - What - Why - Whom(誰のために) - How - How much(価格、量)
4.1.3 FV表
組み合わせるべき因子水準が見つかり、テスト対象の理解が進んだところで FV表を作成
No. | 目的機能(Fr) | 検証内容(V) | テスト技法(T) |
---|---|---|---|
4.2 ペアワイズ
4.2.1 ペアワイズテストとは?
ソフトウェアのバグの多くが1つまたは2つの因子の組み合わせによって発生している という事実に基づいてテストケースを作成する方法。
すべての因子の組み合わせでなく、 2組の因子(強さ2) における水準の組み合わせをすべて網羅することによってテストケースを制限したもの
因子:テスト対象の項目、カテゴリー
水準:因子の取りうる値
強さ:因子の組み合わせ数
例えば、ブラウザにメッセージテンプレートを表示させるときの例
要件は
端末 | ブラウザ | テンプレート |
---|---|---|
iPhone | Chrome | 1 |
android | safari | 2 |
macbook | Firefox | 3 |
windows | Edge | 4 |
この例では因子が端末、ブラウザ、テンプレート
水準がiPhone,android,macbook,windowsなど
強さは組み合わせ数なので、2の場合は(端末,ブラウザ)、3の場合は(端末,ブラウザ,テンプレート)
4.2.2 PICT
ペアワイズ法によってテストケースを生成するためのオープンソース・ソフトウェア
使い方は以下が詳しそう https://qiita.com/greymd/items/ad18aa44d4159067a627
まとめ
複数の要因に倫理関係がない場合。すなわち要因が直交している場合のテスト技法について。
- HAYST法
- テスト対象のテスト条件(HAYST法では「因子」と「水準」と呼ばれる要素を使います)を抽出し、これらの組み合わせを網羅するための直交表という表に割り付け、それをもとにテストを実施する技法
- 組み合わせるべき因子を抽出する方法について
- 有効な因子と水準の見つけ方
- ペアワイズ
- 因子の組(ペア)に注目して、全ての因子の組み合わせでなく、全てのペアの組み合わせにテストを制限
- PICT
5章 時間を網羅する
普段まったく問題なく動作しているソフトウェアが何気ないタイミングで動かなくなる問題について、状態遷移の観点と並列処理の観点からテストによる対応を考える。
5.1 状態遷移テスト
浅く全体を確認するテストから深く詳細にテストするものがある。
時間を意識したテスト設計について考える
状態遷移テスト
状態遷移図を書いてみる→状態遷移図から、適用不可のイベントを見つけることは困難。
状態遷移表を書き、適用不可(N/A)を含め、セルの一つひとつの動作をテストすることで基本的な状態遷移のテストを実施することができる。
Nスイッチカバレッジ
壊れた内部的な問題の顕在化方法について考える。 テストを確実に漏れなく実施するテスト技法は?→Nスイッチカバレッジ
Nスイッチカバレッジとは、 最初に遷移前の状態を列方向に、遷移後の状態を行方向にならべた状態遷移表を作成する。
状態遷移テストの実際
技法は上記の通りだが、実際の製品に適用しようとした瞬間に困難にぶつかる。
- ハードウェアの状態
- ソフトウェアの状態
- 外の世界の状態
に分けて考える
組み合わせテストの延長線上として捉えることができる。(HAYST 法やペアワイズでテストする)
テストだけではなく、アーキテクチャや設計、開発段階でのモデルチェッキングなどを総動員して対処する必要がある
6章 多次元の品質
人間の構造は現有のどのようなソフトウェアよりも複雑な構造をもっている。 ソフトウェアより複雑な構造をもつ人間のテストについて考えてみればソフトウェアテストへの糸口が見つかるかもしれない。
人間に対するテストとソフトウェアテスト
人間のテストというと学校で受けたテスト、すなわち、日々のテスト、中間試験、期末試験。身体測定、体力測定、健康診断など
人間に対するテストとソフトウェアテスト
人間に対するテスト | ソフトウェアテスト | ||
---|---|---|---|
種類 | 目的 | 種類 | 目的 |
小テスト・中間テスト・期末テスト | 新たに学習した範囲を中心にしたテスト | 派生開発テスト テストレベル | 追加開発を中心にテスト 段階的テスト |
科目ごとのテスト | それぞれの分野の能力を確認 | テストタイプごとのテスト | ソフトウェアの特性を中心のテスト |
身体測定 | 大まかな発育状態の確認 | 静的テスト | コード量や複雑度などを静的にテスト |
小テスト・中間テスト・期末テスト | 新たに学習した範囲を中心にしたテスト | 派生開発テスト テストレベル | 追加開発を中心にテスト 段階的テスト |
体力測定 | 運動能力を結果で測定 | 動的テスト | 動かしてみて振る舞いを確認するテスト |
健康診断・人間ドック | 病気の有無を予測しながら確認 | テスト専門者によるテスト | バグの検出と品質の確認 |
テストの効率性
ソフトウェアテストにおいても経済的に実施することはもちろん、ツールを整備し簡単に多くの情報を取得できるようにすべき
ソフトウェアテストとは何か
点にはじまり、線、面、立体、時空とテストの複雑度を増やしてきた。 人間に対するテストと比較することで、適切な時期に適切なテストを行うことが大切。
テスト対象は一般的に複雑なので、さまざまな視点から眺めるということをする。 さまざまな視点から眺めるということは多次元である。
一つの方向から眺めただけでは、決してその姿は想像できない。
さまざまな視点でテスト対象をテストすることが重要
- シナリオテスト
- わざとちょっと変わった行動や失敗を犯すシナリオをつくり、そこから回復させながらユーザーのしたいことを継続させるようにする
- 視点の爆発を狭く深く追うことでカバー
- When,Where,Whoを明確にする
- 固定名詞や定数値を使う
- 例外処理シナリオ
- 受け入れテスト
- 受け入れるユーザー側でのテスト
- サンプリングテスト
- 品質を保証する
- 統計的テスト
- 信頼性を確認するための統計的テスト
最後に(まとめと感想)
テスト技法の奥深さを感じました。
テスト技術者のものの見方とは、「部分的ではなく全体・包括的に複数を捉えること、手段ではなく目的に目を向けること、企業ではなくお客様の目線で考えること、独立ではなく相互関連性を発見すること、構造に加え振る舞いを評価すること」
この一文が印象的でした。
今までテストについて真剣に向き合ったことがなくて、とりあえず書いてみるみたいなことをしていたので、テストを書くときに何を考えるか、とか仕様書の読み方はあまり意識していなかったなあ、と反省しました。
あと、PICTは実際に手を動かして使ってみました。
(テスト工数を半分以下に減らせそう...!)
テスト設計やったことなくて、テストってなんだろう?テスト設計って?な人は読んでみるのをおすすめします。