A use case is a technique to capture the functional requirements of a system. It uses actors/roles and events to represent business functionality.
Use cases provide a description of interaction between business roles and the system under test. Use cases utilize “actors” to represent the initiator role which interacts with the system. These actors can be end users, other systems, or hardware. A use case shows a series of events or actions which are executed by the actor. From a software testing perspective, use cases provide a firm foundation for how tests should be designed to validate business functionality.
A test case is a set of conditions and variables built to determine if software meets expected criteria.
Traditional test cases are built from formal software requirements and are used to measure if the product meets the business needs. The most optimal situation calls for test cases to built from established use cases in order to cover business flows of the software.
Test scripts are test cases are manual or automated.
A test script is often interchanged with the term test case in many organizations. The differentiator with test scripts is that they can be manual or automated tests. Software testing organizations generally dedicate particular testers to develop automation testing programs which are called test scripts.
A test suite, or validation suite, is a collection of test cases designed to conduct and validate a business process.
The concept of a test suite arises when testers feel a need to combine several test cases in order to complete a business process (also known as a business function). Software testers use the results of these test suites to report the stability of business processes. Test suites are an important component of a software tester’s arsenal.
A software defect is generally defined as a discrepancy between established software requirements and software functionality.
Software issues are commonly referred to as defects. From a software testing perspective, a defect is loosely defined as a discrepancy between software requirements and software functionality. There can be many types of defects other than those related to testing. For example, a software requirement can not match the needs of the business and it would generate a defect in the requirements. Defects are often managed in a defect management system that allows developers and testers to enter, assign and prfioritize them. These systems can also generate reports to measure the quality state of the software.
A benchmark is a standard by which something is evaluated or measured.
A benchmark in the SDLC consists of measuring a set of activities or data in order to determine improvement. An example of a benchmark is the STLC is taking a snapshot of the number of critical defects within software build. The benchmark could determine if future software builds are better or worse than the one measured.
Reference: Introduction to Testing, HP Software University Student Guide.