The most complete software testing foundation in 2023 + interview notes compiled by Byte boss (super detailed~)

1. What is software?

Software is the general term for programs and related files or documents in a computer system.

2. What is software testing?

Statement 1: Use manual or automatic means to run or measure the process of the software system to check whether the software system meets the specified requirements and find out the differences with the expected results.

Statement 2: Software testing is the process of judging and evaluating the quality or usability of software using certain methods.

3. Job content of software testing engineer

1. Look for bugs in software, and the sooner you find them, the better

2. Confirm the reproducibility of the bug and the steps in which the bug occurs

3. Confirm whether the bug has been resolved

4. Determination, writing and execution of test methods, test plans, test platforms, test codes, test cases, test documents, and test reports.

At the same time, I have also prepared a software testing video tutorial for everyone (including interviews, interfaces, automation, performance testing, etc.), which is below. If you need it, you can watch it directly, or you can directly click on the small card at the end of the article to get the information document for free.

Where to watch software testing video tutorials:

The latest 2023 [Software Testing Interview 300 Questions] Interview eight-part essay tutorial, covering automated testing/interface testing/performance testing/test development, etc.

4. Common software life cycle models

1. Big Bang Model: Advantages: Simple, no learning required. Disadvantages: Product quality cannot be guaranteed, try to avoid using it

2. Modify the model while working: Advantages: Get a runnable version quickly. Disadvantages: There is a lack of planning, resulting in large changes between versions.

3. Waterfall model: Advantages: well-planned, professional, and implemented step by step. Disadvantages: It is relatively difficult to develop quickly to seize the market. One of the optional models

4. Spiral model: Advantages: Planned changes are considered by colleagues.

5. Several stages of software development

1. Project startup phase: understand customer needs and allocate relevant resources

2. Project design stage: clarify customer needs and establish software development and testing methods

3. Project execution phase: development and testing phase

4. Project completion stage: software launch, post-maintenance and technical support

6. Five elements of software bugs

1. The software does not implement the functions listed in the manual

2. Something happened in the software that shouldn’t happen as mentioned in the manual.

3. The software does not implement things that are not mentioned in the instructions but should be implemented

4. The software is very difficult to learn and use, runs very slowly, and users think it cannot meet expectations.

7. Classification of software testing

1. Black box testing: Do not understand how the software is implemented internally, and inspect the software from an external perspective.

Black box testing methods: equivalence class boundary value, cause and effect diagram, decision table, error speculation method

2. White box testing: White box testing is the opposite of black box testing and requires understanding the structure in the software. White box testing is also called structured testing and glass box testing.

Advantages and disadvantages of black box testing and white box testing

black box testing

Advantages: There is no need to understand the software implementation details. When the internal implementation mechanism of the software changes, it is generally not necessary to modify the use cases. The implementation is relatively simple and based on the user's perspective.

Disadvantages: There is no guarantee that all major paths in the software code are covered, which can easily lead to incomplete testing.

white box testing

Advantages: Testing software codes and paths, relatively easy to debug, and easy to find the causes of bugs

Disadvantages: High requirements for testers’ programming skills, software implementation code changes, and test cases generally also need to be changed.

3. Functional testing

4.Compatibility testing

5.Performance testing

6. Security testing

7. Stress testing

8. What is a test case?

A test case is a document that describes input actual values ​​and expected output behavior or results. It also identifies the results and constraints of the test process.

9. Several major elements of test cases

Identifier, test content, input conditions, expected results, test environment information, dependencies with other test cases, test cases need to be developed, reviewed, used, maintained and saved.

Classification of software testing methods

1) White box, black box, gray box

2) Unit testing, integration testing, system testing, acceptance testing, regression testing, Alpha testing, Beta testing

3) Static testing and dynamic testing

Main methods of designing test cases

1) Equivalence class division

2) Boundary value analysis method

3) Cause and effect diagram method

4) Scenario method

[Interview theoretical knowledge]

1. What is your career development in testing?

The more testing experience, the higher the testing ability. Therefore, my career development requires time to accumulate, and I will run towards a senior test engineer step by step. And I also have a preliminary career plan. I have accumulated testing experience in the first three years. I have to follow the key points of how to be a good test engineer, constantly update myself and correct myself, and do a good job in testing tasks.

2. What qualities do you think testers need to possess?

You should have certain coordination skills when doing testing, because testers often have to contact developers to deal with some problems. If they are not handled well, it will cause some conflicts, which will make it difficult to do their work. Testers also need to have a certain amount of patience, as sometimes testing can be boring. In addition to being patient, testers cannot let go of every possible bug. Be curious, willing to explore software functions, and willing to try new software products. Have certain program development experience.

3. Why can you do testing?

Although my testing technology is not very mature yet, I think I am still qualified for the job of software testing, because software testing requires not only good technology, but also certain communication skills, patience, carefulness and other external factors. Taken together, I think I am qualified for this job.

4. What is the purpose of testing?

The purpose of testing is to find errors in software products and make the software meet user requirements as much as possible. Of course, it is impossible for software testing to find all errors.

5. What are the stages of testing?

Generally speaking, it is divided into 5 stages: unit testing, integration testing, confirmation testing, system testing, and acceptance testing.

6. What is the test object, purpose, test basis and test method of unit testing?

The test object is the program error inside the module, and the purpose is to eliminate the errors and defects in the logic and function of the local module. The test basis is the detailed design of the module, and the test method is white box testing.

7. How to treat the issue of overtime

I don’t have much objection to working overtime, but I still feel that if you can arrange your time reasonably, you won’t have to work overtime too much.

8. Combined with your previous study and work experience, how do you think you can do a good job in the test.

Based on my previous work and study experience, I believe that to do a good job, you must first have good communication. Only when communication is barrier-free can there be good collaboration and better efficiency. Another thing is that technology must be passed. , when doing tests, you need to have enough patience and good working habits. If you don’t understand, ask questions and communicate with colleagues in real time. Only in this way can you do a good job in testing.

9. Why did you choose the software testing industry?

Because I knew about the software testing industry before, I felt that its development prospects were very good.

10. Based on your previous work or study experience, describe the software development and testing process. Which roles are responsible for it and what do you do?

There must be architects, development managers, test managers, programmers, and testers. I am mainly responsible for executing test cases for the allocated modules.

11. Tell us about your understanding of software testing/quality assurance based on your experience.

Software quality assurance and testing is a batch of test cases (i.e. input data and expected output results) carefully designed based on the specifications of the software development stage and the internal structure of the program, and running the program based on these test cases to find errors. process. It is the testing of various aspects of the application to check its functionality, language validity and its visual arrangement.

12. What is the process of software testing?

Requirements survey: Comprehensively understand the system overview, application areas, software development cycle, software development environment, development organization, time schedule, functional requirements, performance requirements, quality requirements and testing requirements, etc. An estimate of the personnel, time and effort required to carry out the project based on the system profile and a project quote.

Develop preliminary project plan.

Test preparation: organizing test teams, training, establishing test and management environments, etc.

Test design: Carry out test design for each test item according to test requirements, including the design of test cases and the development of test scripts.

Test implementation: Implement tests according to the test plan.

Test evaluation: Issue a test evaluation report based on the test results.

13. What is your understanding of SQA’s responsibilities and work activities (such as software measurement)?

