テスト・設計研修【MIXI 24新卒技術研修】 - YouTube
テストは不具合を示す
デバッグは不具合を改修するところまで
ソフトウェアテストは想定通りの動作かの評価検証
運用時の不具合を提言するための一つ
システム利用者が触る外部品質特性
見えない内部品質特性
ソフトウェアの品質は8つに分けられる
- 機能適合性
- 求められた内容
- 性能効率性
- パフォーマンス
- 互換性
- 汎用性
- 使用性
- 使いやすさ
- 信頼性
- 障害耐久
- セキュリティ
- データ漏洩とかへの耐性
- 保守性
- メンテのしやすさ
- 移植性
- どの環境でも動くか
TDD
テストリスト(先)と、その実装
テストリストが空になるまでやる
実装はテストを満たすことを第一に
次のテストリストへ行く前にリファクタ(後)
テストを書く(Red)
実装する(Green)
リファクタリング(Refactor、Blue)
このテスト関数は別のファイルに分けたほうが良い
テストを書くことは自動テスト
テストを先に書くことはテストファースト、システム設計がいつも全て出来てるわけでない
前のテストが落ちてしまったらダメ
テスト中に新しいテストが必要になったら、テストリストの最後に追加する
その時に追加してはいけない
テストは一つずつ
テスト中にリファクタしない
必要以上にリファクタしない
メリット
品質の高いコード
段階的設計
バグの早期発見
コードの変更可容性
テスト容易性
テストが難しい(外部に依存している、パターンが多い)
テスタビリティを元に書く
- 実行円滑性
- 実行速度等
- 観測容易性
- 出力及び内部状態の確認
- 制御容易性
- テストを行うまでの操作
- 内部挙動が弄れる関数作り
- 分解容易性
- テスト範囲のみの分離
- 単純性
- コード、仕様がシンプル化
- 安定性
- 対象はテスト負担を増やすような変更が少ないか
- 仕様変更やそれによる影響が少ないか
- 理解容易性
- テストを行うための情報の得やすさ
- 仕様書など
依存部分をテスト用に変更できる
→制御容易性
適切に関数化されている
→分解容易性
個別テストが可能
→分解容易性、単純性、安定性
テストケース
最小の時間と労力で、ほとんどのエラーを検出する可能性が最も高くなるように
テストケースを設計する
-
単体テスト(ユニットテスト)
- クラス・メソッド単位
-
統合テスト
- 単体より大きい
-
システムテスト
- ソフトウェアテスト
-
受入テスト
- 顧客がソフトウェアを受け入れるときのテスト
-
ブラックボックステスト
- 実装知らなくていい
- 仕様や要件に基づいたテスト
-
ホワイトボックステスト
- 実装テスト
-
グレーボックステスト
- 実装をある程度調べ、ブラックボックステストのテストケースを効率的に選択
- 他の人にブラックボックステストを任せるやつ
テスト技法
無数にあるがざっくりパターン分
- BBT
- 同値クラステスト
- 境界値テスト
- デシジョンテーブルテスト
- ペア構成テスト
- WBT
- 制御フローテスト
- データフローテスト
同値クラステスト
同じ値を返す範囲＝同値クラスに対し、代表値を選んでテスト
代表値に境界値を選ぶこと→境界値テストも
境界値テスト
同値クラスが切り替わる場所のテスト
- 欠陥があることは示せるが、欠陥が無いことは示せない
- 全数テストは不可能
- 早期テストで時間とコストを節約
- 欠陥は一部分に集中しやすい
- 実装に最適なテストを常に考える
- テストは軽くする
- 実装の足かせにしない、数を減らしたりリファクタして軽く
- 確率で落ちるテスト(Flaky Test)に対処
- 再実行はCIコストが上がる
- QAエンジニアとは早めに仕様をすり合わす
- 仕様設計から
- 重要なのは成果・生産性
ペアプロ
ドライバー
何をするか発言
ナビゲータ
いい方法、ミス等に積極的に発言
常にドライバーのやっていることを把握
コードレビュー
PR
背景、理由、物の説明
レビュー欲しい場所、実装での疑問点
関連PR、issue
背景や仕様を追いやすい
マージタイミング
分からなければ聞く
褒めろ