自動テストフレームワークのアイデアを簡単に共有

序文：

テストフレームワークの階層化

ツールレイヤー

序文：

自動テストフレームワークは、自動テストのプロセスとリソースを編成および管理するための構造化されたアプローチです。テストチームが自動テストスクリプトをより効率的に作成、実行、保守できるようにする一連の仕様とツールを提供します。

テストフレームワークの階層化

完全なテストフレームワークとはどのようなものですか?

例えばappiumのテストケースを書く場合、Demoだけをやる場合はWebDriver APIを直接使って書くことになります。現時点でのユースケースは次のようになります。

import os
from time import sleep
from appium import webdriver

if __name__ == '__main__':
    # Returns abs path relative to this file and not cwd
    PATH = lambda p: os.path.abspath(
        os.path.join(os.path.dirname(__file__), p)
    )

    # init driver, open session
    desired_caps = {}
    desired_caps['platformName'] = 'Android'
    desired_caps['platformVersion'] = '4.2'
    desired_caps['deviceName'] = 'Android Emulator'
    desired_caps['app'] = PATH(
        '../../../sample-code/apps/ApiDemos/bin/ApiDemos-debug.apk'
    )

    driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)

    # execute some action
    els = driver.find_elements_by_android_uiautomator("new UiSelector().clickable(true)")

    # check if result is as expected
    if len(els) != 12:
        print "Case Failed. There should be 12 elements but only {} elements exist".format(len(els))
    else:
        print "Case Passed."
     # end the session
    driver.quit()

次に、ユースケースの数が比較的多く、そのたびに appium を起動するのは面倒で、テスト結果が十分ではないため、setUp、tearDown、またはテストレポートを使用して、いくつかの単体テストフレームワークを使用し始めます。この時点でのユースケースは次のようになります。

import os
from time import sleep

import unittest

from appium import webdriver

# Returns abs path relative to this file and not cwd
PATH = lambda p: os.path.abspath(
    os.path.join(os.path.dirname(__file__), p)
)

class SimpleAndroidTests(unittest.TestCase):
    def setUp(self):
        desired_caps = {}
        desired_caps['platformName'] = 'Android'
        desired_caps['platformVersion'] = '4.2'
        desired_caps['deviceName'] = 'Android Emulator'
        desired_caps['app'] = PATH(
            '../../../sample-code/apps/ApiDemos/bin/ApiDemos-debug.apk'
        )

        self.driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)

    def tearDown(self):
        # end the session
        self.driver.quit()

    def test_check_clickable_element_count(self):

        els = self.driver.find_elements_by_android_uiautomator("new UiSelector().clickable(true)")
        self.assertEqual(12, len(els))

if __name__ == '__main__':
    suite = unittest.TestLoader().loadTestsFromTestCase(SimpleAndroidTests)
    unittest.TextTestRunner(verbosity=2).run(suite)

後でさらにユースケースを書くことになりますが、自動テストを行う少数の人だけでは耐えられないため、技術にそれほど強くない一部の人に自動テストを行わせる必要があります。フレームワークを台無しにすることなくユースケースを使いやすくするために、ユースケースを再パッケージ化してテーブルまたは BDD に作成します。これにより、コードの作成方法を知らない人でも簡単に記述したり読み取ったりできるようになります。この時点で、ユースケースは次のようになります (Cucumber):

Feature: Simple android test
  Do some sample operations with android application

  Scenario: Check clickable element count
    When I opened the application
    Then 12 clickable buttons should occur

これら 3 つのステップは、実際にはテストフレームワークの 3 つのレベル、つまりツール層 (appium など)、コア層 (単体テストフレームワークなど)、およびアダプテーション層 (BDD フレームワークなど) に対応しています。

ツールレイヤー

ツール層は主に、対応する側でのテスト実行のアクショントリガーを担当します。（原文は書籍内）

まず、テスト済みのプログラムをプログラムを通じて制御したい場合は、対応するツールが必要です。これらのツールを使用すると、他のツールでは実現が困難または不可能な制御が可能になるだけでなく、実現が容易になります。たとえば、iOS の UIAutomation。存在しない場合は、アプリケーションにいくつかのエージェント (MonkeyTalk など) を追加するか、テストコード (KIF など) をアプリケーションに直接追加するか、インターフェイスを通じてプログラムを制御できるテストツールのセットを作成する必要があります。。これらのツールを使用すると、時間を大幅に節約でき、テスト部分を機能部分から分離することが容易になります。

ツール層には、モバイルテスト用の Appium、robotium、espresso など、Web テスト用の Selenium など、多くのフレームワークがあります。

コア層

コア層は、テストの実行と結果の監視とフィードバックの推進を担当します。（原文は書籍内）

実際、自動テストプログラムにはいくつかの共通点があり、たとえば、豊富なアサーション関数のサポートが必要で、そうでない場合はさまざまな If..else... しか記述できず、検証と実行のステップが結合されています。これがコア層のフレームワークの役割であり、自動テストプログラムなどのプログラムの最も一般的な機能（たとえば、特別な例外が失敗に対応する必要がある、さまざまな柔軟で便利なアサーションを作成する必要がある、前提条件が必要であるなど）を抽出します。特殊関数) を作成し、それらを比較的固定された書き方でカプセル化します。

