App Test Summary

As a QA manager who has experienced two app releases, I hope to summarize my experience and share it with you.

First, the need to collect confirmation

The first is the process of gathering requirements, gathering requirements, and understanding and judging the complexity and duration of this requirement. First of all, there are two types of requirements for app releases: new requirements and optimized requirements. So now the point is:

(1) Optimize the demand. You should be aware of the need for optimization. Because optimization needs often you will see this sentence: Logic with the previous logic, logic does not make changes . Then you have to pay attention, because, each version of the app's hair version is changing, business is not your business logic before. So the ghost knows what the logic was before, in case the new requirements change the problem. So, whatever the way, understanding the logic on the line before is necessary . To make it easier for you to test the logic of this version of the requirement before the regression, prevent the problem from occurring.

(2) New requirements. The new requirements are better than the optimization requirements. Because at least there is no blind spot for you to test, there is no such thing as logic.

Second, scheduling and use case writing

(1) Scheduling must pay attention to the factors of concern: the size of the requirements and integration time. The scheduling time must be appropriate (when the schedule must be taken into account all possible considerations, all the test time is also ranked).

(2) Integration time is the point of time that you should be most concerned about. Because the app release is limited by the time limit. Therefore, it is necessary to ensure that all the back ends are on line one or a day before the integration test time. The requirements for client 80% have been integrated . At this point, there is no need to meet the requirements, for version quality, you can consider the next version or find a better solution.

(3) If you are the main test, then remember that all use cases are written by you, and must be written in detail. Because you are responsible for the version to the last person. And the use case is best marked by whether the requirements are versioned (this is important).

Third, the test phase

Requirements to the stage of the test, the development will send a test mail, according to the address, packaging, installation, even agents, testing. In addition to the normal measurement function, some tool methods are introduced.

(1) Charles Tools. Test app I prefer Charles. Of course some people like to use fiddler. I just like the structure of the Charles directory style, requesting a clearer view.

(2) Charles break point. For some test requirements, you need a specific post that meets your needs, but a normal app request is difficult to request to the post you want. So, if you have the message you want to post, you can break the point request:

A, requests the app request, after the request succeeds, requests the right key, selects the breakpoints, breaks the point.

b, request this request again, the request will be interrupted, and then change the request to the data you want. Click Execute when finished. When the request is successful, the app page displays the data you want. ( Note: Modify the request to note the time, to be quick, it is impossible for this breakpoint to expire )

(3) Modify the request to return data. Of course, sometimes you need to see some styles or something, and you need to change the return data. There are two ways: as above and maplocal can be achieved.

A

b, save the request result locally and change it to the data you want to save. Then select: Tools-"Map Local ...

Next you request this interface, the return interface is your local save (note: Some interfaces do cache, not every time the request is initiated, then you need to clear the phone cache ).

(3) The functional test of the app, focusing on whether the value returned by the backend is correct, and whether the value displayed on the front end is correct.

(4) For version control needs, be sure to remember to read this version of the requirements, there are download online version testing, to ensure that the online version is not affected.

(5) For data testing needs, we must pay attention to the accuracy of data, to see whether the category of data is consistent. Look closely, inconsistent, hurriedly find development, there is always a field development passed the wrong, or forget to deal with (this requirement page does not see what, so it is easy to ignore, but the user experience, is fatal).

(6) Buried point product self-test, this product can also be completed, do not occupy the test time.

Iv. Integration Testing

Return to the main process

Report:

App test Method Summary:

