How to interview software testing positions in the recruitment season? Super comprehensive test sharing

Project testing process

1. After getting the requirements document, write test cases

2. Review test cases

3. Waiting for the development package

4. Deployment test environment

5. Smoke test (web page architecture diagram)

6. Page initialization test (check whether the data content in the database and the content displayed on the page are consistent, and whether they are arranged in a certain order)

7. Specific execution test cases (almost all functional tests, process methods, scenario methods)

8. If a defect is found, fill out the defect form again

9. Non-functional testing (sql, js injection, page efficiency, bypassing js verification and directly adding data to the database)

10. Write the final test report

Test case design method

Equivalence class, boundary value, orthogonal experiment method, state transition method, causality diagram, scenario test method, anomaly analysis method, causality diagram, error guessing method, judgment table

Elements of the test case

Id subject test name creation date designer description step name step description expected result execution status

Priority of testing

1. Test the changed parts first, then test the unchanged parts

2. Test the core functions of the program first, then test the general functions

3. Test logical functions first, then test business functions

4. First test the general situation, then test the abnormal situation

5. Test the function first, then test the performance

What is included in the test report

1. Write the test background

2. Test objectives

3. Test range

4. Test environment

5. Test data

6. Test standards (emphasis)

7. Test progress

8. Test results

9. Test conclusion

Some companies will use non-standard test reports

Approximately include the time spent in the test, the number of bugs found by testers in the test, the number of fixed bugs, the number of remaining bugs, the reasons for the remaining bugs, the test results, etc.

BUG life cycle

Submit-Development Verification-Acceptance-Rejection-Development Solution-Tester Verification-Close-Fail Open

BUG status

1. NEW: All issues submitted to the development docking status are NEW, which means they are not processed

2. OPEN: The development docking person is initially judged as a problem to be transferred, and the tester and developer are designated, and the status is OPEN.

3. REFUSE: The development docker judges that the problem does not need to be transferred to the next link, the status is REFUSE, and the reason is filled in

4. FIXED: The developer has completed the repair and is to be tested, and the status is FIXED

5. REOPEN: The test department passed the repair result of the tester against the developer, and the status is REOPEN

6. CLOSE: The tester judges that the problem is a demand or other problem, and needs to fill in the reason;

Defective elements

Defect Title Defect Status Submitter Person in Charge Priority Severity Defect Description Time Screenshot

Defect level

Fatal issues: Core functions are unavailable or the system crashes

Serious problem The main business process cannot be used, and a function in the main business process has a defect that prevents the main process from continuing to use

General issues General issues, not functional defects in the main process

Minor problems interface UI problem prompts are not standardized, etc.

Suggested questions ask some suggestive questions based on your own experience

The difference between WEB test and APP test

1. The architecture is different.

The web side is based on the b/s architecture, and the b/s architecture is accessed based on the browser address

The app side is a c/s architecture, and the c/s architecture requires a client as a carrier

2. The version release method and process are different.

Web version is released, new code is developed and deployed to the corresponding server address, and the web-side update can be realized uniformly

App version, development needs to be packaged (apk package and ipa package), after packaged, it needs to be published to the corresponding channel

3. compatibility

web, test the compatibility of different browsers (ie, chrome, firefox, 360, QQ)

app, test different resolutions, screen sizes, mobile phone brands, and system versions

4. Performance aspect

web, test response time

app, test response time, traffic, power consumption, CPU, GPU, memory

5. safety

web, sql injection. xss attack etc.

app, https encryption, signature, reinforcement, password encryption, etc.

6. App test features

Suitability test

Network test

Online upgrade test

Interrupt test

Power consumption test

Weak network test

Installation and uninstallation test

Flow test

The main content of app testing

1. function test

Testing the correctness of business logic

2. Compatibility test

system version

Resolution

If a bug is considered by the developer to be not a bug, how to deal with it

Common linux commands

Under what circumstances can't locate the element

The difference between GET request and POST request

Network situation

3. Abnormal test

Hot Start

Network switch

Telephone information terminal recovery

4. Upgrade, install, uninstall

5. Robustness test

Mobile phone resource consumption

Data consumption

Battery test

Crash recovery

If a bug is considered by the developer to be not a bug, how to deal with it

1. Submit the problem to the defect management database for record.

2. Obtain the basis and standards for judgment

According to requirements specifications, product descriptions, design documents, etc., confirm whether the actual results are inconsistent with the plan, and provide a direct basis for confirming the defects;

If there is no document basis, you can explain whether there is any inconsistency based on the general characteristics of similar software to confirm whether it is a defect;

According to the user's general usage habits, to confirm whether it is a defect;

Discuss with relevant personnel such as designers, developers and customer representatives to confirm whether it is a defect;

3. Make a reasonable argument, explain the reason for your judgment to the test manager, and be objective, rigorous, and not mixed with personal emotions.

4. Wait for the test manager to make the final decision. If there is still a dispute, you can report it to the superior through the channel provided by the company's policy, and the superior can make a decision.

Common linux commands

1. ifconfig view IP address

2. cat is used to display the entire contents of the specified file

3. more displays the contents of the specified file in the form of pagination

4. mkdir create directory

5. touch to create a new file

6. grep finds the qualified string in the file

7. find Find the specified file

8. tail -f is used to automatically refresh the contents of the N rows of data after the display file

9. kill -9 forced end

10. netstat -anp | grep port number view port

11. chmod -R 777 gives 777 permissions

Under what circumstances can't locate the element

1. Wrong code

2. The element does not appear (need to wait for the element)

3. Element in iframe

4. Multi-window