たとえば、ほとんどのユースケースには前提条件があり (たとえば、Web ユースケースではブラウザーが開いている必要があります)、反復性が高く、ブロックの特性があります (ブラウザーが開かれていない場合、後続のステップは実行されません)。実行されます）。次に、コア層フレームワークは特別なメソッド (一般的なメソッドは setUp と呼ばれます) を提供し、ユースケースのコンテンツを実行する前にこのメソッドを実行して適切な前提条件を作成し、このメソッドが失敗した場合や、このメソッドが失敗した場合にユースケース全体を自動的に配置します。失敗失敗またはブロックとしてマークします。

コア層には、さまざまな単体テストフレームワーク (JUnit、OCUnit など)、Testng など、多くのフレームワークもあります。一般的には、ツール層で使用するフレームワークを選択した後、使用する言語が決定するため、ツール層が決定してからコア層で使用するフレームワークを選択するのが一般的です。言語に一貫性がない場合は、通話を容易にするために適切な二次開発が必要です。もちろん、appium/selenium のような複数の言語をサポートするツール層フレームワークは、コア層フレームワークをより柔軟に選択できることも人気の重要な理由です。

アダプテーション層

アダプテーション層は、再利用可能なテストメソッドパッケージの適応を担当します。（原文は書籍内）

ユースケースがある程度の大きさ（数十、数百）に達すると、繰り返し部分がうまく抽出されなかったり、より適切な形で記述されなかったりすると、ある程度の冗長なコードが発生します。現時点で、アダプテーション層の役割は、ユースケースを作成する人がより迅速にユースケースを書き込み/読み取りできるように、これらの繰り返しメソッドをより適切にカプセル化することです。

私たちがよく耳にするデータ駆動型、キーワード駆動型、行動駆動型 (BDD) のほとんどは、この層に属します。どのドライバーが使用されても、特定のテストプログラム/テストドメインとは何の関係もないからです。BDD は Android アプリケーションのテストにのみ使用できる、またはデータドライバーは Java でのみ記述できるとは言えません。これらの xx ドライバーは主にアイデアであり、実際に使いやすく実用的で、多くのツールから選択できるユースケースを作成するアイデアです。もちろん、使用するツールが異なるため、使用する言語にも一定の制限がありますが、考え方は同じです。

アダプテーション層には、BDD のキーワード駆動ロボットフレームワークである Cucumber などのさまざまなフレームワークもあります (完全で実用的なテストフレームワークであるコア層とツール層もあり、ツール層は拡張された形式になっています)ライブラリが提供されており、さまざまなソフトウェア分野に適応するために拡張するのが非常に簡単なので、学ぶ価値があります)。アダプテーション層の記述方法はおそらく特定のプログラミング言語に属さないため (言語から分離されたテーブル形式を使用したキーワード駆動など)、アダプテーション層のフレームワークのほとんどには対応するメソッドがあります。コア層/ツール層フレームワークは統合的なサポートを提供します。

簡単な例

ロボットフレームワークを使ったことがある人は多いと思います。これは、次の 3 つの層を備えた完全なテストフレームワークです。

アダプテーション層: ユースケースは主にキーワード駆動の tsv 形式で記述されます。
コア層：setUpメソッドとtearDownメソッドを提供し、適切かつ十分なアサーション機能と例外キャプチャ機能を備えています。
ツール層: 選択できるライブラリが多数あり、さまざまなツールと組み合わせて、さまざまな分野でソフトウェアをテストできます。

別の簡単な例

別の例は、キーワード駆動フレームワークの実装です。

アダプテーション層: 表形式で提示されるユースケース、およびユースケースを実行可能コードに変換するコンバーター:

シート:

アクション	パラメータ
ブラウザを開く	ブラウザ名 = "Chrome"

変換されたコード:

class TestCase(ActionBase, unittest.TestCase):

    # a test case
    def open_browser(self):
        # step of test case
        self.action_call("openBrowser", {"browserName":"Chrome"})

次に、この action_call の実装は、対応するアクションメソッドを呼び出して実際のアクションを実行します。

class ActionBase:
    ...
    def action_call(action_name, params):

        # get action function in this class
        action_fun = getattr(self, action_name)

        # execute action
        action_fun(**kwargs)

    ...
    def openBrowser(browserName=None):
        if browserName == 'Chrome':
            self.driver = webdriver.Chrome()
        ...

コア層: 変換されたコードは単体テストフレームワークを使用してユースケースの実行を管理します。

ツール層: アクションが実際に実行されるときに Selenium フレームワークが使用されます

ここに来た者として、皆さんも寄り道は避けていただきたいと思います。

ここでは、自動テストを進める上で必要なことをいくつか共有し、お役に立てれば幸いです。

（ソフトウェアテスト関連資料、自動テスト関連資料、技術的なQ&Aなど）

そうすることでより良い進歩が見込めると信じています！

下の小さなカードをクリックしてください