Các định nghĩa trong Glossary - A
abstract test case: see high level test case
acceptance: see acceptance testing
acceptance criteria: the exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authority entity [IEEE 610]
accessibility testing: Testing to determine the ease by which users with disabilities can use a component or system. [Gerrard]
accuracy: The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality.
accuracy testing: The process of testing to determine the accuracy of a software product. See also accuracy.
acting (IDEAL): The phase within the IDEAL model where the improvements are developed, put into practice, and deployed across the organization. The acting phase consists of the activities: create solution, pilot/test solution, refine solution and implement solution. See also IDEAL.
action word driven testing: See keyword-driven testing
actor: User or any other person or system that interacts with the system under test in a specific way.
actual outcome: See actual result.
actual result: The behavior produced/observed when a component or system is tested.
ad hoc review: See informal review.
ad hoc testing: Testing carried out informally; no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and arbitrariness guides the test execution activity.
adaptability: The capability of the software product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the software considered. [ISO 9126] See also portability.
agile manifesto: A statement on the values that underpin agile software development. The values are: - individuals and interactions over processes and tools - working software over comprehensive documentation - customer collaboration over contract negotiation- responding to change over following a plan.
agile software development: A group of software development methodologies based on iterative incremental development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
agile testing: Testing practice for a project using agile software development methodologies, incorporating techniques and methods, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm. See also test-driven development.
algorithm test: [TMap]See branch testing.
alpha testing: Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organization. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing.
analytical testing: Testing based on a systematic analysis of e.g., product risks or requirements.
analyzability: The capability of the software product to be diagnosed for deficiencies or causes of failures in the software, or for the parts to be modified to be identified. [ISO 9126] See also maintainability.
analyzer: See static analyzer.
anomaly: Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, etc. or from someone’s perception or experience. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation. [IEEE 1044] See also bug, defect, deviation, error, fault, failure, incident, problem.
anti-pattern: Repeated action, process, structure or reusable solution that initially appears to be beneficial and is commonly used but is ineffective and/or counterproductive in practice.
API (Application Programming Interface) testing: Testing the code which enables communication between different processes, programs and/or systems. API testing often involves negative testing, e.g., to validate the robustness of error handling. See alsointerface testing.
arc testing: See branch testing.
assessment report: A document summarizing the assessment results, e.g. conclusions, recommendations and findings. See also process assessment.
assessor: A person who conducts an assessment; any member of an assessment team.
atomic condition: A condition that cannot be decomposed, i.e., a condition that does not contain two or more single conditions joined by a logical operator (AND, OR, XOR).
attack: Directed and focused attempt to evaluate the quality, especially reliability, of a test object by attempting to force specific failures to occur. See also negative testing
attack-based testing: An experience-based testing technique that uses software attacks to induce failures, particularly security related failures. See also attack.
attractiveness: The capability of the software product to be attractive to the user. [ISO 9126] See also usability.
audit: An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify:
(1) the form or content of the products to be produced
(2) the process by which the products shall be produced
(3) how compliance to standards or guidelines shall be measured. [IEEE 1028]
audit trail: A path by which the original input to a process (e.g. data) can be traced back through the process, taking the process output as a starting point. This facilitates defect analysis and allows a process audit to be carried out. [After TMap]
automated testware: Testware used in automated testing, such as tool scripts.
availability: The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage. [IEEE 610]
acceptance: see acceptance testing
acceptance criteria: the exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authority entity [IEEE 610]
accessibility testing: Testing to determine the ease by which users with disabilities can use a component or system. [Gerrard]
accuracy: The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality.
accuracy testing: The process of testing to determine the accuracy of a software product. See also accuracy.
acting (IDEAL): The phase within the IDEAL model where the improvements are developed, put into practice, and deployed across the organization. The acting phase consists of the activities: create solution, pilot/test solution, refine solution and implement solution. See also IDEAL.
action word driven testing: See keyword-driven testing
actor: User or any other person or system that interacts with the system under test in a specific way.
actual outcome: See actual result.
actual result: The behavior produced/observed when a component or system is tested.
ad hoc review: See informal review.
ad hoc testing: Testing carried out informally; no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and arbitrariness guides the test execution activity.
adaptability: The capability of the software product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the software considered. [ISO 9126] See also portability.
agile manifesto: A statement on the values that underpin agile software development. The values are: - individuals and interactions over processes and tools - working software over comprehensive documentation - customer collaboration over contract negotiation- responding to change over following a plan.
agile software development: A group of software development methodologies based on iterative incremental development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
agile testing: Testing practice for a project using agile software development methodologies, incorporating techniques and methods, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm. See also test-driven development.
algorithm test: [TMap]See branch testing.
alpha testing: Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organization. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing.
analytical testing: Testing based on a systematic analysis of e.g., product risks or requirements.
analyzability: The capability of the software product to be diagnosed for deficiencies or causes of failures in the software, or for the parts to be modified to be identified. [ISO 9126] See also maintainability.
analyzer: See static analyzer.
anomaly: Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, etc. or from someone’s perception or experience. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation. [IEEE 1044] See also bug, defect, deviation, error, fault, failure, incident, problem.
anti-pattern: Repeated action, process, structure or reusable solution that initially appears to be beneficial and is commonly used but is ineffective and/or counterproductive in practice.
API (Application Programming Interface) testing: Testing the code which enables communication between different processes, programs and/or systems. API testing often involves negative testing, e.g., to validate the robustness of error handling. See alsointerface testing.
arc testing: See branch testing.
assessment report: A document summarizing the assessment results, e.g. conclusions, recommendations and findings. See also process assessment.
assessor: A person who conducts an assessment; any member of an assessment team.
atomic condition: A condition that cannot be decomposed, i.e., a condition that does not contain two or more single conditions joined by a logical operator (AND, OR, XOR).
attack: Directed and focused attempt to evaluate the quality, especially reliability, of a test object by attempting to force specific failures to occur. See also negative testing
attack-based testing: An experience-based testing technique that uses software attacks to induce failures, particularly security related failures. See also attack.
attractiveness: The capability of the software product to be attractive to the user. [ISO 9126] See also usability.
audit: An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify:
(1) the form or content of the products to be produced
(2) the process by which the products shall be produced
(3) how compliance to standards or guidelines shall be measured. [IEEE 1028]
audit trail: A path by which the original input to a process (e.g. data) can be traced back through the process, taking the process output as a starting point. This facilitates defect analysis and allows a process audit to be carried out. [After TMap]
automated testware: Testware used in automated testing, such as tool scripts.
availability: The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage. [IEEE 610]
Nhận xét
Đăng nhận xét