SQA is a project team that is independent of software development. By monitoring the software development process, it ensures that the software development process follows the specified CMM procedures (if there are corresponding CMM procedures), and provides timely suggestions and improvement plans for non-conforming items, if necessary. Report to senior managers for resolution of problems. Through this approach, the introduction of defects can be prevented, thereby reducing later software maintenance costs. The main work activities of SQA include formulating SQA work plans, participating in the review of stage products, auditing process quality, functional configuration and physical configuration, etc.; measuring data generated during the project development process, etc.

14. Tell me about your understanding of software configuration management

During the project development process, corresponding configuration management tools must be used to control changes in configuration items (including products at each stage). The use of configuration management depends on the scale and complexity of the project and the level of risk. The larger the size of the software, the more important configuration management becomes. Also in configuration management, there is a very important concept, that is, baseline, which is a combination of various configuration items at a certain stage. A baseline provides a formal standard, and subsequent work is based on this standard and can only be authorized. This standard can only be changed later. Configuration management tools mainly include CC, VSS, CVS, SVN, etc. I have only used SVN and am not very familiar with other tools.

15. How to write test plans and test cases?

To put it simply, the test plan should have detailed testing strategies and testing methods, reasonable and detailed resource arrangements, etc. As for the test cases, it depends on whether the requirements (including functional and non-functional requirements) are refined to function points and whether they are testable. wait.

16. Talk about the general situation of mainstream software engineering ideas (such as CMM, CMMI, RUP, XP, PSP, TSP, etc.) and your understanding of them

CMM: SW Capability Maturity Model Software capability maturity model, its role is to improve and evaluate software processes and evaluate software capabilities.

CMMI: Capability Maturity Model Integration Capability Maturity Model Integration CMMI incorporates most of the latest software management practices while making up for the shortcomings in the SW-CMM model.

RUP: rational unified process is a software engineering process.

XP: extreme program, which means extreme programming, is suitable for software development by small teams. Like the third question above, you can use this development process in conjunction with the prototype method. We must understand the importance of testing for XP development and emphasize the concept of testing (focusing on unit testing) first. Programming can significantly improve the quality of code, and continuous integration is good for quickly locating problems.

PSP and TSP are individual software process and group software process respectively. As we all know, CMM only tells you what to do but not how to do it, so PSP/TSP tells you what the company should do in the process of implementing CMM. PSP emphasizes building personal skills (how to make plans, control quality and how to work with others collaborate with each other, etc.). TSP focuses on producing and delivering high-quality software products (how to effectively plan and manage the project development tasks faced, etc.). In short, the implementation of CMM can never truly improve capability maturity. Only by organically combining the implementation of CMM with the implementation of PSP and TSP can it achieve maximum effectiveness. Therefore, the software process framework should be an organic integration of CMM/PSP/TSP.

17. How do you ensure the quality of software? In other words, how do you think you can ensure the quality of software to the greatest extent?

Testing cannot guarantee the quality of software to the greatest extent. The high quality of software is developed and designed, not tested. It not only requires monitoring the software development process, but also ensuring that all stages of software development must be in accordance with the specified requirements. It is carried out according to the procedures, and the optimization of development is achieved through the review of products at each stage, QA monitoring of the process, and auditing of functions and configurations. Of course, testing is also an important way to ensure software quality and an important component of software quality assurance projects.

18. Based on the current national conditions in China, most companies have tight project schedules, few personnel, and no or very irregular requirement documents. How do you think the quality of software can be guaranteed in this case? (What most companies want to know most How do you ensure the quality of software in the face of this difficulty, because this is generally the case for these companies – they don’t want to invest too much but want to ensure quality)

In the above situation, if you just want to improve software quality through testing, it is almost impossible. The reason is that there is not enough time for you to test, and there are few and irregular documents that prevent the testing requirements from being refined enough and targeted. line of testing. Therefore, as the company's quality assurance factor, we should work with the project manager to determine the software life cycle model (such as RUP's building materials, prototype method) that is consistent with the project itself, clarify the project development process, and urge the project team to carry out work in accordance with this process. All projects Team members (the project manager is more important) must develop a reasonable work plan, strengthen unit testing of the code, conduct continuous integration of the product within the customer's established product delivery date, etc. If time permits, they can cooperate with the customer to perform necessary tasks. System functional testing.

19. What qualities and skills should a test engineer have?

1-Master the basic basic testing theory

2- Conduct testing with the attitude of finding problems in the software, and do not appear to be critical.

3-Be proficient in reading requirements specifications and other documents

4-Look at the problem from the user’s point of view

5-Have a strong sense of quality

6-Careful and responsible

7-Good and effective communication method (with developers and customers)

8-With previous testing experience, you can promptly and accurately determine where the high-risk areas are.

20. Some key points for doing good software testing

1-Testers must be trained in basic testing knowledge and theory

2-Tester must be familiar with system functions and business

3-Testing must be planned, and the testing plan must be coordinated with the entire project plan

4-Writing test cases must be implemented, and the test execution phase must be based on the test cases

5-Ease of use, functions, branches, boundaries, performance and other functional and non-functional requirements must be tested

6- For complex processes, process branches must be carried out, combined condition analysis, and then equivalence class division to prepare relevant test data

7-An important part of test design is to prepare specific test data and know which scenario or branch this test data is used to test.

8-In individual tasks, on average, at least one BUG should be found for every three test cases, otherwise it only means that the quality of the test cases is not good.

9-Except for test automation that can be considered for repeated tests built every day, do not consider automating the rest for the time being.

21. Cultivation of software testers’ own qualities

1-First of all, you should be interested in software testing and have confidence in yourself. If you have these two points, then no matter what kind of difficulties you encounter during the development process, I believe you will be able to overcome them.

2-Be good at doubting. In fact, there is no absolute right. There are always mistakes. I have a rebellious mentality. What others think is impossible, I think it is possible. What others think is right, I think it is not.

3- Break the spirit of asking for answers. For BUGs that only appear once, you must find out the reasons and never give up until they are solved.

4-Keep a good mood, otherwise you may not be able to do the test well. Don't bring unpleasant emotions from life to work.

5-Be careful when doing testing. Not all bugs can be easily found. You must be careful to find these bugs.

6-Be more flexible, be smarter, and create more examples that are prone to bugs.

7-If possible, communicate with customers more often. They have what you need.

8-Put yourself in your customers’ shoes and test the system from their perspective.

9-Don't let the programmer convince you with the sentence "This situation can't happen". On the contrary, you should convince him and tell him that in customer psychology, this is not the case.

10-Consider the problem comprehensively, and consider the problem from multiple aspects such as customer needs, business processes and system architecture.

11-Don’t complicate the problem when asking it. This is contradictory to the previous point. If you are a newbie, don’t worry about this for now, because it will eventually be discussed and solved by your group members.

12-Strive for perfection, for new testers, strive for perfection, it will be good for you, even though some things cannot be done, you should try.

13-Have a sense of humor, being able to communicate well with the development team is key. Try to find a BUG killer for your development team, or say to them "I can't believe that the program you wrote has not found a BUG so far." .

22. Why should testing be carried out in a team?

Because it is difficult to know the quality of software that has not been tested before it is released. Just like ISO quality certification, testing also requires quality certification. At this time, software testing needs to be carried out in the team. During the testing process, problems in the software are discovered, and developers are informed and corrected in a timely manner. When the software is about to be released, the quality of the software is obtained from the test report.

