Common Software Test Questions

I collected some common software test questions and found that I was not thinking about many questions during the test.

Http://blog.sina.com.cn/s/blog_4ffa88df0100bcis.html

Http://www.51testing.com/html/08/n-226208.html

Question 1: Why should I test software in a team?

Any software may leave defects in the development process. If a defective software product is submitted, it may cause immeasurable losses to the company. We must discover as many problems as possible before the customer, to ensure customer satisfaction. The process of discovering the problem is called testing.

 

Question 2: Briefly describe what you have done in your previous work and what you are familiar.

       This issue varies with everyone. My answer is as follows.

My main jobs are system testing and automated testing, and I have also performed a small number of performance tests. During system testing, the business logic functions of the boss system and the class5 features of the softswitch system are tested. In the performance test, the stress test is mainly used to obtain the system response time and system resource consumption in the case of different numbers of requests. Automated Testing mainly tests the characteristics of softswitch by writing scripts and combining some third-party tools.

 

Question 3: What types of software testing do you know.

1.        Basic Function verification. It mainly tests the main functions of the released version. The Common English name is smokingtest, basic verification test, or sanity check.

2.        Function test. The main purpose is to test the released version based on the requirement or requirement analysis document to see if the required version is met and whether unnecessary functions are available.

3.        Unit test. It is one of the tests conducted by developers. Generally, developers test small modules, such as functions. In general, developers also need to develop corresponding testing piles to perform such tests.

4.        Integration testing. In the large-scale development process, the software is modularized for development. If different modules are combined, the test is integrated testing.

5.        System test. After the software is submitted to the test group, all the functions of the entire system are tested. In general, functional testing is a part of system testing.

6.        Stress testing. The main reason is that the performance is close to the limit of the system when the performance is very high. Let's see how the system works.

7.        Load Testing. It mainly uses a variety of performance detection systems to collect data under these performance conditions.

8.        Black box testing. It means that the system is completely opaque to you, leaving only input and final output for you. This is one of the methods for functional testing.

9.        Gray box test. It refers to the coverage test of the system when you understand the internal working mechanism of some systems.

10.    White box testing. In the case of unit test and integration test, the developer knows the code and performs full-path coverage test on the code.

11.    Interface Test. It mainly depends on the friendliness and ease of use of the user interface, whether there are text or typographical errors, and whether there are input restrictions.

12.    Regression testing. Generally, a system detects a bug. After the developer modifies the bug, the system tests the bug directly and possibly related functions.

13.    Installation and uninstall tests.

14.    Resume the test. It mainly refers to whether a system is easy to recover from errors in the event of a disaster.

15.    Compatibility testing. A system is tested in different languages and operating systems.

16.    Security Testing. The performance of the system in the case of attacks or similar situations.

17.    AlphaTest. Before the system gives the end user, the tester simulates the end user's test in the lab.

18.    BetaTest. Tests performed by some end users through use.

19.    Comparison test. Compare with other systems with the same or similar functions.

20.    Acceptance Test. Generally, end users perform tests based on their own requirements before accepting the product. In many cases, the acceptance test may be performed by a third-party organization.

 

Question 4: What is the purpose of the test plan? What should be included in the test plan document? Which of the following are the most important?

The software testing plan is a programmatic document that guides the testing process.

Includes Product Overview, test strategy, test method, test area, test configuration, test cycle, test resources, test communication, risk analysis, and so on. With the help of the software test plan, project members participating in the test, especially test managers, can clarify the test tasks and test methods, maintain smooth communication during the test implementation process, and track and control the Test Progress, various changes during testing should be taken.

There is a strategic and tactical relationship between the test plan and the test detailed specifications and test cases. The test plan mainly plans the scope, methods, and resource configuration of the test activities from a macro perspective, the detailed test specifications and test cases are the specific tactics to complete the test task. Therefore, the most important thing is the test strategy and method (it is best to first review ).

 

Question 5: What do you think is the key to a good test plan?

1.        Clarify testing objectives and enhance the practicability of testing plans

The important purpose of preparing a software test plan is to enable the test process to discover more Software defects, so the value of the software test plan depends on its ability to help manage test projects and identify potential Software defects. Therefore, the test scope in the software test plan must cover the functional requirements highly, and the test method must be feasible. The test tool is highly practical and easy to use. The generated test results are intuitive and accurate.

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

