アジャイル テスト コラムの 4 番目の記事のタイトルとして、レイモンド カーバーの 1981 年の有名な著書「愛について語るときに私たちが語ること」のタイトルをお借りさせてください。もちろん、この素晴らしいタイトルの下、プライベートなことを呟くことをお許しください。
アジャイルには従うべき公式はありません。文化、製品、ユーザーの違いにより、組織ごとにアジャイルの具体的な実践方法には当然大きな違いがあります。これはアジャイル実装の標準ですが、最近私は多くのアジャイル組織と接触するようになりました。中国のテスト マネージャーとテスト エンジニアは、アジャイルで「優れたテスト」を行う方法、特に自動テストについて意見が異なることがよくあり、見解はさらに異なります。
自動テストを学びたい場合は、ここで一連のビデオをお勧めします。このビデオは、ステーション B のネットワーク全体における最初のインターフェイス自動テスト チュートリアルと言えます。同時に、オンライン ユーザーの数は増加しています。 1,000 に達しました。収集するメモとさまざまな Lu Dashen 技術交流があります。記事の下部にあるカードをクリックしてください
ステーションB 
https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337.search-card.all.click
実際、私は以前にアジャイル テストにおける自動テストについて説明し、適切だと思われる自動テスト戦略と方法をいくつか示しました。自動テストについて説明する記事が必要なのはなぜですか? 自動テストには複数の具体的なアプローチがあるはずで、自動テストの技術や手法は数え切れないほどあります。しかし、自動テストについて話すとき、どのような情報を伝えたいのでしょうか?
コックバーン氏は『アジャイル ソフトウェア開発』の中で、「コミュニケーションの成功は、送信者と受信者が引用できる共通の経験を持っているかどうかに依存する」と述べているため、自動テストについて言及する場合、共通の語彙を持たなければなりません。まず、自動テストとは何ですか? 自動テストというと、QTP、WebDriver などの自動テスト ツール、およびこれらのツールに基づく関数や UI の自動テスト スクリプトが最初に思い浮かぶ人もいますが、実際にはこれらは単なる私の意見では、テストの一部またはすべてを自動化するために「マシンの機能を使用する」すべての操作は、「自動テスト」と呼ばれるべきです。
コード内のクラスまたはメソッドに対して確立された単体テストであっても、手動での参加が必要な製品に対して確立された diff メソッドであっても、これは自動テストの特定の方法です。テストの場合、自動テストは存在的な目標ではなく、テストの目標を達成するための手段にすぎません。自動テストから何が得られると期待していますか? 自動テストカバレッジ? 自動テスト カバレッジは自動テストの割合を測定する手段ですが、これはまだプロジェクトにおける自動テストの目標ではありません。プロジェクトでは自動テストを行っていますが、その目的は「自動テストによってテストや製品の品質を向上させる」ことだけです。したがって、自動テストについて話すとき、目標と呼べるものは次のもののみです。
- 同じテスト範囲を確保する場合、人的リソースの投資を削減します。
- 同じ人的資源投資の場合、テストカバー率は向上します。
- テストの実行を上流に移して、開発者が製品の問題を早期に発見できるようにすることで、修復コストを削減します。
目標ができたら、あとはそれをどうやって達成するかだけです。「人的リソースの投資を削減する」は、最も直感的に理解されやすい自動テストの目標であるため、多くのチームのアプローチは、「手動テストを自動テストに置き換える」ことで、本来手動で実行する必要があったテストケースをUI自動テストに変えることです。場合は、自動テスト ツールが代わりにスクリプトを実行します。この方法に効果がないとは言えませんが、自動テストは手動テストに比べて欠陥を特定する効果がはるかに低いため（UIテストの観点からは、「想定外」の欠陥はUIテストによって発見されにくい）、また、UI 自体のばらつきにより、手動テストと同じ範囲を達成するために、純粋な UI 自動テストでは投資収益率を証明することが困難なことがよくあります。
「テスト範囲の拡大」は、自動テストがメリットをもたらすもう 1 つの分野です。思い浮かぶ例は、パフォーマンス テストやファズ テストです。多数のユーザーの同時実行をシミュレートするマシンの機能に依存し、ルールに基づいて大量のランダム データを生成し、それをサーバーに送信して、システムの潜在的なセキュリティ問題を検出するマシンの機能に依存します。これらの分野では、自動テストは明らかな利点をもたらします。
ただし、「テスト カバレッジを増やす」と言うとき、私が話したいのは、アプリケーションの特定の品質属性を検証するパフォーマンス テストやファズ テストだけではありません。「カバレッジ」に関して、私の頭の中にあるもう 1 つのシナリオは、「自動テストを通じてアプリケーション内のより多くのインターフェイスとサービスをカバーする」ことです。つまり、UI テストや機能テストではカバーできない領域を自動テストによってカバーすることです。手の届きにくい部分。このタイプの自動テストは、サブシステムまたはモジュール間のインターフェイスの検証に焦点を当てた、統合テストのテスト方法および方法と比較できます。
ただし、自動テストとして、インターフェイスとサービスの検証スクリプトの確立だけでなく、インターフェイスとサービスの設計の合理性を促進することによって、できるだけ多くの完全なインターフェイス/サービスの自動テストを確立することにも重点が置かれています。可能になる。Web アプリケーションのフロントエンドでインターフェイス/サービス レベルの自動テストを実行するとします。明らかに、このフロントエンド アプリケーションには分離できるインターフェイスとサービスが多数あります。フロントエンドが Clearsilver+Java に似た開発手法を採用している場合、理論的には、ここに自然な継ぎ目があります: Clearsilver は「テンプレート システム」として、主にページを表示する機能を提供します。Java コードは主にビジネス ロジックの実装に使用されます。Java コードは、テンプレートに動的データ項目を入力することで、ユーザーに表示されるページを生成します。
このモードでは、アプリケーションが適切な階層化設計になるようにプロモートでき、Clearsilver 側にロジック実装がまったく含まれず、ロジック部分 (Java コード) によって生成されたすべての動的データに何らかの方法で直接アクセスできます。テストでは、テンプレート部分と Java コード部分を検証するためにまったく異なる方法を使用することを検討できます: ブラウザを使用してデータが埋め込まれたテンプレートを表示し、画像比較に基づいてテストと差分を行います。データ検証を使用します。または diff を使用して、Java ロジックの実装が正しいかどうかを確認します。このようにして、アプリケーションの検証とテストのさらなる層を確立できます。自動テストの設計と実装のこの部分には、通常、テスト容易性の設計が伴います。アプリケーション内で可能なテスト ポイントを見つけ、アプリケーションのテスト容易性を向上させ、アプリケーションのさまざまなテストに対してより自動化されたテストを確立する。これが「テスト カバレッジを増やす」ための一般的な方法です。
「テストを上流にプッシュする」とは、テストの実行を開発フェーズと設計フェーズにプッシュすることを指します。継続的インテグレーションは「上流でテストを実行する」方法で、提出されたコードを定期的（数日または数時間）またはコード提出をトリガーとして検証し、開発エンジニアにコード品質のフィードバックを提供できます。この方法により、不具合を早期に発見することができ、テスト実施者と修正者が同一であるため、通信によるオーバーヘッドを大幅に削減できます。
私の意見では、自動テストが最もメリットをもたらすのは継続的インテグレーションのようなものです。しかし、テストを上流に進めるためには、継続的インテグレーションのフレームワークを確立するだけでは不十分で、開発エンジニアがテストの作成、実行、保守に多大な労力を費やす必要がある場合、この種のテストは受け入れられないのは明らかです。 「上流でテストを実行する」のが理想的です。Android と iPhone はどちらも自動テスト フレームワーク (Android ではインストルメンテーション、iOS では UI オートメーション) を提供しており、理論上、開発エンジニアは独自のアプリケーションの自動テストを作成、実行、保守できます。
しかし、これらのテストを行う際の開発エンジニアのコストを見てみると、開発エンジニアが保守する Android や iPhone 上のアプリケーションの自動テストを開発エンジニアが受け入れるのは非常に難しいことがわかります。iOS での自動テストを例にとると、開発エンジニアが実際のデバイスでテストを実行したい場合は、まず iPhone デバイスを見つけて自分のマシンに接続し、テストするアプリケーションをコンパイルして、iTunes を使用する必要があります。テストが必要なアプリケーションが iPhone デバイスに同期され、UI オートメーションの IDE 環境が開かれ、テスト スクリプトがロードされてテストが実行され、テスト結果が手動でチェックされ、テスト結果が正しいかどうかが確認されます。独立した開発者でない限り、開発エンジニアは続行できないと思います。この方法で 1 週間以上自動テストを実行すると、開発エンジニアはこの作業をテスト チームに熱いジャガイモのように丸投げしなければなりません。
では、この場合、テストを上流にプッシュするにはどうすればよいでしょうか? ここでの主なボトルネックは、テスト実行の消費量が多すぎることです。モバイル デバイス ラボを構築し、iPhone と Android のテスト実行を 1 つのコマンド ラインに統合できれば、テストするアプリケーションのバイナリを指定するだけで済みます。テストを実行する必要があるデバイス。実行する必要があるテスト スクリプトと結果が保存される場所は、このコマンド ラインを通じて開発エンジニアにテストの実行結果を直接伝えることができます。この場合、メンテナンスと比較して、自動テストの作成コストは、自動化によってもたらされる利点が投資よりもはるかに大きくなります (即時のフィードバックが得られ、テストの迅速な実行を繰り返すことができます)。
「上流へのプッシュテスト」は、特定の自動テスト技術ではありませんが、自動テストの非常に価値のある方向性です。上記の iPhone と Android のテストの例では、「テスト実行をコスト効率よく行える自動テスト実行環境を作成する」ことが、この場合「テストを上流にプッシュする」ための最良の選択ですが、他のケースでは解決する必要があるかもしれません。他にも問題があります。いずれにせよ、「テストを上流にプッシュする」という視点を堅持し、自動テストによって上流にプッシュする可能性を作り出すことが、自動テストが引き続きメリットをもたらし続ける方法だと私は考えています。
自動テストは万能薬ではありませんが、自動テストなしでは絶対に不可能です。お金と同じように、自動テストは不可欠であり、多ければ多いほど良いのですが、自動テストですべての問題を解決できることは期待できません。自動化に適さない問題は何ですか? 自動テスト技術は、テストの実行と検証を機械の能力に依存しているため、手動の経験が必要な一部の操作、音声の流暢さなど、機械の実行と検証に適さないものは自動テスト技術の使用には適していません。また、収入面でも安定した需要やUIがないため自動テストには不向き、あるいはアジャイル開発環境ではテスターがソフトウェアを使いこなしたり、ソフトウェアを探索したりする必要がある。反復ごとに探索して学ぶことができます。
このような場合、通常は、アプリケーションを理解し、スクリプト以外のアプリケーションの欠陥を見つけ、自動テストでは到達できないギャップを埋めるために、探索的テストなどの手法を使用した手動テスト方法に依存する必要があります。
自動テストはどこで行うべきですか? 自動テストをどこかに導入するかどうかを決定するのに役立つ簡単な判断方法は次のとおりです。 1. ここで自動化することは技術的に可能ですか? 2. 自動テストが導入された場合、メリットは得られますか? 両方の答えが「はい」の場合は、ためらうことなく自動化を開始してください。