DevOpsにおけるAPIテスト

by CUONG MAI

Embed

Start on current slide

Slide 1

Slide 1 text

DevOpsにおけるAPIテスト  株式会社ヒューマンクレスト  マイ　マイクオン  1 

Slide 2

Slide 2 text

❖ 名前：マイ　マイ　クオン    ❖ 経歴  　2011 来日  　2012 横浜国立大学入学  　2016 大学卒業  　　　　ヒューマンクレスト入社  　現在： RakAPIt PO  Profile  2 

Slide 3

Slide 3 text

Slide 4

Slide 4 text

❖ APIテストとUIテスト  ➢ APIテストとは  ➢ APIテスト vs UIテスト  ➢ APIテストタイミング  ❖ APIテスト自動化  ➢ UIテスト自動化の問題点  ➢ APIテスト自動化のメリット  ➢ APIテストで何を自動化するか  ❖ APIテストは誰のものなのか？  ❖ APIテストをデプロイメントパイプラインに組み込む  ➢ デプロイメントパイプライン  ➢ APIテスト設計・実装  ➢ CIツールに組み込む      Agenda  4 

Slide 5

Slide 5 text

Slide 6

Slide 6 text

• DevOpsの必要性  – 変化が激しい現代社会では、ソフトウェアの価値をいかに早くユーザに届けるかが大事    – DevOpsにおいてはテストの自動化は不可欠    今回はAPIテスト自動化、およびDevOpsへの導入についてお話しします。  背景  6 

Slide 7

Slide 7 text

APIテスト  ・APIとは何か？  　アプリケーションとアプリケーションとの間でやり取りするための仕組み    マシン間の通信が効率的に行える  7 

Slide 8

Slide 8 text

APIテストとUIテストはそれぞれの役割があるが、重なり合うところがある。つまり、その部分はAPIテストで確認することもできるし、UIテストで確認することもできる。    APIテストで実施する時と、UIテストで実施する時を比較してみる  APIテスト vs UIテスト  APIテスト UIテスト 8 

Slide 9

Slide 9 text

APIテスト UIテスト難易度学習コストがかかる直感的でやりやすい実施できるタイミング APIの実装が完了したらすぐできる API及びUIがそれぞれ完成し、結合しないと実施できないテストスコープ UIテストで実施できないケースも実施できる UIによる制限がある実施コスト実行時間が短い実行時間が長い安定性安定不安定自動化自動化しやすい自動化しにくいところがある APIテスト vs UIテスト  9 

Slide 10

Slide 10 text

無理矢理APIテストで確認しなくてもよく、UIテストで確認しても構わない。    システムの中には、UIテストの方がうまくテストできる側面も数多くある。  →APIテストとUIテストをうまく連携し、使い分けるのが大事  APIテスト vs UIテスト  APIテスト UIテスト 10 

Slide 11

Slide 11 text

BACK END  FRONT END  Coding  Unit Testing  Coding  Unit Testing  UI Testing  APIテストタイミング  遅延リスク  バグ修正コスト  11 

Slide 12

Slide 12 text

BACK END  FRONT END  Coding  Unit Testing  Coding  Unit Testing  UI Testing  API Testing  APIテストタイミング  バグ修正コスト↓  遅延リスク↓  12 

Slide 13

Slide 13 text

      出典：https://www.stickyminds.com/article/shift-left-approach-software-testing  APIテストタイミング  13 

Slide 14

Slide 14 text

Slide 15

Slide 15 text

UIを頻繁に変更される→UIを少し変えただけでもテストスイートを壊してしまう  例：アプリケーションの振る舞いには全く問題がないのに、チェックボックスの名前が変わっただけでテストが壊れてしまう  UIテスト自動化の問題点  テストが壊れやすい  15 

Slide 16

Slide 16 text

→ 誤った判断が多く下される  テストが壊れた場合には、開発チームは即座に対応しなければならない  ・テストが壊れた原因を見分けなければならない  + 紛れ込んだリグレッションの結果なのか？  + テストの問題なのか？  ・自動テストがまた通るようになるために、適切なアクションを取る  UIテスト自動化の問題点  テストが壊れやすい  16 

Slide 17

Slide 17 text

テストをアプリケーションと同期させておこうと思うと、何の価値もデリバリーすることなく、大量の時間を浪費することになり得る    このことは、アプリケーション開発をしている間に留まらない。システムのユーザテストをしている間に、ユーザビリティを改善したり、綴りを訂正したりしているうちに起きるかもしれない  UIテスト自動化の問題点  テストが壊れやすい  17 

Slide 18

Slide 18 text

テストケースをセットアップする際、システムをテストできる状態にするために相当やりとりをしなければならないかもしれない    テストの最後には、UIを通じてテスト結果を取得することができないかもしれない  UIテスト自動化の問題点  テストが複雑になる  18 

Slide 19

Slide 19 text

  UIを作る際に使っているテクノロジーによってはテストできないかもしれない    UIテスト自動化の問題点  テストできない  19 

Slide 20

Slide 20 text

テストピラミッド  出典：https://www.mostafableu.com/blog/test-automation/  20 

Slide 21

Slide 21 text

APIテスト自動化のメリット  UI  APIテスト UIテスト実行時間が短い  実装がシンプル  安定性が高い  21 

Slide 22

Slide 22 text

「全てを自動化する必要はない」    判断材料：  + 手動テストを繰り返し行うためにどれほどの時間が費やされているか  + テストの保守に大量の時間を費やさなくても良いか    経験則：同じテストを2回繰り返したら、自動化するのが良いようだ    APIテストで何を自動化するか？  22 

Slide 23

Slide 23 text

Slide 24

Slide 24 text

