Software Engineering Body of Knowledge (v3) (2014) (811503), страница 22
Текст из файла (страница 22)
The customer or a customer’s representative thus specifies or directly undertakes activities to checkthat their requirements have been met, or in thecase of a consumer product, that the organizationhas satisfied the stated requirements for the target market. This testing activity may or may notinvolve the developers of the system.2.2.2. Installation Testing[1*, c12s2]Often, after completion of system and acceptancetesting, the software is verified upon installationin the target environment.
Installation testing canbe viewed as system testing conducted in theoperational environment of hardware configurations and other operational constraints. Installation procedures may also be verified.2.2.3. Alpha and Beta Testing[1*, c13s7, c16s6] [2*, c8s4]Before software is released, it is sometimes givento a small, selected group of potential users fortrial use (alpha testing) and/or to a larger set ofrepresentative users (beta testing). These usersreport problems with the product.
Alpha and betatesting are often uncontrolled and are not alwaysreferred to in a test plan.2.2.4. Reliability Achievement and Evaluation[1*, c15] [2*, c15s2]Testing improves reliability by identifying andcorrecting faults. In addition, statistical measuresof reliability can be derived by randomly generating test cases according to the operational profile ofthe software (see Operational Profile in section 3.5,Usage-Based Techniques).
The latter approach iscalled operational testing. Using reliability growthmodels, both objectives can be pursued together[3] (see Life Test, Reliability Evaluation in section4.1, Evaluation of the Program under Test).2.2.5. Regression Testing[1*, c8s11, c13s3]According to [7], regression testing is the “selective retesting of a system or component to verifythat modifications have not caused unintendedeffects and that the system or component stillcomplies with its specified requirements.” Inpractice, the approach is to show that softwarestill passes previously passed tests in a test suite(in fact, it is also sometimes referred to as nonregression testing).
For incremental development,the purpose of regression testing is to show thatsoftware behavior is unchanged by incremental changes to the software, except insofar as itshould. In some cases, a tradeoff must be madebetween the assurance given by regression testingevery time a change is made and the resourcesrequired to perform the regression tests, whichcan be quite time consuming due to the largenumber of tests that may be executed. Regressiontesting involves selecting, minimizing, and/orprioritizing a subset of the test cases in an existing test suite [8].
Regression testing can be conducted at each of the test levels described in section 2.1, The Target of the Test, and may apply tofunctional and nonfunctional testing.2.2.6. Performance Testing[1*, c8s6]Performance testing verifies that the softwaremeets the specified performance requirementsand assesses performance characteristics—forinstance, capacity and response time.Software Testing 4-72.2.7. Security Testing[1*, c8s3] [2*, c11s4]Security testing is focused on the verification thatthe software is protected from external attacks. Inparticular, security testing verifies the confidentiality, integrity, and availability of the systemsand its data. Usually, security testing includesverification against misuse and abuse of the software or system (negative testing).2.2.8. Stress Testing[1*, c8s8]Stress testing exercises software at the maximumdesign load, as well as beyond it, with the goalof determining the behavioral limits, and to testdefense mechanisms in critical systems.2.2.9. Back-to-Back Testing[7]IEEE/ISO/IEC Standard 24765 defines back-toback testing as “testing in which two or morevariants of a program are executed with the sameinputs, the outputs are compared, and errors areanalyzed in case of discrepancies.”2.2.10. Recovery Testing[1*, c14s2]Recovery testing is aimed at verifying softwarerestart capabilities after a system crash or other“disaster.”2.2.11. Interface Testing[2*, c8s1.3] [9*, c4s4.5]Interface defects are common in complex systems.
Interface testing aims at verifying whetherthe components interface correctly to provide thecorrect exchange of data and control information. Usually the test cases are generated fromthe interface specification. A specific objective ofinterface testing is to simulate the use of APIs byend-user applications. This involves the generation of parameters of the API calls, the setting ofexternal environment conditions, and the definition of internal data that affect the API.2.2.12. Configuration Testing[1*, c8s5]In cases where software is built to serve differentusers, configuration testing verifies the softwareunder different specified configurations.2.2.13. Usability and Human Computer Interaction Testing[10*, c6]The main task of usability and human computerinteraction testing is to evaluate how easy it isfor end users to learn and to use the software.
Ingeneral, it may involve testing the software functions that supports user tasks, documentation thataids users, and the ability of the system to recoverfrom user errors (see User Interface Design in theSoftware Design KA).3. Test TechniquesOne of the aims of testing is to detect as manyfailures as possible. Many techniques have beendeveloped to do this [6, part 4].
These techniquesattempt to “break” a program by being as systematic as possible in identifying inputs that willproduce representative program behaviors; forinstance, by considering subclasses of the inputdomain, scenarios, states, and data flows.The classification of testing techniques presented here is based on how tests are generated:from the software engineer’s intuition and experience, the specifications, the code structure, thereal or imagined faults to be discovered, predictedusage, models, or the nature of the application.One category deals with the combined use of twoor more techniques.Sometimes these techniques are classified aswhite-box (also called glass-box), if the tests arebased on information about how the software hasbeen designed or coded, or as black-box if the testcases rely only on the input/output behavior ofthe software.
The following list includes thosetesting techniques that are commonly used, butsome practitioners rely on some of the techniquesmore than others.4-8 SWEBOK® Guide V3.03.1. Based on the Software Engineer’s Intuitionand Experience3.1.1. Ad HocPerhaps the most widely practiced technique isad hoc testing: tests are derived relying on thesoftware engineer’s skill, intuition, and experience with similar programs. Ad hoc testing canbe useful for identifying tests cases that not easilygenerated by more formalized techniques.3.1.2. Exploratory TestingExploratory testing is defined as simultaneouslearning, test design, and test execution [6, part1]; that is, the tests are not defined in advancein an established test plan, but are dynamicallydesigned, executed, and modified.
The effectiveness of exploratory testing relies on the softwareengineer’s knowledge, which can be derivedfrom various sources: observed product behaviorduring testing, familiarity with the application,the platform, the failure process, the type of possible faults and failures, the risk associated with aparticular product, and so on.3.2. Input Domain-Based Techniques3.2.1. Equivalence Partitioning[1*, c9s4]Equivalence partitioning involves partitioning theinput domain into a collection of subsets (or equivalent classes) based on a specified criterion or relation. This criterion or relation may be differentcomputational results, a relation based on controlflow or data flow, or a distinction made betweenvalid inputs that are accepted and processed by thesystem and invalid inputs, such as out of range values, that are not accepted and should generate anerror message or initiate error processing.
A representative set of tests (sometimes only one) is usually taken from each equivalency class.3.2.2. Pairwise Testing[1*, c9s3]Test cases are derived by combining interestingvalues for every pair of a set of input variablesinstead of considering all possible combinations.Pairwise testing belongs to combinatorial testing,which in general also includes higher-level combinations than pairs: these techniques are referredto as t-wise, whereby every possible combinationof t input variables is considered.3.2.3. Boundary-Value Analysis[1*, c9s5]Test cases are chosen on or near the boundaries ofthe input domain of variables, with the underlying rationale that many faults tend to concentratenear the extreme values of inputs.
An extension ofthis technique is robustness testing, wherein testcases are also chosen outside the input domain ofvariables to test program robustness in processingunexpected or erroneous inputs.3.2.4. Random Testing[1*, c9s7]Tests are generated purely at random (not to beconfused with statistical testing from the operational profile, as described in Operational Profilein section 3.5). This form of testing falls under theheading of input domain testing since the inputdomain must be known in order to be able to pickrandom points within it.
Random testing providesa relatively simple approach for test automation;recently, enhanced forms of random testing havebeen proposed in which the random input sampling is directed by other input selection criteria[11]. Fuzz testing or fuzzing is a special form ofrandom testing aimed at breaking the software; itis most often used for security testing.3.3. Code-Based Techniques3.3.1. Control Flow-Based Criteria[1*, c4]Control flow-based coverage criteria are aimedat covering all the statements, blocks of statements, or specified combinations of statementsin a program. The strongest of the control flowbased criteria is path testing, which aims toexecute all entry-to-exit control flow paths in aprogram’s control flow graph.
Since exhaustivepath testing is generally not feasible because ofSoftware Testing 4-9loops, other less stringent criteria focus on coverage of paths that limit loop iterations such asstatement coverage, branch coverage, and condition/decision testing. The adequacy of suchtests is measured in percentages; for example,when all branches have been executed at leastonce by the tests, 100% branch coverage hasbeen achieved.3.3.2. Data Flow-Based Criteria[1*, c5]In data flow-based testing, the control flow graphis annotated with information about how theprogram variables are defined, used, and killed(undefined).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
