[Dry goods] Mobile APP test case design practical experience sharing

Before talking about mobile APP test case design, I ask everyone to think about the following two questions:

  • First, why do we have to do a good job in test case design? ——Why?
  • Second, what are the commonalities of good test case design? ——What?

It is a very meaningful thing to think deeply about the answers to these two questions. As the guards of product quality in the mobile Internet era, we must improve our test design capabilities, and we must clearly know what to test and how to test. But judging from the current situation of our test team, many people are not prepared, and the test design method is still relatively backward, so I have compiled this article to summarize and precipitate the mobile client test case design practice and help testers review and improve them all the time. Improve self-testing ability.

So back to the two questions at the beginning of the article, I also talk about my understanding, and I hope my colleagues will point out any improprieties.

Why? Why do you need to do a good job in test case design?

The purpose of test case design, generally speaking, is mainly to avoid omission of test points through the test design of demand points, and now every company also very much agrees with the necessity and significance of test case design, regardless of test case design Whether it is good or bad, the existence of this link plays the most basic role in promoting quality and efficiency.

So why do we have to do a good job in test case design?

First, the quality of test case design ability directly affects the quality of the first impression that developers have on us. For example, how do we evaluate a good developer?

  • 1. Good coding, few bugs
  • 2. Rigorous thinking, smooth communication, responsible...

With empathy, how do developers generally evaluate a good tester?

  • 1. High case coverage and less missed test
  • 2. Rigorous thinking, smooth communication, responsible...

Therefore, testers can’t write good test cases, just like developers can’t write good code, which is a bit embarrassing, but often many testers don’t realize this at all, including I have encountered a lot of work for five or six years. The senior testers of, the test case design ability is very average, but the posture is high, so I won’t talk about it here. What I want to express is that test case design is a basic course after all. Whether you are a test recruit or veteran, I suggest you learn it again if you haven't learned it well or not.

Second, the quality of test case design is directly related to the most fundamental test quality and test efficiency. Why do you say that, from the perspective of quality, good test case design is constructed through layer-by-layer analysis according to requirements, and in-depth understanding of development and design logic. Therefore, the test points are often drilled deeper, the scenarios are more complete, and leaks occur. The probability of testing is also lower. From the perspective of efficiency, the high-quality test design done by the developer before the test is carried out, during the test execution stage, there is no need to bother to construct the design. After the test case is executed as planned, the test for this requirement is basically completed.

What? Commonness of good test case design?

This is actually a question of different opinions. Different testers have different test design styles. Here we can seek common ground while reserving differences. The commonalities of good test case design are roughly as follows:

(1) Reasonable organization of test design structure. The organization of test cases is the starting point for testing. A good organization can help us quickly locate the part we want to focus on. The quality of this part is related to the continuous development of the testing work.

(2) Test case design coverage is comprehensive and non-redundant. A test case is clearly described in concise language, and the coverage of required test points is clearly described with fewer test cases.

(3) The test case design has the characteristics of executable, determinable, and reproducible, that is, on the premise that the test conditions are met, each test case can be executed smoothly according to the test steps, and the corresponding expected results are presented at the same time, and the test cases are in The result of multiple executions should be the same.

 

Mobile client platform testing, on the basis of traditional software testing, itself has many outstanding features. For example, the client platform is diversified, the system fragmentation problem is prominent, and the flexibility is extremely high. Therefore, it is not enough to only focus the test on the basic functions and the traditional concept of the test organization to ensure the comprehensiveness of the mobile client test.

The traditional use case organization methods, such as equivalence class division, boundary value analysis, causal analysis, etc., are more about reducing redundancy as much as possible on the premise of streamlining test cases and ensuring comprehensive testing. Now we recommend an organization method for testing that is oriented to problem discovery, that is, the distribution of bugs corresponding to the corresponding test content, so as to achieve a comprehensive test organization.

 

  In the process of testing, we need to constantly summarize and reserve our own knowledge and experience, such as with specific attributes, environments and scenarios, such as: PC, mobile phone, smart device, specific network environment, we need to pay attention to the function points, Error-prone locations will play a crucial role in our entire testing process, making testing more efficient and discovering more potential problems.

 

  In our testing work, there are actually many things that are similar to the test of a certain APP and can be abstracted out. Here, TestMadman summarizes the aspects that must be considered when testing most APPs. If you missed other aspects, you are welcome to add.

  So now we have summarized the functional points that need to be paid attention to in the mobile App testing process for everyone, and hope to help you!

(Ps: In order to facilitate subsequent reading, we will use "APP" to refer to "application" below)

Application start and stop

1.1 First start

    Whether the welcome interface appears, the stay time of the welcome interface is reasonable, and whether the application is normally entered after the welcome interface;

    Whether the first startup time is reasonable;

    Whether the information to be pulled is correct;

    Whether the desktop icon is created successfully, whether the function startup shortcut key is created successfully (some Android phones have the need to create a shortcut key for a certain function in the application on the desktop)

1.2 Second start

    Whether the startup time meets expectations;

    Whether the application can be entered normally from each startup entry: the main icon of the program startup, the shortcut key of a certain function, and the widget;

    Status check after startup: such as initialization information, initial state, startup to network

    Start process service check: process name, process number, service name, service number, SDK called by third party such as GPS

    Whether the application with login is normally logged in when it is started for the second time

