20170710 hifive-test-meetup

23
DevOpsの実践に向けた 自動テスト 10 th -Jul-2017 Naoya Kojima @jugemix

Upload: naoya-kojima

Post on 23-Jan-2018

822 views

Category:

Engineering


0 download

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の目的は、市場の反応を「迅速に」開発にフィードバックすること

素早くフィードバックを得るために欠陥が無い状態でのリリースが必要

欠陥対応に追われ新たな要求に取り組むことが出来なくなってしまう

テスト戦略

機能テスト探索的テスト

ユーザビリティテスト

単体テスト

コンポーネントテスト

パフォーマンステスト

負荷テスト

自動と手動

自動 ツール

手動

アジャイルテストの4象限

自動テストに対する要求

機能テスト探索的テスト

ユーザビリティテスト

単体テスト

コンポーネントテスト

パフォーマンステスト

負荷テスト

自動と手動

自動 ツール

手動

要求事項の整理

単体テスト・コンポーネントテスト

ソースコードに必要な要素を、プログラマが理解できるようにすること

単体テストツール

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)

ロードテスト・自動スケーリング

監視・フィードバック

可用性監視

アプリパフォーマンス監視

自動回復

構成管理

プロビジョニング

運用テスト

ユーザテレメトリ

フォールト挿入

まとめ

自動テストの目的(要求)を意識すること

目的を達成する為に必要な構造を検討すること

プラクティスを実践してみて初めて気付く事もありました

何を自動化すべきか検討すること

本日はありがとうございました