Clever Geek Handbook

uniset2-testsuiteの概要-機能テスト用の小さなバイク





libuniset2の作業の自然な継続として、 uniset2-testsuiteプロジェクトが発生しました。 これは機能テスト用のあなた自身の小さなバイクです。 その結果、彼は「プラグイン」を使用して多かれ少なかれ普遍的なソリューションを開発しました。 Pythonで書かれています。 読書に興味があるなら、どうぞ...入ってください。



uniset2-testsuiteで定義されたテストの基本的な考え方は単純です： 「彼らは効果を適用し、反応をチェックしました 。 」 この抽象的なアイデアは、最終的に次の成果物に具体化されました。



テストシナリオ



テストスクリプトは、一連のテストを記録するxmlファイルです。 各テストは、順番に「アクション」（アクション）とチェック（チェック）に分けられます。 テストは他のテストを呼び出すことができ、さらに、他のファイルにあるテストを呼び出すことができます。 これにより、非常に複雑で重量のあるテストシーケンスを構築し、共通部分を個別のファイルに配置し、「プロシージャとして」呼び出すことができます。 さらに、置換メカニズムがサポートされています。これにより、テストが呼び出されたときに特定の変数に置換される「変数」の抽象的な名前を持つテストパターンを作成できます。



アクション



次の3種類のアクションがサポートされています。





説明する特別なものはありません。 以下の例が見られます。



チェック





ここでは、すべてが多かれ少なかれ明らかです。



その結果、単純なテストシナリオの形式は次のとおりです。 



<?xml version = '1.0' encoding = 'utf-8'?> <TestScenario> <Config> ... </Config> <TestList type="uniset"> <test name="Processing" comment="  "> <action set="OnControl_S=1" comment="  ' '"/> <check test="CmdLoad_C=1" comment="  ''"/> <check test="CmdUnload_C=0" comment="  ''"/> <check test="Level_AS>=90" comment=" .." timeout="15000"/> <check test="CmdLoad_C=0" comment="  ''"/> <check test="CmdUnload_C=1" comment="  ''"/> <check test="Level_AS<=10" comment=" .." timeout="15000"/> </test> <test name="Stopped" comment="  "> <action set="OnControl_S=0" comment="  ' '"/> <check test="CmdLoad_C=0" comment=" ''  " holdtime="3000"/> <check test="CmdUnload_C=0" comment=" ''  " holdtime="3000"/> <check test="Level_AS<=80" comment="  " holdtime="10000"/> </test> </TestList> </TestScenario>


上記の例からわかるように。 アクションはタグとして記録されます。 



 <action set="..."/>


小切手は 



 <check test=".."/>


テストプレイヤー



スクリプトがある場合、誰かがそれを実行する必要があります。 最初は、独自の「プレーヤー」を作成できるシステムを作成したいという要望がありました。各プレーヤーは独自のスクリプト形式を持つことができました。 しかし、最終的には、 xmlが形式として選択されたため、 uniset2-testsuite-xmlplayerがそれに応じて作成されました。 xmlスクリプトを実行するコンソールプレーヤー。 そして、物事はうまくいきませんでした。なぜなら、xml-formatは非常に成功し、xmlplayerは現在のすべての問題を解決するのに十分だったからです。 リポジトリ自体にはまだuniset2-testsuite-gtkplayerがありますが、python-gtkで書かれたGUIプレーヤーです。 しかし、ある時点での開発は不要であるため凍結され、多くの機能をサポートしていません。



合計すると、アクションとチェックで構成されるスクリプトがあり、スクリプトを実行するプレーヤーがあることがわかりました。 これをすべて実行すると、出力には次のようなものが表示されます。







ちょっとした背景...



