Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
14) Test
Large System Development
| Question | Answer |
|---|---|
| Test planning | allocates resources and schedules the testing. Occurs early in the development phase so that sufficient time and skill is dedicated to testing. For example, developers can design test cases as soon as the models they validate become stable. |
| Usability testing | tries to find faults in the user interface design of the system. Often, systems fail to accomplish their intended purpose simply because their users are confused by the user interface and unwillingly introduce erroneous data. |
| Unit testing | tries to find faults in participating objects and/or subsystems with respect to the use cases from the use case model. |
| Integration testing | is the activity of finding faults by testing individual components in combination. |
| Structural testing | is the culmination of integration testing involving all components of the system. Integration tests and structural tests exploit knowledge from the SDD (System Design Document) using an integration strategy described in the Test Plan (TP). |
| System testing | tests all the components together, seen as a single system to identify faults with respect to the scenarios from the problem statement and the requirements and design goals identified in the analysis and system design, respectively: (funct, perform,acc) |
| Functional testing | tests the requirements from the RAD and the user manual. |
| Performance testing | checks the nonfunctional requirements and additional design goals from the SDD. Functional and performance testing are done by developers. |
| Acceptance testing and installation testing | check the system against the project agreement and is done by the client, if necessary, with help by the developers. |
| test component | is a part of the system that can be isolated for testing. A component can be an object, a group of objects, or one or more subsystems. |
| fault | also called bug or defect, is a design or coding mistake that may cause abnormal component behavior. |
| erroneous state | a manifestation of a fault during the execution of the system. An erroneous state is caused by one or more faults and can lead to a failure. |
| failure | a deviation between the specification and the actual behavior. A failure is triggered by one or more erroneous states. Not all erroneous states trigger a failure.2 |
| test case | a set of inputs and expected results that exercises a test component with the purpose of causing failures and detecting faults. |
| test stub | a partial implementation of components on which the tested component depends. |
| test driver | a partial implementation of a component that depends on the test component. Test stubs and drivers enable components to be isolated from the rest of the system for testing. |
| Horizontal integration testing strategies | 1) big bang testing 2) bottom-up testing 3) top-down testing 4) sandwich testing |
| big bang testing | Although this strategy sounds simple, big bang testing is expensive: if a test uncovers a failure, it is impossible to distinguish failures in the interface from failures within a component. |
| bottom-up testing | strategy first tests each component of the bottom layer individually, and then integrates them with components of the next layer up. |
| top-down testing | strategy unit tests the components of the top layer first, and then integrates the components of the next layer down. When all components of the new layer have been tested together, the next layer is selected. |
| sandwich testing | Using the target layer as the focus of attention, top-down testing and bottom-up testing can now be done in parallel. |
| Vertical integration testing strategies | For a given use case, the needed parts of each component, such the user interface, business logic, middleware, and storage, are identified and developed in parallel and integration tested. |
| Black-box testing | 1) Equivalence partitioning 2) Boundary Analysis |
| White-box testing | 1) Code coverage 2) Branch coverage 3) Condition coverage 4) Path coverage |
| Test Fixture | 1) Attributes 2) setUp() of the test class |
| Deployment Pipeline | 1) Development 2) Version Control 3) Test Server 4) Pre-Production Server 5) Production Server |
| Testing Activities | Establish the test objectives, Design the test cases, Write the test cases, Test the test cases, Execute the tests, Evaluate the test results, Change the system, Do regression testing |
| Model-based Testing | There are many different ways to "derive" tests from a system model (black box) ◦ Manual generation ◦ Automatic generation |
| Testcase | A test case implements a test objective.It describes a specified behavior, that is, a behavior specified in the system model (normative behavior) of the SUT |
| Scheduler | Predefined interface in U2TP that controls the execution of the test components that take part in a test case |
Created by:
timeakiss
Popular Computers sets