5. A pop-up window appears (system pop-up window, JS pop-up window)

6. Element attribute values ​​are dynamically loaded

7. Element cannot be uniquely determined

8. Read-only attribute (element is not operable)

The difference between GET request and POST request

1. GET uses URL or Cookies to pass parameters, POST puts data in BODY

2. GET URL will have a length limit, 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, POST is used to send data

Why do interface tests

1. The lower the BUG is found, the lower the repair cost

2. When the front-end changes, the back-end interface does not need to be changed

3. Check the security and stability of the system, the front-end transmission of parameters is not credible

How is the interface test done

–Because the front-end and back-end calls of our project are mainly based on the http protocol interface, the testing of the interface 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 realized by interface automation, which is realized by code. The framework is similar to UI automation. Sending requests is judged by assertions.

Key points of interface testing

1. Check whether the data returned by the interface is consistent with the expected result

2. Check the fault tolerance of the interface, and whether it can be handled when the passed type is wrong

3. Boundary value of interface test

4. Interface performance

5. Security of the interface

http status code

1. 1xx: The request is normal, but there is no response, it can only be used in the experimental state

2. 2xx: The beginning of 2 indicates that the transmission is successful

3. 3xx: 3 represents redirection, common 302

4. 4xx: 400 means that the grammar sent by the client is incorrect, 401 means that the accessed page is not authorized, 403 does not have permission to access the page, 404 means that there is no such page, and 415 is the format error

5. 5xx: The beginning with 5 represents server exception, 500 represents server internal exception, 504 represents server timeout

The difference between cookies and session

1. Cookies data is stored on the client's browser, session data is stored on the server

2. Cookies are not very secure. Others can analyze the cookies stored locally and perform cookie spoofing. Considering security, you should use session.

3. The session will be saved on the server for a certain period of time. When the number of visits increases, it will be more occupied. Considering the performance of your server, you should use cookies to reduce server performance.

Commonly used adb commands

1. adb start-server start adb service

2. adb kill-server close adb service

3. adb devices view device number

4. adb push computer phone

5. adb pull mobile computer

6. adb logcat | grep 包名（unix）

7. adb logcat | findstr Sign up (win)

8. adb shell enter the shell command line

9. adb install install the app on the phone

10. adb uninstall uninstall app to the phone

11. adb logcat> File name output log to file

12. adb shell top test app resource consumption command

Product business process

Parsing

Ask the overall business process of a project written on your resume

For example, the registration function in the e-commerce project, the whole process from the beginning of the registration to the successful registration

What is the version that meets the online standards

Acceptance Criteria

(1) All functions defined in the software requirements analysis specification have been fully 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) All test items have no residual emergency or severe level errors.

(4) The requirements analysis document, design document and coding are consistent.

(5) Complete acceptance test artifacts (test plan, test case, test log, test notice, test analysis report, software installation process to be accepted

sequence. )

Defect repair rate standard

(1) The error repair rate of emergency and severe level should reach 100%;

(2) The error repair rate of ordinary level should reach 95% or more;

(3) Optimization level error repair rate should reach 60% or more;

Note: When the project is urgent, the normal level error repair rate reaches more than 60%; the optimized level error repair rate reaches 20%.

Server operating status response indicators

(1) The maximum usage rate of cpu% during concurrency should not exceed 70-80%. If there is a rendezvous concurrency, it may be allowed to approach or reach 100& for a short time, but most of them are not.

95% should be checked;

(2) During the memery test, ensure that the memory is sufficient and the available memory is not less than 20%;

(3) disk monitors whether the hard disk has read and write not more than 40%;

(4) The cpu load average should not exceed the number of cpu cores*2 or should not exceed the number of cpu cores.

Test case review process and related participants

1: Review process

A: Make the following preparations before starting

1. Determine the reason for review

2. Determine the time for review

3. Identify 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, the content that needs to be reviewed will be sent to the relevant personnel of the review meeting in the form of email. And indicate the time and place of the detailed review and the personnel involved in the compensation.

7. In the email, remind the relevant personnel of the review meeting to read the review content at least once, and record the related questions so that they can be raised at the review meeting.

8. The meeting host (usually a use case writer) should sort out relevant questions before the meeting so that they can be raised at the meeting.

B: Start review

1. Hold a review meeting. Participants gave comments and suggestions after the designer's explanation, and at the same time carried out a detailed review record.

2. Communicate with relevant personnel by general mail

3. General IM tools communicate directly with relevant personnel

4. Review according to the content of the review

2: Judging content

1. Whether the structural arrangement of the use case design is clear and reasonable, and whether it is conducive to efficient coverage of requirements.

2. Whether the priority arrangement is reasonable.

3. Whether to cover all the function points on the test requirements.

4. Whether the use case is well executable. For example, whether the prerequisites, execution steps, input data and expected results of the use case are clear and correct; whether there are obvious verification methods for the expected results.

5. Have redundant use cases been deleted?

6. Does it contain sufficient negative test cases? Fully defined, if the 2&8 rule is used here, it is four times the number of positive use cases. After all, in a robust software, 80% of the code is "protecting" 20% of the function implementation.

7. Whether to design test cases for user usage scenarios and usage processes from the user level.

8. Whether it is concise and reusable. For example, the highly repetitive steps or processes can be extracted and defined as some reusable standard steps.

3: Participating reviewers (here will be divided into multiple levels for review)

1. Department review, review involving all members of the testing department.

2. Company review, including project managers, requirements analysts, architecture designers, developers and testers.

3. Customer review, including the customer’s developers and testers. This situation is more common in outsourcing companies