Negative test (Negative testing)

Very useful, together with everyone.
The negative test (Negative testing) is relative to the positive test (Positive testing). They are also two very important partitions of the test design. To put it simply, a positive test is to test whether the system has done what it should, and a negative test is to test whether the system does not perform what it should not do. Image, positive test is like a respectful pupil, the teacher told me to do what I do, and the negative test is like a mischievous child, you ask me to do so, I do not, and against you. Developers are also the most hated to modify this type of bug.

The positive test mainly according to the demand, the function instruction, the design document and so on related reference document to carry on the test, but the negative test mainly according to the false guessing, the reverse thinking to test the system, certain procedure's dependence tester's experience accumulates.

When performing negative tests, it is not only necessary to test whether the system has handled the user's unusual operations, but also to check whether the system has given the correct error prompts for these exception actions. It is the system to continue the correct operation of the user guidelines.

In short, the trilogy of negative testing is:

1, check the program screen or page is given a clear and full of hints or constraints;
2, test whether the system handled the user's abnormal operation;
3, check the system to see if the error is clear and full.

The following is Steve Miller's top Negative test Cases, which generally mentions some of the tests that often need to be noticed when doing negative testing.

Negative test cases are designed to test software in a way that the software is not intended to be used, and it should also be part of the test effort. Here are ten negative test cases you should consider when designing your test workload.

1, implanted single quotes. Most sql-based database systems have problems when users store information that contains one single quote, such as John's car. Every screen that can accept text-numeric data entries try to enter text that contains one or more single quotes.

"Supplements" are not just single quotes, but basically testers should test all the special character Fu/spaces (spaces before and after the text). Single quotes, comma,/,<,> (for Web applications) are easy to raise errors. Developing an early test group can suggest that the development group write a generic function to handle these special characters, and then apply this function to avoid such errors when processing user input.

2, must enter the data entry. The function specification should clearly indicate the field on the screen where the data entry must be entered. Each field on the test screen is described as having to be entered to ensure that it forces you to enter data in the field.

Supplemental for fields that are forced to enter, it is better to have some identification on the screen to indicate that it is a field that must be entered. Usually in front of the field or after the red * sign. You must check that the identified field is consistent with the function specification or other reference document, that the error message is correct, and that the field that you are forced to enter is really mandatory.

3, field type test. The function specification should clearly indicate the fields that require specific data entry requirements (Date field, Number field, phone number, zip code, and so on). Each of the test screens is indicated to have a specific type of field to ensure that you enter data in the correct format based on the field type (numeric fields should not allow characters or special characters, date-type fields should allow entry of a correct date, and so on)

In fact, there is also a test of field format and field content. Some fields have a requirement for the format you enter, and the format of these fields is generally displayed on the screen with appropriate hints. So you need to test that the presentation is reasonable (consistent with the function specification or other reference document) and that the system correctly recognizes the format of the input. Some fields have restrictions on the contents of a field, such as a common user name, cannot contain special characters, and the first word cannot be digital. Therefore, the test will need to test the format of the hint is reasonable (consistent with the function specification or other reference documents) there is not meet the content requirements of the data input when the system is handled correctly.

4, field length test. The function specification should clearly indicate the number of characters that can be entered in the field (for example, the first name must be 50 or fewer characters). Write test cases to ensure that you can only enter a specific number of characters. Prevents the user from entering more elegant text character the error message given by a user who has entered too many characters than the allowable range.

"Supplemental" is generally used to limit the length of the field, and now development is mostly the method of restricting input (set the length of the field) to deal with. So the test needs to test the length of the limit is reasonable (and the function specification or other reference documents), for the field without limit length, to test the infinite input error, if there is a problem to report the bug when the developer to limit the length.

5. The boundary test of the digital type. For numeric fields, it is important to test the upper and lower bounds. For example, if you are calculating interest on an account, you will never enter a negative interest number for an account that should win interest. Therefore, you should try to use negative tests. Similarly, if a function specification requires a field to be in a particular range (such as from 10~50), you should try to enter 9 or 51, which should give a decent message indicating failure.

6, the number of constraint testing. Most database systems and programming languages allow numeric entries to be recognized as integers or long integers. Generally, the range of integers is from the -32,767~32,767, the range of long integers from the -2,147,483,648~2,147,483,647. For numeric data entries that do not have a specific boundary limit, use these restrictions to test to make sure that no overflow error occurs for the number.

The "Supplemental" decimal field also requires extra testing. For fields that do not indicate numeric types, try to enter negative integers, negative decimals, 0, positive integers, and positive decimal numbers for testing.

No matter what kind of database system, there are generally many numeric types for numbers. So testers are sure to test the overall.

7, date boundary test. For date-type fields, it is important to test the upper and lower bounds. For example, if you are checking a birth date field, it is likely that the date of birth cannot be earlier than 150 years ago. Similarly, the date of birth should not be one day in the future.

"Supplemental" Generally speaking, the date of each database system has a range, such as the SQL Server minimum date is January 1, 1753, so if the date field is the input type should also test the date earlier than 1753.

8, the validity of the date. For date fields, it is important to ensure that invalid dates are not allowed (04/31/2007 is an invalid date). Test cases should also check leap years (each 4th and No. 400 year is a leap month).

9, Web session test. Many Web applications rely on browser sessions to track logged-in users, application settings, and so on. Most screens of an application are not designed to be run without first logging on. The application should make sure that there is a valid login in the session before opening a page of the application.

10, the performance changes. When publishing the latest version of a product, you should have a performance test that runs on the speed of the identification screen (the screen that lists the information, the screen that add/update/delete the data, and so on). The test package should include test cases that compare previous versions and existing version performance statistics. This can help identify potential performance problems that can be demonstrated as a result of code changes to an existing version.

"Add" from the first to eighth is the test we often need to do in the field test, the general test staff are not unfamiliar. The Nineth article is a test for examining the security of an application in a test Web application. The tenth article estimates that many companies will not take it into account in the scope of the test, the most common is to add a check in the test case whether a certain operation in the system allowed response time, rarely do such comparisons, in addition to some targeted performance testing.