2025-08-27 社内勉強会 ソフトウェアテストの基礎 / Basics of Software Testing

Transcript

1. 2025/08/27 社内勉強会 Powered by k1LoW/deck 1 ソフトウェアテストの基礎
2. 2 • ソフトウェアテストの役割と価値を理解する • 開発プロセスにおけるテストの位置付けを知る • 代表的なテスト技法を知る 今日のゴール
3. 3 テストって何？ • ソフトウェアが要求や設計どおりに動 作し、利用者が期待する品質を満たし ているかを確認・評価すること ソフトウェアの品質特性→ ソフトウェアテスト見積りガイドブック
4. 4 • 仕様を満たしていることを確認するため • リリース後の不具合を減らすため • 開発の効率を上げるため なぜテストが必要か？
5. 5 テストレベルと開発プロセス ＜何をテストするのか？＞
6. 6 • 単体テスト ◦ 個々のクラスやメソッド or単一の機能 が正しく動作するか • 結合テスト（統合テスト） ◦ クラス間or機能間の連携が正しく動作するか • システムテスト ◦ ソフトウェア全体が仕様どおりに動作するか • 受け入れテスト（運用テスト） ◦ ユーザーの観点で、要件が満たされているか確認 テストレベル
7. 7 • 商品の合計金額を計算する関数（単一メソッド） ◦ 100円の商品A×2個、300円の商品B×1個 → 500円になるか ◦ 数量が0個なら0円になるか • クーポン割引を正しく計算できるか（単一メソッド） • 商品の検索ボタンを押したときに、条件に一致する商品のリストが表示され るか？（単一機能） 単体テストの例（ ECサイト）
8. 8 • 商品の検索ボタンを押したときに、条件に一致する商品のリストが表示され るか？（複数クラス） • 「カート画面」から「決済画面」へ遷移したとき、選んだ商品・数量が正しく引 き継がれているか？（複数機能） • 「ログイン機能」と「購入履歴表示機能」が組み合わさったとき、正しいユー ザーの履歴が出るか？（複数機能） 結合テストの例（ ECサイト）
9. 9 • 新規ユーザー登録 → ログイン → 商品検索 → カートに入れる → 決済 → 注文確認メールが届く、という一連の流れが問題なく動作するか？ • 大量アクセス時にページが遅くならないか？（性能テストの一部） • パスワードを間違えて入力したらロックされるか？（セキュリティテストの一 部） システムテストの例（ ECサイト）
10. 10 • 「クレジットカード決済が対応していること」という要件に対して、実際に顧客 がカードを使って支払いし、取引が成立するかを確認する • 「1万円以上購入したら送料無料になる」という仕様を顧客が実際に操作して 試す 受け入れテストの例（ ECサイト）
11. 11 V字モデル ソフトウェアテスト見積りガイドブック より V字モデルにも種類がある 中身は重要ではなく、各工程に対応する テストがあることが大事
12. 12 テスト設計 ＜どのようにテストするのか？＞
13. 13 • 理想は全ての可能性をテストすること • 時間・コストの制約があるため、現実的には不可能 → 適切なテストを設計することが重要 網羅性と効率のバランス
14. 14 • ブラックボックステスト ◦ 仕様や要件に基づいて実施するテスト ◦ 実装レベルの知識を必要としない • ホワイトボックステスト ◦ 実装レベルの知識に基づいて実施するテスト ◦ ソフトウェアの内部パス、構造、実装など テスト種別
15. 15 ブラックボックステスト • 同値クラステスト • 境界値テスト • デシジョンテーブルテスト • ユースケーステスト ホワイトボックステスト • 制御フローテスト テスト技法
16. 16 • 結果が同じになる入力のグループ（同値クラス）を特定し、各クラスから代表 的な値を選んでテストする手法 • 例 ◦ 入力値は0～100の整数 ◦ 0～19は未成年、20～100は成人 と返すプログラムを考える ブラックボックステスト 同値クラステスト
17. 17 • 同値クラステストを元に、境界値に注目したテスト • パーティションの最小値と最大値、または最初の値と最後の値を選んでテス トする • -1, 0, 19, 20, 100, 101 ブラックボックステスト 境界値テスト
18. 18 • 可能なすべての条件（入力）と取りうるすべての結果（出力）を表にしてテスト する手法 • 複雑な分岐をテストするのに有効 • 例：ログイン画面 ◦ 条件1：ユーザーIDが正しいか ◦ 条件2：パスワードが正しいか ◦ 結果：ログイン成功 or エラー ブラックボックステスト デシジョンテーブルテスト 条件1 条件2 結果 〇 〇 ログイン成功 〇 × IDエラー × 〇 PWエラー × × IDエラー, PW エラー
19. 19 • 利用者が実際にシステムをどう使うか（ユースケース）をシナリオ化してテス トする手法 • 仕様書や業務フローをもとに、現実的な操作シナリオを作成する • 例：ネットショップでの購入フロー ◦ 商品を検索 → カートに追加 → 決済 → 注文完了メール受信 ブラックボックステスト ユースケーステスト
20. 20 ブラックボックステスト • 同値クラステスト • 境界値テスト • デシジョンテーブルテスト • ユースケーステスト ホワイトボックステスト • 制御フローテスト テスト技法（再掲）
21. 21 • 分岐や繰り返しなどの制御フローに基づいてテストする手法 • 網羅基準を定めてテストケースを作成する ◦ 命令網羅（すべての命令を実行する） ◦ 分岐網羅（すべての分岐を実行する） ◦ 条件網羅（分岐条件のすべての組み合わせを実行する） # 会員かつ購入金額が1000円超の場合は10%割引
 if (member == true && amount > 1000) {
 discount = 10%;
 }
 ホワイトボックステスト 制御フローテスト
22. 22 テストレベル ＜何をテストするのか＞ • 単体テスト • 結合テスト（統合テスト） • システムテスト • 受け入れテスト（運用テスト） テスト設計 ＜どのようにテストするのか＞ • ブラックボックステスト ◦ 同値クラステスト ◦ 境界値テスト ◦ デシジョンテーブルテスト ◦ ユースケーステスト • ホワイトボックステスト ◦ 制御フローテスト 全体像
23. 23 おまけ： テストによる開発の効率化
24. 24 • 仕様を満たしていることを確認するため • リリース後の不具合を減らすため • 開発の効率を上げるため なぜテストが必要か？（再掲）
25. 25 • テストを自動化して、繰り返し実行できるようにする ◦ 修正するたびにテストを実行し、壊れていないか確認する • 不具合を早期に発見し修正する どうやってテストによって効率を上げる？
26. 26 • QAテスト ◦ システム全体の品質を保証し、要件どおりに動作するかを確認するため に行う ◦ ユーザー視点やビジネス要件に基づき、全体の動作や使い勝手を評価す る ◦ 今まで話していたのはこちら • 開発者テスト ◦ 開発者が自身のコードの正確性を確認するために行う ◦ 細かい粒度のテストで、技術的な視点で行われる テストの分類
27. 27 • 和田卓人さんの「質とスピード」を読もう https://speakerdeck.com/twada/quality-and-speed-aws-dev-d ay-2023-tokyo-edition もっと学びたい人
28. 28 • 要件・仕様を満たすことを確認するテスト ◦ テストレベルとVモデル（何をテストするのか） ◦ テスト設計（どのようにテストするのか） • 開発を効率化するためのテスト ◦ 自動化されたテストで自信を持って変更する まとめ