16401385
Description
Flashcards by Tyson Mcleod, updated more than 1 year ago
|
Created by Tyson Mcleod
almost 6 years ago
|
|
| Question | Answer |
| Unit testing | the 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. |
| Black box testing | testing 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. |
| White box testing | testing whilst knowing the internal structure of the software. It requires knowledge to identify paths through the software and determine coverage. |
| Integration testing | testing 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. |
| System testing | a level of software testing where a complete and integrate software is tested against the specified requirements. |
| Acceptance testing | a level of software testing where a complete and integrated software is tested against business requirements, testing whether software is acceptable for delivery. |
| Software fault | a programming error which causes a software error then failure |
| Software failure | the result of a software fault which leads to incorrect output or an incorrect state |
| Static testing | Testing code without running it. Unlike dynamic testing where the code is executed. |
| Reachability (RIP) | A test must reach the location or locations that contain a software fault |
| Infection (RIP) | After reaching a location containing a software fault, the state of a program must be incorrect |
| Propagation | An infected state must propagate through the rest of the execution and cause some output or final state of a program to be incorrect |
| Clause coverage | For each clause, we want to test a clause for true and false |
| Predicate coverage | For each predicate, we want to test a predicate for true and false |
| Active clause coverage | For 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. |
| General Active clause coverage | For 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. |
| Correlated Active clause coverage | For 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. |
| Restricted Active clause coverage | For 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. |
| Input domain | All possible inputs to a program. The domain is infinite for all programs. Input parameters define the scope of the input domain. |
| Input domain partition | The 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. |
| Five stage Input domain modelling plan | Identify testable functions, methods. Find all parameters, global variables. Model the domain, choose characteristics. Combine characteristics, all = infeasible. Refine combinations, choose appropriate block values. |
| Interface based input domain modeling | Develop characteristics solely off of input parameters. Do not consider the function under test. |
| Functionality based input domain modeling | Develop characteristics based on the function under test. Use your understanding of the system under test. |
| Test plan | document containing : how the tests were created, why the tests were created, how to use the tests. Scope, approach, resources and intended usage. (SARI) |
| Removing tests | Remove tests that do not contribute towards coverage. Remove tests which never fail. Remove tests with the same faults as other tests. |
| Regression testing | Tests after changes have been made. Run all of them. Run those who relate to the changes made |
| Test engineers | can contribute at every stage. requirements development, setting up test environment, check if requirements are feasible |
| Software controllabilty | how easy it is to provide a program with needed inputs |
| Software observability | how easy it is to observe a program in terms of output, its affect on other components |
| Test cases | test case values, prefix values, postfix values, expected results |
| Test case values | the input necessary to complete an execution of the software under test |
| Prefix values | the input necessary to get the software in to an appropriate state for testing |
| Postfix values | the input that needs to be sent to the software after the test case values are sent |
| Expected results | the results that should be produced by the test case if the software behaves as expected |
| test oracle | a test oracles determines whether a test has passed or not. Thus, the results the software should produce, are included in the test case |
| TDD mantra | Red: 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. |
| Software verification | the process of determining whether the product of a phase fulfill the requirements from a previous phase or phases |
| Software validation | the process of determining whether the software at the end of development fulfill the requirements in compliance with intended usage. |
| Test requirements | describe 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. |
| Test path | represents the execution of a test case. Starts at an initial node and ends in a final node. |
| Test stubs | test stubs are used in integration testing during a top-down approach. Stubs are used to model components as well as external system interaction. |
| Test drivers | test 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 |
| Integration testing process | Big bang: all code together, run it all. Test top-down or bottom-up, choosing whether to test higher or lower level components first. |
| Testing during requirement specification | Test for completeness, clearness, correctness and consistency. Test for testability as well as for ambiguity in requirements |
Want to create your own Flashcards for free with GoConqr? Learn more.