Requirements and objectives:
In most automated software tests for the UI, case management issues are usually designed. When you already have a test case that has been implemented and completed, if the following two things have changed, what kind of countermeasures will you adopt? 1. Objectives Program The operation logic of is changed, such as the move or delete button; 2. the underlying implementation framework of test case has changed. If a new framework with more powerful functions is available, it is not compatible with the original framework. When considering the response policies, we mainly focus on the project time and migration cost. For question 1, the operating logic of the target program changes, without a doubt, your test case logic must also change. This is like a change in the demand of the software, and a change in the software. For question 2, we have multiple strategies to deal with such problems. Policy 1: rewrite case. This method may be practical when the test case is small, and I believe most people are using this method, however, the stability of the test case and the progress of the project time are followed. It is difficult to ensure that the test case after migration can fully meet the test requirements, as a result, we will not migrate the underlying platform without a last resort, but this also produces the coverage problem. The original underlying platform cannot cope with some special scenarios, which may lead to case omissions. Policy 2: encapsulate and establish your own testing framework. This policy is also a popular and practical method. By abstracting and encapsulating the business logic, a modular case component is generated, once the underlying layer changes, we only need to modify the underlying case components to adapt to the changes. This method is actually much better than writing in terms of implementation, and it is also suitable for large-scale test cases. However, this method still has problems. Hard coding and lack of flexible test data are big issues. First, we use both test cases Code Write and compile once without modification. Only a few simple sets of test data support the test process, and it is still difficult to migrate at the framework level. Policy 3: using test tools, there are currently many tools available for auxiliary testing, such as behavior recording playback and generating test scripts, the advantage of this tool is that it can be tested without writing the test case code. The poor part is that the controllability and adaptability are too poor, and the coverage and stability are hard to guarantee, if different resolutions are changed, the case may fail.
When we analyze the design process of test case, we find that the test logic is the most important and abstract and independent for test case, that is to say, the operation steps of the software (all tests we mentioned here are for software with UI interfaces ). Any software operation steps are fixed in a specific version, and there are many similarities in different versions. The underlying implementation platform is the least important, and many excellent platforms are emerging constantly. They may be good at solving some problems. Is there a way to save these test logic without being limited by the platform? That is, case management framework.
At the beginning, I paid great attention to the protection of the test logic when designing this framework. I found that the test logic remains unchanged. How to Adapt the underlying implementation to the test logic is a major solution of case management framework (CMF.
Analysis and Design:
To protect the test logic, we need two things: script and control lookup methods. Any test logic is composed of a series of behavioral actions. These actions can be described by a set of abstract script statements. Therefore, we need to abstract the appropriate scripts first. In the end, we need to implement any action on the control operation, so how to find the control based on the given information is the key method. Fortunately, all excellent underlying frameworks provide such a function to find the target control based on the given information. With these two tools, we have a clear goal to design CMF. Abstract A set of script statements to design the search interface. Before entering the actual design and development, we still need to consider one thing. All the tools are defective, and the CMF won't cover all the test scenarios. Then we need a method to expand it, that is, the Customer Code extension, that is, the case code. The advantage of case code is its strong flexibility and debugability. It can make up for the missing or overly complex scenario of CMF. In this way, CMF has another task, that is, it is compatible with running script case and code case.
So, the basic preliminary analysis and design of CMF is like this. In the next article, I will talk about implementation design and problems encountered in it.
