[Tool] techniques for obtaining Negative tests in software testing

One test case is used to prove that the requirement has been met, usually called a positive test case. · another test case reflects an unacceptable, abnormal, or unexpected condition or data, this test case is called a negative test case.

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 test environment-so that the tester does not need to test each value in the same price 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. Status transition test
False has a state transition diagram or an equivalent understanding, so 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.
 
. 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
In practice, it tends to process the 'happy path' of the system '. 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 demonstrating the activities of users out of the expected results, and allow a formal method to test selection and coverage.

[Tool] techniques for obtaining Negative tests in software testing