1.3 Startup after the program exits abnormally

    Restart after the operation crashes: such as null pointer, memory overflow, etc.

    Manually stop the process: if there are multiple processes, stop all of them or restart after stopping one of them

    Manually stop the service: In the case of multiple services, after stopping all or stopping some services, use directly without restarting

    The housekeeper software cleans up the process and restarts

    Other system software tools stop the process and clean up software data

Program function module

      This is generally based on the requirements to verify all the trigger events of all modules of the application one by one. This is the most basic to investigate from two aspects, one is to comply with the requirements to operate the module, whether it meets the expectations of the requirements; the other is whether the program runs counter to the requirements, whether the program will have corresponding abnormal control and so on. Uncle Liao proposed the concept of test modeling that Google is using. This method can help us better integrate the architecture of the requirements analysis application and design more complete functional module use cases.

 

2.1 Text box input function

Normal input, input out-of-bounds, special character set (\n, \r, etc.), use copy and paste to input content into the text, input the characters that the program stipulates not to input

2.2 Event trigger

    Whether each button and each clickable item can complete the required function 

    Try to click on the non-clickable area on the page to verify whether the back door of the reserved test during the test is closed

 

Permission security

· The permission that needs user confirmation is not authorized, and the permission is closed by default

· Networking operations under the condition that the network authority is restricted by the housekeeper and system security software

· Permission sensitivity, such as the address book, is the top secret permission of the system and carefully obtained

· Use security software to scan for security vulnerabilities and viruses to see if the tested APP will be prompted by these security software to have problems that affect the user's use or impression of the tested APP

File storage

· Temporary file storage path, naming method, etc. generated during APP use

· The file storage method of the download operation involved in the APP

· Stored files are locked or occupied

· If there is an external SD card or a built-in SD card, it is necessary to check whether the files generated by the APP are correct

· APP is installed in SD card or mobile phone storage space

· Insufficient disk space, disk without permission (such as read, write)

Network and traffic

· Network signal, especially the performance of the application in a weak network environment

· Different operator networks: China Telecom, China Unicom, China Mobile, 2G/3G/4G

· Logical processing of network interruption and network recovery scenarios (such as retry), and network prompts

· Whether the traffic of the first launch of the application meets expectations

· The impact of statistics and abnormal reporting on traffic

· Whether the size and size of the picture in the APP have considered the impact on network traffic

· Special services based on traffic security, such as wifi networking only

Interface fault tolerance 

 · Request network layer error: http response returns a status other than 200

 · Request business layer error: the returned content of the interface is empty, too long, and the field type does not match

Interrupt test

· Lock screen interruption: stay in the program operation interface to lock the screen, and check whether the operation is normal after recovery

· Front and back switching: stay in the program operation interface and use the Home button to switch between the front and back of the program

· Load interruption: When the page interface request and interface frame load, it is interrupted by the Home button, the back button, and the fast switching operation.

· Abnormal system interruption: such as shutdown, power failure, incoming call

Model adaptation

8.1 Resolution adaptation

UI structure and dialog boxes are adapted based on resolution and screen size

8.2 OS version adaptation

Involving API calls such as obtaining SIM card information, external SD card settings (4.4 external SD card does not have the permission to write)

8.3 CPU hardware configuration

X86 model, V5, V6, V7, V8

System Configuration

· Process management: power saving management, background process residency management

· Display management: font size, font type

· Language Environment: Language Environment

· Horizontal and vertical screen configuration: Whether to support horizontal and vertical screen adaptive processing

Upgrade overwrite installation

· Gradually upgrade: the retention of user data, settings and status, Xtep pays attention to the status or settings that have been removed from the new version

· Skip: that is, separate version overwrite installation

· Downgrade: Overwrite and install the lower version

· Uninstallation 4. Uninstallation, installation directory cleaning, SD card storage data will not be cleaned

· Data-saving upgrades: some assistants provide a way to save data-saving upgrades

· When there is no update or network, users need to be given correct information expression

· If the upgrade ignores the current version upgrade, when there is a new upgrade version, whether there is a prompt to upgrade

· Mandatory upgrade 8. Cannot be used without upgrade

Performance Testing

11.1 Performance

Performance indicators of core operations: such as CPU/memory, response time, power, flow

11.2 Stability

· Select certain scenes for continuous and repeated operations

· Monkey stable operation, lasting multiple hours

11.3 Fluency

List sliding, return to enter, and quickly click (this is not a good judgment with the naked eye, you can use GT, generally a score of 90 or more is better)

11.4 Software compatibility

· Universal software input method

· Security Software

· Communication

· Competitive software similar software, whether there are conflicts

Competitive product comparison test

· In terms of function: Compare with similar competing software in UI design, interactive experience, etc.

· Performance: Competitive software of the same kind is at least equal to the other party in terms of performance, power consumption, traffic, etc., and it is best not to be too much lower than the other party

Software testing exchange group: 785128166

WeChat public account: Programmer Erhei; After paying attention, you can receive a set of video resources for free; explain in detail: python automated testing, web automation, interface automation, mobile terminal automation, interview experience and other related content, the value of learning resources depends on you Action, don’t be a "collector"

Here is a collection of selected dry goods articles for functional testing:

Dry goods sharing | Featured article collection of functional tests (Are you afraid that you can't find the article you need?)

Guess you like

Origin blog.csdn.net/m0_52668874/article/details/115248250