Karteikarten
clemson
Karten in diesem Stapel (44)
- 1Unit testingthe first level of software testing performed prior to integration testing early in the
development cycle. Unit testing is used to find problems in the development cycle regarding
implementation and specification. - 2Black box testingtesting with the implementation not being known to the tester. The basis for
testing is the software specification. Tests are constructed with valid input and look for valid output. - 3White box testingtesting whilst knowing the internal structure of the software. It requires
knowledge to identify paths through the software and determine coverage. - 4Integration testingtesting individual components as a group to expose faults in the interaction between the different components. test drivers and test stubs are used to assist in integration testing. Integration testing occurs after unit testing and before system testing.
- 5System testinga level of software testing where a complete and integrate software is tested against the specified requirements.
- 6Acceptance testinga level of software testing where a complete and integrated software is tested against business requirements, testing whether software is acceptable for delivery.
- 7Software faulta programming error which causes a software error then failure
- 8Software failurethe result of a software fault which leads to incorrect output or an incorrect state
- 9Static testingTesting code without running it. Unlike dynamic testing where the code is executed.
- 10Reachability (RIP)A test must reach the location or locations that contain a software fault
- 11Infection (RIP)After reaching a location containing a software fault, the state of a program must be incorrect
- 12PropagationAn infected state must propagate through the rest of the execution and cause some output or final state of a program to be incorrect
- 13Clause coverageFor each clause, we want to test a clause for true and false
- 14Predicate coverageFor each predicate, we want to test a predicate for true and false
- 15Active clause coverageFor each p ∈ P and each major clause ci ∈ Cp, choose minor clauses cj, j ≠ i so that ci determines p. TR has two requirements for each ci : ci evaluates to true and ci evaluates to false.
- 16General Active clause coverageFor each predicate p and major clause ci, we want to choose minor clauses so that ci determines p. TR has two requirements: major clause evaluates to both true and false, the minor clause values do not have to be the same.
- 17Correlated Active clause coverageFor each predicate p and major clause ci, we want to choose minor clauses so that ci detmermines p. Minor clause values must cause p to be true for one value of the major clause and false for the other value of the major clause.
- 18Restricted Active clause coverageFor each predicate p and major clause ci, choose minor clauses so that ci determines p. Minor clause values must cause major clause values to be true and false, minor clauses must be the same.
- 19Input domainAll possible inputs to a program. The domain is infinite for all programs. Input parameters define the scope of the input domain.
- 20Input domain partitionThe domain for each parameter is partitioned into regions. Partitions must be disjoint for no overlapping test cases. Partitions must cover the entire domain to ensure every element is tested. Partition based on characteristics and combinations of characteristics.
- 21Five stage Input domain modelling planIdentify testable functions, methods.
Find all parameters, global variables.
Model the domain, choose characteristics.
Combine characteristics, all = infeasible.
Refine combinations, choose appropriate block values. - 22Interface based input domain modelingDevelop characteristics solely off of input parameters. Do not consider the function under test.
- 23Functionality based input domain modelingDevelop characteristics based on the function under test. Use your understanding of the system under test.
- 24Test plandocument containing : how the tests were created, why the tests were created, how to use the tests. Scope, approach, resources and intended usage. (SARI)
- 25Removing testsRemove tests that do not contribute towards coverage.
Remove tests which never fail.
Remove tests with the same faults as other tests. - 26Regression testingTests after changes have been made. Run all of them. Run those who relate to the changes made
- 27Test engineerscan contribute at every stage. requirements development, setting up test environment, check if requirements are feasible
- 28Software controllabiltyhow easy it is to provide a program with needed inputs
- 29Software observabilityhow easy it is to observe a program in terms of output, its affect on other components
- 30Test casestest case values, prefix values, postfix values, expected results
- 31Test case valuesthe input necessary to complete an execution of the software under test
- 32Prefix valuesthe input necessary to get the software in to an appropriate state for testing
- 33Postfix valuesthe input that needs to be sent to the software after the test case values are sent
- 34Expected resultsthe results that should be produced by the test case if the software behaves as expected
- 35test oraclea test oracles determines whether a test has passed or not. Thus, the results the software should produce, are included in the test case
- 36TDD mantraRed: what you want the code to do - write a test you know the code will fail. Green: write code which passes the test. Refactor: optimization of the code. Short development cycle.
- 37Software verificationthe process of determining whether the product of a phase fulfill the requirements from a previous phase or phases
- 38Software validationthe process of determining whether the software at the end of development fulfill the requirements in compliance with intended usage.
- 39Test requirementsdescribe the properties of test paths. A test requirement is satisfies a test criterion (100% node coverage) if there exists a path/paths which meet the requirement.
- 40Test pathrepresents the execution of a test case. Starts at an initial node and ends in a final node.
- 41Test stubstest stubs are used in integration testing during a top-down approach. Stubs are used to model components as well as external system interaction.
- 42Test driverstest drivers are used in integration testing during a bottom-up approach. Drivers are used to simulate behaviour of upper level models that are not yet integrated
- 43Integration testing processBig bang: all code together, run it all. Test top-down or bottom-up, choosing whether to test higher or lower level components first.
- 44Testing during requirement specificationTest for completeness, clearness, correctness and consistency. Test for testability as well as for ambiguity in requirements