テスト自動化:短所

自動テスト(自動テスト)は、アプリケーションでのユーザーの対話をシミュレートするスクリプトです。その目的は、ソフトウェアのエラーをローカライズすることです。



テストの自動化の最終的な目標は、「GO!」ボタンをクリックすると、1つずつ起動される一連の自動テストです。 さて、または必要に応じて、いつでも個別に自動テストを実行できます。 このような各スクリプトは、アプリケーションの特定の部分の正しい動作をチェックし、何かが正しく動作しない場合はエラーを修正します。

この記事では、手動テストよりも自動テストを使用する方が収益性が高いこと、および自動テストの利点について詳しく説明しています。 自動テストの使用を決定したテスターが遭遇する可能性のある問題について説明したいと思います。





自動化のためのテストの選択



自動化が必要なテストケースを選択すると問題が発生します。 すべてのテストケースが自動化に適しているわけではありません。また、一部のテストケースが手動テストに残ったほうがよい場合もあります。 つまり、テストシナリオが1000個ある場合、1000個のテストシナリオを自動化できる可能性はほとんどありません。 手動テストから自動テストに完全に切り替えることは非常にまれです。 手動テストと自動テストは相互に排他的ではなく、補完的な方法であることを忘れないでください。

たとえば、次のようなテストを自動化することは不可能です(非常に困難です)。



費用



自動テストの開発と保守が手動テストよりも安くなるとは限りません。 開発環境、システム管理者、雇用プログラマー、彼らの情報サポート(テスト中のシステムおよびテストケースに関する質問のサポートを意味する)に投資して、ジョブを提供する必要があります。 これはすべてかなりの量になり、かなりの数のテストを自動化できる場合に大規模なシステムをテストする場合にのみ効果があります。 スクリプトを開発した後、誰かがそれらを実行し、結果を分析する必要があります。 「開始-待機-最終結果の受信」というスキームに従ってテストを実行することはできません。 自動テストのパフォーマンスを分析できる人が必要です。改訂のためにテストを送信するかどうか、自動テストで実際にエラーが見つかったかどうかを判断し、テスト用のデータを準備します。 開発環境、開発自体の準備には多くの時間がかかります。



自動化の費用の別の項目は、自動テストのサポートです。



サポート



自動テストには常にサポートが必要です。 自動テストの作成はプログラミングであるため、自動テストのロジックを変更/修正するには、ソースコードに移動する必要があります。 これを行うには、書かれたスクリプトに同行する追加の専門家を雇う必要があります。 これらは避けられない新しい費用であり、自動テストのコストを大幅に増加させます。 ソースコードへの介入が必要になる可能性のある主なケースは2つあります。



1.テストへの入力を変更します


アプリケーションのテストを何回か繰り返している間、入力のために常に同じデータを自動テストに送信できると便利です。 たとえば、データベースのエントリをチェックしたり、入力がまったく必要ないメニューのオープンをチェックしたりします。

しかし、自動テストを開始する前に、データを再度準備する必要があることもあります。 多数のテストでは、入力データの準備に時間がかかる場合があります。 たとえば、銀行システムをテストする場合、ルーブル、ドル、ユーロのアカウントが必要になる場合があります。 個人と組織の両方に属する異なる金額のアカウント。 一連の自動テストを実行した後、すべてのアカウントの残高がゼロになる場合があり、一部は閉鎖され、一部はブロックされます。 後続のテストでは、他のアカウントを使用する必要があります。 場合によっては、自動テストでデータがハードコードで記述されることがあります。これは、開発者がスクリプトをより柔軟にするのが面倒だったためではなく、テストケースでそのようなハードコードが必要だったためです。 しばらくすると、テストケースが変更され(たとえば、銀行の名前が「habrabank」から「habrakreditbank」に変更されます)、スクリプトの変更が必要になります。



2.機能の変更


特に回帰テストに関連-新しいバージョンのテスト。 テストされたソフトウェアのインターフェイスまたは機能が更新されるたびに、自動テストの完了が必要になります。 自動テスト自体は新しいインターフェイスに適応できず、正しい操作を続けるには、すべてを手動で変更する必要があります。 テストの数が多くなり、ソフトウェアのイノベーションが増えるほど、更新に時間がかかります。

例:古いバージョンのプログラムには「ファイル->オプション」というメニューがありましたが、新しいバージョンではこのアイテムは「ファイル->設定」と「ファイル->オプション」の2つに分かれていました。 自動テストは引き続き「オプション」項目を検索し、クラックしても、「設定」は見つかりません。

または、たとえば、テストされたページの読み込み時間が変更される場合があります。 瞬時にロードする前であれば、今では1分かかります。 接続速度が遅いか、ベースが遅いと仮定します。 自動テストはこれを認識せず、ページがロードされるのを10〜15秒間待機し、「エラー:ページがロードされませんでした」というメッセージを表示します。 繰り返しますが、スクリプトのソースコードを改良する必要があります。



どちらの場合も、開発者に大きく依存します。自動テストを作成するプロセスは、他のソフトウェアを作成するプロセスほど知識と労力を必要としません。 したがって、品質管理と信頼性の複雑さ、期限の延期、予算の変更など、開発に関連するすべての問題がここに現れます。



そしてまだ



これらの不利な点は、すべてのコストで自動テストを回避する必要があるという意味ではありません。 彼らも便利です。

グラフからわかるように、自動化を使用すると、同じコストで最高の結果が得られます。 しかし、繰り返しますが、これらの結果は、大規模プロジェクトのテストを自動化する場合にのみ最適になります。



画像



自動化のその他の利点:








All Articles