自動化テストフレームワーク:テストプログラミングフレームワーク

何をするにも、あなたのユーザーが誰なのか覚えておいてください.フレームワークを設計して、あなたのユーザーの使用需要が何なのかを知っておくと、フレームワークの設計が受け入れられやすくなり、成功までさらに進みます.
フレームワークのユーザーはテスト担当者です.テスト担当者の特徴は次のとおりです.

業務に精通または精通している

プログラム要素は知っていますが、プログラム構造は知りません.

細部の実現はさらに洞察しにくい

したがって,設計初期には,コントロールのアクセスをカプセル化することが考えられる.テスト担当者にとって、すべてのコントロールはカプセル化されており、呼び出すだけでいいです.
この点は,すでに初歩的に問題を解決したはずだ.しかし、私たちはそれを満たしていません.
テストでは、ビジネス要素を理解していますが、コントロールをプログラミング要素にカプセル化するのが一般的です.これは違います.例を挙げます.
インタフェースのプログラミングでは、btnOkというボタンコントロールに名前を付け、タイトルは「OK」です.プログラマーにとってbtnOkは自然な識別名である可能性があり、テストにとって「確定」はかえって自然な選択である.
最後にプログラミングされたコードをテストするには、DSL(domain-specific language分野記述言語)に近づくべきだと考えています.いくつかの方法があるかもしれません.

設定テキスト(タイトル編集ボックス、「新しいタイトル」)

タイトル編集ボックス.設定テキスト(「新しいタイトル」)

VCLのコントロールパッケージポリシーを採用しているので、インタフェースのアクセス方式(使用.方式)を使用して、テスト担当者にインタフェースを開放する傾向があります.この点で同僚と論争したことがある.しかし、その後、テスト担当者に簡単な調査を行ったところ、2つ目の方法は受け入れられることが分かった.
次の考慮問題は、これらのコントロールのアクセスコードが、どのようにテストに書かれたのかということです.最も直接考えられる方法は、フォームを遍歴することによって、各コントロールにアクセスすることによって、一つずつコードにカプセル化することで、テストはこの複雑なコードの作成に関心を持つ必要はありません.
例:

  
  
  
  

   
   
   
   
TMyFormTestCase=class 
   
   
   
   
private  
   
   
   
   
  FEdit1: IEdit;  
   
   
   
   
public  
   
   
   
   
  property Edit: IEdit read FEdit1;  
   
   
   
   
  procedure DoTestCase; override;  
   
   
   
   
end; 
  
  
  
  

ここでDoTestCaseは、ビジネス機能を本格的に完成させる仮想関数です.上書きにより、実際のビジネスコードを完了します.プロパティEditは、テスト担当者に直接カプセル化されます.しかし、ビジネスコードと私たちが自動的に生成したコードが混在していることに気づきました.これには2つのデメリットがあります.

が自動的に生成したコードは、作成したコードと混合処理する必要がある.自動化の可能性を低減します.

の両者が混合され、実際にはテスト学習のコストが増加した.逆に、隔離すれば、アプリケーションを簡単にすることができる.

この2つの欠点は、フォームごとにベースクラスを構築し、このベースクラスですべてのコントロールの定義とアクセスを完了することを決定します.これらのコントロールをすべてクラスにカプセル化し、1つのユニットに集中します.各クラス、1つのユニットも考えたことがありますが、複雑すぎる感じがします.必要もない.
この中にはもう一つの使いやすさの問題があります.これは第1編で述べたコンポーネントアーキテクチャと関係がある.もし私たちのテストビジネスコードがメインプログラムと混ざっていたら、テスト担当者にとって、

ビジネステストコード

をデバッグするには、プライマリ・プログラム・コードがある必要があります.

プログラムコードも、彼らの負担になります

また,プログラムコードのカプセル化の観点から,破壊される可能性もある.したがって、すべてのビジネスコードを独立したDllにカプセル化することにした.また、Dllのプログラムコードへの依存性を低減するために、コントロールへのアクセスは、IEdit、Itorm、IButtonなどの対応するインタフェースによってアクセスされ、これらのインタフェースのオブジェクトインスタンスの作成は、プログラムコードに残ることができる(これは、拡張を容易にするためである).
フレームワーク全体の過程で、いくつかの重要な問題があります.1つ目は、コントロール名の名前の問題です.本来はコントロールの属性で生成されるかもしれませんが、EditコントロールやGridコントロールなど、必ずしも中国語の情報があるとは限りません.だから辞書表の方式を支持して翻訳をします.まずコントロールNameをラクダの命名法に従って分離し、それらの略語または単語を対応するテーブルに移動し、中国語の解釈を検索し、最後に組み合わせて名前と呼ぶ.
また、ビジネスプロセスのログの問題です.この実装は,後にAOPモードを採用した.具体的な実現構想は、後で専門的に紹介されます.
もちろん、実際の応用では、他にも多くの問題がある可能性があります.これらはすべて細かく解決しなければならない.一言で言えば、ユーザーの気持ちを十分に考えているので、この部分のフレームワークは、変更したり変更したりして、今やっと少し満足しています.