Ten abnormal Test Cases (reproduced)

This article is reproduced, formerly known as the "ten negative test Cases", I think the negative test is not as good as the abnormal test to understand, I changed. Well, first of all talk about my own experience. The first eight use cases are already in my mind system and are often covered in the test. The nineth session test, has this concept, but does not have the system to do, in the future should try to merge in the work. Tenth one, performance change test, the original statement of a bit wordy, I understand the summary of this is to increase, delete, change, check and other operations, from user input, click triggered the request, to the response, output such a time, or called speed, need a set of comprehensive measurement system. Each version is statistically and vertically compared to identify potential performance problems that may result. This will also be part of my previous test, such as when the response time is obviously too long and will be presented as a bug, but the portrait version is one of my blind spots and needs to be improved.

The original text reads as follows:

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 whether the screen or page in the program gives a clear and sufficient hint or constraint;
2. Test whether the system handled the user's abnormal operation;
3. Check to see if the system's error prompts are clear and adequate.

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 10 negative test cases that 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.
"Kiki Supplement" is not just single quotes, but basically testers should test all the special characters Fu/spaces (spaces before and after the text). Single quotes, commas,/,&lt, > (for Web applications) can easily cause 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. Data entries that must be entered. 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.
Kiki supplemental for fields that are forced to enter, it is best to identify them on the screen to indicate that they are fields 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)
"Kiki added" there's actually a test for the field format and the field contents. 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.
"Kiki Supplement" is generally used to limit the length of the field, now developed mostly using 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 constraint test of the number. 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 "Kiki Supplement" 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.
"Kiki Supplement" in general, each database system has a range of dates, such as the SQL Server minimum date of January 1, 1753, so if the date field is an input type, it should also test the date earlier than 1753.

8. 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. Changes in performance. 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.

"Kiki Supplement" 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.