23. What types of software testing are you familiar with?

Test types include: functional testing, performance testing, interface testing

Functional testing accounts for the largest proportion of testing work, and functional testing is also called black box testing.

Performance testing uses automated testing tools to simulate a variety of normal, peak, and abnormal load conditions to test various performance indicators of the system. Both load testing and stress testing are performance tests, and the two can be combined.

Interface testing, the interface is the most direct layer of interaction between software and users. The quality of the interface determines the user's first impression of the software.

The difference is that functional testing focuses on all functions of the product, taking into account every detailed function and every possible functional problem. Performance testing mainly focuses on the stability and robustness of the overall product under multi-user concurrency. Interface testing focuses on content related to user experience, whether the product has been used by users, whether it is easy to understand, and whether it is standardized (the user accidentally inputs invalid data, of course, considering the experience, a warning cannot be popped up too rudely). When doing a certain performance test, first it may be a function point. First, make sure that there is no problem with its function, and then consider the performance issue.

24. What do you think is the key to good test case design?

The key to white-box test case design is to cover as much of the internal program logic structure as possible with fewer test cases. The key to black box test case design is also to cover the module output and input interfaces with fewer use cases. It is impossible to test completely and find the most problems in a reasonable time with the fewest use cases. Black box testing of software means that testing is performed at the interface of the software. This method treats the test object as a black box. The tester does not consider the internal logical structure and internal characteristics of the program at all, and only relies on the program's requirement specifications. Instructions, check whether the functions of the program comply with its functional description. Therefore, black box testing is also called functional testing or data-driven testing.

Black box testing is mainly to find the following types of errors:

1- Are there incorrect or missing features?

2-On the interface, can the input be accepted correctly? Can the correct result be output?

3-Is there a data structure error or external information (such as data file) access error?

4-Whether the performance can meet the requirements

5-Are there any initialization or termination errors?

White-box testing of software is a detailed examination of the procedural details of the software. This method treats the test object as an open box, which allows testers to use the internal logical structure and relevant information of the program to design or select test cases to test all logical paths of the program. By checking the program state at different points, determine whether the actual state is consistent with the expected state. Therefore, white-box testing is also called combination testing or logic-driven testing.

White box testing mainly wants to check the program modules as follows:

1-Test all independent execution paths of the program module at least once.

2-For all logical judgments, both "true" and "false" situations can be tested at least once.

3-Execute the body of the loop within the bounds of the loop and within the bounds of the run.

4- Test the validity of internal data structures, etc.

25. Please introduce the meaning of various test types in detail.

1-Unit test (module test) is a small piece of code written by the developer to check whether a small and clear function of the code under test is correct. Generally speaking, a unit test is used to determine the behavior of a specific function under a specific condition (or scenario). Unit testing is completed by the programmers themselves, and the programmers themselves ultimately benefit. It can be said that programmers are responsible for writing functional code, and they are also responsible for writing unit tests for their own code. Executing unit tests is to prove that this code behaves as we expect.

2-Integration testing (also called assembly testing, joint testing) is a logical extension of unit testing. In its simplest form, two already tested units are combined into a component and the interface between them is tested. From this level, a component refers to an integrated aggregation of multiple units. In real-life scenarios, many units are combined into components, which are aggregated into larger parts of the program. The approach is to test combinations of fragments and eventually extend the process to test your module with other groups of modules. Finally, all the modules that make up the process are tested together.

3-System testing is to assemble the tested subsystems into a complete system for testing. It is an effective method to verify whether the system can indeed provide the functions specified in the system solution specification. (Common joint debugging test). The purpose of system testing is to comprehensively test the final software system to ensure that the final software system meets product requirements and follows the system design.

4- Acceptance testing is the last testing operation before deploying the software. The purpose of acceptance testing is to ensure that the software is ready and ready for users to perform its intended functions and tasks. Acceptance testing is about showing future users that the system will work as ordered. After integration testing, all modules have been assembled into a complete software system according to the design, and interface errors have been basically eliminated. Then the effectiveness of the software should be further verified. This is the task of acceptance testing, that is, the function and function of the software. Performance is as users would reasonably expect.

26. What is the purpose of test planning work? What does the test planning work include? Which of them are the most important?

Software test plan is a programmatic document that knows the testing process, including product overview, test strategy, test method, test area, test configuration, test cycle, test resources, test communication, risk analysis, etc. With the help of software test plans, project members involved in testing, especially test managers, can clarify test tasks and test methods, maintain smooth communication during the test implementation process, track and control test progress, and respond to various changes during the test process.

There is a strategic and tactical relationship between test plans, detailed test specifications, and test cases. Test plans mainly plan the scope, methods, and resource allocation of test activities from a macro perspective, while detailed test specifications and test cases are specific tactics for completing test tasks. So the most important ones are the testing strategy and testing methods (it is best to review them first).

27. What do you think is the key to good test planning?

1-Clear the goals of the test and enhance the practicality of the test plan

The important purpose of writing a software test plan is to enable the testing process to discover more software defects. Therefore, the value of the software test plan depends on its help in managing the test project and identifying potential defects in the software. Therefore, the test scope in the software test plan must highly cover functional requirements, the test method must be practical, the test tool must be highly practical, easy to use, and the generated test results must be accurate.

2-Adhere to the "5W" rules and clarify the content and process

The "5W" rule refers to "WHAT (what to do)", "WHY (why to do it)", "WHEN (when to do it)", "WHERE (where)" and "HOW (how to do it)". Using the "5W" rule to create a software test plan can help the testing team understand the purpose of testing (WHY), clarify the scope and content of testing (WHAT), determine the start and end dates of testing (WHEN), and indicate the testing methods and tools ( HOW), giving the location (WHERE) where the test documents and software are stored.

3-Adopt a review and update mechanism to ensure that the test plan meets actual needs

After the test plan is completed, if it is sent directly to the test team without review, the content of the test plan may be inaccurate or the test content may be omitted, or changes in software requirements may cause the test scope to increase or decrease, and the content of the test plan may not be updated in a timely manner, misleading the tester. executive staff.

4-Create test plans, test detailed specifications, and test cases respectively

Detailed test technical indicators should be included in an independently created test detailed specification document, and test cases used to guide the test team's execution process should be placed in an independently created test case document or test case management database. There is a strategic and tactical relationship between test plans, detailed test specifications, and test cases. Test plans mainly plan the scope, methods, and resource allocation of test activities from a macro perspective, while detailed test specifications and test cases are specific tactics for completing test tasks.

28. How do you deal with it when the developer says it’s not a BUG?

The developer said it was not a BUG. There are two situations. One is that the demand has not been determined, so I can do this. At this time, I can find the product manager to confirm whether any changes are needed. After the three parties have discussed and finalized, we will see whether to change it. Second, this situation cannot happen, so there is no need to modify it. At this time, I can first try my best to say what is the BUG? If it is discovered by the user or something goes wrong, what adverse consequences will there be? Programmers may You will be given many reasons that you can use to refute his explanation. If it still doesn't work, then I can raise this issue and confirm it with the development manager and test manager. If I want to modify it, I will change it. If I don't want to modify it, I won't change it. In fact, some of them are really not bugs. I just wrote them into the test documents in the suggested way. If the developers don't modify them, there won't be a big problem. If it is not a BUG, ​​you must stick to your position and let the problem be finally confirmed.

