統合による自動化。 プロモーションバージョン。 UPD

UPD ：スキンショットを追加しました。



Software Engineering Forum 2011は5月19〜20日にミンスクで開催されました。「新しいレベルのテスト自動化」というタイトルのプレゼンテーション、または代替の長いバージョン「テストツールの統合による自動テストの事前自動化」を行いました。 その中で、3つの主な質問を明らかにしました。

1. 組織内のテスト自動化のレベル。
2. 自動化をテストするときに注意すべき主なポイント（自分の経験と同僚の経験、および調査の結果に基づいて）。
3. 自動テストを管理するためのソリューションのプロトタイプ（Octopusの内部開発に基づく）。

カットの下-レポートの内容、タコのプロモーション版へのリンク。 長い投稿。

1.テスト自動化のレベル

自動テストの実装における私たち自身の経験、QA会議中に話し合った他の企業の同僚の経験、および調査のデータに基づいて、企業が自動テストを通過する3つの主要な段階を特定しました。

A.発生段階（I）

手動テストに加えて、企業は次の使用を開始します。

-テスト済み製品のセットアップをコピーし、インストールし、部分的にテストするスクリプト。

-自動テスト開発環境で作成されたテスト。



ステージの特徴

• 自動テストに関連するアクションは手動で実行されます（スクリプトとテストの実行、仮想マシンの操作など）。
• テストのストレージの明確な組織化の欠如（原則として、テストはテスターのマシンに保存され、テストのみによって使用されます。つまり、テストされたインターフェースの変更に再利用および適応できません）
• 実行中のテストの体系化と実装の制御はありません（テストを実行することも、忘れることもできます）。
• ビルド検証ステータスに関するテスターと開発者の間の情報フローはありません。
• 原則として、テストには完全な自信はありません。 ただし、テストとスクリプトにより、テスターのリソースが大幅に解放されます。

この段階は、まず第一に、短期プロジェクトを持つ企業に特有のものです。そのため、自動化されたテストを新しいレベルに引き上げる時間がありません。 この段階では、ソフトウェア品質管理プロセスで自動化されたテストのみを実装する組織や、テストプロセスを明確に記述していない小規模企業もあります。

B.意識段階（I + II）

テスト自体の自動化とともに、プロセスの一部が自動化されます。



ステージの特徴

• 中央ストレージの構成とテストの再利用（機能のライブラリ）が表示されます。
• 自動化されたテストの命名規則が施行されます。
• ほとんどのアクションは自動化されています：テストの実行、仮想マシンの起動/停止（仮想化が使用されている場合）、必要な構成ファイルのテストマシンへのコピーなど。
• テスト自体の品質は向上しています。
• テストの実行は、各製品アセンブリのリリースで体系化および自動化されます。
• テスト結果を処理するときの動作は明確に定義されています-バグの作成/終了。

これは最も人気のあるステージの1つです。 テストプロセス自体を確立し、中期および長期プロジェクトに取り組んでいる企業にとっては典型的なことです。 つまり 製品の回帰テストを実施する必要がある組織について話している。

C.上級レベル（I + II + III）

段階「自動テストの自動化」。 トートロジーは、自動テストサイクルのすべての操作がテスターの参加なしに実行されるという考えを表現するために意図的に使用されました。レポートを作成します。 原則として、これはスクリプトと構成ファイルの助けを借りて達成され、自動テストを管理する統合システムの開発に投資する可能性ははるかに低くなります。



ステージの特徴

• 環境設定、仮想マシンの起動、パフォーマンステストの実行、バグの登録、レポートの作成など、自動テストの実行に関連するすべての操作は「事前に自動化」されています。
• 制御システムでのエラーの作成（必要に応じて、修正されたエラーのクローズ）は、会社が採用したすべてのルールに従って自動的に行われ、責任者が任命され、BTSの指定されたフィールドに入力されます。
• テストの効率を高めるさまざまな「ガジェット」：同時起動用のテストグループの作成、特定の基準（軸、インストールされているプログラム、ローカリゼーションなど）による仮想マシンのグループ化。
• テスト実行をパラメータ化するための単一のインターフェイス（一般的ではありません）。

