Some people like to create worlds, they do developers; Some people like developers, they become testers. What is software testing? Software testing is a disaster that should have happened in front of the user in advance in front of their own, which will make them give birth to a sense of savior, save the user, also save the software, avoid their uninstall fate.
Test process of the project
1. After getting the requirements document, write test cases
2. Review test cases
3. Wait for development kits
4. Deploy the test environment
5. Smoke Test (Web architecture)
6. Page initialization test (check whether the data content in the database is consistent with the content displayed on the page, and whether it is arranged in some order)
7. Perform specific test cases (almost all functional tests, process methods, scenario methods)
8. Fill in the defect form if any defect is found
9. Non-functional testing (SQL, JS injection, page efficiency, adding data directly to the database bypassing JS validation)
10. Write final test report
Test case design method
Equivalence class, boundary value, orthogonal test method, state transfer method, causality diagram, scene test method, anomaly analysis, causality diagram, error guess method, decision
table
Elements of the test case
Id Topic Test Name Creation Date Designer Description Step Name Expected Result Execution status
The priority of testing
1. Test the changed parts first, and then test the unchanged parts
2. Test the core function of the program first, and then test the general function
3. Test logical functionality first, then business functionality
4. Test for general conditions first, then for exceptions
5. Test functionality first, then performance
What does the test report contain
1. Write test background
2. Test objectives
3. Test scope
4. Test environment
5. Test data
6. Test criteria (key points)
7. Test progress
8. Test results
9. Test conclusions
Some companies use non-standard test reports
Test duration Test environment Number of bugs detected by testers Number of bugs fixed Number of remaining bugs Cause of remaining bugs
Test results, etc.
Believe that dreams will come.
When lost, choose the harder road.
When you have goals and dreams in your heart, don’t be afraid to give it a try. It’s easy to give up, and it’s easy to kill your passion. But if you stick to it, you may see a different yourself.
Every successful person will receive a lot of encouragement on the way forward and will be willing to encourage others. I deeply feel the help that encouragement brings to me. Every “like” from you is the biggest support for me and makes me keep on making better content.
BUG lifecycle
Submit — Development validation — Accept — reject — Development resolution — Tester validation — Close — Don’t pass Open
The state of the BUG
1. NEW: All issues submitted to the development docking are in NEW state, indicating that they are not handled
2. OPEN: The development docking person initially determines that the problem needs to be transferred, and assigns testers and developers with the status as OPEN.
3. REFUSE: the development docking person judges that the problem does not need to be transferred to the next link, and the status is REFUSE, and fill in the reason
4. FIXED: The developer has completed the fix and is waiting for testing. The state is FIXED
5. REOPEN: The test department passed the repair result of the tester for the developer, and the state was REOPEN
6. CLOSE: The tester judges that the problem is demand or other problems and needs to fill in the reason;
Element of defect
Defect Title Defect Status Submitter Responsible Person Priority Severity Defect Description Time Screenshot
Level of defect
Critical problem Core functions are unavailable or the system crashes
Major fault A major service process cannot be used. A function in a major service process is defective
General issues General issues, not major process functional defects
Minor problems Interface AND UI problems are not standardized
Suggest questions Based on your experience
Differences between WEB testing and APP testing
1. Architecture is different.
The Web side is based on b/ S architecture, which is based on browser address access
App terminal is based on C/S architecture, and C/S architecture requires a client as a carrier
2. Version release methods and procedures are different.
Web version, the development and deployment of new code to the corresponding server address, you can achieve a unified update on the Web side
App release, development needs to package (APK package and IPA package), after the package needs to be released to the corresponding channel
3. The compatibility
Web, test compatibility of different browsers (IE, Chrome, Firefox, 360, QQ)
App, test different resolution, screen size, phone brand, system version
4. Performance
Web, test response time
App, test response time, flow, power consumption, CPU, GPU, memory
5. Security
Web, SQL injection. XSS attacks etc.
App, HTTPS encryption, signature, hardening, password encryption, etc
6. App test features
Fitness test
Network test
Online Upgrade Test
Interrupt the test
Power consumption test
Weak network test
Installation and Uninstallation test
Flow test
If you are interested in software testing and want to learn more about testing, solve testing problems, and get started with guidance to help you solve the puzzles encountered in testing, we have technical experts here. If you are looking for a job or just out of school, or have already worked but often feel a lot of difficult, think that their test learning is not enough, want to continue learning, want to change careers afraid of learning not, can join us 1079636098, In the group, you can get the latest software test factory interview materials and Python automation, interface, framework building learning materials!
The main content of app testing
1. Functional testing
Testing the correctness of business logic
2. Compatibility test
System version
The resolution of the
What if a bug is not considered a bug by the developer
Common Linux Commands
When can elements not be located
The difference between GET and POST requests
Network situation
3. Exception test
Warm start
Network switch
The phone information terminal is restored
4. Upgrade, install, and uninstall
5. Robustness testing
Mobile resource consumption
Traffic consumption
Power test
Crash recovery
What if a bug is not considered a bug by the developer
1. Submit problems to the defect Management database for record.
2. Obtain the basis and criteria for judgment
According to the requirements specification, product description, design documents, etc., confirm whether the actual results are inconsistent with the plan, and provide the direct basis for the confirmation of defects;
If there is no documentation, you can explain whether there is any inconsistency according to the general characteristics of similar software to determine whether it is a defect.
According to the user’s general usage habits, to confirm whether it is a defect;
Discuss with designers, developers and customer representatives to determine if there is a defect;
3. Reasonable discussion, to the test manager to explain their own reasons for judgment, pay attention to objective, rigorous, do not involve personal emotions.
4. Wait for the test manager to make the final decision. If there is still any dispute, report it to the superior through the channels provided by the company policy, and the superior will make the decision.
Common Linux Commands
1. Ifconfig View the IP address
2. Cat displays all contents of a specified file
3. More Displays the content of a specified file in paging mode
4. Mkdir Create a directory
5. Touch creates a new file
6. Grep Search for qualified strings in the file
7. Find Finds the specified file
8. Tail -f is used to automatically refresh N lines of data after a file is displayed
9. Kill -9 Forcibly ends
10. Netstat anp | grep port number Check the port
11. Chmod -r 777 Grant permission for 777
When can elements not be located
1. Wrong code
2. Element not present (requires element wait)
3. The element is in the iframe
4. Window
5. Pop-ups (system pop-ups, JS pop-ups)
6. Element attribute values are loaded dynamically
7. Element uniqueness cannot be determined
8. Read-only attributes (elements are not operable)
The difference between GET and POST requests
1. GET uses URL or Cookies to pass parameters, and POST places data in BODY
2. GET urls are limited in length, and POST data can be very large
3. POST is safer than GET because it is not visible in the address bar
4. Generally, GET is used to obtain data, and POST is used to send data
Why do interface tests
1. The lower the bugs are, the lower the repair cost is
2. When the front end changes, the back-end port does not change
3. Check the security and stability of the system
How does the interface test work
— Since the front-end and back-end calls of our project are mainly interfaces based on HTTP protocol, the testing of interfaces is mainly to simulate the sending and receiving of HTTP requests through tools or codes. There are many tools such as Postman, JMeter, soupUI, etc.
It can also be done with interface automation, which is code, framework and UI automation, where requests are judged by assertions.
Focus of interface testing
1. Check whether the data returned by the interface is consistent with the expected result
2. Check whether the fault tolerance of the interface can be handled when type errors are added
3. Boundary value of the interface test
4. Interface performance
5. Interface security
The HTTP status code
1.1XX: The request is normal, but there is no response. It is used only in the experimental state
2. 2xx: indicates that the message starts with 2
3. 3xx: 3 indicates redirection, usually 302
4. 4xx: 400 indicates that the syntax sent by the client is incorrect, 401 indicates that the page is not authorized, 403 indicates that the page is not authorized, 404 indicates that the page is not available, and 415 indicates that the format is incorrect
5. 5XX: Indicates that the server is faulty. 500 indicates that the server is faulty
Cookies and Sessions
1. Cookies data is stored in the client’s browser, and session data is stored on the server
2. Cookies are not very secure. Others can analyze cookies stored locally and cheat cookies
3. Session will be stored on the server for a certain period of time. When the number of visits increases, it will occupy more space
Common ADB commands
1. Adb start-server Starts the ADB service
2. Adb kill-server Disables the ADB service
3. Adb Devices Check the device number
4. Adb Push
Adb Pull Mobile PC
6. The adb logcat | grep package name (Unix)
7. The adb logcat | findstr searches the package name (win)
Adb shell Go to the shell command line
Adb install install app on mobile phone
Adb uninstall Uninstall the app to your phone
Adb logcat > adb logcat > adb logcat
Adb shell top test app resource consumption command
The business process of the product
parsing
Ask about the overall business process for a project on your resume
For example, the registration function in the e-commerce project, the whole process from the beginning of registration to the success of registration
What are the criteria for a version to go live
Acceptance criteria
(1) All functions defined in the software requirement analysis manual have been realized, and all performance indicators have reached the requirements.
(2) The errors found in the acceptance test have been corrected, and the defect repair rate at all levels has reached the standard
(3) There are no residual critical or critical errors in all test items.
(4) Requirements analysis documents, design documents and coding implementation are consistent.
(5) Complete acceptance test artifacts (test plan, test cases, test log, test notice, test analysis report, software installation procedure to be accepted)
Sequence).
Defect repair rate standard
(1) The repair rate of emergency and critical errors should reach 100%;
(2) Ordinary level error repair rate should reach more than 95%;
(3) The error repair rate of optimization level should reach more than 60%;
Note: When the project is urgent, the normal level error repair rate reaches more than 60%; Optimization level error repair rate of 20%.
Server health response metrics
(1) The maximum utilization rate of CPU % concurrency should not exceed 70-80%. If there are collection points concurrency can be allowed to approach or reach 100&but most of them do not
Should be checked by 95%;
(2) During the memery test, ensure sufficient memory and no less than 20% available memory;
(3) Disk Monitors whether the read/write status of the hard disk is less than 40%.
(4) CPU load average shall not exceed the number of CPU cores *2 or the number of CPU cores.
Test case review process and related participants
1: Review process
A: Make the following preparations before you start
1. Determine the reasons for the review
2. Determine the timing of the review
3. Determine the participants in the review
4. Clarify the content of the review
5, determine the end of the review criteria
6, at least one day in advance to the content of the review by email to the review meeting related personnel. Specify detailed examination time, place and compensation of participants, etc.
7. Remind relevant personnel of the review meeting to read the review content briefly at least once in the email, and record relevant questions, so as to put forward in the review meeting.
8, the meeting moderator (usually the use case writer) should organize relevant questions before the meeting so that they can be raised in the meeting.
B: Start the review
1. Hold a review meeting. Participants give comments and suggestions after the presentation by the designer, and take detailed review notes.
2. Communicate with relevant personnel by general email
3. General IM tool to communicate directly with relevant personnel
4. Review according to the review content
2: Review content
1. Whether the structure arrangement of use case design is clear and reasonable, and whether it is conducive to efficient coverage of requirements.
2, priority pole arrangement is reasonable.
3. Whether all function points on test requirements are covered.
4. Is the use case executable? For example, whether the preconditions, execution steps, input data and expected results of the use case are clear and correct; Is there an obvious way to verify the expected results?
5. Whether redundant use cases have been removed.
6. Do you include enough negative test cases? Sufficient definition, if used here, is four times the number of positive use cases, after all, in a robust software, 80% of the code is “protecting” 20% of the functional implementation.
7. Whether to design test cases of user usage scenarios and usage processes from the user level.
8. Whether it is simple and reusable. For example, repeatable steps or processes can be isolated and defined as reusable standard steps.
3: Participants in the review (the review will be divided into multiple levels)
1. Department review, involving all members of the test department.
2. Corporate review, which includes project managers, requirements analysts, architects, developers, and testers.
3. Customer review, including developers and testers from the customer side. This situation is more common in outsourcing companies
Finally:
I wish you and I meet, both gain! Welcome to wechat public account: Programmer Yifan
1. Receive a free 216-page software test engineer interview guide.
2. Software test learning route and corresponding video learning tutorial free to share!