29. What do you think are the advantages of testing?

The advantage lies in my unwavering confidence and enthusiasm for testing. Although I still lack experience, I am confident that I can use the basic skills required for testing at work.

30. What is the system bottleneck?

Bottlenecks mainly refer to the inability of one or more aspects of the entire software and hardware system to meet the specific business requirements of users. "Specific" means that bottlenecks will appear under certain conditions, because after all, most systems cannot meet the specific business requirements of users before they are put into operation. .

Strictly speaking from a technical point of view, all systems will have bottlenecks, because the resource configuration of most systems is not coordinated. For example, when the CPU usage reaches 100%, it is not common for systems to run out of memory. Therefore, when we discuss system bottlenecks, we must discuss them from an application perspective: the key is to see whether the system can meet user needs. When users use the system to the limit, the system's response is still normal. We can think that there is no bottleneck in the system or that the bottleneck will not affect the user's work.

Therefore, we test system bottlenecks mainly to achieve the following two purposes:

-Discover "surface" bottlenecks. The main purpose is to simulate user operations, find out the bottlenecks when users use the system to the limit, and then solve the bottlenecks. This is the basic goal of performance testing.

-Discover potential bottlenecks and resolve them to ensure the long-term stability of the system. The main consideration is to ensure that the system can adapt to changes when users expand the system or business changes in the future. The system that meets the current needs of users is not the best. Our goal in designing the system is to ensure that the entire software life cycle of the system can continuously adapt to user changes, or that the system can adapt to new changes by simply expanding the system.

31. What does document testing mainly include?

In domestic software development management, document management is almost the weakest item, so it is not surprising that document testing is particularly easy to ignore in testing work. To provide users with a complete product, document testing is essential. Document testing generally focuses on the following aspects:

Document integrity: It mainly tests the comprehensiveness and completeness of the document content and grasps the overall quality of the document. For example, the user manual should include all functional modules of the software.

Consistency between the description and the actual situation of the software: It mainly tests the consistency between the software documentation and the actual software. For example, after the user manual is basically complete, we also need to pay attention to whether the user manual is consistent with the actual function description. Because documentation often cannot keep up with the update speed of software versions.

Comprehensibility: Mainly check whether the document has graphic descriptions of key and important operations, and whether the text and charts are easy to understand. For key and important operations, textual descriptions alone are definitely not enough. Diagrams should be attached to make the descriptions more intuitive and clear.

Examples of operations are provided in the documentation: This check is primarily for the user manual. Whether the application examples provided for the main functions and key operations are rich, and whether the descriptions of the examples provided are detailed. The user manual with only simple graphic descriptions and no examples looks like a simple copy of the software interface, which is actually of little help to users.

Printing and packaging quality: mainly to check the degree of commercialization of software documents. Some user manuals are simply printed and bound, which are too rough and difficult for users to save. Excellent documents, such as user manuals and technical white papers, should be provided in commercial packaging and printed beautifully.

32. How detailed do functional test cases need to be to be qualified?

This question is also a question often asked by test engineers. Some people advocate that the test cases should be written down in such detail as to perform each step, so that even a novice who does not understand the system can perform the work according to the test cases. Those who advocate this type of writing can also cite examples: software outsourcing documents in Europe, America, Japan and other countries all do this.

Another point of view is to advocate writing it more roughly, similar to writing a test outline. People who advocate this view are because software development requirements management is not standardized and changes are very frequent, so test cases cannot be written according to high European and American standards. Such test cases are easy to maintain and allow test executors to have more room to perform.

In fact, the detailed level of software test cases must first cover the test points as a basic requirement. For example: The test case of "User logging into the system" does not need to write specific execution data, but at least five situations must be written (). If this function is covered in only one sentence, it is an unqualified test case. Covering function points does not mean listing the function points, but writing out all aspects of the function points (equivalent division can be used if there are many combinations).

Another factor that affects test cases is the organization's development capabilities and test object characteristics. If the development force is relatively backward, it is unrealistic to write more detailed test cases because there is simply no such large resource investment. Of course, this situation will gradually improve as the team develops. The characteristics of the test object mainly refer to the requirements of the test object in terms of progress, cost, etc. If the schedule is tight, there will be no time to write high-quality test cases. Sometimes the testing work is even just an auxiliary work, so No test cases are written.

Therefore, the writing strategy of test cases should be determined based on various aspects such as the characteristics of the test object and the execution ability of the team. The last thing to note is that testers must not complain and strive to continuously improve their own abilities while continuously improving their test case writing skills.

33. What is the difference between configuration and compatibility testing?

The purpose of configuration testing is to ensure that the software can run normally on its related hardware, while compatibility testing is mainly to test whether the software can work correctly with different software.

The core content of configuration testing is to use various hardware to test the operation of the software, which generally includes:

(1) How the software runs on different hosts, such as Dell and Apple;

(2) The operation of the software on different components. For example, the developed dial-up program needs to be tested on the operation of Modems produced by different manufacturers;

(3) Different peripherals;

(4) Different interfaces;

(5) Different options, such as different memory sizes;

The core content of compatibility testing:

(1) Test whether the software is compatible on different operating system platforms;

(2) Test whether the software is compatible on different versions of the same operating system platform;

(3) Whether the software itself is forward or backward compatible;

(4) Whether the test software is compatible with other related software;

(5) Data compatibility testing, mainly refers to whether data can be shared;

Configuration and compatibility testing are generally important for developing system software, such as drivers, operating systems, database management systems, etc. The specific execution is still carried out according to the test cases.

34. What does software documentation testing mainly include?

As software documentation systems become increasingly large, document testing has become an important part of software testing. The main document test objects are as follows:

packaging text and graphics;

Marketing materials, advertisements and other inserts;

Authorization and registration form;

End User License Agreement;

Installation and setup wizard;

User manual;

Online help;

Samples, demonstration examples and templates;

……

The purpose of documentation testing is to improve ease of use and reliability and reduce support costs, because users can solve problems themselves through documentation. The main inspection contents of document testing are as follows:

Audience target - mainly whether the content of the document can be understood by readers of this level;

Terminology – mainly checking whether the terminology is appropriate for the reader;

Content and theme - check whether the theme is appropriate, whether it is missing, whether the format is standardized, etc.;

Icons and Screenshots – Check charts for accuracy and precision;

Samples and examples - whether they are consistent with the functionality of the software;

Spelling and grammar;

Relevance of the document - whether it is consistent with the content of other related documents, such as whether it is consistent with advertising information;

Document testing is a very important piece of testing work. Not only must it be given full attention, but it must also be completed seriously. Document testing must be treated like functional testing.

35. Is it possible to conduct black box testing without product manuals and requirements documents?

This problem is a problem that domestic test engineers often encounter. The root cause is that domestic software development document management is not standardized, and the change management method is even more unreasonable. In fact, when there is no documentation, testers can conduct black box testing. This testing method can be called exploratory testing. The specific method is that the test engineer continuously understands the test object in depth based on his or her professional skills, domain knowledge, etc. , Understand software functions and then discover defects.

In this approach, the software is basically treated as a product manual, and continuous communication with developers is required during the testing process. Especially when working on a project, the progress pressure is relatively high, so it can be used as an expedited testing solution. The biggest risk is not knowing if some features are missing.

