[Tool] Top 10 negative test cases

Top 10 negative test cases

A positive test is to test whether the system has completed the work it should have done, and a negative test is to test whether the system has not performed the operations it should not have done. A positive test is like a respectful primary school student. A negative test is like a naughty child, I am not doing this, and I am in conflict with you. Developers also hate to modify such bugs.

In short, the trilogy of Negative tests is:

1. check whether there are clear and sufficient prompts or constraints on the screen or page of the program;

2. test whether the system has handled abnormal user operations;

3. Check whether the system prompts are clear and adequate.

The following is Steve Miller's top 10 negative test cases, which generally mentions some tests that often require attention when performing Negative tests.

1. insert single quotes. Most SQL-based database systems encounter problems when users store information that contains a single quotation mark, such as John's car. Try to Enter text that contains one or more single quotes for each screen that can accept text numeric data entries.

[Supplement] In fact, it is not just a single quotation mark. Basically, the tester should test all the special characters and spaces (simple spaces and spaces before and after the text ). Single quotes, commas, //, <,> (for Web applications) are prone to errors. Early in development, we recommend that developers write a common function to process these special characters, and then apply this function when processing user input to avoid such errors.

2. Required data entries. The function manual should clearly indicate that fields of data entries must be entered on the screen. Each field on the test screen is described as mandatory to ensure that it forces you to enter data in the field.

[Supplement] for mandatory fields, it is best to identify them on the screen to indicate that they are required fields. Generally, it is represented by a red * sign before or after a field. During the test, you must check whether the identified field is consistent with the feature manual or other reference documents. The error message prompts whether the field is correct and whether the mandatory field is required.

3. Test the field type. The functional manual should clearly indicate the fields that require specific data input (Date Field, number field, telephone number, zip code, etc. Each field on the test screen is indicated with a specific type to ensure that you have entered data in the correct format based on the field type (numeric fields should not allow characters or special characters, the date field should allow the input of a correct date, and so on)

[Supplement] There is also a test of the field format and content. Some fields have requirements on the input format. The format of these fields is usually displayed on the screen. Therefore, during the test, you need to test whether the prompt format is reasonable (consistent with the functional instruction manual or other reference documents) and whether the system correctly identifies the input format. Some fields have restrictions on the Content of fields. For example, common user names cannot contain special characters, and the first word cannot contain numbers. Therefore, during the test, you need to test whether the prompt format is reasonable (consistent with the functional instruction manual or other reference documents) and whether the system correctly processes data input that does not meet the content requirements.

4. Test the field length. The function manual 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. It is more elegant to prevent users from entering more characters than permitted characters than the error message given by users who have already entered too many characters.

[Supplement] Generally, for fields with limited length, most of the current development uses the Restricted Input Method (set the length of the field) for processing. Therefore, during the test, you must test whether the length of the limit is reasonable (consistent with the functional instruction manual or other reference documents). For fields with no limit length, you must test whether an error occurs during infinite input, when a bug is reported, it is recommended that developers limit the length as needed.

5. Digital border testing. For numeric fields, it is very important to test the upper and lower boundary. For example, if you are calculating the interest of an account, you will never input a negative interest amount to the account that should win the interest. Therefore, you should try a negative number test. Similarly, if the function manual requires a field to be in a specific range (for example, from 10 ~ 50), you should try to enter 9 or 51, it should give a decent information to indicate failure.

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

[Supplement] decimal numeric fields also need to be tested. For fields that do not specify the digit type, try to enter a negative integer, negative decimal, 0, positive integer, and positive decimal.

No matter which database system is used, there are generally multiple numeric types for numbers. Therefore, testers must perform comprehensive tests.

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

[Supplement] Generally, the dates of each database system have a range. For example, the minimum SQL Server date is January 1, January 1, 1753. Therefore, if it is an input date field, you should also test the date earlier than 1753.

8. Validity of the date. It is important to ensure that invalid dates are not allowed for the date field (04/31/2007 is an invalid date ). The test case should also check the leap year (every 4th and 400th years is a leap year ).

9. web session test. Many Web applications rely on browser sessions to track logged-on users and application settings. Most screens of applications are not designed to run without first logon. The application should ensure that there is a valid logon in the session before opening a page of the application.

10. performance changes. When the latest version of a product is released, a set of performance tests should be performed to identify the screen (display of information, screen of Add/update/delete data, etc.) speed. The test package should include test cases that compare the performance statistics of previous and existing versions. This helps identify potential performance problems that can prove to be caused by code changes to existing versions.

[Supplement] from article 1 to Article 8 are the tests we often need to perform during field testing. Generally, testers are not unfamiliar. Article 9 A web application will be tested to check the security of the application. Article 10 it is estimated that many companies will not take it into account in the scope of testing. Generally, they will add at most the test cases to verify whether an operation is in the response time allowed by the system, there are few such comparisons, except for some targeted performance tests.

[Tool] Top 10 negative test cases