[Original] Test Case Design: "positive test and negative test"

[Original] Test Case Design: "positive test and negative test"

 

Generally, during the design of test cases, test cases are classified based on the test types or test requirements associated with them, and will be changed accordingly; therefore, during the test case design process, at least two test cases are prepared for each test requirement. One test case is used to prove that the requirement has been met, which is usually called a "positive test case ", another test case reflects an unacceptable, abnormal, or unexpected condition or data used to demonstrate that this requirement can be met only under the required conditions. This test case is called a negative test case. To put it more simply, "positive test cases" are the work that the test system has done; negative testing is to test whether the system does not perform operations that should not be completed.

Therefore, in the test case design process, we need to consider both positive and negative tests. The following is the top 10 negative test cases by Steve Miller, generally, some tests that require attention during Negative tests are mentioned.
The following content is taken from Kiki's "10 major negative test cases". You can learn more about negative test cases.

 

Negative test cases are designed to test the software in a way that is not intended to be used by the software. They should also be part of the test work. The following are the top 10 negative test cases you should consider when designing the test workload.
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.
[Kiki 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.
[Kiki supplement] for mandatory input fields, it is better to have some identifiers 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)
[Kiki supplement] Here is 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. This prevents users from entering more characters than permitted characters than the error message given by users who have already entered too many characters.
[Kiki supplement] For fields with limited length, most of the current development uses a 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 enter a negative amount of interest 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 constraints 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.
[Kiki 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.
[Kiki supplement] Generally, each database system has a date 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. Date validity. 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.

The following content is taken from Kiki "get negative test technology". You can learn more about it:

 

 

--- Original James Lyndsay a positive view of negative Testing
--- Kiki translation at 2007/121/30
 
1. Purpose of negative Testing
The UK standard definition of negative testing in BS7925-1 is defined by beizer, which defines negative testing as a test designed to indicate that the software cannot work: testing aimed at showing software does not work ). It can bring out a series of complementary and competitive purposes.
• Identifies faults that cause major failures, crashes, damages, and Security Vulnerabilities
• Observe and measure the system's response to external problems
• Expose software vulnerabilities and development potential
Although there is a fair definition, it is far from being widely accepted. Negative testing is a term that is closely followed by a redefinition, sometimes even of various groups. A common approach, in practice different from the definition of the British Standard, is that it includes testing specifically designed to deal with ineffective features.
• Input verification, rejection, and re-request functions (manual input and external systems)
• Internal data verification and rejection
• Cope with the lack of, slow, or broken external resources
• Error handling functions, such as messages, logs, and monitoring functions
• Recovery functions, such as fault recovery, rollback, and recovery
 
2. Techniques for obtaining Test Cases
Negative testing is not a test design technique, but a method or classification is more appropriate. Using many formal test design techniques to obtain tests that can be divided into 'negative test' is very likely. This section details the application of various well-known technologies.
• Boundary Value Analysis and equivalence class partitioning
• State Transition test state transition Testing
• Test against known constraints
• Failure Mode and Effects Analysis
• Concurrent concurrency
• Use Cases and misuse cases use cases and mis-Use Cases
 
2.1. Boundary Value Analysis and equivalence Classification
There are two technologies based on input and output data and system behavior expectations.
Boundary Value Analysis (BVA: Boundary Value Analysis) Checks data elements that can bring out a coherent range of values using requirements and designs for the boundaries that predict the locations of system behavior conversion.
This method is used to generate three values-one is the boundary itself, and the other two are on both sides of the former (as close as possible to the number ). If the boundary is between valid and invalid, a test case with invalid values will become a negative test case. For example, if 66 is used, only accept from 18 ~ The age field of 65.
ECP: Equivalence Class partitioning focuses on the range between boundaries. Each member of the given equivalence class should do the same in a known testing environment-so that the tester does not need to test each value in the equivalence class. The range of invalid input data can be seen as a negative test-for example, an age field may be expected to reject all negative numbers in the same way.
ECP is generally extended to a set of non-continuous values, which is better than a continuous value range. Note that some inputs may seem equivalent, but there are actually many different behaviors. For example, if the input of a simple web form is empty or too long, it may be rejected, but the correct combination of control characters may endanger the security of the potential web server.
 
2.2. Status transition test
If there is a state transition diagram or an equivalent understanding, it is easy to obtain a test case that can explicitly check whether the inaccessibility status is truly inaccessibility. The same variant as this method is called the n-switch test. After a set of known transformations, are the unattainable states Still unreachable? Graphic tools, such as compendium-ta [4], can help you get such a test.
 
2.3. Test against known constraints
Most systems have explicit and implicit restrictions and constraints. Various Negative tests can be performed on these constraints (participation in Robinson + Robinson, [5]) as needed. For example:
• "The site is designed to be viewed with Internet Explorer 4.5 or later"-ie3.0 or Netscape can be used for Negative tests.
• "No more than five users will use the system at the same time"-You can try six Negative tests and then eight.
In summary, testing includes measuring and observing the behavior of the system, which is better than directly testing against the expected results. This can only be used when operating outside of system parameters, and such observation may lead to further understanding of the system.
 
2.4. Failure Mode and result analysis
It is very likely to Predict System-specific faults from the analysis of potential technologies, implementations, and known faults. This analysis is the basis for observing system behavior under fault conditions. Capturing and documenting this information is very important-especially if they allow diagnosis of data and environment. For organizations that monitor their systems and have technical experts who can take action when the system is used (such as banks and phone companies), these documents are usually necessary for testing. On the other hand, this information can also be part of a faq or fault diagnosis guide for a wider range of distributed software packages.
These tests may not be executed without a valid test tool or application driver. Such tools are usually customized and may need to be run in the submitted version of the code.
However, tools like canned heat and holodeck (both from the Florida Institute of Technology, [6]) allow the introduction of common faults to software running on Windows.
6.4.1. Fault families
There are many sources that can help you develop fault models. The root cause analysis, system design documents, and knowledge of infrastructure-specific problems can help identify failure modes and thus provide sources for obtaining test results.
Although the list below is not detailed, it may help to raise more ideas about possible failures.
• External Resources: slow, uncertain, or inappropriate responses.
• Coprocessor faults: Unique interrupt processor, multi-task and recursive
• Concurrent Use: Resource lock, rejected request lock, deadlock, and response lock Delay
• Sacrifice processor sacriicial processes: Allows failed processors to be recovered in a controllable manner
• File System: files cannot be found, opened, read, write, permission change, file system identifies media errors, media removal, and media Filling
• Network: network is interrupted, the network is busy/slow, transmission segments are lost, damaged, and unordered, and conversations between processors are interrupted.
• Memory: insufficient for request allocation and fragmentation
• Reached limits: queuing, licences, threads, connections, array size, and resource allocation
 
2.5. Concurrency
Testing concurrent use of resources can be a very fruitful way to find bugs. Initial analysis includes identifying data, database entries, files, connections, and hardware that may be used at the same time. By allowing testers to use resources before the system, simple, custom tools may be helpful and publish them when they choose. The test should also check that the second requestor eventually gets the resource. More complex tests will focus on more than two requests, queuing, timeout, and deadlock.
 
2.6. Use Cases and misuse cases
Use Cases tend to process the 'happy path' of the system in practice '. Various input overwrites, rejected loops, and partial conversions are usually rare. The term "misuse of Use Cases" is not a remote standard, but can help clearly identify and distinguish them. Executing these path-based use cases can help improve the design by showing the activities of users outside the expected results to be normal, and allow a formal method to test selection and coverage.

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/imlogic/archive/2007/12/30/2004400.aspx