36. What does the “insecticide weirdness” in the test refer to?

The term "Pesticide Strangeness" was proposed by Boris Beizer in the second edition of "Software Testing Technology" edited by him. Used to describe the phenomenon that the more tests a tester performs on the same test object, the fewer defects found. Just like if you keep using a pesticide, the pests will become immune and the pesticide will no longer be effective. The fundamental reason for this phenomenon is that testers are too familiar with the test software and have formed a fixed mindset.

In order to overcome this phenomenon, testers need to constantly write new test programs or test cases to test different parts of the program to find more defects. You can also invite new people to test the software. Newbies who have just come in can often find some unexpected problems.

37. In configuration testing, how to judge whether the defects found are general problems or specific configuration problems?

When performing configuration testing, test engineers will still find some common defects, that is, defects that have nothing to do with the configuration environment. Therefore, to determine a newly discovered problem, you need to re-execute the steps for discovering software defects in different configurations. If the software defect no longer appears, it may be a configuration defect; if it appears in all configurations, it may be a common defect.

It's important to note that configuration issues can arise in a broad class of configurations. For example, the dialer may have problems with all external modems, but the built-in modem will not have any problems.

38. Why try not to let employees who have ample time do some tests?

On the surface, this reflects the efficiency and flexibility of management, but in fact it also reflects the manager's contempt for testing. Testing has a lot to do with the people testing it. Testing staff should be diligent and patient, good at learning, thinking and discovering problems, careful and organized, and summarizing problems. If you have such advantages, you will also be excellent at other jobs, so there is another requirement here, that is, you must like Test this work. If he is full-time, he must be more experienced and confident. Domestic young men all seem to like to be programmers. The nature of their work is different, their remuneration is different, their status is different, and their understanding of the value of self-realization is also different. This is a problem that needs to be improved in the industry. If you just complete a task for the sake of completing it, or if you find a few problems and feel satisfied, this will not work in any other job.

39. Is it possible to fully test a program?

Beginners in software testing may think that after receiving the software, they need to conduct complete testing to find all software defects so that the software can be released with "zero defects." In practice complete testing is impossible. There is mainly one reason:

Complete testing is time-consuming and time does not allow;

Complete testing usually means greater resource investment, which is often not feasible in reality;

The amount of input is too large to be tested one by one;

There are too many output results and can only be classified for verification;

There are too many ways to implement software;

There is no objective standard for software product specifications. From different perspectives, the standards for software defects are different;

Therefore, the extent of testing should be determined based on the actual situation.

40. Where are the risks of software testing mainly reflected?

By not fully testing the software, we are actually choosing risk, because defects are most likely to exist in parts that have not been tested. For example, for the sake of convenience, programmers will pop up some prompt information boxes when debugging a program, and these prompts will only pop up under certain conditions. It happens that some of these codes were not commented out before the program was released. The test engineer did not test it during the test. If a customer encounters it, it will be a costly defect as it will not be discovered until after delivery.

Therefore, we must try our best to select the most appropriate test volume and minimize the risk.

41. Does the more defects found mean there are more software defects?

This is a relatively common phenomenon. Test engineers will rack their brains before finding a defect, but after finding one, they will find many defects one after another, which gives them a sense of personal accomplishment. The main reasons are as follows:

Code reuse and copying code make programmers prone to making the same mistakes. Class inheritance causes all subclasses to contain errors in the base class, and copying the same code repeatedly means that defects may also be copied.

- Programmers are more tired, which can lead to more functional defects in some continuous writing. It is a common phenomenon for programmers to work overtime, so it is easy to write programs with many defects when their physical strength is not enough. And these continuous latent defects are exactly where test engineers come into play.

"Defects one after another" is not an objective law, but a common phenomenon. If the software was written better, this phenomenon would be less common. Testers only need to follow the testing procedures seriously.

42. Can all software defects be repaired? Do all software defects need to be repaired?

Technically, all software defects can be fixed, but it is not necessary to fix all software defects. What testers need to do is to be able to correctly judge when they cannot pursue software perfection. For the entire project team, what needs to be done is to make trade-offs for each software defect and decide which defects to fix based on risk. The main reasons why this phenomenon occurs are as follows:

Not enough time resources. In any project, there are usually not enough developers and testers, and there is not enough regression testing time budgeted in the project. In addition, modifying defects may introduce new defects, so there is strong pressure on the delivery deadline. In this case, some defective modifications must be abandoned.

Some defects only occur under special circumstances. Such defects are considered in commercial interests and can be fixed in future upgrades.

A defect that is not a defect. We often encounter certain functional problems that are treated as defects. Such problems can be considered and dealt with later when we have time.

The last thing to say is that software testers, project managers, and programmers must discuss whether to fix defects. People with different roles think from different perspectives to make the right decision.

43. Are software testers QA?

The responsibility of software testers is to find software defects as early as possible and ensure that they can be fixed. The main responsibility of quality assurance personnel (QA) is to create or formulate standards and methods to improve software development capabilities and reduce software defects. The main job of testers is testing. An important part of the daily work of quality assurance personnel is inspection and review. Testing work is also the work target of test assurance personnel.

Software testing and quality are complementary to each other, and both work to improve software quality.

44. How to reduce the losses caused by testers changing jobs?

Job-hopping is a common phenomenon in the IT industry, and job-hopping will bring certain losses to both the company and the individual. The testing team will undoubtedly face the threat of job-hopping. As a test manager, you can only minimize losses by starting from your daily work. It is recommended that we start from the following two aspects:

Strengthen mutual learning among employees within the department. Mutual learning is a basic requirement for establishing a learning organization and is a process of mutual transfer of knowledge. On this basis, the technology owned by individuals can be deposited in the form of knowledge, thus completing the transformation from tacit knowledge to explicit knowledge.

Under normal circumstances, when a company can provide employees with enough development space, employees will not leave the company voluntarily unless their remuneration is particularly low. Therefore, if we want to retain employees, managers should link employees' personal growth with the development of the company, set reasonable development plans for employees and implement them. However, this requirement needs to be supported by a better corporate culture.

45. What is the difference between test products and test projects?

It is customary to commercialize software after development and sell it to users with almost no code modifications, that is, software that can be bought and sold as copies, such as Windows 2000. Software developed for one or several specific users is usually called a software project. A software project is a personalized product that can be completely redeveloped according to user requirements, or existing software products can be modified to meet specific needs. User needs. The different characteristics of projects and products determine that there will still be many differences between our test products and test projects:

Quality requirements are different. Usually the quality of the product is higher, and the cost of repairing the defects of the product after release is higher, and may even bring many negative impacts. Projects are usually aimed at a certain user. Although the higher the quality, the better, but generally it only needs to meet the user's requirements.

The amount of testing resources invested varies. Software products are usually developed by R&D centers, so there is less progress pressure. At the same time, due to high quality requirements, more human and material resources will be invested.

At the end of the project, the project must be jointly accepted and tested with users, which is a feature that product testing does not have.

In addition, test products and test projects will be very different in terms of defect management and test strategy formulation. Test managers should complete the work appropriately based on the specific environment.

46. ​​What are the points to note when testing with users (UAT testing)?