まず、幅広い機能、中長期のプロジェクトを備えた複雑なソフトウェア製品を開発し、高品質でタイムリーな回帰テストの欠如の問題を強く感じている企業は、この段階を達成するために努力しています。

Habrozhitelで実施した調査の回答者の約12.5％が、彼らの会社はこの段階にあると述べています。

残念ながら、自動テストをどのようにパラメーター化するかを明確にする方法はありません-単一のUIを通じて、構成ファイルを使用するなど。 このような質問をするというアイデアは、100件以上の回答を受け取った後に生まれたもので、追加する意味はありませんでした。 ただし、LinkedInのQAコミュニティの参加者を対象とした英語の調査に含めました（下の図を参照）。



上記の分類は私たちの経験の結果であり、唯一の正しいものであると主張するものではありません。 あなたのビジョンが私たちのビジョンとどのように一致しないのだろうか？

いくつかの歌詞、または回帰テストの問題

新しいビルドの定期的な回帰テストが、最終製品の一貫した高品質を保証することは秘密ではありません。 しかし、リソースの制限により、しばしば無視されるか、完全に実装されていない回帰テストです。

約5年前、当社はこの問題に遭遇しました。 顧客側で見つかったエラーの数は、すべての良識の基準を超えていました。 この製品は、多くのエージェント、モジュール、コンポーネントで構成される自動車業界向けの複雑なデスクトップシステムです。 毎月、アプリケーションは新しい機能で大きくなりすぎ、テスターは新しい機能と古い機能の一部のみをチェックすることに成功しました。 開発者とテスターの間の緊密な協力にもかかわらず、誰も予想していなかった場所でシステムが「クラッシュ」しました。

テストプロセスを新しいレベルに引き上げる必要があることが明らかになりました。

彼らは、自動テスト、スクリプト、バッチファイルの作業を促進し始めました。 これにより、回帰テストをより迅速に、より広範囲に実施できるようになりました。 ただし、自動テストの導入により、当初は予測していなかった多くの問題が隠されました。 実際、自動化の段階の説明でそれらのいくつかに簡単に触れましたが、ここでさらに詳しく検討します。

2.テスト自動化の問題

A.不完全な自動化

「自動テスト」という表現はややarbitrary意的です。 多くの場合、テスターは多くのタスクを手動で実行します。環境の準備、製品の新しいバージョンのダウンロード、構成ファイルのドラッグ、異なるAxesでの自動テストの実行、BTSでの欠陥の登録など。 これは簡単ですが、時間がかかり、人的要因によるエラーの可能性も高くなります。





場合によっては、時間の損失が大きくなる可能性があります。 たとえば、個々の結果が重要なデータドリブンテストの場合、欠陥管理システムに追加する必要があるバグの数は膨大になる可能性があります。 平均して、BTSで必要なすべてのフィールドに入力してバグを作成した経験豊富なスペシャリストは、1分以上かかり、クローズするのに約15秒かかります（*）。 これらの時間のかかるアクティビティは付加価値が低く、新しいテストを作成するなど、テスターの知的潜在能力を使用して、実装に費やした時間をより効果的に使用できます。



（*）測定は、次の条件下で実行されました。

1.欠陥制御システム-MS TFS、Mantis、Bugzilla。

2.実験者：4年の経験を持つ2人のテスター。

実験中に、次の必須フィールドを含む10個のバグが作成されました。

MS TFS：タイトル、AssignTo、反復、エリア、テスター、FoundIn、重大度。

カマキリ：カテゴリ、概要、説明、プラットフォーム、OS、重大度。

Bugzilla：コンポーネント、バージョン、概要、説明、重大度、担当者。

BTSを開くのにかかる時間も考慮されました。

B.便利で柔軟なテスト管理ツールの欠如

会社がテスト自動化の高度な段階にあったとしても、自動テストに関連するすべてのタスクを管理するための共通のインターフェースを持つことはめったにありません。 ほとんどの場合、パラメーター化は構成ファイル（回答者の50％）を介して行われ、多くの場合検証されません。 その結果、エラーの数が増加し、自動テスト全体の有効性が低下します。

LinkedInユーザー調査結果：

