After the product and some users have used it, give corresponding modification opinions, and go online after it feels OK. It can be used directly on the Internet or some app download platforms, and no standardized software testing has been carried out ! There are more or less bugs in these softwares, and these bugs may be problems in functions, compatibility, performance, etc.!
In order to improve the problem of low software quality, the industry of software testing has only begun to receive attention! The purpose of software testing is to improve software quality and give users a better experience!
Software testing process
Regardless of development or testing, there is a demand side. Through communication with the demand side, information is integrated and a demand specification is formulated! Requirements specification: refers to the text of the user's requirements for software functions, performance, compatibility, UI, etc.! Development Develop and design programs according to the requirements specification! However, some companies do not provide requirements specifications, and most companies use meetings and design models as requirements irregularly in this part. The purpose of this is that the requirements are not clear, and the communication cost is too high!
The following is a test flow chart that I think is more rigorous or standardized:
Mobile test series of software testing
Extract test points
After the requirements specification has passed the review, there is a unified requirements document for development, product, and testing at this time. Based on the requirements specification, the test extracts test points based on the content in the requirements specification. The criterion for the extraction of test points is generally: one test point Corresponds to a test case! To ensure the coverage of requirements! Generally, testers directly write tests according to the requirements specification, which can easily lead to incomplete coverage of requirements! The test points include not only the demand points indicated in the requirements specification, but also some implicit requirements, so as to ensure that the extracted test points can cover as many requirements as possible!
Design test case and use case review
Test case is the smallest granular unit of software testing and one of the key points of testing. Whether you are a rookie in testing or a veteran in testing for many years, test case testing is an indispensable part! According to the company's business, the test cases of each company are different. The common core parameters of the template mainly include the following points: use case ID, use case name, use case description, execution steps, expected results, actual results, belonging function modules, use case status, The version number, author, creation date. Some companies also have priorities, preconditions, etc. These attributes are used for improvement according to their own business. The main points of test case design are: simple, clear and organized!
The following figure shows a simple test case template. The attributes in the template can be expanded and deleted according to your own needs or business. Generally, the use case attributes are displayed in a column. Here is a form template given by me.
1. Clarify the key points of the test, unify the understanding of the requirements, and ensure the completeness of the test. After the use case design is completed, the next step of the test is not to start, but to go through the use case review. Although the requirements specification has been given, there may be differences in the understanding of the unified requirements in products, development, and testing, so different results will appear in the implementation and testing. The main purpose of this part is as follows:
2. Review whether the test case design fully covers the functional requirements;
3. Determine the test time node.
The participants at this stage are mainly: product, development, and testing. In large companies, the project leader will also participate in the use case review.
Test type selection
After the use case is designed and reviewed, it is necessary to select different test methods for test implementation. Generally, the types of tests included in a project are as follows: manual testing, black box testing/functional testing, white box testing, automated testing, compatibility testing, interface testing, performance testing, penetration testing, etc.
l Manual testing
Mainly do some functions with more complex logic and less frequent use! However, at present, most companies use manual testing to account for about 70% of app testing.
l Automated testing
Mainly for occasions that are repetitive and frequently used. Automation can be realized by choosing the appropriate language and tools according to your own skills! At present, there are many used in the market: RF, UFT (QTP), winrunner, selenium, appium, uiautomator, XCUITEST, etc. Those who are interested can find out by themselves! Before designing the automation script, it is necessary to sort out the relevant business, design the test execution process, and prepare the test data
l Interface test
The interface test is to verify whether the return parameters and status of the interface are correct. The following preparations need to be done in the early stage of the interface test:
a. The developer provides the service interface (interface path, header file, request data format, etc.);
b. Give the test data. Take login as an example: various combinations of username and password are required;
c. According to the first two parts, you can choose any one of postman, RESTClient, Fiddler, and Charles to simulate the request. When the request is sent successfully and returns !
d. According to the simulated design request format, select the corresponding test tool. The current mainstream interface tests mainly include: Jmeter, Locust, and some scripts written by myself. For individuals who are just getting started, it is recommended to learn Jmeter. Jmeter can not only do interface testing, but also do concurrency testing, pressure testing, and load testing based on interfaces, but the performance and stability are not as good as loadrunner.
The project directory for writing scripts generally includes: library file lib, test data file data, test case file, test report, log file and main program.
l Compatibility testing
Due to the diversity of devices, browsers, and operating systems, before the product goes online, it is usually operated on different devices (different resolutions), browsers, and operating systems to check whether the application is displayed normally, Can the application function respond normally! Compatibility testing currently mainly refers to mobile device compatibility, operating system compatibility, and browser compatibility.
The compatibility testing method is to determine a test benchmark, take the test benchmark as the expected result, and perform the same operation on other devices, browsers, and operating systems. It is consistent with the test benchmark, indicating that the application meets the needs of users or products in terms of compatibility. of.
l Performance test
Performance testing is based on complete functions and interfaces, and performs stress testing, load testing, fatigue testing, and concurrency testing on the server to discover performance bottlenecks.
Performance testing mainly includes:
1. Demand extraction, this part includes: response time, number of concurrent users, TPS, throughput, CPU utilization, memory usage, number of online concurrent users, etc.
2. Requirements strategy formulation: design performance test scenarios! Here is an example of logging in:
Number of concurrent users: 150, 200, 250 and 300;
User Interval: 1, 2, 2 and 2;
Continuous run time: 20, 30, 30 and 30.
3. Prepare test data
The test data here is different from the test data used by the automated test. The test data here is the data that effectively composes the requirements, and the request to use this data can respond to the successful data.
4. Select the test tool
The test tool personally recommends the cracked version of loadrunner, the main reasons are: a. I have stack overflowed many times when using jmeter for long-term pressure testing, which is not as stable as loadrunner; b. Secondly, the reports generated by loadrunner are also more standardized and more selective. If the requirements are not very standardized, you can choose jmeter. The number of concurrent users of jmeter has a lot to do with the client configuration of the pressure test, but it is suitable for beginners. For you, the company does not require me to recommend you to use this, which can meet the basic performance. testing and interface testing. The internal programming script of loadrunner uses C language, and the entry level is relatively high.
5. Select the appropriate performance counters and related performance analysis indicators
Note that the performance counters here are set on the server, not on the client. If you do not have permission on the server, it is necessary to record the stress measurement time node and communicate with the server to obtain the performance indicators of the server during this period.
Performance analysis indicators: response time, number of concurrent users, TPS, throughput, number of online concurrent users
6. Conduct stress tests and obtain test test data or reports
7. Write a performance test report
l Penetration testing
With the development of technology and the development of mobile payment, security testing has gradually received attention. Security testing requires a wide range of knowledge, and my personal level is limited, so I won't do anything wrong here! However, the current mainstream penetration testing platforms mainly include: BT5 and Kali. These two platforms gather the most used tools and commands for security testing. If you are interested, you can check them online, or private message me, and I will give you the learning documents!
Test execution and defect management
Test execution includes: manually execute test cases, run automated test scripts, interface test scripts, performance test scripts, compatibility tests, etc. If a bug is found during this process, you can choose the bug management system in the company to record the bug. Bug management systems currently include: bugzilla, mantis, bugtags, etc. If you have not used these tools, you can use doc or excel to create a bug module yourself. The core attributes of the bug include: bugId, bug name, bug description, severity level, priority, functional module, version number, developer, reproduction steps, expected results, and actual results.
Defect life cycle flowchart:
A bug report template is given below:
Regression testing and acceptance testing
Regression testing selects the appropriate regression strategy according to the time schedule. If there is enough time, then execute all test cases. If there is not enough time, choose to execute core test cases and bug repair test cases.
Acceptance test requires the product or user to check whether the product function realization, page display, and performance are consistent with the requirements of the requirements specification according to the requirements specification. If they are consistent, it means that the product meets the requirements and passes the acceptance.
Test report
After the test is completed, the test products of each stage need to be given. Such as test requirement documents, test cases, automation scripts, performance test scripts, performance test reports, automation execution reports, interface scripts and reports, etc.
Summary
The process of software testing given above, and what each process needs to do? Through this article, we need to focus on the three cores: test process, test case writing, bug writing and management. As for the types of tests involved, it is only briefly mentioned here. The tools and technologies mentioned in the article can be received by private messages, discuss the things about the test together, learn together and make progress together, and help each other on the road of testing together
Mobile test series of software testing
