Summary of APP test cases

In our testing work, there are actually many things that are similar to the test of a certain APP and can be abstracted out. Therefore, the following sorting and summary are made for the testing process and key content of the APP.

1. The first is the confirmation and preparation of test resources  

1.1

Product requirement documents, product prototype drawings, interface description documents and design description documents should be complete;

1.2  

Preparation of test equipment and tools: Real devices of different versions of IOS and andriod, and preparation of related test tools.

2. Design and review of test cases

  (1) According to the product requirement document, product prototype drawing and other documents, design the general functional test case of the client;

  (2) Test case review, modification and improvement. After passing the review, proceed to the formal testing stage.

 Three, UI test

  (1) Ensure that the prototype drawing and effect drawing at hand are the current latest version, which meets the requirements of product managers and users;

  (2) During the testing process, everything is subject to the renderings. If there are user experience suggestions, you can first confirm with the product manager in the form of email. After the confirmation is passed, you can formally raise user experience issues to the development;

  (3) Since the data in the test environment is simulated data, the type of data that may appear in the formal environment must be considered in advance during the test.

Four, functional test

  (1) During the functional test, the software function is traversed mainly based on the written functional test case;

  (2) The tests involved mainly include basic function tests, installation, uninstallation, and operation tests, and abnormal handling (including handling of abnormal situations such as sudden network disconnection, slow network speed, insufficient machine memory, etc.) tests.

Five, interrupt the test

  (1) Answer phone calls, receive text messages, lock screen, alarm, and charge during the operation of the software, and then use the software after receiving the notification reminder, the software should still be able to operate normally;

  (2) When the software is running, switch from the foreground to the background, and then switch back to the foreground, it should still be able to run normally.

 Six, compatibility and adaptation test

  (1) Hardware adaptation: adaptation of different mobile phone manufacturers, hardware performance, and different screen sizes;

  (2) Compatibility of OS version: IOS6-9; Andriod3 and above, if some new APIs are not supported on the old system, it will cause a crash;

  (3) Adaptation of screens with different resolutions: The resolutions of mobile devices are diverse. If the APP does not do a proper processing, it may display poorly and even affect the operation of the function.

  (4) Compatibility testing must be performed on a certain number of real devices. Because there are too many types of real devices, especially when Android is doing compatibility testing, you can select several typical real devices that are more used for compatibility testing;

  (5) In addition, the open source test testin cloud test can be used to carry out compatibility testing of more models. Testin cloud test provides basic operating conditions and some screenshots, as well as simple test reports, which help to expand the scope of the test.

 Seven, performance test

  (1) Client performance testing focuses on: installation and uninstallation time, startup time, page loading time, CPU, memory, traffic, power consumption, etc. occupied by main functions, and whether it has advantages compared with similar products;

  (2) The page loading time can be obtained by using the Android debugging tool DDMS, and you can see the page loading time by searching for the Displayed keyword in DDMS;

  (3) The CPU, memory, traffic, etc. occupied by the main functions during operation can be obtained with the help of the open source tool emmagee (for Android);

  (4) As for the performance of the server, the interface is mainly used to exert pressure on the server, focusing on response time, throughput, concurrency, transaction pass rate, etc., which can be tested as tools loadrunner and jmeter.

8. Stability test 

8.1 

  The stability of Android APP is often tested by using monkey commands to simulate human operations through a stream of random events, which has a great effect on checking program memory overflow and null pointers.

8.2 

Monkey is mainly used to detect system problems such as ANR and Crash

9. Test analysis and test report output

  After the above tests are completed, complete analysis and report documents (including buglist, performance and stability results analysis, version launch risk analysis, etc.) should be formed and output to relevant personnel.

10. Practical experience of mobile test cases

  Each test method actually has an optimal test time. For example, in the version test phase, we should first perform basic functional testing, boundary analysis testing and interruption, interactive functional testing, and quickly find the bug bill of lading for the development to quickly repair, to ensure that the main body The function can be guaranteed as soon as possible, instead of entangled with performance, stress and compatibility testing at the beginning. On the one hand, this type of testing often consumes a long time, which reduces the speed of finding bugs. On the other hand, after doing this part of the test first, and then discover the bugs of the main function, then after the developer has moved a lot of code, it is still Performing performance, stress, and compatibility testing related use cases again will not only cost you money, but also get half the result with half the effort.