C.アーキテクチャの拡張性とスケーラビリティ

多くの場合、自動化されたテスト管理システムの開発を開始し、システムの拡張性とスケーラビリティを提供せずに、現在使用中のツールに焦点を当てています。

このアプローチの欠点は明らかです。 会社がBTSバージョンを更新したか、新しいタイプの仮想化サーバーを追加することを決定した場合、または新しいタイプのテストを使用し始めた場合、システムのカスタマイズと新しいツールとの統合にかなりのリソースを投資する必要があります。

拡張性がシステムアーキテクチャに固有でない場合も同様の状況が発生します。製品が機能を獲得するにつれて、自動テストの数が増加し、仮想化リソースの合理的な分散が必要になります。 仮想サーバーのプールを増やすと、テスト自動化システムをサポートし、個々の要素を管理する努力が増えます。

D.単一の形式での累積レポートの欠如

原則として、各タイプのテスト（たとえば、Visual Studio、HP QTPなどで記述された）は、結果に関するレポートを独自の（ネイティブ）形式で提供します。プロジェクトマネージャーまたは顧客が表示するには、適切なソフトウェアがインストールされている必要があります。 一部の自動化されたテスト開発環境では、これらの結果を、たとえば誰でも見ることができるHTMLレポートにエクスポートできるという事実にもかかわらず、それらはすべて形式と構造が異なり、情報の認識を複雑にします。 さらに、仮想マシンまたは物理マシンで必要なテストを実行すると、レポートのパックがいくつか得られますが、それぞれを個別に表示する必要があります。

「累積」という言葉は、1つのドキュメントでテストに合格した場合の結果の蓄積を意味します。 したがって、「単一形式の累積レポート」とは、単一の一般レポートの作成を意味し、新しいテスト結果が到着するたびに常に更新され、情報の関連性を保証します。



すべてのテストの一般的なHTMLレポートの例

E.プロセスの継続性

自動テストを制御するシステムは、基本的にパイプラインです。 テスト用の新しいアセンブリが入力に送信され、作成されたバグとレポートの形式の出力が出力されます。 そのようなシステムを開発する際、「愚か者」からの保護が欠如しているという問題に直面しました。 つまり、テストの1つがエラーで書き込まれた場合、システムによって無期限に実行され、仮想マシンまたは実マシンの形式でリソースをロードする可能性があり、実行キュー内のテストに道を譲ることができません。 この問題はさまざまな方法で解決できます。 「タイムアウトキル」機能（長時間実行コマンドの実行を中断する機能）を実装しました。

F.不十分なシステムロギング

ログファイルがないため、エラーのデバッグが困難になります。 多くの場合、テスト自動化システムの一部のみ、たとえばテストのみのログがあります。 同時に、仮想マシンイベントの記録、バグの作成、レポートなどはありません。 これにより、システムが不透明になり、操作を追跡するのが難しくなり、プロセスの全体的な効率が低下します。

3.自動テストを管理するためのソリューション

上記で説明した「大したこと」という点を踏まえて、環境の準備からテストの実行、欠陥の登録、レポートの作成まで、自動テストのサイクル全体を24時間自律的に管理するシステムを徐々に開発しました。

これは、独自のバグ追跡システムまたはスクリプト環境を作成することではないことを、別に強調する価値があります。 このソリューションは、既存のテスト機器を共通のインターフェースを備えた単一のシステムに統合するインテグレーターです。 テストツールには、テストおよびプロジェクト管理用のさまざまなソフトウェアが含まれています。ビルドシステム、バージョン管理システム、バグ追跡システム、仮想化システム、テスト開発環境です。

最初に、テスターとこれらのツールのそれぞれとの主な相互作用を研究し、次に後者のAPIを研究しました。 最後に、これらはすべて共通のUIの下で統合され、社内に存在するルールとプロセスに従ってシステムを便利かつ迅速に構成できます。

制御システムの主要な開発は、後に8つの主要な機能に敬意を表してタコと呼ばれましたが、その後1.5〜2年前に完成しました。 その結果、5人のテスターを追加雇用したように感じます。

