The study is based in part on NSF-developed EIA-0113539 ITR/SY+PE: "Improving the education of software Testers." "Any opinions, findings and conclusions or comments expressed in the material are the authors and do not represent the views of the National Science Foundation (NSF)."
The design of a good test case is a complex art. There are three reasons for the complexity of this:
1. Test cases can help us find information. Different types of tests are valid for different types of information.
2. The test case can be proven to be "good" in many ways. But none of the test cases are excellent in any way.
3. People often create test cases based on a test type, such as domain tests or risk-based testing. Good domain testing is different from good risk-based testing.
What is a test case?
Let's start with the basics, what are test cases?
IEEE Standard 610 (1990) defines the test case as follows:
1) A set of test inputs, execution conditions, and desired results developed for a specific purpose, such as applying a special program path or checking to see if the application meets a specific requirement.
2) (IEEE Std 829-1983) Specifies the input, expected results, and a set of test item execution conditions for the document. According to the definition of Ron Patton (2001,p,65):
A test case is a special input and compliance process that you try to use when you are testing your software.
Boris Beizer (1995,P.3) defines the test as:
The order of execution of one or more sub-tests is like a sequence, because the result and/or final state of a sub-test is the input and/or initial state of the next sub-test. The term "test" usually covers sub-tests, specialized tests, and group tests.
Bob Binder (1999,p.47) defines the test cases:
The test case illustrates the state before the IUT test and its environment, test input or condition, and expected results. The expected results indicate what the IUT will produce from the test input. These rules include information generated by IUT, exceptions, return values, IUT result states, and their environment. Test cases also specify initial and result conditions for other objects that make up the IUT and its environment.
In practice, many things can be used as test cases, even if they completely do not conform to the prepared test documentation.
Brian Marick uses a related term to describe a test case that is not fully documented, and its test concept (IDEA) is:
"Idea" is a brief description of the object under test. For example, to test the square root function, one of the test ideas could be "measuring a number less than 0". The test idea is to verify that the code has an error handling mechanism. ”
I think the test case is a challenge to the program, and the purpose of running the test is to get information, such as whether the program passes the test.
When it comes to defining what the test idea is and how to apply it to certain aspects of the product (such as the appearance), it is necessary or not to indicate the details of the process. As a rule, if a file record is an integral part of a test case, use a test idea instead of all of the test cases that follow.
One important application of the test case definition is:
test cases must have some ability to expose information.
1. According to this definition, the range of test case changes will stabilize with the program. At the beginning of the test, in any aspect of the program, it is a sensible and effective way to try to fill in the data type input fields with the maximum valid values. A few weeks later, after several builds passed the test, the test case is no longer required to test the field independently because it already has the ability to handle the exception. At this point, more relevant tests combine 10 different variables to form the boundary line at the same time, or set boundaries based on a longer test sequence or story.
2. Similarly, by this definition, there is no point in measuring the number of test cases reported. A few weeks ago a group of 20 univariate tests were useful, and now they are useless or integrated, what should be done? Suppose you created a combination test with 20 tests, is the measurement report 20 or 21 tests? What is the test performed only once? What is the test without running the design and implementation, because of the changes in the programming that make the test meaningless?
Another application of the test case definition is that the design of the test is not intended to expose the defect and is intended to be information. Often, the flaw contains information, but not absolute (thanks to marick,1997 's insights.) ）。 To get the test results, we need to fully look for the information provided by the test.
What can we learn or get when we perform tests on information targets? Here are a few examples.
1. Defects found. This is the common purpose of testing. The purpose of running tests is to trigger failures and expose defects. Generally, we are looking for defects in all parts of the product that are of interest.
2. Maximum number of defects. This differs from the "discovery flaw" in that the total number of defects is more important than its coverage. Even if this is a useful way to find more flaws in time, we are only focusing on a few high-risk areas.
3. Prevent the release of nonconforming products. Testers prevent the product from being out of the library until they are found to be severely defective until these problems are resolved. At each release of the resolution, testers aim to discover new flaws and flaws.
4. Assist Manager to make library decision. Managers are generally concerned about the risks in this area. They want to know the defect coverage (which may not be overly simple code coverage statistics, but rather how many flaws the product has found, how much has not been resolved), and the importance of the problem that has been identified. Issues that are significant in writing that do not cause customer dissatisfaction may not affect the product's outbound decision.
5. Minimize the cost of technical support. Working with a technical support or service group, the Test team identifies the issues that need to be supported. These are usually product-related peripheral supports that do not need to be tested, for example, test products that need to work with a specific printer or successfully import data from a third-party database, with high frequency access and data crashes.
6. Follow the specification for review. The requirements in the specification are audited. The program features not listed in the specification are not audited (as part of the target).
7. Follow the specifications. If the specification indicates a type within the coverage (for example, at least one test for each declaration of the product), then the test group creates the appropriate test. If the specification specifies a type for the specification or other documentation, then the test group may need to check the type. Generally, the test group focuses on everything that is covered in the rule and that is not covered.
8. Minimize the risk of security litigation. Any mistake that can cause an accident or injury should be noticed in the first time. Errors that result in time or data loss or data corruption, but do not cause harm or damage to the actual thing can be done without consideration.
9. Discover the use of the product's security scenario (even if a defect is found, the method can work). Sometimes, looking for a way to keep doing a job---others reliably send the useful information they expect from a set of instructions. In this case, the tester is not looking for defects. He is experimenting with the method of doing homework according to experience.
10. Quality assessment. This is a tricky goal, because quality is multidimensional. The nature of quality depends on the nature of the product. For example, a computer game without entertaining shaking objects is a nasty game.
Conduct quality assessments-measure and report on quality levels-you may need to have a clear definition of most important quality standards for this product, and need to have relevant theoretical knowledge of defining test results. For example, reliability is not just about the number of product defects. It is (or is often defined as) the number of failures related to reliability that are expected to occur over a period of time or over a period of time. (Reliability related?) For example, when measuring reliability, businesses may not be concerned about spelling mistakes in error messages. In order to make predictions, you need a precise, empirical, and reasonable prototype to make the test results reliable. Testing involves getting the data the model needs, including the absolute stability and instability of the product to do in-depth work. Imagine a reliable model that is based on statistics (which may be distinguished by severity type) per n lines of code or the number of bugs found per K-hour test. Finding bugs is important, eliminating duplication is also important, identifying and resolving issues to make defect reports easier to understand and more likely to correct (within the scope of the assessment) to be out of scope.
11. Verify the correctness of the product. Testing is not possible to do this. You can prove that the product is incorrect, or you can prove that you have not found any errors with a specific test strategy within a given time. However, you will not be able to perform exhaustive, no-misses tests, and the product may fail under conditions that you have not tested. (If you have a real, reliable model) the best you can do is evaluate the probability of errors. (Refer to the following discussion on reliability).
12. Quality assurance. Although quality assurance is a common goal, it cannot be tested to ensure quality and quality can not be ensured by acquiring measures, and not by setting standards. Quality assurance includes building a high-quality product, as well as a person who has the skills, the time, the passion, the direction, the freedom to create, throughout the development process. This is beyond the scope of a Test team's work, but within the scope of the project manager and the relevant implementers. In the process of conducting technical research, the Test team can get some help, but these studies do not guarantee the quality.
Given a test object, a good test process can provide information that is directly related to the object. Testing is about exposing defects that limit our focus to the two main objectives of the Test team:
People other than the development team will consider finding relevant (and reported) defects and modifying them.
Even within these purposes, there are many different good test methods. For example, we might say that a test is better than another test if it:
1. More forceful (more powerful). According to general statistical knowledge, I understand that it is advantageous: if there is a flaw, it is more likely to be exposed. Note that for a class of defects, test 1 is more powerful than Test 2, and for another type of defect, test 1 is less powerful than Test 2.
2. More likely to produce significant (more based, convincing results). If an influential person in charge of a major problem refuses to modify the issue. (the person in charge refers to those who have an impact on the product.) An influential person in charge of a product is one whose preferences and opinions lead to product changes. ) 3. More reliable. A reliable test is more likely to be a real (or reasonable) set of actions by a programmer or other influential person in charge. "Corner testing" is an example of what programmers are accustomed to saying: "There is nothing to prove it." "If some (or all) of the people responsible for the product agree to the authenticity of the test case, then it is reliability.
4. It is more likely to find typical events that customers encounter. Many of the tests designed are highly reliable. Allow your people to influence the real use of the application.
The more frequently the active group appears, the more likely it is to be overwritten or completely overwritten. (The activity Group I'm talking about is that many features are used at the same time, so we track which feature sets are used in what order and reflect that information based on our analysis.) See Musa (1998) for software reliability Engineering in more detail.
5. more easily evaluated. The question is whether the program passed the test? To be easy to evaluate, testers should have the ability to quickly and effortlessly determine whether a program can pass the test. It is not enough to say whether the program may be tested. More difficult to evaluate is that the more time spent, the more likely errors inadvertently flashed. In the face of time-consuming assessment, testers will use a convenient method, a way to reduce the time-consuming evaluation of the integrity of the program. These handy methods are often not entirely accurate (that is, they will not find obvious flaws or mark the correct code as false.) ) is more conducive to solving problems.
For example, a large number of automated tests often destroy the system when it is not possible to provide a lot of information about the test conditions to reproduce the problem. They are not good for solving the problem. The harder it is to repeat the test, the more difficult it is to solve the problem. If the problem that needs to be solved is discovered by this test, the harder it is to execute, the harder it will be to perform the next test.
6. More information. The value of testing is that we can learn something from it. In most cases, you'll learn more from the program you're testing than the program you didn't pass the test on, but the information test will teach you (reduce uncertainty) whether the program can pass the test.
I. For example, if we have run a test after several builds and the program passes the test reliably every time, then we expect the program to pass the test again. The additional "pass" results obtained from the repeated tests do not help us to understand the program.
Ii. the idea of equivalence classes is another example of the value of information. There is a test set behind any test, and there is a high degree of similarity between them, and we think that the other tests are essentially redundancy of the test. In the colloquial jargon, this is the "equivalence class" or "equivalent part". If these tests are sufficiently similar, the second Test will have less additional information than the first Test.
III. This standard is very close to Karl Popper's experimental Value theory (ref. Popper 1992). The best experiments cover the risk forecast. This theory predicts that something that people expect is untrue, that your preferred theory is wrong or that many people are surprised. Popper analysis believes that excellent experiments (excellent testing) are similar to the mainstream core philosophy of scientific philosophy.
V. Perhaps the real consideration here is that what you want to learn from the test is balanced with the opportunity cost of the test design and operation. The time you spend on testing is the time you have not spent on other tests or activities.
7. More complex. A complex test contains many aspects of the software being tested, or variables, or other attributes.
Complex testing is not advocated when there are many changes in the program or when many features are measured at a time. If there are many bugs in the program, the complex test will soon fail and there will be no need to execute it again. Test groups rely mainly on complex tests to find modular bugs. A modular bug prevents many tests from passing, preventing the test group from understanding the information that the test should expose. Therefore, it is reasonable and necessary to conduct a simple test at the beginning of the test. More complex tests become more meaningful when the program is more stable, or if the program has more stable features (in extreme programming or any development life cycle).
8. It is more likely to help testers or coders to gain insight into certain aspects of a product, customer, or external environment. Sometimes we test the product to see how it works and the risks that exist. We then design tests to expose the product's flaws, but at the beginning of the test, we are interested in what is and how to measure. Many of these tests are not repeated. However, in the first test environment, it is expected (typically, the unit) to test the collection to warn about the side effects of code changes in the coding staff experiment. In this environment, the tests are designed to mark performance changes, differences in rounding errors, or some other change, which are not defects. Unexpected changes in the program alert the coder that her code or code changes affect the prototype is incomplete or wrong, and lead her to carry out additional tests or solve the problem. (thank Ward Oummingham and Brain Marick for this example.) Test type and test quality in the field of black box testing, Kanner&bach (refer to the course notes published on www.testingeducation.org by Bach 2003b and kanner,2002, as well as Kanner,bach & Pettichord, 2002) describes 11 advantages of the black box test:
Functional test (function testing) domain Test (domain testing) test based on specification (specificaiton-based testing) risk-based testing (risk-based testing) pressure Force test (Stress testing) regression test (Regression testing) user test (users testing) scenario test (Scenario testing) test based on the state model (State-model Based testing High-volume automated testing (high Volume automated testing) exploratory testing (exploratory testing) I and Bach collected some tests "paradigm" to be repeated, of which one or two ruled the test The idea of a team or genius tester. After analysis, we find it interesting that:
How do I actually test this program if I am a "scene tester" (the person who is testing the app defined primarily by the scenario test)? What can make a scene test a better one than one? What kind of questions do I miss that is difficult for me to find or explain, and what is particularly simple?
Here, what kind of test cases can be considered "good" ideas, to simply explain these types.
Functional tests independently test each function, performance, and variable.
Many test teams start with very simple functional tests and then switch to the other one, usually with several features that cross each other until the program passes through the main functionality of the test.
In this way, a good test should focus on a single function and use the median value to measure it. We do not want the program to fail in such a test, but it is still defeated by a fundamentally wrong algorithm, a failed build, or a change in the other parts of the program.
These tests are highly reliable and easy to evaluate, but there is no apparent strength.
Some test teams spend most of their time on functional tests. For them, the test is complete when each item is completely independent and thoroughly tested. In my experience, there is strength in functional testing similar to domain testing, with their strengths.
The nature of domain testing is sampling. We divide the set (distinguish) Chengzi set (subdomain), break down a large set of possible tests into a group, and select a representative one or two method from the subcollections.
In a domain test, we focus on the variable, and occasionally the initial value of the variable.
To measure a given variable, the test set assigns all values (including invalid values) You can imagine to this variable. Divide this collection into subdomains and perform at least one typical test in each subdomain. In general, you perform one of the most representative tests, that is, you use a value that is at least as likely to be exposed as the other elements of the same class. If this variable can reach the data boundary, then the most representative is the typical boundary value.
Most domain test discussions are about whether the value of the input variable can reach the data boundary line. The most representative of these use-case intervals is the typical boundary use case.
For numeric variables, a good set of domain test cases detects each boundary value, including the minimum, maximum, a value less than the minimum value, and a value greater than the maximum value.
1. Whittaker (2003) presents an in-depth discussion of many different types of variables in software analysis, including input variables, output variables, intermediate calculations, values stored in the file system, and data sent to devices or other programs.
2. Kaner,falk & Nguyen (1993) provides a detailed analysis of the tests that are not able to reach the data bounds of the variable (configuration test printer type).
These tests are more powerful than unrepresentative or ignoring certain subdomains (for example, people often ignore test cases that expect to produce error messages). After the first run of these test cases, or significant related changes, these tests produce a lot of valuable information, because boundary/limit value errors are common.
Sometimes, the bugs found in these tests are ignored, especially if you test the limit values for several variables at the same time. (These tests are called corner use cases.) They do not need to be reliable and do not need to represent the user's expectations, so they do not have to be designed to solve the problem.
A specification-based test examines every statement about a program in a related document, such as design specifications, requirements lists, user interface descriptions, release prototypes, or user manuals.
In the enterprise, it is very important (motivating) to test strictly according to their specifications. For example, if the specification is part of a contract, it is important to follow the specification. Similarly, products must comply with their claims that life-related products must comply with all safety-relevant specifications.
Spec-driven testing is generally weak, and testing for specific specification entries is obviously not representative of this type of test.
Some of the team based on spec testing is confined to the description in the document. For them, a good test set contains the explicit, relevant tests that are developed for each statement in the specification.
Other teams have a long-term perspective on the issues in the specification. They found that most of the information tests performed on detailed products often showed ambiguous points in the specification, or that the product was not exhaustive.
Risk-based testing assumes a scenario where the program fails, and then designs one or more tests to check if the program really fails in that situation.
A perfect set of risk-based tests should be based on an exhaustive list of risks, a list in which each scenario can make the program fail.
A good risk-based test is a typical representation of a specific risk testing effort.
In this degree, risk-based failure can be very reliable and highly motivating if there is a significant error in the test or a significant error in the opponent's product. However, many risk-based tests are ignored in theory (which is unlikely to happen in practical applications). The risk that is measured from the actual error is valuable and makes the test more reliable.
Risk-based testing is about delivering a high level of information value because you have reason to believe that there is a problem in your product that you want to test. We can learn a lot from whether the program can pass the test.
Stress test (Stress testing) Here are a few different definitions of stress testing:
1. An ordinary definition, using a peak pulse activity to impact the program to see if he will fail.
2. The IEEE standard 610.12-1990 is defined as: "Tests evaluate whether a system or component exceeds its specified requirements by targeting a system failure." "3. The third method causes the program to fail to observe its error behavior. For example, if the test uses too much input, then you are not just testing the prescribed limit. You continuously increase the scale or speed of the input until the program eventually fails or you are confident that further increases will not result in failure. In fact, the final failure of the program will not be significantly surprising or exciting. It is interesting when you see failure, ask what weaknesses are exposed, and which of these weaknesses are triggered in a lower-limit environment. Jorgensen (2003) provides a tempting example of this type.
I work with a third definition.
These tests are very forceful.
Some people overlook the stress tests that make the use of customers unrepresentative and therefore unreliable and non-purposeful. Another problem with stress testing is that failure is useless unless the test provides a problem-solving message, or the person who leads the test is familiar with the application.
A good stress test pushes the limits you want to add, including enough diagnostic support to make it very easy to find when you see a failure.
Some testers, such as Alberto Savoia (2000), use a similar stress test to expose failures, which makes it difficult to see if the system is running several tasks at the same time. These failures are often exposed within the theoretical limits of the system, so they are more reliable and purposeful, but they are not easy to solve.
The goal of regression test design, development, and preservation testing is to regularly re-use them, repeating tests after changes occur.
A point to note (consider regression testing) is that this is not a straight-through list of test types. You can give your regression test set input domain test or spec-based test or any other test type.
So what's the difference between these and other tests? I'll use an example to answer this question:
Suppose a tester creates a set of domain tests and saves them for reuse. Is this a domain test or a regression test?
When testing is created, if the tester is primarily concerned with differentiating variables and finding the most representative one, I think it is primarily a domain test.
If testers primarily consider creating a reusable test set, I think it's mostly regression testing.
If it is a regression test designed for the first time, then they should be powerful, reliable, and so on. However, after a test runs and passes multiple times, the program cannot fail on the next test unless a large change has occurred or part of the code change is directly involved in the test. Therefore, in most cases, regression testing results in very little information value.
A good regression test is designed for reuse. It is fully documented and maintainable. (recommendation: Improve serviceability of GUI-level testing, see Graham & fewster,1999; kaner,1998; PETTICHORD,2002, and the paper on www.perrichord.com).
If the change reduces the function or scope of the program's regression test, a well-designed regression test may fail.
User testing user testing is performed by the user, not by the tester disguised as the user, not by the Secretary or performer disguised as testers, users. The user is the person who uses the final product.
User testing is designed by users or testers or other people (and sometimes lawyers who are tested in customer software contracts). The collection of user tests may include boundary value tests, stress tests, or any other type of test.
Some of the user tests designed are performed by the user only and the details of whether the program passes these tests are reported. This is a good way to design tests if your goal is to provide an elaborate system script sample that does not have any chance of displaying error events.
If your goal is to discover the problems users will encounter in the actual use of the system, then your work will be more difficult.
Beta testing is often a simple, effective user test, but in practice they are very difficult to manage and do not generate a lot of information. For some recommendations on beta testing, see Kaner,falk & Nguyen (1993).
A good user test, when giving the user sufficient structure to report the effectiveness of the results, must give the user sufficient room for cognitive activity (to some extent, help the reader to understand and solve the problem).
Faults found in user testing are generally reliable and purposeful. A handful of users perform particularly aggressive tests. But some users will run the program in complex situations.
Scene testing (Scenario testing) A scenario is a story that describes a hypothetical situation. On the test, check how the program is reproduced in this hypothetical environment.
Ideal scenario testing is reliable, purposeful, easy to evaluate, and complex.
In fact, many scenarios are weak at least one of these features, but people still call it a scene. The key message of this pattern is that when you design a scene test and try to complete it, you need to remember these 4 features.
An important variation of scene testing is rough testing. The story often has a sequence or data value that is used only by ordinary users. However, they will appear in addition to user errors, or under unusual but specious circumstances, or hostile user behavior. Hans Buwalda (2000a,2000b) calls it a "soap killer" to differentiate itself from what it calls "soap operas." Similar situations are prevalent in safety tests or other forms of stress testing.
In Rup (Rational Unified Process), scenarios are derived from use cases. (Jacobson,booch, & rumbaugh,1999). The scenario sets up the actors, roles, transactions, goals of the participants, and events that occur in the process of attempting to achieve the goal. A scenario is an instantiation of a use case. A simple scenario traces the entire process of using the use case independently, specifying the data values and the paths in the use cases. A more complex use case is used to track a given task by using a number of use cases in tandem. (See Bittner & spence,2003; cockburn,2000; collard,1999; Constantine & Lockwood,1999; wiegers,1999.) Warning note, see Berger (2001).
In any case they are inherited, good scene testing has a lot of strength in the first run.
How often different teams perform a given scenario test.
1. Some teams create a scenario test pool similar to regression testing.
2. Other teams (like me) perform a scene test once or in a short time, and then design another scene instead of sticking to a previously used one.
Typically, a tester-generated scenario can gain insight into the product's interior. This is very real at the beginning of the test and again later in the test (when the product is stable, testers try to understand the product for further use.) State-model-based testing in a state-based test, you simulate a program's visible behavior as a state machine, and the driver transitions between States to detect consistency with the expected model. An in-depth discussion on this test method is on the www.model-based-testing.org website.
In general, software behavior is likened to a model using automated tests, so the errors are easier to find (easy to evaluate).
Typically, model-based testing is reliable, stimulating, and easy to solve. However, because there are too many states (El-far 1995), model-based testing is often simplified, and it looks at the way of operation rather than the transition between States. Some abstract ways of doing things are obvious and credible, and for some stakeholders, others seem to be overly broad or non-fixed, simplifying testing. In addition, if the model is too simplified, the errors exposed by the model will be difficult to solve (houghtaling,2001).
Talk about Harry Robinson (2001) experience in creating a software state model, he reports: There are many flaws in modeling before automated testing is complete. Elisabeth Hendrickson (2002) Training testers to work with the state model as a detection test tool-her model was not generated by automated testing, and its value was to instruct testers to analyze.
El-far,thompson & Mottay (2001) and El-far (2001) Discuss things to consider when building an excellent model-based test set. For example, the tradeoff is to consider the level of detail (the more detailed the model, the more defects it finds, but the more difficult it is to read and maintain).
For further instructions, please refer to the paper on the www.model-based-testing.com website.
Large quantities of automated tests large quantities of automated tests include a large amount of test data, comparing the results to one or more local Oracle databases.
1. The simplest local Oracle database is anti-crash, if the program crashes, there must be a bug. For a detailed description and experience report, see Nyman (1998,2002).
2. If the stop rule is based on the test results rather than the coverage criteria, then the test based on the state model is in large quantities. See Whittaker (1997) for a general concept of random state-based testing. For a discussion on state model-based testing that ends with coverage rules, see Al-ghafees & Whittaker (2002).
3. Jorgensen (2002) provides an additional example of a large volume test. His tests started with the application of a valid file, and then he destroyed it in a variety of ways, supplying the destroyed file to the application. The application rejects most of the corrupted files and continues to ruin the part. Sometimes, some applications lose control when they process these files. Buffering overrun or other errors allows testers to take over the application or the machine running the application. If the tester can modify the data flow before acquiring the program, then any program that reads all types of data streams belongs to this type of test.
4. Kaner (2000) describes several other examples of automated test methods for large quantities. A common approach is to apply random data to the application to be tested and to compare it with another reference application. Another method is to run the regression test and enter an arbitrary long random sequence, and the test program can pass the test one after another. Memory leaks, stack corruption, useless pointers, or other useless things accumulate over time, and finally an error occurs in this long sequence. Another approach, however, is to use long sequence actions and user sniffing (as part of a program that logs warnings and error messages in response to unexpected situations). ) test the program to expose the problem.
Mass testing is a variable combination. The essence is that the structure of such tests is designed by people, but each test case is developed, executed, and parsed by a computer that can mark suspicious errors for People's review. Almost complete automation makes it possible to run a large number of tests.
1. Individual tests are usually weak, but they can compensate for the lack of high-volume testing.
2. Because this test is not manual, some tests are exposed to problems that are not particularly credible or valuable. A skilled tester usually imagines the problem as a problem in a more obvious or important environment, and then uses a manual test to prove it.
3. Some high-volume test methods produce errors that are difficult to resolve. It is easy to see that an error occurs under a specific test, but a necessary condition that causes the error to occur may have been tested hundreds of thousands of tests before a real failure. The way to solve these problems is to design a set of tests that are more effective than others.
Exploratory testing exploratory testing is "the testers actively perform these tests while designing the tests, using the information obtained in the tests to design new and better tests" (Bach 2003a).
Bach points out that the test is a combination of a pure script that is explicitly done by the tester, and a pure exploration (the tester's behavior is not pre-designed, and there is no need to produce any test documents except bug reports). Any given test in this union is a cast of labor. Even the outstanding, pre-scripted tests performed by skilled testers are exploratory tests.
"In prototype use cases (called" Exploratory Testing "by Bach), exploratory testers are constantly learning about the software they are testing, the market for the product, the various scenarios in which the product will fail, the weaknesses of the product (including where problems have arisen in the application history and what kind of errors are developed), and use the best method to test this software. While learning these, exploratory testers are also testing the software, reporting on the problems they find, advocating solutions to the problems they find, and developing new tests based on the information they receive during their learning process. "(Tinkham & kaner,2003) Exploratory testers can use any type of test-domain testing, spec-based testing, stress testing, risk-based testing, and any number of them. The fundamental problem is that no matter which type of test is best, as long as the information that the tester is looking for can be presented at this moment.
Exploratory testing is not purely spontaneous.
Testers need to do in-depth research, such as understanding the competitive product, the failure history of this or similar product, communicating with programmers and users, reading specifications, and working with the product.
The difference between skilled exploratory testing and other methods and poor exploratory testing is that, while testing, the people who do exploratory testing are busy working, learning, planning, and running tests. Good test cases improve the testers ' knowledge of seeking information goals. Exploratory testing is highly target-driven, but the goal is quickly changing when testers acquire new knowledge.
Conclusion There are no simple formulas or rules that can be followed to generate "good" test cases. Even people who have been interested in testing for years are hard to do.
Testing is good for showing you the purpose of your information.
I've seen a lot of test teams that use a few types of tests, mostly for scenario testing or domain testing, and so on. As long as they are good at the type of test they prefer, their tests will become extremely good in some ways. Unfortunately, the type of test we want is not a very good test in any way. In order to make the test results diversified and extensive, we must have all aspects of the technology.
This part of the study was supported by EIA-0113539 ITR/SY+PE: "Improving the education of software Testers". Thanks to Andy Thinkham,al Jorgenson, and Pat McGee comments on the manuscript above.
English version: Http://www.kaner.com/pdfs/GoodTest.pdf
Go: What is a good test case