当初、uniset2-testsuiteはlibunisetとの連携の一環としてのみ考えられていました。その基本概念は「すべてがセンサー」です。 したがって、記録形式は、センサー識別子（数値または名前）を使用して動作し、数値のみ（整数）をチェックすることを意味します。 しかし、徐々に開発され、modbusプロトコル（ type = "modbus" ）を介して通信する機能が追加され、最近snmp（ type = "snmp" ）を介して機能する機能が追加されました。 そして最終的に、テスト用のインターフェースを2つの主な関数GETとSETに減らすことができることがより明らかになりました。 つまり システムをテストするには、 get_value（id）とset_value（id、value）の 2つの関数を実装するだけで十分です。 また、テスト対象システムとの相互作用のプロトコルは重要ではありません。 開発者は、システムと対話するために、これらの2つの機能の実装を提供するだけです。 このアイデアは、プラグインシステムの類似物を作成するための基礎を形成しました。 つまり テストしたシステムの一部との相互作用を実装するには、特別なpythonインターフェイスを実装し、適切な場所に配置（接続）するだけで十分です。 テスト用に独自のインターフェイスを作成する方法については、第2部で説明します。 それまでの間、可能性について簡単に説明します。 それらの多くがあるので、私は主なものについて話します、あなたはドキュメントwiki.etersoft.ru/UniSet2/testsuiteで残りについて読むことができます



機能の説明



プログラムの自動起動



もちろん、テストスクリプトを実行するだけでなく、テストを開始するときにテストに必要なすべてのプログラムを実行したいと思います。 この場合、テストスクリプトでRunListセクションが提供されます。



疑似例： 



 <?xml version = '1.0' encoding = 'utf-8'?> <TestScenario> <RunList after_run_pause="5000"> <item after_run_pause="2000" script="./start_my_testprog1.sh" args="arg1 arg2" name="TestProg1"/> <item script="./start_my_testprog2.sh" args="arg1 arg2" chdir="../../TestPrograms/" name="TestProg2"/> <item script="./start_my_testprog3.sh" args="arg1 arg2" ignore_terminated="1" name="TestProg3"/> </RunList> <TestList> ..... </TestList> <TestScenario>


このセクションでは、テストを開始する前に実行する必要があるもののリストを指定できます。 起動される各プログラムについて、起動パラメータ（ args ） が示され、プログラムは他のディレクトリ（ chdir ）に存在できます。 プログラムがクラッシュした場合にログに表示される一意の名前（ name ）を指定できます。 さらに、この例からわかるように、プログラムを開始した後または一緒に一時停止を設定することもできます。 silent_mode = [0,1]を設定できます。1はすべての出力を/ dev / nullにリダイレクトすることを意味します）。 または、パラメーターlogfile =“ filename”を指定できます。このパラメーターでは、すべての出力が指定されたファイルにリダイレクトされます（silent_modeアクションをキャンセルします）。



すべてのプログラムはバックグラウンドで実行されます。 デフォルトでは、テスト中にそれらのいずれかが突然クラッシュした場合、エラーでテストが中止されます。 ただし、これはパラメータignore_terminated = "1"によって無効にできます。 テストに合格すると、実行中のプログラムはすべて終了します（成功したかどうかは関係ありません）。 つまり その結果、 RunListを使用すると、テストに必要な環境を実行できます。これは、 後で自動的に完了します。 さて、またはテストを開始する前にいくつかの準備手順を実行します。



完了時にスクリプトを実行する



uniset2-testsuiteのもう1つの可能性は、テストの成功または失敗時に指定されたスクリプト（プログラム）を実行することです。 



 <?xml version="1.0" encoding="utf-8"?> <TestScenario> <Success> <item script="./success.sh param1 param2"/> <item script="./success.sh param3 param4"/> </Success> <Failure> <item script="./failure.sh param1 param2"/> <item script="./failure.sh param3 param4"/> </Failure> .... ... </TestScenatio>


さまざまなケースで使用できます。 例（明らかなことから）：





タグ



「フルカバレッジ」を含む多数の拡散テストがある場合、1つの「論理テストブランチ」をチェックするためにすべてを実行したくない場合があります。 この問題を解決するために、「タグ」が助けになります。 各テストに1つ以上のタグをタグ付けできます。 



 ... <test name="Test3" tags="#tag1#tag2"> <check test="outlink" file="Test4.xml" link="ALL"/> </test> <test name="Test5" tags="#tag1"> <check test="outlink" file="Test6.xml" link="ALL"/> </test> <test name="Test7" tags="#tag2"> <check test="outlink" file="Test8.xml" link="ALL"/> </test> ...