Test work is usually carried out in the following ways: Functional module test cross-event test performance Test safety test capacity Test compatibility Test interface test ease of use/user experience test Hardware Environment Test Install/Uninstall Test upgrade/Update test app front and back switch 1, Functional Module Testing:According to the requirements of the software or user requirements to verify the implementation of the various functions of the app, using the following methods to achieve and evaluate the functional testing process: the use of time, place, object, behavior, and background five elements or business analysis methods, refining the application of the user scene, compare the description and requirements, sort out the internal, External and non-functional direct-related requirements, build test points and use cases, and clear test criteria, if there is no clear criteria for user requirements to follow, you need to refer to industry or relevant international standards or guidelines. The test cases for which the type is covered are listed according to the characteristics of the function point being tested, such as: the place involved in the input needs to be considered equivalent, boundary, negative, exception or illegal, scene rollback, association test, and other test types to overwrite it. Track test implementation and requirement input coverage at every stage of the test implementation, and remediate the wrong place for business or demand understanding in a timely manner. 2. Cross-event test: Also called event conflict testRefers to a feature being executed while another event or operation interferes with the process. Such as: The app in front/background running state with the call, file Ixaz, music listening and other key applications such as interactive testing. Whether multiple apps run at the same time affects normal functionality. Whether the app runtime pre/background switch affects normal functionality. make/Receive phone calls while the app is running. Send/Receive information when the app is running. Send/Receive messages while the app is running. App Runtime switch Network (2G/3G/WIFI). The app runs the Browse Web page. The app uses Bluetooth to transmit/receive data while it is running. The app uses a camera and calculator to bring your own device while running. Plug and unplug the charger while the app is running. Conflict events that do not interfere with the software application software anomalies, phone crashes or huaping serious problems, but also need to pay attention to the priority of the cross-event, check whether the system can be processed according to the priority level of each event. It is not possible to hang a lower priority event because of a high priority event. In addition, the Chinese and English mode switch mobile phone should pay attention to the Chinese and English mode after switching the function of the implementation of the existing problems. 3. Performance test: Evaluate the time and space characteristics of the appExtreme testing: Verify that the app responds correctly at various boundary pressures, such as battery, storage, and speed. --Install app when memory is full--the phone loses power when running the app--disconnect the network responsiveness test when running the app: test whether the various actions in the app meet the user response time requirements. --app response time for installation and uninstallation--app the impact of various functional operations time pressure test: Under the repeated/long-term operation, the system resources are not occupied by the exception. --app repeatedly carry out the loading and unloading, to see if the system resources are normal--other functions repeatedly, to see if the system resources are normal performance evaluation: to evaluate the usage of system resources in typical user scenarios.  Benchmark Test (baseline test): Benchmarking with competitive products, product evolution comparison test, etc. Specific scenario Test 1. Low power through analog terminals (e.g. 5% The state of the power) to test the correctness of the function in this state 2. Test the correctness of the function in this state by a simulated terminal in a special geographic location (e.g. Shanghai) 3. Test the correctness and depth performance of the function in this state by simulating the terminal in a specific network state (e.g., 3G) 1. Get the app's power consumption in typical usage Volume Consumption 2. Get the app's traffic consumed in typical usage scenarios and standby 3. Gets the app's CPU usage in typical usage scenarios and standby status 4. Get the app in typical usage scenarios and the amount of memory in standby 5. Get app cold start and hot start time consuming content 6. Getting content for a specific page of an app is time consuming 7. PP Exit time 8. Get the app's frame rate under typical usage scenarios 4. Safety test:  Software rights-deduction risk: including sending text messages, making calls, connecting networks and other  --privacy risk: including access to mobile phone information, access to contact information, such as  --to the app's input validity check, authentication, authorization, sensitive data storage, Data encryption and other aspects of detection  --limit/allow use of mobile phone function to pick up the Internet  --limit/allow the use of mobile phone to send accept information function  --Limit/allow application to register auto-start application  --limit or use local connection  --limit/allow use of mobile phone photo or recording  --limit/allow use of mobile phone to read user data  --limit/allow use of mobile phone writer user Data  --Detect app user authorization level, data leakage, unauthorized access, etc.   Install and uninstall security--the application should be installed correctly on the device driver  --be able to find the appropriate icon for the application on the installation device driver  --Whether it contains digital signature information  -- The Jad file and all the managed properties contained in the jar package and their values must be the correct  --jad file the data content displayed by the application should be consistent  --the installation path should be able to specify  --without user's permission, the application cannot pre-set auto-start  --Uninstall is safe, its installed files are all uninstalled  --Uninstall the user whether the files produced during use are prompted  --its modified configuration information is restored  --uninstall affects the functionality of other software  -- Uninstall should remove all files  --Verify that the app is properly installed, running, uninstalled, and the use of system resources before and after operation and operation, mainly including:  --detection software can correctly install, run, uninstall; a large number of real-machine multi-dimensional test, compatibility Test no dead corner  --Install, uninstall, update error report; includes installation, uninstall, high/Low version overlay installation  --security software for detection includes: Baidu mobile phone butler, LBE, QQ phone Butler, Qin, Android optimization master   Data security-When a password or other sensitive data is lost to the application, it will not be stored in the device, and the password will not be decoded  --the sender's password is not displayed in clear text  --password, credit card details, or other sensitive data will not be stored in their pre-lost location  --different applications of the personal ID or password length must be at least between 418 digital lengths  --when the application processes credit card details, or otherSensitive data, the data is not written in clear text to other separate files or temporary files. With  --to prevent an application from terminating abnormally and without a temporary file on its side, the file may be attacked by a human attacker and then read the data information.  --when you send sensitive data to an application, it will not be stored in the device  --backups should be encrypted, recovery data should consider exceptions to the recovery process    5, compatibility testing         This includes mobile phone models (different Android models, iOS models of different screen sizes), and different versions of the mobile phone system.   for Android phone models compatible, according to the user's habits, the use of high coverage of several models.                    Summary to this end ~ 

App Test Summary