Therefore, in actual project testing, our current project divides the test content into functional testing, compatibility testing, performance testing, and stability testing, which are carried out in different testing phases (the specific schedule is determined in the test plan):

  (1) Functional testing-version testing phase

  (2) Compatibility test-early stage of regression test

  (3) Performance test-regression test stage, executed after the version function is stable

  (4) Stability test-Throughout the entire test phase, monkey is executed every night

  Therefore, more of our functional use cases will use "basic functional testing", "boundary analysis testing", "interrupted functional testing" and "interactive functional testing" these types of test case design methods. Specifically, when you are doing project testing, it is also recommended to make adjustments based on actual conditions.

 

image

  Xunzi said, “If you don’t hear it if you hear it, if you hear it if you see it, if you see it if you know it, if you know it, if you do it, learning is as good as doing it." Only by summing up and accumulating, can we break the inherent thinking and improve our test case design ability. Therefore, we have also refined the test case design points of some common functions of the mobile client. Here are the test points of the APP page type functions we summarized, which are roughly as follows:

 

1. UE experience

 

  (1) The layout is consistent with the interactive diagram

  (2) There is no serious visual deviation between the real machine effect and the UE image, such as font size, font size, boldness, font color, line height, line spacing, button placement, spacing, size, etc.

  (3) The resource map is used correctly, without unnecessary stretching, compression or other effects.

  (4) Various prompts, the text is smooth and does not produce ambiguity, and the display conforms to the user's usage habits.

  (5) The animation effect is not stuck, and it is displayed normally.

 

2. Page operation

 

  (1) Is there an anti-repetitive click, that is, multiple pages or pop-up windows will not appear when clicking continuously

  (2) One-finger slide, one-finger click, one-finger double-click, one-finger long press, one-finger zoom, and multiple-finger click

  (3) Shake, switch between horizontal and vertical screen, switch between front and back

  (4) Long time use, long time in the background

 

3. Page operations in different scenarios

 

  (1) Page jumps under different networks and weak networks, and click-response display effects

  (2) The page operation display effect after modifying the local parameters, such as modification date, time, time zone, language, keyboard, etc.

  (3) The page operation display effect after modifying the system permissions, such as opening and closing positioning, camera, photo, address book, etc. authorization, etc.

  (4) System interruption during the page operation, such as incoming calls, text messages, alarm clock reminders, calendar reminders, Bluetooth reminders, plugging and unplugging the data cable, plugging and unplugging the headset, standby, screen lock, low battery reminder, etc.

  (5) Switch between front and back during the page operation. For example, when the page data is exchanged, there is a pop-up window, and it is easy to find the problem when the timing of the prompt box is switched.

  (6) For the interface called by the non-main thread, the front-end must perform asynchronous processing on exceptions and no network conditions, without prompting exceptions and not affecting the main thread operation.

 

4. Page data acquisition and display

 

  (1) Whether the page is cached, what is the cache mechanism, and what are the contents of the cache?

  (2) Whether there is a retry mechanism after the page data submission fails, and whether the interface parameters of the retry remain unchanged

  (3) In the process of page operation, whether the content returned by the asynchronous interface is transparent to the user (the client is compatible with ignoring the request and returning msg)

  (4) During page operation, the client must be compatible with the abnormal data returned by the interface to ensure that the program does not crash.

 

5. Words written at the back

 

  In the process of managing the team, there are often testers who complain to me that the developers don't take us seriously, the test status is very low, and so on. In fact, this phenomenon is quite normal. When our basic testing work is not done well, there are many online missed tests, and the test conclusions are often overturned, our professionalism in the testing direction will be questioned, and people do not believe what happened to you. Can you still value you?

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/115247944