また、スクリプトを実行するときに、指定したタグ--play-tags "＃tag1＃tag2＃"を使用してテストを実行するだけでよいことを指定できます。



テストツリー出力



なぜなら 他のテストや他のファイルからテストを呼び出すためのメカニズムがあり、テストのやや複雑な構造で、それらがどのように呼び出され、どのような順序で、誰が誰を呼び出すのかを見たいです。 これを行うには、画面にテストツリーを表示する特別なコマンドがあります--show-test-tree 



 Test1 Test2 Test3 Test 4 Test 5 Test 6 Test 7


さらに、このコマンドに--play-tags "＃tag1＃tag2＃"を指定すると、タグ付きのテストツリーが表示されます。 



  Test1 [#tag1] Test2 [#tag2] Test3 [#tag1]


スクリプト検証



複雑なテスト構造の重要な部分は検証です。

一部のテストにはかなり時間がかかる場合があります。 そして、テストの1時間後にタイトルの「タイプミス」に落ちたときに「“辱」します。 この問題を解決するために、2つの特別なテスト検証モードが用意されています。





チェックの実際の「実行」のこれらのモードでは、チェックはなく、一時停止とタイムアウトはありません。 つまり 正確さのために、テストとパラメーターの単純な「構文」チェックがあります。



結果は次のとおりです。







テスト出発時のコールツリー



テストの出発中にコールのトレースを表示する場合は、特別なパラメーター--print-calltraceがあります。これは、出発地から開始までのコールツリーを表示します。 深さを制限する特別なパラメーターがあります--print-calltrace-limit N



次のようになります。







テストパターン



もちろん、「テンプレート」は便利なものです。 また、uniset2-testsuiteには、このメカニズムの簡単な実装もあります。 この場合、「1つ」を「別の」に自動的に置き換える簡単な方法について説明しています。 たとえば、次のように記述します。 



 ... <test name="Check [MyVariable]" lname="tname"> .... <check test="[MyVariable]=[MyValue]"/> </test> ...


そして、さまざまなパラメーターをMyVariable 、 MyValueとしてこのテストを呼び出します 。 簡単... 



 ... <test name="Check Name1=100"> <check test="outlink" file="my-template-test.xml" link="lname=tname" replace="[MyVariable]:Name1,[MyValue]:100"/> </test> <test name="Check Name2=200"> <check test="outlink" file="my-template-test.xml" link="lname=tname" replace="[MyVariable]:Name2,[MyValue]:200"/> </test> ...


置換ルールには3つのスコープがあります。





グローバル置換は TestListセクションに登録されます 



 <TestList replace="[MyVariable]:Name2,[MyValue]:200"


テストレベルは テストセクションに登録され、このテストと、その内部で使用されるすべてのリンク、アウトリンクに対してのみ機能します。 



 <test name="MySuperTes replace="[MyVariable]:Name2,[MyValue]:200"> <check test="[MyVariable]=11"/> <check test="Othrer=[MyValue]"/> <check test="outlink" file="my-template-test.xml" link="lname=tname"/> </test>


特定のチェックのレベルは チェックセクションに登録され、リンクまたはアウトリンクテストへの特定の呼び出しでのみ動作します 



  <test name="Check Name2=200"> <check test="outlink" file="my-template-test.xml" link="lname=tname" replace="[MyVariable]:Name2,[MyValue]:200" /> </test>


この置換メカニズム（置換）は、 action 、 check 、 set 、 testタグだけでなく、 テストの名前、パラメーター、ネストされたテストの置換プロパティにも影響することに注意してください。



さて、最後に、私が言わなかったもの：





2番目の部分では、検証用に独自のインターフェイスを作成する方法を検討します。





More articles:


All Articles