Software products usually undergo user acceptance testing before being put into production. If the user acceptance test fails, the direct result is that the money is lost, and the indirect impact is that the company's image is damaged, and the latter impact is often more serious. According to the author's experience, user acceptance testing must satisfy users.

In fact, user field testing tends to be more of a demonstration. On the premise of not deceiving users, we show users the advantages of our software. In the end, our goal is to satisfy "God" and happily take out the "money". Therefore, user testing should pay attention to the following matters:

(1) User on-site testing cannot test all functions, so core functions must be tested. This requires preparation in advance. These core functions must be tested in advance to prove that there are no problems before they can be tested with users. The purpose of testing core modules is to build user confidence in the software. Of course, if these modules have many problems, they should not be demonstrated.

(2) If there are indeed problems with some modules, we can demonstrate other important business function modules and provide reasonable explanations to users if necessary. After gaining time, correct the defects in time to make up for them.

(3) Never deceive users and get away with it. The reason is very simple, because the software is for users to use, and problems will be exposed sooner or later unless you can modify them immediately.

When testing with users, you also need to pay attention to various communication skills, so as to not only satisfy short-term interests, but also lay a solid foundation for future cooperation.

47. How to write a test report submitted to users?

As testing work becomes more and more important, it is inevitable for development teams to provide test documents to customers. Many people will ask: "Can we provide on-the-job test reports to customers?" The answer is no. Because providing internal test reports may cause customers to lose confidence or even deny the project.

Test reports are generally divided into internal test reports and external test reports. The internal report is our project document in the testing work, which reflects the implementation of the testing work. We will not discuss it too much here. Readers can refer to relevant teaching materials. Here we mainly discuss how to write external test reports. Generally, external test reports must meet the following requirements:

It is written based on the internal test report, which can generally be excerpted;

Serious defects cannot be reported to customers. Even if the defects have been corrected, there is no need to let customers know about defects in development;

Some defects can be listed on the report, but they must be medium-level defects, and these defects must be repaired;

The content in the report must be as true and reliable as possible;

The entire test report must be carefully reviewed to try not to bring negative effects to the project, especially the performance test report.

In short, external test reports should be written carefully.

48. What is the role of testing tools in testing work?

Many domestic test engineers are quite obsessed with testing tools, especially some novices, and even expect testing tools to replace manual testing. Testing tools play an auxiliary role in testing work and are generally used to improve testing efficiency. Automated testing makes up for the shortcomings of manual testing and reduces a certain amount of workload. In fact, testing tools cannot replace most manual tests, and some automated tests such as performance testing cannot be completed manually.

Automatic testing technology should be treated separately according to different situations of the software. Generally, automatic technology will be applied in places that cause a lot of repetitive work, system pressure points, and any place where programs are suitable for solving large batches of input data. Then look for a suitable automatic testing tool, or develop your own test program. Be sure not to use testing tools for the sake of using them.

49. What are the common test case design methods? Please use specific examples to illustrate the application of these methods in test case design work.

1-Equivalence class division

Common software testing interview questions divide equivalence classes: Equivalence classes refer to a subset of an input domain. In this subset, each input data is equivalent to exposing errors in the program. It is reasonably assumed that: Testing the representative value of an equivalence class is equivalent to testing other values ​​of this class. Therefore, all input data can be reasonably divided into several equivalence classes, and one data in each equivalence class is taken as the input condition of the test. You can use a small amount of representative test data to obtain better test results. There are two different situations for equivalence class division: valid equivalence classes and invalid equivalence classes.

2-Boundary value analysis method

The boundary value analysis method is a supplement to the equivalence class division method. Testing work experience tells me that a large number of errors occur at the boundaries of the input or output range, rather than within the input and output range. Therefore, designing test cases for various boundary conditions can detect more errors.

When using the boundary value analysis method to design test cases, you should first determine the boundary conditions. Usually the boundaries of the input and output equivalence classes are the boundary conditions that should be focused on testing. Values ​​that are exactly equal to, just larger than, or just smaller than the boundary should be selected as test data. Instead of selecting typical values ​​or arbitrary values ​​in the equivalence class as test data.

3-Wrong guessing method

Based on experience and intuition, speculate on all possible errors in the program, thereby designing test cases in a targeted manner.

The basic idea of ​​the error speculation method: List all possible errors in the program and the special situations where errors are prone to occur, and select test cases based on them - for example, many common errors in modules that were listed during unit testing - previous products Errors discovered during testing, etc., these are the summary of experience. Also, the input data and output data are 0. The input form is blank or the input form has only one row - these are error-prone situations. Examples of these situations can be selected as test cases.

4-Causal diagram method

The equivalence class division method and boundary value analysis method introduced earlier focus on considering the input conditions, but do not consider the connection between the input conditions, mutual combination, etc. - considering the mutual combination between the input conditions, some new ones may be generated. situations - but it is not an easy task to check the combination of input conditions. Even if all input conditions are divided into equivalence classes, there are quite a lot of combinations between them - so it is necessary to consider using a method suitable for describing a variety of conditions. The combination of multiple actions will be considered to design test cases - this requires the use of cause-and-effect diagrams (logical models) - the final result generated by the cause-and-effect diagram method is a decision table - which is suitable for checking various combinations of program input conditions.

5-Orthogonal table analysis method

Sometimes, the combination of a large number of parameters may cause a surge in the number of test cases. At the same time, there is no obvious gap in priority between these test cases, and the testers cannot complete such a large number of tests, they can pass the normal test. Submit the table to reduce some use cases, so as to achieve the possibility of covering as large a range as possible with as few use cases as possible.

6-Scenario analysis method

It refers to simulating the user's operation steps based on user scenarios. This is similar to a cause-and-effect diagram, but may have better execution depth and feasibility.

50. What do you think is the key to good test case design?

The key to white-box test case design is to cover as many internal program logic results as possible with fewer test cases.

The key to black box method use case design is also to cover the module output and input interfaces with fewer use cases. It is impossible to test completely and find the most problems in a reasonable time with the fewest use cases.

51. Describe the complete process of a testing activity in detail.

1-The project manager completes the requirements document through communication with the customer, and developers and testers jointly complete the review of the requirements document. The review content includes: areas where the requirement description is unclear and areas where there may be obvious conflicts or unachievable functions. . The project manager completes the project plan by integrating the opinions of developers, testers and customers. Then sqa enters the project and starts statistics and tracking

2-The developers complete the requirements analysis document based on the requirements document, and the testers conduct a review. The main content of the review includes whether there are any omissions or differences in understanding between the two parties. The tester completes the test plan document, and the content included in the test plan is described above.

3-Testers start writing test cases based on the modified requirements analysis document, while developers complete the outline design document and detailed design document. These two documents become supplementary materials for testers to write test cases.

4- After the test cases are completed, testing and development need to be reviewed.

5-Tester builds environment

6- When developers submit the first version, there may be unfinished functions that need to be explained. Testers conduct tests and submit bugs to bugzilla after discovering them.

7-Develop and submit the second version, including bug fixes and added functions, for testers to test.

8- Repeat the above work. Generally, the number of bugs will be reduced after 3-4 versions and meet the shipping requirements.

9-If there are problems reported by customers, testers are required to assist in reproduction and regression testing.

52. Have you ever engaged in performance testing work in the past? Please describe the complete process of your previous performance testing work in as much detail as possible.