"5 W" Rules refer to "what", "why", "when", and "where) "," how )". Using the "5 W" rule to create a software test plan can help the test team understand the purpose of the test (why), clarify the scope and content of the test (what ), determine the Test start date and end date (when), identify the test method and tool (how), and provide the test documentation and software storage location (where ).

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

After the test plan is written, if it is not reviewed, it is directly sent to the test team. The test plan content may be inaccurate or missing, or the software requirement change may cause the increase or decrease of the test scope, however, the content of the test plan is not updated in a timely manner, misleading the test execution personnel.

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

Detailed test technical indicators should be included in the detailed test specification documents created independently, place the test cases used to guide the test team to perform the test process in the independently created test case document or test case management database. There is a strategic and tactical relationship between the test plan and the test detailed specifications and test cases. The test plan mainly plans the scope, methods, and resource configuration of the test activities from a macro perspective, the detailed test specifications and test cases are the specific tactics to complete the test task.

Question 6: Common Test Case DesignWhat are the methods? Use specific examples to describe the application of these methods in the test case design.

1) Division of equivalence classes

Common Software Test Questions divide equivalence classes: equivalence classes refer to subsets of an input field. 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 equal to testing other values of this type. therefore, we can reasonably divide all input data into several equivalence classes, and take a data in each equivalence class as the input conditions for testing. Then we can use a small number of representative test data. obtain good test results. there are two differences between equivalence classes: Valid equivalence classes and invalid equivalence classes.

2) Boundary Value Analysis

The boundary value analysis method is complementary to the equivalence classification method. Test experience tells me that a large number of errors occur on the boundary of the input or output range, rather than inside the input and output range. therefore, you can design test cases for various boundary conditions to identify more errors.

When using the Boundary Value Analysis Method to Design test cases, the boundary condition should be determined first. generally, the boundary of the input and output equivalence classes is the boundary that should be tested. we should select a value equal to or greater than or less than the boundary as the test data, rather than a typical value or any value in the equivalence class as the test data.

3) incorrect inference

Based on experience and intuition, all possible errors in the program can be inferred, so as to design the test case method in a targeted manner.

The basic idea of the error inference method: list all possible errors and special circumstances that are prone to errors in the program, and select test cases based on them. for example, many common errors in modules are listed during unit testing. errors found in previous product tests are a summary of experience. In addition, when the input and output data are 0. Enter a space in the table or enter only one row in the table. These are prone to errors. You can select an example in these cases as a test case.

4) Causal Method

The equivalence division and boundary value analysis methods described above both focus on the input conditions, but do not consider the associations and combinations between input conditions. considering the combination of input conditions, there may be some new situations. however, it is not easy to check the combination of input conditions. Even if all input conditions are divided into equivalence classes, there are many combinations between them. therefore, we must consider using a combination suitable for describing multiple conditions and generating multiple actions to consider the design of test cases. this requires the use of the logical model ). the Cause-to-cause method is used to generate a decision table. it is suitable for checking various combinations of program input conditions.

5) orthogonal table Analysis

Sometimes, the number of test cases may surge due to the combination of a large number of parameters. At the same time, there is no obvious gap in priority between these test cases, testers cannot complete so many tests, so they can use orthogonal tables to reduce some use cases, so as to minimize the possibility of case coverage.

6) Scenario Analysis Method

It refers to simulating the user's operation steps based on the user scenario. This is similar to the cause and effect, but the depth and feasibility of the operation may be better.

Question 7: What do you think is the key to designing test cases?

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

The key to the Black Box case design is also to overwrite the module output and input interfaces with fewer use cases. It is impossible to perform a full test. The most problems can be found with the least number of use cases within a reasonable period of time.

Question 8: describes in detail the complete process of a test activity.

1) The Project Manager completes the requirement documents through communication with the customer, and the developers and testers review the requirements documents. The review includes: where the Requirement Description is unclear and there may be obvious conflicts or features that cannot be implemented. 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 developer completes the requirement analysis document according to the requirement document, and the tester reviews the document. The main content of the review includes whether there are omissions or whether the two parties understand the differences. The tester completes the test plan documentation, which describes the content included in the test plan.