ビルド、マシン、手動開始、キュー、ログの5つのタブを使用して自動テストプロセスを構成します。 各タブでは、対応する要素が完全に構成されており、ログを使用すると、システムの隅で何が起こっているかを監視できます。



スクリーンショットの例

ビルドタブ





マシンタブ





キュータブ

タコ制御システムの主な機能

1.テスト中に仮想化が使用されている場合、仮想マシン（VM）を起動します。

2.テスト環境を準備します。テストのために構成ファイルと自動テストをマシンにコピーし、製品をインストールします。

3.ビルドの優先度に従って、正常に収集されたビルドをテストキューに配置します。

4.スケジュールまたはビルドリリースが成功したイベントで自動テスト/テストグループを実行します。

5.「クリーンな」VM、特定のスナップショット、および物理マシンでテストします。

6. BTSで検出されたエラーをログに記録し、テスターに​​よって割り当てられたフィールド（たとえば、タイトル、割り当て先、状態、説明、検出元、レビューア/テスター、重大度など）に入力します。

7.オペレーターによって許可されている場合、修正されたバグを閉じます。

8.合格したすべてのテストに関する一般レポートをHTMLで作成します。

テスターは自動テストを統合システムのデータベースにロードし、特定のプロジェクトの設定を一度設定し、製品の新しいビルドごとにノンストップで個別にテストします。

このビデオ（3分）は、システムが組み立てられたビルドのテストを自動的に開始する方法を示しています。

タコのシステム構造

ソリューションは3つのモジュールで構成されます。

自動テストマネージャーは、システム全体の動作を制御するサーバーコンポーネントです。

実装テクノロジー： .NET Framework v3.5用のC＃のWindowsサービス。

リソース消費：

CPU：実質的に負荷なし

RAM：〜50 Mb

ネットワーク：タスクの開始時と完了時に完全に占有されています-環境が仮想マシンにダウンロードされ、結果が取得されます



自動テスト起動エージェント -テスト用に仮想マシンまたは物理マシン上のビルドでテストを直接実行し、環境を構成し、テスト結果のファイルを自動テストマネージャーに転送するモジュール。

実装テクノロジ： C ++コンソールアプリケーション。

リソース消費：

CPU：テスト実行中は使用されません

RAM：〜7 Mb



自動テストコントロールパネルは、タコのユーザーインターフェイスを提供するクライアント部分です。 これにより、テスト実行の包括的なチューニングを実行し、リソース（仮想マシン）を管理し、テスト実行の現在のステータスとイベントログを表示し、必要に応じてテストを手動で開始および停止できます。

実装テクノロジ： Microsoft Silverlightプラットフォーム用のC＃デスクトップおよびWebアプリケーション。

リソース消費：

サイズ：〜0.5 Mb

RAM：〜30 Mb

システム要件

OS：Windows XP / Vista / 7、Windows Server 2003/2008

CPU：1.0 GHz

RAM：512 MB

ハードドライブ：4 MB



このシステムは内部ニーズのプロジェクトとして開発されたため、最初に社内で使用するテスト製品と統合しました。

おそらくそのようなシステムが他の誰かに役立つ可能性があるという考えが浮かんだとき、リストはフリーソフトウェアを追加することで拡張されました。



現在、リストは次のようになっています。



仮想化システム： VMware Server 2.0 *、Hyper-V。

ビルドシステム： CruiseControl.NET *、Microsoft Team Foundation Server 2008/2010。

バージョン管理システム： SVN *、Microsoft Team Foundation Server 2008/2010。

エラー制御システム： Mantis Bug Tracker *、Bugzilla *、Microsoft Team Foundation Server 2008/2010。

開発環境のテスト： AutoIt *、Microsoft Visual Studio、HP QTP。

（*）-フリーソフトウェア。



このシステムは、オープンAPIを備えた商用および無料のツール用にカスタマイズ可能です。 近い将来、バグ追跡システムJiraを「固定」してください。

無料プロモーション版

フリーソフトウェアをベースにしたOctopusアプリケーションの無料プロモーションバージョンを作成しました。 フリーウェアを選択したので、必要に応じて誰もが実際に試すことができます。

このページの詳細： www.appsys.net/Octopus/Download/Ru

質問やコメントを待っています。