clemson

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

Next up

Description

Resource summary

Similar

	Created by Tyson Mcleod over 5 years ago