DevOpsの実践に向けた 自動テスト 10 th -Jul-2017 Naoya Kojima @jugemix
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
DevOpsの実践に向けた自動テスト
10th-Jul-2017
Naoya Kojima
@jugemix
プロフィール
私について
業務アプリケーションの開発者
業務システムのアーキテクチャ・フレームワーク、品質に関心があります
日本 Selenium ユーザコミュニティに参加しています
得意分野
アプリケーション開発
Java / Spring Framework etc.
自動テストの環境構築、実装
キーワード駆動テストアプローチ
突然ですが、質問です
開発
テスト
その他
突然ですが、質問です
DevOpsの定義
DevOpsとは
業務と開発・運用が協力しあい、事業における価値創出サイクルを継続改善する活動
引用元
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E
3%83%AB:Devops.svg
DevOpsの目的
ビジネスにおける市場のニーズを受けて、迅速に開発、テスト、リリースをし、市場の反応を迅速に開発へフィードバックすること
引用元
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A
4%E3%83%AB:Devops-toolchain.svg
DevOpsに求められること
市場の反応を「迅速に」開発にフィードバックすることが目的
「素早く」、「頻繁に」、「安全に」実践する必要がある
DevOpsのプラクティス（一例）
開発・テスト
継続的インテグレーション（CI）
自動テスト
リリース
継続的デリバリ（CD）
リリース管理
Infrastructure as Code（IaC）
ロードテスト・自動スケーリング
監視・フィードバック
可用性監視
アプリパフォーマンス監視
自動回復
構成管理
プロビジョニング
運用テスト
ユーザテレメトリ
フォールト挿入
DevOpsに対する現場のイメージ
CI/CD、自動テストといった手法を導入すること
注意点
手段が目的化しがち
DevOpsな体制が求められるようになった背景を意識することが大切
DevOpsに取り組む上での課題
ビジネス価値の創出を改善する自分たち（組織やプロジェクト）にとって重要だと思うことを考える
市場の反応を「迅速に」開発にフィードバックすることが目的
「素早く」、「頻繁に」、「安全に」実践するプラクティスから選択してみる
出来ていること、出来ていないことを知る事からはじめるhttp://devopsassessment.azurewebsites.net
自動テスト自体の目的
反復作業の効率化
テストデータ準備
テスト実行
テスト結果の検証
手間の掛かる作業の効率化
複雑な手順のテスト実行
テスト結果集計作業の効率化
テスト実行結果の集計作業
人為ミス、やり直しの排除
DevOpsにおける自動テストの目的
問題の早期検出
ソースコードの変更毎にテストできる
安全性の担保
テストが行われずにリリースされるという状況を回避できる
DevOpsの実現に必要なテスト
DevOpsの実現には自動テストは必要
DevOpsの目的は、市場の反応を「迅速に」開発にフィードバックすること
素早くフィードバックを得るために欠陥が無い状態でのリリースが必要
欠陥対応に追われ新たな要求に取り組むことが出来なくなってしまう
テスト戦略
機能テスト探索的テスト
ユーザビリティテスト
単体テスト
コンポーネントテスト
パフォーマンステスト
負荷テスト
自動と手動
自動 ツール
手動
アジャイルテストの４象限
自動テストに対する要求
機能テスト探索的テスト
ユーザビリティテスト
単体テスト
コンポーネントテスト
パフォーマンステスト
負荷テスト
自動と手動
自動 ツール
手動
要求事項の整理
単体テスト・コンポーネントテスト
ソースコードに必要な要素を、プログラマが理解できるようにすること
単体テストツール
TDD（テスト駆動開発）
技術面での問題に関して、タイムリーにフィードバックを得られること
単体テストツール
ビルドツール
ビルド自動化/CIツール
ソースコード管理ツール
機能テスト
業務面での要求の実現についてタイムリーにフィードバックを得られること
単体テストツール
テスト自動化ツール
ビルドツール
ビルド自動化/CIツール
ソースコード管理ツール
自動テストの設計 1/3
機能テストの実行タイミング
master
develop
request
request
リモート
ローカル
merge
push
merge
検証環境自動テスト実行デプロイ
本番環境リソース作成
テストシステムビルダー（Maven）
テストランナー（Pitalium based JUnit）
TestCaseLoder（POI）
テストケースファ
イル（Excel）
テストステップ
ファイル（Excel）
TestClass
KeywordInvokerClass
Abstruct Keyword Class
Concrete Keyword Class
PageLocator Class
自動テストの設計 2/3
テストシステムの構造Programming Part
Ptaliumに「WebDriverの管理」、「レポート」機能を委譲
selenium-javaを利用した「操作」、「ロケータ」の記述箇所
自動テストの設計 3/3
デプロイメントパイプラインのイメージ
開発PC
Git 検証環境 本番環境
Mavenビルドジョブ
Jenkins
検証環境Azure・AWSなどIaCが可能な環境を使うとテストしたいときに環境を構築できる。
本番環境用リソース作成にとどめるという手もある。
自動テストプログラムを実行する
プラクティスの選択
開発・テスト
継続的インテグレーション（CI）
自動テスト
単体テスト、コンポーネントテスト
機能テスト
リリース
継続的デリバリ（CD）
リリース管理
Infrastructure as Code（IaC）
ロードテスト・自動スケーリング
監視・フィードバック
可用性監視
アプリパフォーマンス監視
自動回復
構成管理
プロビジョニング
運用テスト
ユーザテレメトリ
フォールト挿入
まとめ
自動テストの目的（要求）を意識すること
目的を達成する為に必要な構造を検討すること
プラクティスを実践してみて初めて気付く事もありました
何を自動化すべきか検討すること
本日はありがとうございました
Related Documents
