【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 #JaSST
?
30 likes?12,031 views
JaSST'14 Tokyo での"システムテストの自動化による大規模分散検索プラットフォームの開発行程改善"という題目の事例発表です。 スライドに入りきらなかったコンセプトについてhttp://kokotatata.hatenablog.com/entry/2014/03/11/104240 に書いています。そちらもご参照ください。 --- 2014/03/08 08:00 文字のレイアウトのずれや配色の問題を修正
【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 #JaSST
- 1. システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 Mar/07/2014 荻野 恒太郎, パランデ アビジート, 松本 幹, 鵜飼 大志 Search Platform Group, Search Section, Big Data Department, Rakuten Inc. http://www.rakuten.co.jp/
- 5. 5 ウェブサービス
- 6. 6 ウェブサービス開発の特徴 要求スコープ 時 間 軸 ? 永続的開発 フェーズ 日々サービスを成長 させるため - 市場要求の変化 - 技術トレンドの変化 “Development and Deploy in Facebook”, Facebook, 2013, 継続的なサービス改善 → 絶え間ないリリース
- 8. 8 クオリティ vs アジリティ アジリティ 高 低 遅い 速い サービス クオリティ 機能開発のリードタイム バグ修正日数 など
- 9. 9 クオリティ vs アジリティ アジリティ 高 低 遅い 速い サービス クオリティ 開発 - 機能追加 - 機能改善 - パフォーマンス改善 機能開発のリードタイム バグ修正日数 など
- 10. 10 クオリティ vs アジリティ アジリティ 高 低 遅い 速い サービス クオリティ 開発 - 機能追加 - 機能改善 - パフォーマンス改善 開発 開発 開発 継続的な サービス改善 → 小さく産んで 大きく育てる 機能開発のリードタイム バグ修正日数 など
- 11. 11 クオリティ vs アジリティ アジリティ 高 低 遅い 速い サービス クオリティ 開発 開発 開発 開発 品質の門番としての システムテスト - 新機能の振る舞い - デグレード ? 機能開発のリードタイム バグ修正日数 など
- 12. 12 品質の門番：システムテスト 機能テスト - 検索機能など - 検索ランキング 探索的テスト (ET) 受け入れテスト (UAT) 単体テスト (UT) コンポーネントテスト (CT) パフォーマンス /負荷テスト 「?性」テスト - 運用性 - 可用性 ビジネス面 支 援 製 品 批 評 ISBN:9784798119977“ 実践アジャイルテスト” p.96 技術面 ＊以前結合テスト と呼んでいた ? アジャイルテスト４象限
- 13. 13 品質の門番：システムテスト 機能テスト - 検索機能など - 検索ランキング 探索的テスト (ET) 受け入れテスト (UAT) 単体テスト (UT) コンポーネントテスト (CT) パフォーマンス /負荷テスト 「?性」テスト - 運用性 - 可用性 ビジネス面 支 援 製 品 批 評 ISBN:9784798119977“ 実践アジャイルテスト” p.96 技術面 ＊以前結合テスト と呼んでいた ? アジャイルテスト４象限 システムテスト(ST) その他
- 14. 14 クオリティ vs アジリティ アジリティ 高 低 遅い 速い サービス クオリティ 開発 開発 開発 開発 機能開発のリードタイム バグ修正日数 など
- 15. 15 クオリティ vs アジリティ アジリティ 高 低 遅い 速い サービス クオリティ 機能開発のリードタイム バグ修正日数 など
- 16. 16 クオリティ vs アジリティ アジリティ 高 低 遅い 速い サービス クオリティ ? 技術的負債 ? システムテストの 肥大化 開発 50% ST 33% QA 17% 機能開発のリードタイム バグ修正日数 など
- 17. 17 システムテストの問題：バグ修正日数 0 2 4 6 8 10 UT/CT ST バグ修正日数 Q3 Q1 中央値 Q3 Q1 中央値 システムテストで 見つかったバグは 修正コストが高い ST
- 18. 18 クオリティ vs アジリティ アジリティ 高 低 遅い 速い サービス クオリティ 機能開発のリードタイム バグ修正日数 など
- 19. 19 クオリティ vs アジリティ アジリティ 高 低 遅い 速い サービス クオリティ サービス 機能開発のリードタイム バグ修正日数 など
- 20. 20 システムテスト自動化の目的 アジリティ 高 低 遅い 速い サービス クオリティ サービス目的： アジリティ改善のため システムテストを自動化 機能開発のリードタイム バグ修正日数 など
- 29. 29 システムレベルの検証が必要な項目②: 可用性?運用性 バランサ ノード 検索クラスター 検索クラスター ... ノード ノード …ノード
- 30. 30 システムレベルの検証が必要な項目②: 可用性?運用性 バランサ ノード 検索クラスター 検索クラスター ... ノード ノード …ノード
- 31. 31 システムレベルの検証が必要な項目②: 可用性?運用性 バランサ ノード 検索クラスター 検索クラスター ... ノード ノード …ノード Fail overするか？ 復旧出来るか?
- 49. 49 継続的システムテスト：課題 コンポーネント ソースコード レポジトリ ビルド ビルド サーバー UT 自動化された システムテスト … … コンポーネント … … … … ① 複数のチームや コンポーネントの スムーズな結合 ③ テストと開発の サイクルを作るには？ STG ② システムテストの 自動化は高コスト？
- 50. 50 自動化された継続的システムテストの課題①: スムーズな結合 インデクサー サーチストレージ アドミン 問題点: - チームの属人的な設計 → テスト自動化可能性に問題 - 低レイヤのコンポーネントのバグ → 他のコンポーネントの結合やテストに支障 … … … …
- 51. 51 課題①への取り組み: Software Engineer in Test (SET) 役割：自動化の専門部隊 テスト自動化方針に則った自動化 http://googletesting.blogspot.jp/2010/03/google-is-hiring-sets.html
- 52. 52 課題①への取り組み: Software Engineer in Test (SET) コンポーネント 開発者 Software Engineer in Test Search Indexer Storage Admin 開 発 機能の開発工程 テスト自動化方針 分析 設計 実装 テスト 役割：自動化の専門部隊 テスト自動化方針に則った自動化 分析 設計 実装 テスト … … … … http://googletesting.blogspot.jp/2010/03/google-is-hiring-sets.html
- 53. 53 課題①への取り組み: Software Engineer in Test (SET) コンポーネント 開発者 Software Engineer in Test Search Indexer Storage Admin 開 発 機能の開発工程 テスト自動化方針 分析 設計 実装 テスト 役割：自動化の専門部隊 テスト自動化方針に則った自動化 分析 設計 実装 テスト 自動化の観点から 分析や設計に 積極的に関わる … … … … http://googletesting.blogspot.jp/2010/03/google-is-hiring-sets.html
- 56. 56 課題①への取り組み: ：スモークテスト ? 最低限の結合を保証するスモークテストを自動化 Smoke Test 機能テスト 非機能テスト Pass Version Pass Yes No 大規模 データ UT&Build Yes Jenkins STG 手動システムテスト No A A ? スモークテストを パスしたバージョン を記録 ? 上記のバージョンを システムテストで 対象とする
- 60. 60 自動化された継続的システムテストの課題②: テストにまつわるコスト テストケース 手動 自動 フレームワーク 手動 自動 学習 開発 テスト実行 フレームワークの 学習や開発は 必要な投資
- 66. 66 テストツール: Ngauto ドメイン固有テスト 言語で記述された シナリオ ? アクション１ デプロイ ? アクション２ データ投入 ? アクション３ 検索クエリ テストツールの中で アクションに対する実際の 振る舞いを定義 “検索クエリ” アクションの例） --- Report report = issueSapiQuery（testId,query); … int expectedHttpStatus = getExpectedHttpstatus(testId); int actualHttpstatus = report.getActualHttpStatus() TestCase.assertEquals( message, expectedHttpStatus, actualHttpstatus ); … Ngauto （内製の テストツール）
- 69. 69 APP APP 自動化された継続的システムテストの課題③: テストと開発のサイクル APP 検証環境 開発マシン テスト 開発 環境差異による テスト結果の再現性の問題 によって壊れる！！
- 73. 73 開発 サイクル
- 74. Implement GIT merge UT Smoke Test 機能テスト 非機能テスト Smoke Test Pass Pass Version Pass Yes No No 大規模 データ UT&Build 実装 Yes システムテスト自動化後の開発サイクル LOCAL Jenkins STG 手動システムテスト 機能テスト 非機能テスト No Yes A A A A
- 75. Implement GIT merge UT Smoke Test 機能テスト 非機能テスト Smoke Test Pass Pass Version Pass Yes No No 大規模 データ UT&Build 実装 Yes システムテスト自動化後の開発サイクル LOCAL Jenkins STG 手動システムテスト 機能テスト 非機能テスト 自動化されたすべてのテストを毎日、継続的に実行 → リードタイム、バグ修正日数が最短１日に No Yes A A A A
- 76. 76 評価
- 77. 77 システムテスト自動化の効果の評価方法 ?自動化前後のバグ修正日数の比較 ?継続的システムテスト適用後の累積バグ数 参考情報：自動化前後のテストの比較 継続的システムテスト 前 後 自動化テストの カバレッジ 機能テスト の一部 （604件) 機能テスト 非機能テスト 大規模テスト (2887件) SET ? スモークテスト ? ? ドメイン固有テスト言語 ? バグのトレーサビリティ △ テストシナリオの透過性 △ ?：最初から △：途中から
- 78. 78 0 2 4 6 8 10 UT/CT ST 0 2 4 6 8 10 UT/CT ST 評価結果：バグ修正日数の比較 前 Q3 Q1 中央値 Q3 Q1 中央値 Q3 Q1 中央値 Q3 Q1 中央値 最大値 59 最大値 64 最大値 75 最大値 87 ST 後 (10572*） (11453*） *テストメソッド数 (日数) (日数)
- 79. 79 0 2 4 6 8 10 UT/CT ST 0 2 4 6 8 10 UT/CT ST 評価結果：バグ修正日数の比較 前 Q3 Q1 中央値 Q3 Q1 中央値 Q3 Q1 中央値 Q3 Q1 中央値 システムテストで発見された バグの修正日数が大幅に改善 最大値 59 最大値 64 最大値 75 最大値 87 ST 後 (10572*） (11453*） *テストメソッド数 (日数) (日数)
- 82. 82 自動化された継続的システムテスト適用後の累積バグ数 0 20 40 60 80 100 非機能テスト 機能テスト スモーク 3月 5月 7月 9月 機能テスト 自動化完了 大きな 機能要件 受け入れ テスト開発 テスト 自動化
- 83. 83 自動化された継続的システムテスト適用後の累積バグ数 0 20 40 60 80 100 非機能テスト 機能テスト スモーク 3月 5月 7月 9月 機能テスト 自動化完了 大きな 機能要件 受け入れ テスト開発 テスト 自動化
- 84. 84 自動化された継続的システムテスト適用後の累積バグ数 0 20 40 60 80 100 非機能テスト 機能テスト スモーク 3月 5月 7月 9月 機能テスト 自動化完了 シナリオの 透過性 大きな 機能要件 断続的な 小さな要件 受け入れ テスト開発 テスト 自動化
- 85. 85 自動化された継続的システムテスト適用後の累積バグ数 0 20 40 60 80 100 非機能テスト 機能テスト スモーク 3月 5月 7月 9月 機能テスト 自動化完了 シナリオの 透過性 大きな 機能要件 断続的な 小さな要件 受け入れ テスト開発 テスト 自動化
- 86. 86 自動化された継続的システムテスト適用後の累積バグ数 0 20 40 60 80 100 非機能テスト 機能テスト スモーク 3月 5月 7月 9月 機能テスト 自動化完了 シナリオの 透過性 大規模テスト 自動化完了 バグの トレーサビリティ 大きな 機能要件 システム リファクタリング 断続的な 小さな要件 受け入れ テスト 受け入れ テスト開発 テスト 自動化
- 87. 87 自動化された継続的システムテスト適用後の累積バグ数 0 20 40 60 80 100 非機能テスト 機能テスト スモーク 3月 5月 7月 9月 機能テスト 自動化完了 シナリオの 透過性 大規模テスト 自動化完了 バグの トレーサビリティ 大きな 機能要件 システム リファクタリング 断続的な 小さな要件 受け入れ テスト 受け入れ テスト開発 テスト 自動化
- 91. 91 まとめと 今後の課題
- 92. 92 まとめ：継続的システムテストの意味 クオリティ バグ修正日数の逆数 ( アジリティ ) 高 低 遅い 速い 自動化前 自動化前
- 93. 93 まとめ：継続的システムテストの意味 クオリティ バグ修正日数の逆数 ( アジリティ ) 高 低 遅い 速い 自動化前 自動化後自動化前
- 94. 94 まとめ：継続的システムテストの意味 クオリティ バグ修正日数の逆数 ( アジリティ ) 高 低 遅い 速い 自動化前 1/5 1/2 自動化後自動化前
- 95. 95 まとめ：継続的システムテストの意味 クオリティ バグ修正日数の逆数 ( アジリティ ) 高 低 遅い 速い 自動化前 1/5 1/2 自動化後自動化前 まとめ ? システムテスト自動化とCIやTDDの アイデアを組み合わせる事で 継続的システムテストを実現 ? バグ修正日数を改善
- 96. 96 まとめ：継続的システムテストの意味 クオリティ バグ修正日数の逆数 ( アジリティ ) 高 低 遅い 速い 自動化前 1/5 1/2 自動化後自動化前
- 97. 97 まとめ：継続的システムテストの意味 クオリティ バグ修正日数の逆数 ( アジリティ ) 高 低 遅い 速い 自動化前 1/5 1/2 自動化後自動化前
- 98. 98 まとめ：継続的システムテストの意味 クオリティ バグ修正日数の逆数 ( アジリティ ) 高 低 遅い 速い 自動化前 1/5 1/2 自動化後自動化前 今後の課題 ? システムのリファクタリングによる パフォーマンスの向上 ? 検索ランキングの改善 → どういった“クオリティ”に有効か？
- 100. 100 Good to see system test getting some