1. What is compatibility testing? What are the focus of compatibility testing?
Compatibility testing is mainly to check whether the software can run normally on different hardware platforms and software platforms, that is, the portability of software in general.
Compatible types, if subdivided, include platform compatibility, network compatibility, database compatibility, and data format compatibility.
The focus of compatibility testing is the analysis of the compatibility environment. Generally, compatibility is only required when the environment in which the software is running is not very certain. According to the needs of the software operation, or according to the requirements document, it is generally possible to figure out the environment in which the user will use the software. After organizing these environments into a form, a compatible environment for compatibility testing can be obtained.
2. I have a program now, and I find that it runs very slowly on Windows, so how can I tell if it is a problem with the program or a problem with the hardware and software system?
Check the system for signs of poisoning.
Check whether the software/hardware configuration meets the software's recommended standards.
Confirm whether the current system is independent, that is, there is no external service that consumes CPU resources.
If it is C/S or B/S structured software, you need to check whether it is caused by a connection problem with the server or a problem with access.
When the system is not under any load, check the performance monitor to confirm the application's access to the CPU/memory.
3. What are the testing strategies?
Black box/white box, static/dynamic, manual/automatic, smoke test, regression test, public test (Beta test)
4. Describe the complete process of test case design?
Demand analysis + maintenance work for demand changes.
Draw test requirements based on requirements.
Design the test plan and review the test plan; after the plan review is passed, design the test cases, and then review the test cases.
5. What is the difference between Alpha test and Beta test?
Alpha testing (α testing) is a test conducted by a user in a development environment, or a controlled test conducted by an internal user in a company that simulates an actual operating environment.
Beta testing (beta testing), testing is a test performed by multiple users of the software in the actual use environment of one or more users, and the developer is usually not on the test site.
6. What to do if the requirements document is found to be imperfect or inaccurate during the testing activities?
You should coordinate and communicate with relevant personnel immediately.
7. What do you think is the key to a good test plan?
The software test plan is to clarify the test object before the formal implementation of the software test work, and through the comprehensive analysis and planning of resources, time, risk, test scope and budget, etc., to ensure the effective implementation of the software test.
The key to a good test plan: purpose, management, standard
8. What phases should a complete test consist of?
Test plan, test design and development, test implementation, test review and test conclusion
9. Briefly describe the relationship between integration testing and system testing?
The main basis for integration testing is the outline design specification, and the main basis for system testing is the requirement design specification.
The integration test is the test of the system module, and the system test is the test of the entire system, including the related software and hardware platform, network and related peripherals.
10. To what extent do functional test cases need to be detailed to be qualified?
This question is often asked by test engineers.
Some people advocate that the test cases should be written in detail to the implementation of each step. The purpose is that even a novice who does not understand the system can perform work according to the test cases. Those who advocate this type of writing can also cite examples: Europe, America, Japan, etc. Software outsourcing documents all do this.
Another point of view is to advocate writing thicker, similar to writing a test outline. Those who advocate this view are because the software development requirements management is not standardized and changes frequently, so test cases cannot be written in accordance with the high standards of Europe and the United States. Such test cases are easy to maintain and can give test executives more room to play.
In fact, the detailed level of software test cases must first be covered to the test point as the basic requirement. For example: the test case of "user login system" does not need to write specific execution data, but at least several kinds of test cases must be written. If only one sentence covers this function, the test case is unqualified. Covering function points does not mean to list function points, but to write out all aspects of function points (equal division can be used if there are many combinations).
Another factor that affects test cases is the organization's development capabilities and the characteristics of test objects. If the development force is relatively backward, it is unrealistic to write more detailed test cases, because there is no such large investment in resources. Of course, this situation is gradually improved with the development of the team. The key point of the characteristics of the test object refers to the requirements of the test object in terms of schedule and cost. If the schedule is tight, there is no time to write high-quality test cases, and sometimes the test work is just an auxiliary work, so Do not write test cases.
Therefore, the preparation of test cases should be based on the characteristics of the test object, the execution ability of the team and other aspects to determine the writing strategy. The last thing to note is that testers must not complain, and strive to continuously improve their own capabilities while continuously improving the level of test case writing.
11. The more defects are found, does it mean that 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, and feel a sense of personal accomplishment.
The main reasons are as follows:
Code reuse and copy code make programmers easy to make the same mistakes. Class inheritance causes all subclasses to contain errors in the base class. Repeated copying of the same code means that defects may also be copied.
More tired programmers can lead to more defects in some continuous programming functions. It is a common phenomenon for programmers to work overtime, so it is easy to write programs with more defects when they are exhausted. And these continuous latent defects are precisely where the test engineers show their talents.
"Defects are connected to one another" is not an objective law, but a common phenomenon. If the software is well written, this phenomenon is not common. Testers only need to test the program seriously.
12. Write down the steps of the bug report circulation, the person responsible for each step and the main tasks completed.
The tester submits a new bug into the library, and the error status is New.
The senior tester/test manager verifies the error, and if it is confirmed to be an error, assign it to the development team. Set the status to Open. If it is not an error, reject it and set it to Declined status.
The development manager assigns the bug to the corresponding module developer.
Developers query for bugs with Open status. If it is not an error, set the status to Declined; if it is a bug, fix and set the status to Fixed; for bugs that cannot be resolved, leave a text description and keep the bug in the Open state.
For bugs that cannot be resolved or postponed, they cannot be decided by the developers themselves. Generally, they can only be approved through a certain meeting (review meeting). The tester queries the bug with the status of Fixed, and then verifies whether the bug has been resolved, if it is resolved, set the status of the bug to Closed, if not resolved, set the status of the bug to Reopen.
13. Write some necessary content in the bug report.
Version. When submitting a defect report, this field is used to identify which version of the software under test the defect exists in
Bug report priority
Bug status
Bug number
Discoverer
Submitter
Designated processor
Overview
Detailed Description
severity
Owning module
annex
Submission date
14. Draw the V model diagram of the software test.
15. Why should software testing work be carried out in a team?
Because it is difficult to know the quality of the software before it is released without tested software, just like ISO quality certification, testing also requires quality assurance. At this time, software testing needs to be carried out in the team. In the process of testing, problems in the software are discovered, and the developers are informed and corrected in time. When the issue is about to be released, the quality of the software will be obtained from the test report.
16. What types of software testing are you familiar with? Please try to compare the differences and connections of these different test types separately?
The test types are: function test, performance test, interface test.
Functional testing accounts for the largest proportion of testing work, and functional testing is also called black box testing. It treats the test subject as a black box. When using the black box testing method for dynamic testing, it is necessary to test the function of the software product, without testing the internal structure and processing process of the software product. The methods of using black box technology to design test cases include: equivalence class division, boundary value analysis, wrong guessing, cause and effect diagram, process analysis, etc.
Performance testing is to test various performance indicators of the system by simulating a variety of normal, peak and abnormal load conditions through automated testing tools. Load testing and stress testing are both performance testing, and the two can be combined. Through load testing, determine the performance of the system under various workloads. The goal is to test the changes in various performance indicators of the system when the load gradually increases. Stress testing is a test to obtain the maximum service level that the system can provide by determining the bottleneck or unacceptable performance points of a system.
In interface testing, the interface is the most direct layer between the software and the user. The quality of the interface determines the user's first impression of the software. And a well-designed interface can guide users to complete the corresponding operations themselves, and play a role as a guide. At the same time, the interface is like a human face, which has the direct advantage of attracting users. A well-designed interface can bring users a sense of ease and joy and a sense of success. On the contrary, due to the failure of the interface design, the user has a sense of frustration. No matter how useful and powerful functions are, the user's fear and abandonment may be in vain.
The difference is that functional testing focuses on all the functions of the product, taking into account every detail 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 pays more attention to user experience, whether users use the product easily, whether it is easy to understand, whether it is standardized (shortcut keys and the like), whether it is beautiful (whether it can attract the user’s attention), whether it is safe (as far as possible in The front desk prevents users from entering invalid data unintentionally. Of course, considering the experience, it should not be too rude to pop up warnings).
17. 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, tests can be carried out to prove whether each implemented function meets the requirements. Black box testing is also called functional testing.
White box test: Knowing the internal working process of the product, testing can be used to prove whether each internal operation meets the design specifications and whether all internal components have been checked.
A unit test (module test) is a small piece of code written by a developer to check whether a small, 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 done by the programmer himself, and the programmer himself will ultimately benefit.
Integration testing (also called assembly testing, joint testing) is a logical extension of unit testing. Its simplest form is: two units that have been tested are combined into a component, and the interface between them is tested. In this sense, components refer to the integration of multiple units.
System testing is to assemble the tested subsystems into a complete system for testing. It is an effective method to check whether the system can indeed provide the functions specified in the system plan specification. (Common joint debugging test) The purpose of system testing is to conduct a comprehensive test on the final software system to ensure that the final software system meets the product requirements and follows the system design.
Acceptance testing is the last test 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 established functions and tasks of the software. Acceptance testing is to show future users that the system can work as intended. After the integration test, all the modules have been assembled into a complete software system according to the design, and the interface errors have been basically eliminated. Then the effectiveness of the software should be further verified. This is the task of the acceptance test, that is, the function and function of the software. The performance is as expected by the user.
18. What is the purpose of the test planning work? What does the test plan work include? Which of these are the most important?
The software test plan is a programmatic document that guides the test 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 the software test plan, the project members participating in the test, especially the test management personnel, can clarify the test tasks and test methods, maintain smooth communication in the test implementation process, track and control the test progress, and respond to various changes in the test process. There is a strategic and tactical relationship between the test plan and the detailed test specifications and test cases. The test plan mainly plans the scope, methods and resource allocation of test activities from a macro perspective, while the detailed test specifications and test cases are specific tactics for completing the test tasks. So the most important thing is to test the test strategy and test method.
19. What was the testing process during your previous work?
The company does not specify how to do the testing process, but each tester has his own set of testing procedures. Let me talk about the process I summarized myself. Requirements review (there are developers, product managers, testers, project managers)-"determination of requirements (a definite requirements document)-"development design documents (developers can output design documents before they start to write code)-" Think about the test strategy and write out test cases—"Send to developers, test managers and other relevant personnel (use case review)—"Receive the test version—"Execute test cases (use cases may be added in the middle)—"Submit bugs (some bugs) Need to be determined by the developer, the severity level, or suddenly found out of the scope of the test case, difficult to reproduce), some can be directly recorded into the defect management tool)-"Developer modification (can be quickly in the test process) Modifications)-"Regression test (may find new problems, and then start to run according to the process).
20. How do you respond when developers say that it is not a bug?
There are 2 situations:
First, the requirements are not determined, so I can do this. At this time, I can ask the product manager to confirm whether it needs to be changed or not. After the three parties have negotiated and determined, we will see if we need to change it.
Second, it is impossible for this situation to happen, so there is no need to modify it. At this time, I can say as much as possible the basis of the bug? If it is discovered by the user or something goes wrong, what will be the bad result? The programmer may give you many reasons, and you can refute his explanation. If it still doesn't work, then I can ask the question and confirm with the development manager and the test manager. If you want to modify it, then modify it, if you don't want to modify it, don't change it.
21. Briefly describe what are stored procedures and triggers?
A stored procedure is an object in the database, a precompiled collection of Transact-SQL statements, which are stored under a name and processed as a unit. (It can be understood as a function in C language, which has function characteristics such as parameters and return values)
A trigger is a special type of stored procedure. When the data is modified in the specified table using one or more of the following data modification operations, the trigger will take effect: UPDATE, INSERT, or DELETE.
22. Describe the hierarchical structure of the TCP/IP protocol and the important protocols in each layer.
23. In the Linux system, the access permission of a file is 755, what is the meaning?
755 means that the file owner has read, write, and execute permissions on the file, and the group users of the file owner and other users have read and execute permissions on the file.
24. Briefly describe the C/S mode and the B/S mode?
C/S mode: client/server mode. How it works: Client submits a request to Server; Server uses some methods to process this request and returns the effect to Client.
The B/S structure, that is, the Browser/Server (browser/server) structure, is a change or improvement of the C/S structure with the rise of Internet technology. Under this structure, the user interface is completely realized through the WWW browser.
Send a sentence:
The appearance of the world depends on the gaze you stare at it. Your own value depends on your pursuit and mentality. All good wishes are not possessed in waiting, but in struggle.
Finally: a wave of benefits:
I am a test lady in the workplace! Just finished the test tutorial, I will share it again. Testers who are interested in python automated testing, web automation, interface automation, mobile terminal automation, interview experience exchange, etc., can follow the WeChat public account:[Sad Spicy Strips], Obtain the interview information of the software test engineer from Dachang! My learning exchange group: 902061117 group has technical experts to communicate and share together~
If the article is of interest to you, please reach out to make a fortune and give me a like. Thank you for your support. Your likes are my motivation for continuous updates.
Recommend good articles:
What exactly should I learn in automated testing?
Which is more advanced, automated testing or manual testing?
Novice must see: How to write a qualified test case?
Python login interface test problem record and solution (dry goods)