データ駆動テスト設計パターン

Priscila逮捕によって－2020年3月2日
真新しいプロジェクトにおけるデータ駆動テスト設計パターンを用いた成功物語
あなたがテスターであり、あなたが真新しいプロジェクトに取り組んでいるとき、私は、私たちは、私たちが新しいものを学んで使用することができる将来の時間を節約することができる完全に自動化されたテストフレームワークを作成するという考えが好きであると思います.
しかし、現実の生活では、我々は常に手動テストケースを取り除くことはできません、それ以外に、アジャイル方法に従うブランドの新しいプロジェクトの自動テストケースを作成する.すべての必要なテストスクリプトを開発するのに必要な努力がすべてのスプリントの間の一定の変化とコード安定性をチェックするためにまだ必要とされる手動テストの他に巨大であるので、時々ほとんど圧倒的でありえます.
時々、あなたが1つのスクリプトでされると思うとき、突然ユーザーが新しい分野を必要とする新しい物語があります、そして、この一つのフィールドはいくつかのテスト/テストスクリプトを修正することを意味します.
私のチームと私は現在アジャイル方法を使用して常に進化しているブランドの新しいプロジェクトに取り組んでいますので、我々は、ゼロから自動化されたテストスクリプトを作成する必要がありました.我々はまた、ユーザーストーリーの変更がある場合、それは我々が既に持っているテストスクリプトの完全な再加工を意味していない方法でそれらを設計するためのより良い方法を見つけたかった.
データ駆動テスト設計を入力します.
では、どのようにデータ駆動テスト設計を使用していますか?基本的に、テストスクリプトの入力としてテストデータファイルがあります.テストスクリプトは、コード内で指定されたすべてのアクション/手順をデータ入力ファイルからデータを使用します.その後、実際の結果を取得し、期待結果と比較します.一旦比較が行われると、それはファイル(行/payload)から以下のデータ入力で続きます.

テストスクリプトによるデータの流れ
このパターンに従う利点のいくつかは以下の通りです.

You can have more test coverage because while you are creating the data file you will  have a better visualization of what have you already included and this will help you to identify if you are missing any test scenario.
Scripts and functions can be reused in different tests and also be combined with multiple data files which give us a wide variety of test scenarios with less test scripts.
Test scripts will run faster because  most of the time with one single test you can cover positive and negative scenarios by just changing the expected result in our data file
Maintenance of our test scripts is easier, because if we are using one scripts which is testing both positive and negative test cases and there is a story in the future which implies that a field is no longer required, instead of making the changes in several scripts we only change one script and remove the field form the data file.
Data setup required for the test execution can be also included in your data file and created inside your test script.
And the more important reason for us is that there is not hardcoded data in your test scripts, since you have the test data in a separate file. Changes to the scripts do not affect test data and vice versa.

私たちのために働いているデータファイルを作成するときの一般的な推奨事項

The easiest way to visualize your data file, if you don’t know where to start, is every row/payload  from your input data file will be map to a test case. You can add a row/payload with the data required for every test case that you will usually create. So, if you have one test script that is using a CSV file with 30 rows you will be testing 30 test combinations with a single script.
Add every element/attribute/field  as parameter, so you can use the same data file for several test scenarios.
Use element/attribute/field names related to the parameter you are going to replace so everyone who is checking your script understands it.
In case of API testing If you have a field that is an array, add a field for every element you will add in the array  including the comas, so you are not forced to always enter the same array length.
In case of API testing if you want  to cover scenarios like validating the response code 404 or checking Authorization header , you can add an URL field so you can test the response code 404 and a field with the Authorization so you can test as many combinations as possible.
Use a field to describe your test scope, so you don’t forget what that payload or line was for.
Add a field with the expected result. It can be a response code if you are testing an API or the text of a message if you are testing UI. If you do so, you can have both positive and negative tests in the same data file.

現在のプロジェクトでは、次のテストスクリプトを作成しています.

テストスクリプトの階層的組織化

The first try was using Jmeter (which we are using for API Testing and Performance test). We started using it for REST API testing because there is a lot of documentation on how to use it, it is simple to use, easy to learn and it has all these “plugin controllers” that can be used to create your script.  So, by using the CSV controller you can create a script using parameters and with a single script test positive and negative test in most of the cases. The only cons that we found were that if your payload is big is not that easy to visualize your CSV data file and you need a tool to separate the field by columns because if you try to use a regular text editor it can become a nightmare (and sometimes even with the columns you have to scroll your window).  I also use a column for the test scope, so you can remember in the future what was the intention of that test.
Since our brand-new project also has a UI and is developed in Angular then we started reviewing Protractor which was designed especially for angular and uses Webdriver and we were already familiar with Selenium. I created some test scripts and the transition from Selenium to Protractor was smooth and  it works very nicely and started designing our test using a JSON file as our data input adding all the required fields for ou test scripts and also a field for the test scope so we don’t forget what is the test intention of the payload (Recommendation when using protractor to make your scripts easier to maintain separate your page object from your spec, and create a helper file that contain all the functions required to your script to run like click, add text into a text field, function to read the data file, etc.)
In my experience I like using JSON files rather than CSV files as data files, at least for me it is easier to read, it looks cleaner and more organized.
For these reasons I wanted to try another tool to create REST API test scripts using JSON files so last year I attended to the automation Guild and there was a conference about Inuit Karate, which is kind of new, it uses Gherkins syntax, so it is not hard to learn, and I wanted to give it a try. I started creating integration tests and I like it because with the JSON file my data file looks clean and with the Gherkins syntax, code is easier to understand.
Besides the already mentioned tools we  have also created some other tools based on a data driven test design pattern. We have some python and java script for example one to analyze the test results based on a CSV file or another to create JWT tokens based on a JSON file.

それで、私はすでにデータ駆動テスト設計の後で見つかる利点のいくらかに言及します.
私の観点から不利な点がありますか.はい、配列のフィールドを持っている場合、データファイルに指定しなければならず、配列の長さは常に同じです.また、データファイルを作成することは、常にCSVファイルで最も特別に楽しむ活動ではありません.なぜなら、ファイル内のすべてのテストシナリオを持っているので、スクリプトを作成しているときに、より多くの時間を費やしているアクティビティの1つです.それについての良いニュースは、すべての変更を必要とする場合、それはマイナーな変更が必要な場合は、ファイル全体を一度と時間のほとんどを作成する必要があります.
これを緩和する方法はありますか?はい、テストスクリプトを作成することでこれを緩和しようとしています.これはテストデータを作成し、配列の問題も解決します.我々はまだそこにはありませんが、うまくいけば、我々はそれが動作するようにうまくいけば、テストを作成過ごす時間が削減され、我々の全体のプロセスがより効率的になります.
上記のすべての長所と短所を考慮に入れて:データ駆動テストは、我々のユースケースのための良い選択でした、我々は速く前進することができて、我々の命をより簡単にしました.DDTの特典の1つは、一旦モジュールが完全に自動化されたならば、より多くのテストケースがテストデータを加えるだけの問題であるということです.
では、次は何ですか?手動でデータを作成するのではなく、必要なテストデータを作成するのに役立つスクリプトの作成に取り組んでいます.