Test your basic knowledge |

Instructions:
  • Answer 50 questions in 15 minutes.
  • If you are not ready to take this test, you can study here.
  • Match each statement with the correct term.
  • Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.

This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.
1. A 2-dimensional array constructed with special mathematical properties - such that choosing any two columns in the array provides every pair combination of each number in the array.






2. A set of test cases derived from the internal structure of a component or specification to ensure that 100% of a specified coverage criterion will be achieved.






3. Attributes of software products that bear on its ability to prevent unauthorized access - whether accidental or deliberate - to programs and data. [ISO 9126] See also functionality. The capability of the software product to provide functions which me






4. Operational testing in the acceptance test phase - typically performed in a simulated real-life operational environment by operator and/or administrator focusing on operational aspects - e.g. recoverability - resource-behavior - installability and te






5. Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure.






6. Formal testing with respect to user needs - requirements - and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user - customers or other authorized entity to determine whether or n






7. Systematic application of procedures and practices to the tasks of identifying - analyzing - prioritizing - and controlling risk.






8. A tool that supports the recording of requirements - requirements attributes (e.g. priority - knowledge responsible) and annotation - and facilitates traceability through layers of requirements and requirements change management. Some requirements ma






9. A white box test design technique in which test cases are designed to execute LCSAJs.






10. The process of testing the installability of a software product. See also portability testing. The process of testing to determine the portability of a software product.






11. The process of testing to determine the reliability of a software product.






12. Testing where the system is subjected to large volumes of data. See also resource-utilization testing. The process of testing to determine the resource-utilization of a software product.






13. Code that cannot be reached and therefore is impossible to execute.






14. A sequence of one or more consecutive executable statements containing no branches. Note: A node in a control flow graph represents a basic block.






15. A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases. See also operational profile testing. Statistical testing using a model of system operations (short duration tasks)






16. Modification of a software product after delivery to correct defects - to improve performance or other attributes - or to adapt the product to a modified environment. [IEEE 1219]






17. An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements - e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.






18. A tool used to check that no brtoken hyperlinks are present on a web site.






19. Testing of individual components in isolation from surrounding components - with surrounding components being simulated by stubs and drivers - if needed.






20. A document reporting on any event that occurred - e.g. during the testing - which requires investigation. [After IEEE 829]






21. Procedure to derive and/or select test cases based on an analysis of the specification - either functional or non-functional - of a component or system without reference to its internal structure.






22. A test is deemed to fail if its actual result does not match its expected result.






23. The capability of the software product to be upgraded to accommodate increased loads. [After Gerrard]






24. The capability of the software product to enable specified modifications to be implemented. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified






25. Formal or informal testing conducted during the implementation of a component or system - usually in the development environment by developers. [After IEEE 610]






26. A list of activities - tasks or events of the test process - identifying their intended start and finish dates and/or times - and interdependencies.






27. A development activity where a complete system is compiled and linked every day (usually overnight) - so that a consistent system is available at any time including all latest changes.






28. The assessment of change to the layers of development documentation - test documentation and components - in order to implement a given change to specified requirements.






29. A set of input values - execution preconditions - expected results and execution postconditions - developed for a particular objective or test condition - such as to exercise a particular program path or to verify compliance with a specific requireme






30. The percentage of sequences of N+1 transitions that have been exercised by a test suite. [Chow]






31. The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The software life cycle typically includes a concept phase - requirements phase - design phase - implementation phase - tes






32. A program of activities designed to improve the performance and maturity of the organization's processes - and the result of such a program. [CMMI]






33. The process of testing to determine the interoperability of a software product. See also functionality testing. The process of testing to determine the functionality of a software product.






34. A version of component integration testing where the progressive integration of components follows the implementation of subsets of the requirements - as opposed to the integration of components by levels of a hierarchy.






35. A human action that produces an incorrect result. [After IEEE 610]






36. The process through which decisions are reached and protective measures are implemented for reducing risks to - or maintaining risks within - specified levels.






37. The ratio of the number of failures of a given category to a given unit of measure - e.g. failures per unit of time - failures per number of transactions - failures per number of computer runs. [IEEE 610]






38. The insertion of additional code into the program in order to collect information about program behavior during execution - e.g. for measuring code coverage.






39. The testing of individual software components. [After IEEE 610]






40. The leader and main person responsible for an inspection or other review process.






41. A tool for seeding (i.e. intentionally inserting) faults in a component or system.






42. A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects) - which can be used to design test cases.






43. The representation of selected behavioral characteristics of one physical or abstract system by another system. [ISO 2382/1]






44. A test management task that deals with developing and applying a set of corrective actions to get a test project on track when monitoring shows a deviation from what was planned. See also test management. The planning - estimating - monitoring and co






45. A basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths is available - e.g. case - jump - go to - if-then-else.






46. The percentage of executable statements that have been exercised by a test suite.






47. A requirement that does not relate to functionality - but to attributes such as reliability - efficiency - usability - maintainability and portability.






48. The calculated approximation of a result (e.g. effort spent - completion date - costs involved - number of test cases - etc.) which is usable even if input data may be incomplete - uncertain - or noisy.






49. Testing of software used to convert data from existing systems for use in replacement systems.






50. The process of testing to determine the recoverability of a software product. See also reliability testing. The process of testing to determine the reliability of a software product.







Sorry!:) No result found.

Can you answer 50 questions in 15 minutes?


Let me suggest you:

Browse all subjects

Browse all tests

Most popular tests



Major Subjects

Tests & Exams


AP
CLEP
DSST
GRE
SAT
GMAT

Browse all subjects

Browse all tests

Most popular tests