Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

アプリケーションが 正しく動作するということ - 自動テスト編 / Automated Tes...

アプリケーションが 正しく動作するということ - 自動テスト編 / Automated Testing

# 参考資料
- 「家づくりで理解する要求明確化の勘どころ~システム構築を成功させる要件定義のポイント~」
- https://www.ipa.go.jp/archive/files/000065172.pdf

- ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J01
- https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf

soudai sone

June 25, 2024
Tweet

More Decks by soudai sone

Other Decks in Technology

Transcript

  1. 自己紹介
 曽根 壮大(39歳)
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO


    
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます(長女、次女、長男)
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

  2. 1. 要望 
 2. 要求 
 3. 要件 
 4.

    仕様
 正しく動作しているとはなにか 上から下にブレイクダウンしていく 場合によっては往復もする 要求と要件は一緒として扱われることも多い
  3. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか
  4. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか ステークホルダー(顧客やPO)が持っている要望の例 - 会員制のECサイトがやりたい(機能) - 高速に表示したい(非機能) - 商品を沢山売りたい(機能・非機能)
  5. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか ステークホルダーと決めること - 会員登録できること(機能) - 商品を注文できること(機能) - 在庫を管理できること(機能 - 素早く表示できること(非機能要件) - 世界中のユーザが利用できること - Webとスマホアプリとして動作すること(機能要件) …etc
  6. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか 要件定義 - 会員登録機能 - 保存したい情報とか - マイページ - 表示したい内容とか - 管理画面 - CSV登録の有無とか - 実行環境 - Chromeだけでいいのかとか - 表示速度の基準値 - 表示して100ms以内に表示するとか …etc
  7. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 正しく動作しているとはなにか 各要件を実装するために必要な仕様の定義 - 会員登録はSSOに対応すること - 会員登録時に生年月日を取得すること - 氏名は姓と名で分けて保存すること - パスワードは20桁以上の半角英数字を使うこと - パスワードとメールアドレスは暗号化して保存すること …etc
  8. 正しく動作しているとは
 
 • 要望・要求を満たす要件である
 • 要件を満たした仕様である
 • 仕様通りに動作する
 正しく動作しているとはなにか 一般的なバグ

    仕様や要件が曖昧なときに「仕様通りではない」と言われて、ここに なる場合もある 今日のフォーカスするポイントはここ
  9. • 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。 
 • 故障を引き起こし、欠陥を発見する。 
 • 求められるテスト対象のカバレッジを確保する。 
 •

    ソフトウェア品質が不十分な場合のリスクレベルを下げる。 
 • 仕様化した要件が満たされているかどうかを検証する。 
 • テスト対象が契約、法律、規制の要件に適合していることを検証する。 
 • ステークホルダーに根拠ある判断をしてもらうための情報を提供する。 
 • テスト対象の品質に対する信頼を積み上げる。 
 • テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。 
 ソフトウェアテストの典型的な目的 引用元:Foundation Level シラバス 日本語版 Version 2023V4.0.J01
  10. • テストは欠陥があることは示せるが、欠陥がないことは示せない
 • 全数テストは不可能
 • 早期テストで時間とコストを節約
 • 欠陥の偏在
 • 殺虫剤のパラドックス


    • テストは状況次第
 • 不具合ゼロの落とし穴
 ソフトウェアテストの7原則 引用元:Foundation Level シラバス 日本語版 Version 2023V4.0.J01
  11. 1. コンポーネントテスト(ユニットテスト)
 メソッドや関数などの小さいコンポーネント(ユニット)単位で行うテスト。 
 2. コンポーネント統合テスト(ユニット統合テスト)
 ユニット間のインターフェイスや相互処理を対象にする。モデルの呼び出しやビジネスロジックの機能テ ストなど。
 3. システムテスト


    E2Eテスト使った機能テストなどシステム全体を対象とする。シナリオテストなども含む。 
 4. システム統合テスト
 他のシステム、外部サービスとの連携を対象にする。本番環境に近い環境の方がよりよいテストができ る。
 5. 受け入れテスト
 妥当性の確認などを行い、ビジネスニーズを満たしているか確認する。 
 テストレベル 参照元:Foundation Level シラバス 日本語版 Version 2023V4.0.J01
  12. 1. 機能テスト
 コンポーネントやシステムが実行する機能について評価する。機能テストは「何」をするべきかをテスト する
 2. 非機能テスト
 コンポーネントやシステムの実行する機能以外のテスト。非機能テストは「どのようにうまく振る舞うか」 をテストする
 3. ブラックボックステスト


    対象に対して、仕様を元に動作をテストする。仕様を満たしているかの確認。 
 4. ホワイトボックステスト
 対象に対して、コンポーネントやシステムの内部構造を元に動作をテストする。コンポーネントやシステ ムが意図どおりかを確認する。 
 他にも色々ある(シナリオテストとか
 テストタイプ 参照元:Foundation Level シラバス 日本語版 Version 2023V4.0.J01
  13. 1. コンポーネントテスト(ユニットテスト)
 メソッドや関数などの小さいコンポーネント(ユニット)単位で行うテスト。 
 2. コンポーネント統合テスト(ユニット統合テスト)
 ユニット間のインターフェイスや相互処理を対象にする。モデルの呼び出しやビジネスロジックの機能テ ストなど。
 3. システムテスト


    E2Eテスト使った機能テストなどシステム全体を対象とする。シナリオテストなども含む。 
 4. システム統合テスト
 他のシステム、外部サービスとの連携を対象にする。本番環境に近い環境の方がよりよいテストができ る。
 5. 受け入れテスト
 妥当性の確認などを行い、ビジネスニーズを満たしているか確認する。 
 テストレベル 参照元:Foundation Level シラバス 日本語版 Version 2023V4.0.J01 ここの話
  14. 1. 機能テスト
 コンポーネントやシステムが実行する機能について評価する。機能テストは「何」をするべきかをテスト する
 2. 非機能テスト
 コンポーネントやシステムの実行する機能以外のテスト。非機能テストは「どのようにうまく振る舞うか」 をテストする
 3. ブラックボックステスト


    対象に対して、仕様を元に動作をテストする。仕様を満たしているかの確認。 
 4. ホワイトボックステスト
 対象に対して、コンポーネントやシステムの内部構造を元に動作をテストする。コンポーネントやシステ ムが意図どおりかを確認する。 
 他にも色々ある(シナリオテストとか
 テストタイプ(再掲) 参照元:Foundation Level シラバス 日本語版 Version 2023V4.0.J01
  15. • 機能テスト
 ◦ できること
 ◦ できてはダメなこと
 ◦ できないこと
 • 非機能テスト


    ◦ 場合による
 • ブラックボックス
 ◦ 境界値分析・同値分割法 
 ◦ デシジョンテーブル(入力の全組み合わせ) 
 ◦ 状態遷移
 • ホワイトボックステスト
 ◦ ステートメントテスト(正常系) 
 ◦ ブランチカバレッジ(分岐網羅) 
 ◦ コンディションカバレッジ(複数の分岐を網羅する) 
 ◦ 改良条件判定カバレッジ MC/DC(最終結果が変わるケースの分岐を網羅する) 
 ユニットテストに書くべきこと 参照元:Foundation Level シラバス 日本語版 Version 2023V4.0.J01
  16. テスト(検査)のコツ コードの振る舞い 意図した振 る舞い 既知の 問題 意図した振 る舞い 意図した振 る舞い

    意図した振 る舞い テスト(検査)が可能な部分 意図していない部分 軽微なバグなど