I have done a performance test on a network management system, mainly testing whether the software can meet the requirements in terms of response time, CPU/disk/memory and other parameters when managing a large number of terminals at the same time.

I have also done call performance testing of softswitch systems, mainly to test whether the response time, call success rate, cpu/disk/memory and other parameters of the softswitch system meet the design requirements when there are a large number of calls.

53. In your previous work, what content did a software defect (or bug) record contain? How to submit a high-quality software defect (bug) record?

1-In traditional bugzilla, the bug description should include the following information

2-The software version corresponding to the bug generation

3-Developed interface personnel

4-bug priority

5-Severity of the bug

6-The module the bug may belong to. If you cannot confirm it, you can use the developer to judge it.

7-bug title needs to clearly describe the phenomenon

8-Bug description, you need to try your best to give the steps to re-bug

The relevant logs and screenshots can be given in the 9-bug attachment.

High-quality bug records refer to bug records that are easy to understand. Therefore, they have high requirements for description and can provide a lot of accurate information, which can help developers position themselves well.

54. Have you used any testing tools when you were engaged in performance testing? If so, please describe the working principle of the tool, and use a specific working example to describe how the tool is applied in actual work.

In testing the network management system, using Mimic to simulate terminals can save a lot of costs.

When testing the softswitch system, I used prolab to simulate the terminal and send calls to the softswitch. It completed the off-hook dialing work that could only be completed by hundreds of people at the same time. The main working principle is to generate some IP packets that meet the requirements and send them to the softswitch. The system also processes the response of the softswitching system and determines the next action.

55. What do you think is the purpose of performance testing? What is the key to doing a good job in performance testing?

The main purpose is to ensure that the service can be used normally when there are a large number of users.

56. Please try to compare the differences and connections between black box testing, white box testing, unit testing, integration testing, system testing, and acceptance testing.

Black box testing: Knowing the functional design specifications of the product, testing can be performed to prove whether each implemented function meets the requirements.
White box testing: The internal working process of the product is known, and it can be tested to prove whether each internal operation meets the design specifications and whether all internal components have been inspected.

Black box testing of software means that testing is performed at the interface of the software. This method treats the test object as a black box. The tester does not consider the internal logical structure and internal characteristics of the program at all, and only checks whether the function of the program meets its functional description based on the program's requirements specification. Therefore, black box testing is also called functional testing or data-driven testing.

Black box testing is mainly to find the following types of errors:
  1. Are there incorrect or missing functions?
  2. Can input be accepted correctly on the interface? Can it output correct results?
  3. Are there any data structure errors or external information (such as data file) access errors?
  4. Can the performance meet the requirements?

57. Are there any initialization or termination errors?

White-box testing of software is a detailed examination of the procedural details of the software. This method treats the test object as an open box, which allows testers to use the internal logical structure and related information of the program to design or select test cases to test all logical paths of the program. Determine whether the actual state is consistent with the expected state by checking the program state at different points. Therefore, white-box testing is also called structural testing or logic-driven testing. White box testing mainly wants to check the program module as follows:
  1. Test all independent execution paths of the program module at least once.
  2. For all logical judgments, both "true" and "false" situations can be tested at least once.
  3. Execute the loop body within the boundaries of the loop and the boundaries of the operation.
  4. Test the validity of internal data structures, etc.
  A unit test (module test) is a small piece of code written by the developer to verify whether a small, well-defined function of the code under test is correct. Generally speaking, a unit test is used to determine the behavior of a specific function under a specific condition (or scenario).
  Unit testing is completed by the programmers themselves, and the programmers themselves ultimately benefit. It can be said that programmers are responsible for writing functional code, and they are also responsible for writing unit tests for their own code. Executing unit tests is to prove that this code behaves as we expect.
  Integration testing (also called assembly testing, joint testing) is a logical extension of unit testing. In its simplest form,
  two already tested units are combined into a component and the interface between them is tested. In this sense, a component refers to an integrated aggregation of multiple units. In real-life scenarios, many units are combined into components, which are aggregated into larger parts of the program. The approach is to test combinations of fragments and eventually extend the process to test your module with other groups of modules. Finally, all the modules that make up the process are tested together.
  System testing is to assemble the tested subsystems into a complete system for testing. It is an effective method to verify whether the system can indeed provide the functions specified in the system solution specification. (Common joint debugging tests)
  The purpose of system testing is to comprehensively test the final software system to ensure that the final software system meets product requirements and follows the system design.
  Acceptance testing is the last testing operation before deploying the software. The purpose of acceptance testing is to ensure that the software is ready and can be used by end users to perform the software's intended functions and tasks.
  Acceptance testing demonstrates to future users that the system will work as intended. After integration testing, all modules have been assembled into a complete software system according to the design, and interface errors have been basically eliminated. Then the effectiveness of the software should be further verified. This is the task of acceptance testing, that is, the function and function of the software. Performance is as users would reasonably expect.

58. What is the purpose of test planning work? What does the test planning work include? Which of these are the most important?

Software test plan is a programmatic document that guides the testing process, including product overview, test strategy, test method, test area, test configuration, test cycle, test resources, test communication, risk analysis, etc. With the help of software testing plans, project members involved in testing, especially test managers, can clarify testing tasks and testing methods, and maintain testing

Communicate smoothly during the implementation process, track and control test progress, and respond to various changes during the test process.

There is a strategic and tactical relationship between test plans, detailed test specifications, and test cases. Test plans mainly plan the scope, methods, and resource allocation of test activities from a macro perspective, while detailed test specifications and test cases are specific tactics for completing test tasks.

So the most important thing is to test the testing strategy and testing method (it is best to review it first)

59. What do you think is the key to good test planning?

1. Clarify the goals of the test and enhance the practicality of the test plan

The important purpose of writing a software test plan is to enable the testing process to discover more software defects. Therefore, the value of the software test plan depends on its help in managing the test project and identifying potential defects in the software. Therefore, the testing scope in the software testing plan must highly cover functional requirements, the testing method must be practical, the testing tools must be highly practical and easy to use, and the generated test results must be intuitive and accurate.

2. Adhere to the "5W" rule and clarify the content and process

The "5W" rule refers to "What (what)", "Why (why you do it)", "When (when to do it)", "Where (where)", "How (how to do it)". Using the "5W" rule to create a software test plan can help the testing team understand the purpose of testing (Why), clarify the scope and content of testing (What), determine the start and end dates of testing (When), and indicate the testing methods and tools ( How), giving the storage location of test documents and software (Where).

3.Adopt a review and update mechanism to ensure that the test plan meets actual needs

After the test plan is written, if it is sent directly to the test team without review, the content of the test plan may be inaccurate or missing test content, or changes in software requirements may cause an increase or decrease in the test scope, and the content of the test plan may not be updated in a timely manner, which may be misleading. Test Executive.

4. Create test plans, detailed test specifications, and test cases respectively

Detailed test technical indicators should be included in an independently created test detailed specification document, and test cases used to guide the test team to perform the test process should be placed in an independently created test case document or test case management database. There is a strategic and tactical relationship between test plans, detailed test specifications, and test cases. Test plans mainly plan the scope, methods, and resource allocation of test activities from a macro perspective, while detailed test specifications and test cases are specific tactics for completing test tasks.

60. What are the test case design methods that you are familiar with? Please use specific examples to illustrate the application of these methods in test case design work.

