In the context of automated testing, you often hear the term data-driven, which loosely refers to automated use case execution driven by test data. Other relevant believe already familiar, here not much said, today to share a time called the countless according to drive, the main idea is to cancel the data in the test case introduction, the main test data maintenance in automated test cases, save the cost and improve the robustness of use cases.

The goal of data-driven automated testing is to write test cases that run indefinitely with minimal data input to reduce maintenance.

The following example is a test case consisting of a product selling interface and related interfaces. This interface purchases a header interface, the main parameters gid, PID, in this use case written dead, how much I forget, three years ago code, it is not easy to find out. The main business logic is very simple, the purchase is successful (valid for 30 days, natural days), then the value of the response is increased in the attribute, the balance is reduced in the value of the response, and by the way, the purchase will give away another seven days of validity for the header.

	/** * Purchase monthly card use case */
	public void testDemo001(a) {
		String label = "Purchase monthly Card use case" + TAB + Thread.currentThread().getStackTrace()[1];
		Headgear headgear = new Headgear(base);
		Long aLong = headgear.getHeadgearInfo().get(27);
		int balance = NajmBase.getUserBalance(drive.user_id);
		long deadTime = drive.getDeadTime();
		Verify verify = new Verify(drive.bugMonthCard(gid, pid));
		int balance1 = NajmBase.getUserBalance(drive.user_id);
		long deadTime1 = drive.getDeadTime();
		Long aLong1 = headgear.getHeadgearInfo().get(27);
		JSONObject result = new JSONObject();
		result.put("Status code is 0", verify.isRight());
		result.put("Decrease in amount of users", balance - balance1 == 2000);
		result.put("Increased validity of user's monthly card", deadTime1 - deadTime == 30 * DAY);
		result.put("It is normal for users to donate headsets", aLong1 - aLong == 7 * DAY);
		MySqlTest.saveTestResult(label, result);
	}
Copy the code

For more on why tests look the way they do, check out the FunTester testing framework:

  • GiteeaddressGitee.com/fanapi/test…
  • GitHubaddressGithub.com/JunManYuanL…

At the end, I’ll show a video of the FunTester testing framework, which is a little early and missing some of the new features, especially in terms of performance testing. Refer to my previous article on performance testing.

In the test case above, I first created a New User-based business module class Headgear object in order to complete the interface calls in the following module. I also wrote some static methods in the base class NajmBase, which is supposed to be a separate tool class for a single project, three years ago. The driver object, which is the base driver object of the use case class, is also a module object used to make interface calls to the module. Since the current class is the use case class of the module, a public static object is made.

The use-case method logic here is easier to understand: The first step is to obtain the expiration date of the user’s account balance from the personal headers information center, and then obtain the user’s account balance. Then the user purchases the header with the specified ID. Then save the response object, convert the response into a general verification object, and obtain the expiration date of the header with id 27. Finally, business judgment is made based on the previously saved objects and data information.

Of course, all use cases need to be setup and setdown. This use case needs to maintain several items of data.

  • ID forgid, pidtheheaderThe validation exists, and the user executing the use case must ensure that the initialization is purchased and expires, which is not difficult to do.
  • ID forgid, pidThe price is constant at2000, and execute the use case user balance to be greater than this number before purchase, which is not difficult to do, insetupIt can be done in China.
  • ID forgid, pidtheheaderValid for 30 days. ComplimentaryheaderID for27The base property of thegid, pidtheheaderAll the properties remain stable.
  • It’s also easy to keep track of business changes.

It takes a lot of time to design and maintain the information corresponding to parameters such as GID and PID, as well as the user amount.

Later, all these information can be optimized out, there is no need to set a fixed GID, PID does not need to verify the validity period, can be obtained from the header information interface. In this way, the GID and PID are not required, the price of 2000 is not required, the validity period of 30 days and 7 days is not required, and the complimentary header with ID 27 is not required (it depends on whether the business interface provides the complimentary rule).

In the actual operation, almost no problems due to the automation of use cases, basically achieve write once, Run Everywhere! .

Almost that time the reason is as follows: what will happen if the membership continues for 100 years, and the use case execution warning caused by this will be adjusted for later.

Although not perfect, enough to express my ideas!

Here is a video explanation of the testing framework:

Interface Test video

  • FunTester Test Framework
  • Get HTTP Request objects – Test framework video tutorial
  • Send requests and parse responses – Test frame video interpretation
  • Basic operations on JSON objects – video tutorial
  • GET Request Practices – Test framework video tutorial
  • POST request Practices – Video demonstration
  • How to handle headers and cookies — video demo
  • FunRequest class functionality – video presentation
  • Interface test business validation – video demonstration
  • Basics of automated Test projects – Video tutorials
  • JSONArray Basic Operations – video demonstration
  • Automated Project base Class practices – video demonstrations
  • Module classes and automated use case practices — video demonstration
  • Performance Framework multithreaded base classes and execution classes – video tutorial
  • Timing and quantitative pressure measurement mode implementation – video explanation
  • Multithreading implementation class based on HTTP request – video explanation
FunTester, non-famous test development, the article records learning and comprehension, welcome to pay attention to, exchange growth.

FunTester hot text selection

  • Bind mobile phone number performance test
  • Fixed QPS pressure test
  • Output test data graphically in performance tests
  • Groovy uses topics in JMeter
  • Client encapsulation based on WebSocket
  • Client encapsulation based on socket. IO
  • Socket.IO interface multi-user testing practice
  • Java and Groovy re usage
  • How to record each time-consuming request in the link pressure test
  • JSON objects mark syntax validation classes