この記事は、「モデルベースドテストについて学んでみよう」2018年アドベントカレンダー、1日目の記事です。
こんな構成で、クリスマスまでに8夜分くらい書く予定です。
- 例によって、ISTQBシラバスを読みながら、自分の理解をまとめる。
- MBTを実現するためのツールを使って、具体的なイメージを掴む。
テスト自動化アーキテクチャにおける位置づけ
第1回では、テスト自動化においてMBTがどう位置づけられているかについて確認していきます。
ISQTBのAdvance Level - Test Automation Engineer（以下「ALTAE」）のシラバス3.1.1では、「包括的テスト自動化アーキテクチャ」（generic test automation architecture、gTAA）というものを定義しています。その全体図を引用します。
※ALTAEシラバスより引用
内側に「テスト生成」「テスト定義」「テスト実行」「テスト適合」の4つの層があります。テストプロセスでいうと、生成はテスト設計、定義はテスト実装に、実行はそのままテスト実行に、ほぼ相当します。
わかりづらいのが適合（adaptation）です。
The Test Adaptation Layer which provides the necessary code to adapt the automated tests for the various components or interfaces of the SUT. It provides different adaptors for connecting to the SUT via APIs, protocols, services, and others.
ざっくりいうと、テスト対象プロダクトの実装に依存しないテストケースと、プロダクトを結びつけるための層です。
たとえば状態遷移表から1スイッチカバレッジ100%を満たすテストケースを導出したとしましょう。人間であれば、プロダクトの仕様から、どのような操作をすればこのテストケースを実行できるかを推測することができそうです。一方、機械は（今のところ、たぶん・・・）そうはいきません。ですので、実装に合わせて「このように操作する」ということを翻訳してやる必要があります。これを担うのが「適合」の層です。
さて話が逸れましたが、モデルは「テスト生成」層にありますね。
テスト生成の中にあるもう1つの層が「手動設計」であることを考えると、「テストモデル」とは「自動」的にテストを生成するものと想像できます。
Automatically generating test cases from models that define the SUT and/or its environment (i.e., automated model - based testing)
テスト自動化のアーキテクチャの一部に、テストケースの自動生成というブロックがあるのですね。
長所と短所の概要
3.2.2では、「テストケース自動化のアプローチ」として、7つのアプローチの概要とメリット/デメリットを解説しています。
たとえば一番初歩的な、キャプチャ・プレイバックアプローチ。テスターがプロダクトを操作する過程を記録し、それを同じように再生することで、実行の自動化を実現しています。
また、抽象化やモジュール化を進めて可読性・保守性・再利用性を向上させた「キーワード駆動テスト」も、テストの「実行の」自動化の話であり、スクリプトの形態に違いがあるだけです。詳しくは以下のような記事で言及していますが、これらは「テスト実行」の自動化に伴うスクリプトの書き方に関するものです。
www.kzsuzuki.com www.kzsuzuki.com
一方、モデルベースドテストは、テストの「実装の」自動化の話。ソフトウェアの一側面を規定のルールに従ってモデル化し、これに対し何らかの基準（カバレッジ基準やフィルタ）を与えることで、条件を満たすテストケースが導出されるという仕組みです。
「テストケースの自動化」という不思議なタイトルになっているのは、「実行」と「実装」が混じっているからかもしれません。
シラバスの説明の要約
基本的なコンセプト
- MBTは、テストケースの自動実行ではなく、自動生成に関するものである。
- （準）形式的なモデルを利用する。
- テスト生成のメソッドは一つではない。
- スクリプティングフレームワークのためのテストを導出することができる。
最後の部分が少しわかりづらいのですが、ここは何気なく大事なことを言っています。
それは、テスト自動実行の形に合わせて、テストケースの自動生成をすることができるということ。つまり、MBTのためのモデルを適切に設計することで、テストケースの生成から実行まで一気通貫で自動化できる、ということを暗示しているのですね。
長所
- 抽象化によって、テストの本質部分（ビジネスロジック、データ、シナリオ、構成、・・・）に集中することができる。
- （システムの内部で利用される）技術が変化していっても、モデルは再利用・保守することができる。
- 要件に変更があった場合でも、モデルだけをそれに合わせればよい。テストケースはそこから自動的に生成される。
短所
- SUTを、インタフェース、データ、ふるまいといった観点で抽象化するのは高度な技術であり、モデリングの専門家が必要。
- MBTのためのツールがまだまだ主流ではなく、成長段階にある。
- テストプロセスと統合していかなくてはならない。
- 品質のよいテスト生成のために、モデル自体の品質保証が必要になる。
長所としては特に3つ目が重要だと思います。テスト対象を分析・抽象化した結果がモデルだであり、これとテスト設計を組み合わせることでテストケースが生成される。最終生成物がどのように導出されたかの「根拠」が、モデルと設計に残っていることが重要です。
短所として、ツールがまだいまいちというものがあります。ただ実用で通用するのではと思えるものもありますので、このシリーズの後半でそのイメージをお伝えできればと思います。
では、第2回以降は Foundation Level - Model-Based Tester（FL-MBT）を読んでいきましょう。
