背景
市場には非常に強力で開発されたユーザーインターフェイステストツールがあります。 特別なスクリプト言語、多くのドキュメントと方法論があります。 つまり、「問題はありますか？ 解決策があります！」
一方、問題を解決するために費やされるエネルギーは、全体として集合体によって生成されるエネルギーと何らかの形で一致しなければなりません。 しかし、実際には、大企業が個々のQAスペシャリストとテスターの人員配置でプロセスを最大限に展開できる場合、小規模オフィスは常にこれを行うことができず、一部の機能を自分自身に割り当てる必要があり、プロセス自体の哲学はわずかに歪められます。
つまり、地理的に分散した1Cの開発者のグループで、最大10人、平均で最大5つのアクティブプロジェクト、主に標準1C製品を使用しないカスタムソリューションの開発です。
目的：インターフェイスおよびビジネスロジックの動作のテストを含む、開発テストプロセスを可能な限り効率的に実装する。 効率は、テストに費やした時間が最終結果の観点から依然として意味をなす場合のバランスです。 私はこの線が非常に主観的であり、おそらく「温かさとソフトを比較する試み」という表現を完全に正当化することを認めます。 そのようなシナリオテストの目的は何ですか、読者は著者よりもよく知っていると思います。
1Cバージョン3.0およびxUnitFor1Cからのシナリオテストと同様に、欧米のベンダーの多くの機器システムを調査した後、これらの技術の導入についてまだ精神的に成熟していないようでした。 時間が経ちましたが、まだ成長できません。 同時に、すべては腸によって要求され、少なくとも何らかの解決策を要求していました。
古いレコードを取得すると、潜在的なソフトウェア製品の要件のリストが再びコンパイルされました。
- ソリューションは曇っている必要があります
- すべての開発のテストベースを統一する必要があります
- アプリケーションへのアクセス制御が必要です（各プログラマーは独自の開発プールを持っています）
- テストの開発と実行は1つのIDEで行う必要があります
- スクリプトは、ユーザーアクションによって作成されるのではなく、プログラムする必要があります。
- テストプログラミング言語は1Cに似ていることが望ましい
- テストは、事前の操作、コンパイル、アセンブリ、アンロード、ダウンロードなどを行わずに、ボタンをクリックするだけで開始する必要があります。
- テストを記述するプロセスでは、ウィンドウの構造とテストされたアプリケーションの詳細を1Cマネージドインターフェイスモデルの観点から分析できる必要があります。これは、テスト自体が開発されたプログラム内にある必要があります。 テストデータベース内のコントロールツリーを通過するときに、テスト対象のアプリケーションのフィールドのプロパティを取得できるようにする必要があります。テストされたアプリケーションは、このコントロールがどこにあるかを示す必要があります。
- ビジネスロジックのテストには、参照ベースを使用しないでください
- テストをテストするには、特別に準備されたベースがなく、すべてのテストが機能し、必要なものをすべて作成できる必要があります
もちろん、このリストは完全にはほど遠いものであり、他のソフトウェア製品にはある程度存在します。 若々しい最大主義のように思えるかもしれませんが、1つの製品でこれらすべての条件が満たされている場合にのみ、状況にシナリオテストを導入する可能性があります。 同僚は私に反対するかもしれませんが、テストの質と量の重要な問題の1つは、アプリケーション開発の連続モードでこれらのテストをどれだけ迅速かつ便利に実行できるかということです。
おそらくさらに6か月が経ち、最終的に次のテスターバイク（以下テスターと呼びます）の開発を緩慢なオプションモードで開始することにしました。
それはどのように見えますか
その結果、1Cに基づいたソリューションのスクリプトテストが記述され、実行される1Cに基づいたアプリケーションが誕生しました。 毎日の使用は次のようなものです。テスターは1日中、2番目のモニターでプログラマーに対してオープンです。 プロジェクトアカウンティングデータベースで、マネージャーは、プロジェクトの対象となる必要なテストセットを示します。
また、タスクごとにプログラマが実行する必要のある標準的な必須テストもいくつかあります。 たとえば、文書がに基づいて入力される場合、それに基づいてテスト入力が必要です。 つまり、プログラマはどのテストを作成する必要があるかを知っています。
テストが作成されるとき
実際には、開発プロセス中にケースの半分でテストを記述します（アプリケーションを再起動するたびに同じアクションを繰り返す必要がある場合、ルーチンを自動化するのに非常に便利です）。 他の半分で-後に。 洗練された読者が気づいているに違いないので、この状況は古典的なBDDではありません。
試験例
「ドキュメントアセンブリキットを開発する」というプロジェクトがあるとします。 このドキュメントには、ウェアハウスによるフィルターを備えたリストフォームが必要です。 検討中のソリューションのリスト作業の一般的な概念は次のように採用されました：フィルターが設定されている場合、フィルター値によるドキュメントの選択に加えて、このフォームから新しいドキュメントを入力するときに選択値がデフォルト値として機能する必要があります。 したがって、ウェアハウスがインストールされている場合、新しいドキュメントを入力すると自動的にインストールされます。
一見しただけでは、このようなシナリオではテストは必要ないように見えますが、ドキュメント入力オプションがさまざまであるため、Warehouseフィールドは異なる値を取ることができます。 結局、ドキュメントをコピーするか、ユーザーにデフォルト設定で指定された別の会社があり、フィルターで選択された倉庫はその組織単位ではありません。 何らかの方法で、テストは次のようになります（チームに外国人がいるため、テスター自体は英語で書かれており、問題のアプリケーションソリューションはアメリカのクライアント向けです）。
上は開発中のアプリケーション、下はテスターです。シンクライアントモードでは、テストデータベースはクラウド内にあります。 表示されるコードは1Cで書かれています。 スクリプトコードは、テスト中の1Cアプリケーションのメソッドのラッパーを介して実行中のクライアントアプリケーションと対話します。たとえば、これはChoose（...）メソッドの外観です。
ほとんどすべてのインターフェイス操作をテスターに実装しようとしましたが、何か特定のものであっても、テスト対象のフィールドのオブジェクトをいつでも取得し、テスト対象のアプリケーションのモデルに実装されたメソッドを実行できます。
さらに興味深いシナリオに移ります。
テスト関係
前の例のように、アセンブルドキュメントを作成および実行するためのシナリオを開発するために、多くの追加データが必要です：必要なディレクトリの構成、倉庫内の材料の残り、少なくとも何らかの種類の到着の存在を意味します。 前に述べたように、参照ベースが存在しない条件下でテストを実行することを決定しました。アプリケーションの初期イメージのみがあり、管理権限、塗りつぶされた分類子、および快適な初期作業のためのデフォルト値を持つユーザーが少なくとも1人います。ユーザー。
ただし、必要な「途中」のデータをすべて作成するスクリプトを毎回作成するのは非効率的です。 私は、何かを行う方法を知っているだけでなく、パラメータを受け入れるパラメータ化されたテストを開発したいと思います。 たとえば、データベースにレシートを作成するには、そのためのレシートを作成するテストが必要です。 そして、このテストをパラメーター化して、それに到着する日付、倉庫、来るべき材料/サービスなど、必要なすべてのデータを転送することを妨げるものは何もありません。 次に、教区を作成するテストでは、テストを使用して、倉庫、梱包のタイプ、タイプ、変換係数などのパラメーターで予想される材料を作成します。
私たちのアプリケーションは曇っていて、テストデータベースが統一されているため、テストを開発する各プログラマーは、テストを直接作成するプロセスでパラメーター化し、他のプログラマーが広く使用できるようにします。
以下は、入学のための組み立てテストの準備方法の例です。
（価格、合計、数量は文字列の形式で設定され、異なるロケールで実行されているかどうかをチェックするときに誤検知の問題を回避します。たとえば、トライアドと小数部の区切りが異なる場合があります）
このテストを実行する過程で、他の一連のテストが実行され、アセンブリ自体をテストするために必要なすべてが作成されます。 データベースに結果として生じるものは大体次のとおりです。
ビジネスロジックテスト
すべてのボタンが「クリック」され、フィールドが「選択」されたという事実に加えて、文書処理メカニズムの結果をテストし、データベースの現在の会計状況を評価しなかった場合、テストイベントは心に深い傷を残します。
私は長い間、リファレンスベースなしでそれを実装する方が良いのではないかと思っていましたが、それは簡単で簡単です。 レポートのテストと併せてドキュメントの動きを確認する以上のことは思いつきません。
テストアプリケーションでのドキュメントの移動に関するレポートの例を次に示します。
テスターがこれらの動きをテストする方法は次のとおりです。
赤い領域は検証に重要です。 領域に加えて、テスターでは、テンプレートに従ってフィールドのチェックを設定できます。
型チェック
多くの場合、同じタイプのオブジェクトをチェックするタスクがあります。 たとえば、半分の場合、ドキュメントフォームには表形式のセクションがあり、行のコピー、最初の行の削除、または最初の行以降の入力と入力の拒否時にソフトウェアエラーがよく発生します。 この目的のために、独立したスクリプトを持たず、ローカルコールにのみ使用されるテストメソッドを開発することができます。 これは非常に便利です。時間が経つにつれて、他のテスト要素を追加することでそのようなテストを増やすことができ、そのようなテストの広範な使用によるアプリケーションカバレッジの自動拡張が必要になるからです。
エラー制御
制御したいエラーには少なくとも3つのタイプがあります。 最初のタイプは、ゼロによる除算、存在しないプロパティまたはメソッドへのアクセスなどのコーディングエラーです。 2番目のタイプのエラーは、ロジックのエラーです。たとえば、ボタンをクリックするとフォームが閉じますが、これは発生しません。またはチェックすると、フォームの一部がアクセス不能または非表示になります。 また、3番目のタイプのエラーであるビジネスロジックのエラーは、たとえば、倉庫から資材を償却するとき、データベースからその存在を判断できませんでした。 テスターの3種類のエラーはすべて解決できます。 トリガーされると、テスターは例外をログに記録し、ログに書き込み、たとえば次のようにコールスタックを表示できます。
多数のビジネスロジックエラー処理メソッドも実装されています。 たとえば、テストで意図的にさらに資料を削除したい場合、メッセージが正しく形成されるかどうか、およびメッセージがまったく形成されるかどうかを確認する必要があります。
テストの1つでこのようなチェックを実装する例を次に示します。
要素ツリー分析
テスターは、テスト対象のアプリケーションのビジュアルオブジェクトを読み取ることができます。 これは便利であり、スクリプトの記述に必要な場合があります。特に、ボタンの名前がユーザーの言語に依存する多言語ソリューションの場合は、内部識別子を使用してインターフェイスを処理する必要があります（もちろん、ボタンの碑文の構文をチェックするタスクがない限り）。 テスターが読み取りデータを提示する方法の例を次に示します。
おわりに
一般に、1Cプログラマーを支援するために小さな自転車になりました。 プログラムの良い点として、次の点に注意してください。
- テスターのインストールと構成は簡単です。
- 最初はマルチユーザーです（ユーザーはテスター、管理サブシステムでも作成されます）
- テストを書くのに特別な知識は必要ありません
- 複雑なビジネスロジックシナリオを実装できます。
- 1つのデータベース内のさまざまなプロジェクトで数千のテストを保持し、それらを「再利用」できます。 たとえば、すべてのプロジェクトに共通のテストを作成して、リスト内のドキュメントを番号で検索できます。 または、既にテストが行われている標準ソリューションに基づいてクライアントベースが実装されている場合、すべての親テストとクライアント用に特別に設計されたテストを呼び出すことにより、クライアントベースを確認できます。
そしてもちろん、まだ多くは実装されていません。
- テスト実行スケジュールなし
- テスト結果に関する高度な分析システム、グラフ、レポートはありません
- ニュースレターと通知は自動的に実装されません。
- リポジトリーとバージョン付きテストとの接続はありません
テスターはオープンで無料であり、8.3.8から実行することをお勧めしますが、互換モードを有効にすると8.3.7でも動作します。 内部には少しの助けがあります（インターネットから送られます）。メソッドのラッパーもロシア語です。dt-shnikはここからダウンロードできます 。 アカウンティングビルディング3.0にはいくつかの例があります。
テストの友達と頑張ってください、あなたの注意に感謝します！