学習進捗
今日はクラシフィケーションツリー技法を中心に、シラバスの品質特性の学習をしていました。
以下は学習メモとなります。
クラシフィケーションツリー
クラシフィケーションツリーについては、ソフトウェアテスト技法ドリルで学習をしたのですが、テスト技法が定着していないので、YouTubeで確認をしつつ、ネットの記事を探して問題を解いてみました。
以下の資料がとても参考になりました。
https://jasst.jp/symposium/jasst24tohoku/report_pdf/S4.pdf紙のノートを利用し、問題を解いてみます。字が汚くてすみません。
答え合わせをしながら、クラスを追加して遊んでました。
品質特性
品質特性のメモです。
- 機能正確性テスト
- 適用：すべてのテストレベル
- 機能適切性テスト
- 適用：システムテスト。統合テスト後半でも可能
- 相互運用性テスト
- 設計上の特徴に重点
- 標準の通信規格
- 通信に必要なものを自動的に検出
- COTS、システムオブシステムズ、IoT、外部連携しているWebサービス
- 適用：コンポーネント統合テスト、システム統合テスト
- データ変換 => 「データ ＋ トランザクション」を作成できなければならない
- 各技法はすべて相互運用性テストに適用可能
- 設計上の特徴に重点
- 使用性評価
- TAは評価作業を調整、支援する立場
- アクセシビリティ
- 適用：統合テスト -> システムテスト -> 受け入れテスト まで継続
- 使用性評価の手法
- 使用性テスト：有効性（効果性）、効率性、満足性
- 使用性レビュー：ヒューリスティックに適合、視覚化
- 調査、アンケート：
- SUMI：使用性の明確な測定値を提供
- WAMMI：Webサイト解析と測定一覧表
- 設置性テスト
- パラメータが多い時はペアワイズを使う
- 機能正確性をテスト
- 機能適合性テスト（何をするのか）
- 環境適応性テスト
- 効果的、効率的
- 置換性テスト
- 完成システムに統合するための、複数の代替コンポーネントを使用できる場合、機能統合テストと並行してテストアナリストが実行することができる
置換性テストの具体例
特定のコンポーネントがシステム内で適切に置き換えられるかを評価するテスト
シナリオ: オンラインショッピングシステムの支払いモジュール
- 背景
- オンラインショッピングシステムの支払い処理では、複数の支払いゲートウェイ（例: PayPal、Stripe、Square）が利用できる。
- 各支払いゲートウェイは独立した「コンポーネント」として扱える。
- テスト対象
- システム全体を再設計することなく、PayPalをStripeやSquareに置き換えても、システムが正しく機能することを確認する。
- 置換性テストの実行
- 準備：テストアナリストは、それぞれの支払いゲートウェイごとに統合テスト用の環境を設定する。
- テスト実施：
- Stripeで決済を実行 → 注文が正しく処理されるかを確認。
- Squareにコンポーネントを切り替え → 同じシナリオを実行し、結果が一貫しているかを確認。
- 各支払いゲートウェイがエラーを返した場合、システムが適切にエラーメッセージを表示するかも評価する。
- ポイント
- このテストは「機能統合テスト」と並行して行う。
- 機能統合テストでは、システム全体が仕様通りに動作するかを確認する一方で、置換性テストでは、異なるコンポーネント間でシステムの振る舞いが安定しているかに焦点を当てる。
