Must-see software testing interview documents for testers

foreword

It's the graduation season again, and we will welcome many friends who need to be interviewed. Here, the author has prepared a top-level interview document for the friends who are engaged in software testing.

1. What is a bug? What fields (elements) does a bug consist of?
1) Some undiscovered defects or problems hidden in a computer system or program are collectively referred to as bugs

2) The bug consists of title, precondition, severity, priority, operation steps, expected result, actual result, bug cutoff

Composition such as graph or log

2. What are the severity levels of bugs stipulated by your previous company, and how are they divided?
1) Bugs are divided into 4 levels (fatal, serious, general, and minor)

2) Fatal urgent: usually manifested as: the main process cannot run through, the system cannot run, crashes or serious resource shortage, should

The modules cannot be started or exit abnormally, and the main function modules cannot be used.

Serious\high hight: usually manifested as: affecting system functions or operations, there are serious defects in main functions, but will not affect

to system stability

Average/moderate medlumao: Usually manifested as: interface, performance defects, such as: 1. Errors under boundary conditions 2. Big data

3. No progress bar is provided for large data operations

Minor/low: Usually manifested as: usability and suggestion problems

3. What are some good suggestions for daily bug writing?
1) Contains the necessary steps to reproduce the bug

2) If there are some special preconditions to be explained

3) After providing relevant screenshots of the page where the bug occurred, background log information

4) Defects (descriptions) are submitted without any words that vitiate development or criticize development

5) When submitting a defect, you must not include statements that have questions about the defect

6) Submit defects in time (there is an occasion: one month before the newcomer officially executes the test)

7) Submit even small defects

4. How to deal with controversial defects?
The development changes the defect state to not be resolved, the design is so, external reasons, etc.

1) Confirm whether it is a defect (or think it is a bug) according to the test case and requirement document again

2) Then show the corresponding requirements to the development (the development will say that the demand personnel will notify temporarily)

3) Confirm with the corresponding demand personnel. If it is confirmed that the development is correct, fill in the reason for the problem and set it to the closed state (confirm

Requirement personnel did not inform the testing department)

4) Afterwards, report the problem to the boss in the morning meeting or during working hours

5. How to deal with the small defects that the development does not want to change?
1) Make the small defects a little more serious, such as what impact will it have on users if they do not change

2) Compare products of the same type

3) Must submit to test management tool

6. How to deal with random defects?
Random defects occur occasionally or appear only once during the test process

1) Random defects should be submitted to the test management tool (screenshots and related logs should be saved as soon as a bug is found, as a

evidence or develop a mindset for solving bugs)

2) Recall the operation steps when the bug occurred, try to reproduce it as much as possible

3) Ask the development to help analyze and enable the log records of bug-related modules

4) When the random defect reappears, let the developer come over and test the machine for analysis (keep the scene)

7. How to deal with defects outside the test cases?
There are many similar situations in the test process

1) Submit a bug

2) Maintain use cases, write the operation steps of bugs into test cases

8. How to deal with repeated defect submissions?
1) Development sets the defect as a repeated bug

2) After the tester confirms that it is a repeated bug, explain the reason and close it

9. Reasons for repeated defect submission and how to solve it?
1) The division of labor of the testing department is not clear, or the cross-testing does not focus on the defect library, and the modules have intersecting partial tester assignments

unclear

2) How to solve: clear division of labor: when cross-testing, the problem is first submitted to the person in charge of the corresponding module with a document

10. In the state of the defect, which state of the defect has a great impact on development and testing?
Re-opening has a great impact on development, not a problem, but it has a great impact on testing

11. How to distinguish whether it is a front-end defect or a back-end defect? ​​(How to locate whether the bug is the front-end or the back-end)
1) After finding the bug, use fiddler to capture packets to analyze when reproducing the bug

2) If the data submitted by the front end is displayed incorrectly in fiddler, then the returned data must be incorrect, so it is

Front-end development bugs

3) If the data submitted by the front end is displayed correctly in fiddler, but the returned data is wrong, then it is the backstage open

bug

In addition to packet capture tools such as fiddler, you can also judge through the logs in the background

12. Before the version goes online, what is the status of the bug?
It is closed or deferred. The latter is left to be tested in the next version. The open and new states do not exist.

13. How to deal with the problem that hinders the test?
Notify the development to solve it immediately and update the latest patch package, and check whether there are other testing tasks during the development and repair.

Do the rest first. This is generally not the case with a sound smoke test implementation.
 

Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:

These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey, and I hope it can help you! Partners can click the small card below to receive 

 

Guess you like

Origin blog.csdn.net/kk_lzvvkpj/article/details/131646739