Outline
本コンテンツは、これからテスト自動化を始める人向けに作成するコンテンツ。
筆者のこれまでの経験を元に作成しているので、教科書と異なる場合があります。
もしくは、他企業で異なる考え方もあると思う。その場合は是非コメントをください！
1回につき10分ほどで終わるコンテンツ量で毎週記載する予定です。
Condition
筆者はWEBサービスのテストエンジニアである。
そのため、WEBサービスの開発を前提としたテスト自動化の話になる。
Test Layer & Test Automation Tool
ウォーターフォールの開発モデルをベースに説明します。
上図は、ウォーターフォール開発モデルで上流工程とそれに対となるテストを定義するV字モデルです。
テスト自動化はどの工程でも行うことは可能です。
尚、テスト支援ツールに関しては、主旨が異なるため割愛します。
Requirements and Architecture (要件定義フェーズ)
要件定義書等のドキュメントのフォーマットや文章の妥当性等をチェックする
RedPen
技術文書をターゲットにした文書の自動検査ツール。
文長、不正な表現、スペルミス等を検査する。
ClearDoc
日本語でよく発生するあいまいな記述や、複雑な文章を検出する。
あいまいな記述は、読み手によって仕様の解釈を異なる事象を発生させてしまう。
Implementation - Statistic analysis
プログラムのコーディングルールのチェックや、プログラムを実行せずにbugやsecurity issueを発見する。
いわゆる、コードレビューの作業を自動で行う
SonarQube
重複コード、セキュリティ脆弱性、バグになりそうなコードの検出
複雑性をメトリックス化（サイクロマチック数）
Coverity
ソフトウェアの重大な不具合およびセキュリティ脆弱性を検出
改修方法の提案
Implementation - Dynamic analysis
Unit Levelでプログラムの妥当性を実際に実行することでテストする
White Box Testの手法やC0~C2カバレッジのカバー率測定などが使われる
JUnit
Javaプログラムのユニットテストを自動化するためのフレームワーク
PHPunit
PHPプログラムのユニットテストを自動化するためのフレームワーク
Integration Test and Verification (IT)
Interface levelのテストを自動化する
SoapUI
APIレイヤのテストを自動で実行する
動作検証以外に、負荷試験やモックサポートなどの付加価値もある。（バージョンによる）
System Verification and Validation (UT)
End to End layer の様々なテストを自動化する
Selenium / Appium + Webdriver 等
WEB、NativeAppのEnd to End テストを自動化させるためのフレームワーク
UFT
WEB、NativeApp、windows アプリ等のEnd to End テストを自動化するためのGUIツール
Ranorex
UFTと同様でWEB、NativeApp、windows アプリ等のEnd to End テストを自動化するためのGUIツール。
UTFに比べると後発であるが、ライセンスコストが安く、利用シェアの拡大が広がってる
gartner reportでも高評価を得ている
Apache JMeter
Webアプリケーション向けの負荷試験ツール
Burp
WEBアプリケーションの脆弱性を検出するツール
テストシナリオを作成し、その過程から脆弱性を検索させたり、サイトをクロールして脆弱性を検出させたりする
Test Automation Pyramid
Ideally Pyramid
プログラムのテストに関して、テストサイズやコスト、スピードを表現するのにテストピラミッドがよくつかわれる。
Unit Test
- Smallサイズのcomponentの機能テスト
- bugのroute causeに一番近いところでテストするため、バグを見つけやすい
- ほかのUnitと依存せずに期待値通り機能するかのテスト
- 正常系/ 異常時の挙動の確認
- test setは多くなる傾向（Unit単位に作成されるため）
- test speedは速いことが求めらる（大量のUnitテストを行うため）
- code change/ make 時等にテストすることが一般的
Pyramidの底辺にあるというのは、以下のことを意味している
- test speedが早い
- test setが多い
- test runの頻度が多い
- costが低い
Integration Test
- 2つのものが接するテスト。例えばAPIを経由した処理
- codebaseでunitテストでは品質を検証がむつかしいところをテスト
- Databaseを介したテスト(Unitではスタブを使うのが一般的）
- IF仕様 baseにテストするため、BlackBoxテスト
Pyramidの真ん中にあるというのは、test speed, volume, frequency, costが中間であることを指す
End to End Test
- Front end & Back end(system全体を通して)を組み合わせたテスト
- BlackBoxテスト
- End userによるテスト
- test speedが遅くなる傾向（テスト時間がかかる）
- test caseを膨大にすると、テストが終わらない
- test costが多くなる傾向
- test environmentはfragile
Pyramidの頂点にあるというのは、以下のことを意味する
- test speedが遅い
- costが高い
- test setをunitに比べ少なくしないと回らない
- test runの頻度は少ない
Anti Pattern Automation Test Pyramid
anti pattern : cupcake
- 各担当がcollaborateしていない状況
- 各layerで同じようなテストを行う
- END2ENDのテストの後にマニュアルテストで頑張る
- 最後にexploratory testを心配なので実施する
anti pattern : ice cream cone
- End User 目線に近づく(End to End Test)につれて、自動化テストのvolumeが多くなる
- Black Box テストでとにかく品質を頑張る
- Test feedbackが遅くなる
- Test Costが高くなる
- Bugのroute causeの発見に時間がかかる
anti pattern : hourglass
- API等のテストを忘れる
- Ice cream coneほどではないが、cost/speed/debug等に問題を生じる
anti pattern : Dual Pyramid
- それぞれの専門チームが個別に自動化テストプラットフォームを作成する
- それぞれの自動化テストが重複したテストを行っている
Finaly
各工程において、検証する作業が発生するが、その検証作業を自動化することができる。
次回以降は、主にWEBサービスのEnd to Endテスト自動化に特化して記述する。
次は6月12日（金）頃配信予定です。
Automation Testing 導入プロセスを予定。