Entry-level----black-box testing, white-box testing, manual testing, automated testing, exploratory testing, unit testing, performance testing, database performance, stress testing, security testing, SQL injection, buffer overflow, environmental testing

black box Test

　　Black box test product software as a black box, only the export and the entrance, the test process as long as you know what to enter into the black box, know the black box will come out of what results can be, do not need to know the black box inside is if done.

That is, testers do not bother to understand the software inside the specific composition and principles, as long as the user to look at the product.

　　For example, the bank transfer function, do not need to know how to transfer the specific implementation code is how to work, just want to think of themselves as various types of users, simulation of a variety of transfers to see if the system can transfer the normal.

But testing just like users is not enough. If you only do black-box testing, there must be a certain amount of risk.

　　For example, a high security software system, developers in the design of the program to take into account the need to log system logs, the software run a lot of information in the process of logging to the client's system log, and even the software client connection server side of the database connection request string is also recorded in the System log, This is bound to leak important data.

If you follow the black box test, this is the behavior inside the program, the user does not directly manipulate the database connection behavior, so check the system log this aspect of the test is not done, so it will form a hidden bug.

Some people compare black-box testing to traditional Chinese medicine by "palpation" to determine whether there is a problem.

"Hope": observe whether the software behaves normally.

"Smell": Check the output for correct results.

"Q": Enter a variety of information, combined with "hope", "smell" to observe the software response.

"Cut": like traditional Chinese medicine to the software "pulse", tapping some of the software's "joints"

White Box Test

Above the black box test analogy to Chinese medicine, then the white box test is undoubtedly western medicine. Testers need to use a variety of instruments and equipment to test software, and even put the software on the operating table anatomy to see exactly.

White box testing is a software testing technique based on understanding the internal structure of software and the operation mode of the program. It is often necessary to keep track of which functions are handled by one input in the program, and how they are handled correctly.

If you are a junior tester, you may think that you do not understand the code of the basic white box testing, in fact, this view is a certain error.

Of course, will understand the code to do white box test, that is certainly the best. But generally do white box testing, do not need to read each line of program code.

If the software is a black box, the key to the white-box test is to put a pair of X-ray glasses on the tester, and the tester can see clearly how the input to the software works in the black box.

If you don't understand the code, there are a lot of hospital-like testing instruments that can help you understand the internal workings of the program.

　　For example, for a software system connected to a SQL Server database, you can simply interpret the role of the program as: the user input data through the SQL command request back-end database, the database will return the requested data to the interface layer of the program to display to the user. the SQL Server-brought tool profiler can be said to be a precision instrument for checking SQL data transmission, documenting the interactions between the software client and the server database, allowing testers to gain insight into what the software is doing.

In the test process, black-box testing and white-box testing should be integrated, regardless of which method is used, can find a bug is a good way. A good tester should know how to use a variety of testing techniques and find the means of finding bugs.

manual testing and automated testing

Some people think that doing manual testing is a very simple thing, just a few points, and to do automation is very difficult, many people are not.

In fact, both of these methods need to be used together. Automation can not be replaced by manual, manual testing of specific non-replaceable.

Automated testing is a supplement to manual testing, mainly used in regression testing. The main focus is on stable functions, which help to verify the function of the stable module by manual testing.

For the correctness of the data, the interface is beautiful, business logic and so on to meet the degree of automation testing is not done, all need to be done by hand. After all, the machine is dead, people's judgment of right and wrong, logical reasoning ability is not a tool.

Automation Advantage is the computer's computing power, can be repeated, do not know exhaustion, for the data can be accurate, large-scale comparison, and no error.

As we can see, both manual testing and automated testing are not less, and need to be organically combined to take advantage of the advantages that testers offer in a variety of ways and means.

Exploratory Testing

The most straightforward explanation for exploratory testing is to design test cases and perform tests at the same time. This approach is typically tested by experienced testers because they have a certain amount of testing experience and know what is prone to problems.

You can also find more ways to test your test cases as you execute them. More divergent thinking is needed.

Exploratory testing is especially useful for test tasks that are not well-defined or that are used by a tester who has just received a new test task.

Unit Test

Unit test, that is, for the minimum unit in software Design-the program module for the correctness of testing work. The goal is to discover possible errors within each program module.

　　Who should be the unit test to do?

This is divided into two factions:

The faction thinks that should be done by development;

Because the code is written by the developer, developers should be responsible for the code they write, and developers are most familiar with their code, so it's easier to write than testers and get good code.

Another faction should be done by testers;

Because developers do not have a keen sense of testing like testers, they do not have the testing staff fine, so testers are required to do unit tests.

In fact, this problem is a matter of disagreement, but the best way is to cooperate with each other.

That is, the tester designs the test case, the developer writes the test code, and the tester executes the test case.

Unit-level performance testing

Performance testing is a problem that many companies ignore, or the direction of testing until the program has been developed.

Performance test Results Table Name System has a serious performance problem, the corresponding time is slow, memory consumption too much, can not support a large number of data requests, in the case of a large number of users concurrent access to the system crashes.

If we have done the whole system function after the discovery of the above bug, then to modify the program is very difficult, because if you want to completely solve the performance problem, need to readjust the system architecture design, a lot of code needs to be reconstructed, if need to make adjustments, the programmer will not only tired, A rewritten program can also cause a lot of instability and bugs.

So performance testing should be the entire production process throughout the software, including architecture design, Unit coding, integration, and release.

Performance testing should begin at the unit testing stage, from the efficiency of each line of code, to the efficiency of a method execution, to the efficiency of a logical implementation algorithm, from the efficiency of the Code to the efficiency of the stored procedure, should be optimized. Performance testing of the unit phase can be considered in the following ways:

• Code Efficiency evaluation
• Application Unit Performance Testing tools
• Database optimization

In code writing, there may not be a big problem with a single method, but it can be a big problem. These problems can be found through code-walking. If the tester is unfamiliar with the code, you can use code standards to check the work, for example: FxCop. Test and so on to help automatically find similar problems .

Testers can also use some code efficiency testing tools to help find out which code or method takes a long time to execute, such as aqtime, a tool that calculates the execution time for each line of code.

In addition to the code line efficiency testing tools, there have been some open-source unit-level performance testing frameworks, such as the use of Xunit as a unit test framework, but not for testing the correctness of the unit code, but for testing the function, whether the performance of the method meets the requirements.

such as Ntime. It can concurrently run the same method multiple times to see if the expected performance targets can be achieved. For example, the following code uses the Ntime framework to start 2 threads and execute the MyTest method multiple times in 1 seconds:

[Timerhitcounttest (98,threads = 2,unit = Timeperiod.second)]

public void MyTest ()

{

Call the method being tested

Methodtobetest ();

}

If the test results indicate that it can be performed more than 98 times, the performance of the method is considered to be standard. Conversely, it is not standard.

Entry-level----black-box testing, white-box testing, manual testing, automated testing, exploratory testing, unit testing, performance testing, database performance, stress testing, security testing, SQL injection, buffer overflow, environmental testing