1. Equivalence class division

Divide equivalence classes: An equivalence class refers to a subset of an input domain. In this subset, each input data is equivalent to exposing errors in the program. It is also reasonably assumed that: testing an equivalence class The representative value is equal to the test of other values ​​of this type. Therefore, all input data can be reasonably divided into several equivalence classes, and one data in each equivalence class is taken as the test

By inputting conditions, you can use a small amount of representative test data to obtain better test results. There are two different situations for equivalence class division: valid equivalence classes and invalid equivalence classes.

2. boundary value analysis

The boundary value analysis method is a supplement to the equivalence class division method. Testing work experience tells me that a large number of errors occur at the boundaries of the input or output range, rather than within the input and output range. Therefore, designing test cases for various boundary conditions can detect more errors.

When using the boundary value analysis method to design test cases, you should first determine the boundary conditions. Usually the boundaries of the input and output equivalence classes are the boundary conditions that should be focused on testing. Values ​​that are exactly equal to, just larger than, or just smaller than the boundary should be selected as test data. Instead of selecting typical values ​​or arbitrary values ​​in the equivalence class as test data.

3.error guessing 

Based on experience and intuition, speculate on all possible errors in the program, thereby designing test cases in a targeted manner.

The basic idea of ​​the error speculation method: List all possible errors in the program and the special situations where errors are prone to occur, and select test cases based on them. For example, many common errors in modules have been listed during unit testing. Previous products Errors that have been discovered during testing, etc., these are the summary of experience. Also, the cases where the input data and output data are 0.

The input form has spaces or only one row. These are error-prone situations. Examples of these situations can be selected as test cases.

4. Cause and Effect Diagram Method

The equivalence class division method and boundary value analysis method introduced earlier focus on considering the input conditions, but do not consider the connection between the input conditions, mutual combination, etc. Considering the mutual combination between the input conditions, some new ones may be generated. situation. But it is not easy to check the combination of input conditions. Even if all input conditions are divided into equivalence classes, there are quite many combinations between them
. Therefore, it is necessary to consider using a method suitable for describing multiple conditions. Combinations of multiple actions are generated to consider designing test cases. This requires the use of cause-and-effect diagrams (logical models). The final result generated by the cause-and-effect diagram method is a decision table. It is suitable for checking various combinations of program input conditions.

61. Have you ever been engaged in performance testing work in the past? If so, please describe the complete process of your previous performance testing work in as much detail as possible.

Yes, I have done website performance testing before, although the time I did it was not long ago (about 2 months). At that time, a senior with very rich experience in website performance testing took me to do it together.
  Performance testing types include load testing, strength testing, capacity testing, etc.
  Load testing: Load testing is a performance test that refers to whether the program can withstand the data running in an overload environment.
  Strength test: Strength test is a kind of performance test. It measures the operation of the software system when the system resources are particularly low. Capacity test
  : Determine the maximum number of users online at the same
  time that the system can handle. When the website traffic gradually increases, start to consider doing so. After performing the performance test, you must first write a performance test plan and determine the page with the largest traffic based on the operational data (if it is the first time, it is usually the homepage, download page, and personal account page with the largest traffic, and at a certain percentage)

Web server indicators:
  * Avg Rps: average number of responses per second = total request time/second;
  * Successful Rounds: successful requests;
  * Failed Rounds: failed requests;
  * Successful Hits: number of successful clicks;
  * Failed Hits: The number of failed clicks;
  * Hits Per Second: The number of clicks per second;
  * Successful Hits Per Second: The number of successful clicks per second;
  * Failed Hits Per Second: The number of failed clicks per second;
  * Attempted Connections: The number of attempted links ;

62. What is system testing? What aspects need to be considered?

1) System testing is to combine the confirmed software, computer hardware, peripherals, networks and other elements to conduct various assembly tests and confirmation tests of the information system. The purpose is to discover all the information system requirements by comparing them with the system requirements. Where the developed system does not match or contradicts user needs, a more complete solution can be proposed.

2) Its mission is to check out errors in the program as thoroughly as possible and improve the reliability of the software system. Its purpose is to check "how is the system doing?" This stage can be divided into three steps: module testing, testing whether the program of each module has errors; assembly testing, testing whether the interface between modules is correct; confirmation testing, testing whether the entire software system meets user function and performance requirements . At the end of this stage, a test report should be delivered, explaining the selection of test data, test cases and whether the test results meet the expected results.

3) After the problem is discovered in the test, debugging should be carried out to find out the cause and location of the error, and then make corrections. It is a black box test based on the overall system requirements specification and should cover all joint components of the system.

4) System testing is a test for the entire product system. The purpose is to verify whether the system meets the definition of the requirement specifications and to find out the areas that are inconsistent with or contradictory to the requirement specifications.

The objects of system testing include not only the software of the product system that needs to be tested, but also the hardware, peripherals and even some data, some supporting software and its interfaces on which the software depends. Therefore, the software in the system must be combined with various dependent resources and tested in the actual operating environment of the system.

63. How to become a qualified software testing engineer?

1) Computer professional skills

2) Test professional skills

3) Software programming skills

4) Knowledge of network, operating system, database, middleware, etc.

5) Have a strong sense of responsibility, have a tireless attitude towards testing work, and communicate more with demand personnel and R&D personnel.

64. An officer asked 24 soldiers to stand in 6 rows, with 5 people in each row. The soldiers were all stupid. The last soldier finally came up with a good idea. How did he arrange it?

Just arrange it in a hexagon

65. What do you think is the key to good test planning?

Understand the business requirements of the project or system

Coordinate with the project manager to understand the project schedule and arrangement

66. What is the process of software testing?

Requirements survey: Comprehensively understand your system overview, application areas, software development cycle, software development environment, development organization, time schedule, functional requirements, performance requirements, quality requirements and testing requirements, etc.

An estimate of the personnel, time and effort required to carry out the project based on the system overview and a project quote.

Develop a preliminary project plan: Our testing plan is developed in full collaboration and consultation with you.

Test preparation: organizing test teams, training, establishing test and management environments, etc.

Test design: Carry out test design for each test item according to test requirements, including the design of test cases and the development of test scripts.

Test Implementation: Implement testing according to the test plan.

Test evaluation: Issue a test evaluation report based on the test results.

67. Final graphic summary

 

Interview question document collection point

PS: Here is a collection of self-study tutorials for software testing. It should be helpful to friends who are developing in the testing industry. If you need it, you can dd me. In addition to basic introductory resources, bloggers also collect a lot of advanced automation resources. From theory to practice, only by integrating knowledge and action can you truly master it. The full set of content has been packaged on the network disk, and the total content is close to 100G.

☑ 240 episodes - a complete set of video courses from zero to mastery
☑ [Courseware + Source Code] - complete supporting tutorials
☑ 18 sets - source code of practical testing projects
☑ 37 sets - testing tool software package
☑ 268 - real interview questions
☑ 200 templates - Interview resume template, test plan template, software test report template, test analysis template, test plan template, performance test report, performance test report, performance test script case template (complete information)

These materials should be the most comprehensive and complete preparation warehouse for friends who do [software testing]. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you! Everything must be done early, especially in the technical industry, where technical skills must be improved.

Guess you like

Origin blog.csdn.net/huace3852/article/details/132806116