[Lesson Test Automation. Day 02] Test Layer and Tool

# Outline
本コンテンツは、これからテスト自動化を始める人向けに作成するコンテンツ。
筆者のこれまでの経験を元に作成しているので、教科書と異なる場合があります。
もしくは、他企業で異なる考え方もあると思う。その場合は是非コメントをください！
1回につき10分ほどで終わるコンテンツ量で毎週記載する予定です。


# Condition
筆者はWEBサービスのテストエンジニアである。
そのため、WEBサービスの開発を前提としたテスト自動化の話になる。


# Test Layer & Test Automation Tool

<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/14ca7e51-fc53-b243-b690-1bc250caee53.png">

ウォーターフォールの開発モデルをベースに説明します。
上図は、ウォーターフォール開発モデルで上流工程とそれに対となるテストを定義するV字モデルです。
テスト自動化はどの工程でも行うことは可能です。
尚、テスト支援ツールに関しては、主旨が異なるため割愛します。

### Requirements and Architecture (要件定義フェーズ)

要件定義書等のドキュメントのフォーマットや文章の妥当性等をチェックする

<B>RedPen</B>
技術文書をターゲットにした文書の自動検査ツール。
文長、不正な表現、スペルミス等を検査する。

<A HREF="https://redpen.cc/docs/latest/index_ja.html">RedPen 1.10 ドキュメント</A>

<B>ClearDoc</B>
日本語でよく発生するあいまいな記述や、複雑な文章を検出する。
あいまいな記述は、読み手によって仕様の解釈を異なる事象を発生させてしまう。

<A href="http://www.proveq.jp/verification/document/cleardoc/">ツール	ドキュメント検証ツール ClearDoc</A>


### Implementation - Statistic analysis

プログラムのコーディングルールのチェックや、プログラムを実行せずにbugやsecurity issueを発見する。
いわゆる、コードレビューの作業を自動で行う

<B>SonarQube</B>
重複コード、セキュリティ脆弱性、バグになりそうなコードの検出
複雑性をメトリックス化（サイクロマチック数）

<A href="https://www.sonarqube.org/">SonarQube</A>

<B>Coverity</B>
ソフトウェアの重大な不具合およびセキュリティ脆弱性を検出
改修方法の提案

<A href="https://www.synopsys.com/ja-jp/software-integrity/security-testing/static-analysis-sast.html">Synopsys Coverity</A>


### Implementation - Dynamic analysis

Unit Levelでプログラムの妥当性を実際に実行することでテストする
White Box Testの手法やC0~C2カバレッジのカバー率測定などが使われる

<B>JUnit</B>
Javaプログラムのユニットテストを自動化するためのフレームワーク


<B>PHPunit</B>
PHPプログラムのユニットテストを自動化するためのフレームワーク

<A href="https://phpunit.readthedocs.io/ja/latest/">PHPUnit マニュアル</A>

### Integration Test and Verification (IT)

Interface levelのテストを自動化する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/520392eb-2949-052a-5da3-baaf6c671ff6.png)


<B>SoapUI</B>
APIレイヤのテストを自動で実行する
動作検証以外に、負荷試験やモックサポートなどの付加価値もある。（バージョンによる）



### System Verification and Validation (UT)

End to End layer の様々なテストを自動化する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/7526501d-12c3-0940-95a3-7bdd5c9901ce.png)


<B>Selenium / Appium + Webdriver 等</B>
WEB、NativeAppのEnd to End テストを自動化させるためのフレームワーク

<A HREF="https://www.selenium.dev/">Selenium</A>
<A HREF="http://appium.io/">Appium</A>


<B>UFT</B>

WEB、NativeApp、windows アプリ等のEnd to End テストを自動化するためのGUIツール

<A HREF="https://www.microfocus.com/ja-jp/products/uft-one/overview">Microfocus UFT</A>

<B>Ranorex</B>
UFTと同様でWEB、NativeApp、windows アプリ等のEnd to End テストを自動化するためのGUIツール。
UTFに比べると後発であるが、ライセンスコストが安く、利用シェアの拡大が広がってる
<A HREF="https://www.gartner.com/reviews/market/software-test-automation">gartner report</A>でも高評価を得ている

<B>Apache JMeter</B>
Webアプリケーション向けの負荷試験ツール

<A HREF="https://jmeter.apache.org/">Apache Jmeter</A>

<B>Burp</B>
WEBアプリケーションの脆弱性を検出するツール
テストシナリオを作成し、その過程から脆弱性を検索させたり、サイトをクロールして脆弱性を検出させたりする

<A HREF="https://portswigger.net/burp">Burp</A>


# Test Automation Pyramid

### Ideally Pyramid


<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/fbf11967-93b1-460a-f60d-eb446090220d.png">

プログラムのテストに関して、テストサイズやコスト、スピードを表現するのにテストピラミッドがよくつかわれる。

<B>Unit Test</B>

- Smallサイズのcomponentの機能テスト
- bugのroute causeに一番近いところでテストするため、バグを見つけやすい
- ほかのUnitと依存せずに期待値通り機能するかのテスト
- 正常系/ 異常時の挙動の確認
- test setは多くなる傾向（Unit単位に作成されるため）
- test speedは速いことが求めらる（大量のUnitテストを行うため）
- code change/ make 時等にテストすることが一般的

Pyramidの底辺にあるというのは、以下のことを意味している

- test speedが早い
- test setが多い
- test runの頻度が多い
- costが低い

<B>Integration Test</B>

- 2つのものが接するテスト。例えばAPIを経由した処理
- codebaseでunitテストでは品質を検証がむつかしいところをテスト
- Databaseを介したテスト(Unitではスタブを使うのが一般的）
- IF仕様 baseにテストするため、BlackBoxテスト

Pyramidの真ん中にあるというのは、test speed, volume, frequency, costが中間であることを指す



<B>End to End Test</B>

- 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

<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/c90274b5-825a-8389-d506-a489ec0f6aba.png">


- 各担当がcollaborateしていない状況
- 各layerで同じようなテストを行う
- END2ENDのテストの後にマニュアルテストで頑張る
- 最後にexploratory testを心配なので実施する



### anti pattern : ice cream cone

<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/e6b53c3b-0385-bfa7-344d-fa6a897a71fa.png">

- End User 目線に近づく(End to End Test)につれて、自動化テストのvolumeが多くなる
- Black Box テストでとにかく品質を頑張る
- Test feedbackが遅くなる
- Test Costが高くなる
- Bugのroute causeの発見に時間がかかる



### anti pattern : hourglass 

<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/a0b8f3a3-d897-7911-6be0-aab98c1f5092.png">

- API等のテストを忘れる
- Ice cream coneほどではないが、cost/speed/debug等に問題を生じる



### anti pattern : Dual Pyramid

<IMG SRC="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/267085/3097aa62-819c-e259-072c-cab7d10c3d5b.png">

- それぞれの専門チームが個別に自動化テストプラットフォームを作成する
- それぞれの自動化テストが重複したテストを行っている



# Finaly

各工程において、検証する作業が発生するが、その検証作業を自動化することができる。
次回以降は、主にWEBサービスのEnd to Endテスト自動化に特化して記述する。

次は6月12日（金）頃配信予定です。
Automation Testing 導入プロセスを予定。


# reference

- <A href="https://www.istqb.org/certification-path-root/test-automation-engineer.html">ISTQB Advanced Level Test Automation Engineer</A>


# back number

- <A HREF="https://qiita.com/emurin/items/af7b91b979159e27286a">[Lesson Test Automation. Day 01] What's Test Automation</A>