APIテストはテストチームが責任を持つという伝統的なモデルを用いることが多い    問題：  + 開発チームは変更を加えた時、テストへの影響を意識しない。テストチームが変更に気づくのはプロセスの比較的後の方になる。  →修正すべき自動テストが極めて多いため、問題発見までには時間がかかる  →開発チームは別のタスクに着手  →修正に時間がかかる  APIテストは誰のものなのか？  24 

Slide 25

Slide 25 text

APIテストはテストチームが責任を持つという伝統的なモデルを用いることが多い    問題：  + 修正すべきテストに対してテストチームの負担は大きい。しかも、新しい要件に対して新しいテストも実装しなければならない  APIテストは誰のものなのか？  25 

Slide 26

Slide 26 text

→APIテストの開発と保守をテストチームに持たせるのではなく、開発担当、運用担当、テスターを含む DevOpsチーム全体で責任を持つ    そうすると、  + 変更を行ってから、テストで問題が発見されるまでの時間が短くなる      APIテストは誰のものなのか？  26 

Slide 27

Slide 27 text

→APIテストの開発と保守をテストチームに持たせるのではなく、開発担当、運用担当、テスターを含む DevOpsチーム全体で責任を持つ    そうすると、  + 開発者が自分たちの行った変更の影響をより直接的に意識するようになる。  + 開発者がテストの観点から考えるようになることで、新しく変更した時にテストスイートのどの部分に影響が出るかをより的確に予期できる  APIテストは誰のものなのか？  27 

Slide 28

Slide 28 text

❖ APIテストとUIテスト  ➢ APIテストとは  ➢ APIテスト vs UIテスト  ➢ APIテスト：スコープとタイミング  ❖ APIテスト自動化  ➢ UIテスト自動化の問題点  ➢ APIテスト自動化のメリット  ➢ APIテストで何を自動化するか  ❖ APIテストは誰のものなのか？  ❖ APIテストをデプロイメントパイプラインに組み込む  ➢ デプロイメントパイプライン  ➢ APIテスト設計・実装  ➢ CIツールに組み込む      Agenda  28 

Slide 29

Slide 29 text

デプロイメントパイプラインに組み込むと、大きなメリットが得られる    + フィードバックループを加速させる  開発者はテスターのところに行かなくても自動テストを実行するだけで、特定の要件を完成できたかを確認できる  →ソフトウェア開発チームの生産性が一段上に行く    メリット  29 

Slide 30

Slide 30 text

デプロイメントパイプラインに組み込むと、大きなメリットが得られる    + APIテストは強力なリグレッションテストスイートとなる。  　このテストのおかげで変更を行った時にも既存　の機能を壊していないことが保証される  　また、コードのリファクタリングも簡単になる      メリット  30 

Slide 31

Slide 31 text

成果物リポジトリキャパシティステージ環境設定バイナリデプロイスモークテスト UAT 環境設定バイナリデプロイスモークテスト本番環境設定バイナリデプロイスモークテストソースコードコミットステージコンパイルコミットテストアセンブルコード分析受け入れステージ環境設定バイナリデプロイスモークテスト受け入れテスト環境 &アプリ設定環境 &アプリ設定開発者コードメトリクスとテストの失敗を確認する   テスター自分でデプロイ運用ボタン１つでリリースレポートメタデータレポートバイナリメタデータバイナリバイナリレポートメタデータバージョンコントロールデプロイメントパイプライン  出典：継続的デリバリー　Jez Humble (著), David Farley (著), 和智右桂(訳), 高木正弘 (訳)  31 

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

成果物リポジトリキャパシティステージ環境設定バイナリデプロイスモークテスト UAT 環境設定バイナリデプロイスモークテスト本番環境設定バイナリデプロイスモークテストソースコードコミットステージコンパイルコミットテストアセンブルコード分析受け入れステージ環境設定バイナリデプロイスモークテスト受け入れテスト環境 &アプリ設定環境 &アプリ設定開発者コードメトリクスとテストの失敗を確認する   テスター自分でデプロイ運用ボタン１つでリリースレポートメタデータレポートバイナリメタデータバイナリバイナリレポートメタデータバージョンコントロールデプロイメントパイプライン  APIテスト出典：継続的デリバリー　Jez Humble (著), David Farley (著), 和智右桂(訳), 高木正弘 (訳)  35 

Slide 36

Slide 36 text

テストスイート作成  例：インタフェース観点  UI  　正常なデータ：受け付けて仕様通りに処理  　異常なデータ：適切なエラーメッセージを返す  HEADER BODY HEADER BODY STATUS CODE   36 

Slide 37

Slide 37 text

HEADER BODY STATUS CODE   HEADER BODY Path  Query  Header Key  Body Property  パラメータ化する箇所   それぞれのパラメータに対して、正常系と異常系のテストデータを抽出    そのデータを駆動してテストを実施  テストスイート作成  例：インタフェース観点  37 

Slide 38

Slide 38 text

HEADER BODY HEADER BODY STATUS CODE   Assertion  Assertion  Assertion  スキーマ検証  テストスイート作成  例：インタフェース観点  38 

Slide 39

Slide 39 text

テスト対象として考える  テストスイート作成  例：インタフェース観点  39 

Slide 40

Slide 40 text

・テストケース作成          テストスイート作成  例：インタフェース観点  40 

Slide 41

Slide 41 text

CIツールに組み込む  CI/CDツール RakAPIt テスト対象テストケース実行APIを呼び出す   テスト実行開始の通知  テストケース実行状況を取得   テストケース実行状況を返却   テストケース実行状況を取得   テストケース実行完了の通知   実行結果を返却  テスト実施  ポーリング...  リクエスト  レスポンス  41 