IT205: Software Engineering

MIDTERM

Software Testing - a critical element of software quality assurance and represents the ultimate review of specification, design and coding - a series of tests cases that are intended to demolish the software that has been built are created - one step in the software engineering processes that could be viewed as destructive rather than constructive - requires that the developer discard preconceived notions of the correctness of software just developed and overcome a conflict of interest that occurs when errors uncovered Testing Objective - testing is a process of executing a program with the intent of finding an error - a good test is one that has a high probability of finding an as-yet undiscovered error - a successful test is one that uncovers an as-yet undiscovered error Testing Principles - all tests should be traceable to customer requirements - tests should be planned long before testing begins - the Pareto principle applies to software testing - testing should begin in the small and progress toward testing in the large - exhausting testing is not possible - to be most effective, testing should be conducted by an independent third party Testability - simply how easily a computer program can be tested - it pays to know what can be done to streamline it - sometimes used to mean how adequately a particular set of tests will cover the product - set of characteristics that lead to testable software o operability o observability o controllability o decomposability o simplicity o stability o understandability White box testing - sometimes called glass-box testing - a test case design method that uses the control structure of the procedural design to derive test cases - the software engineer can derive test cases that: o Guaranteed that all independent paths within a module have been exercise at least once. o Execute all loops at their boundaries and within their operational bounds o Exercise internal and data structures to assure their validity - Reasons in conducting white box testing o Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed o We often believe that a logical path is not likely to be executed when, in fact, it may be executed on a regular basis o Typographical errors are random

Page 1 of 6

Prepared by: Cris Norman P. Olipas

IT205: Software Engineering

MIDTERM

Basis Path Testing - a white box testing technique first proposed by Tom McCabe - Enables the test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Black Box Testing - focuses on the functional requirements of the software - enables the software engineer to derive set of input conditions that will fully exercise all functional requirements for a program - not an alternative to white box techniques - a complementary approach that is likely to uncover a different class of errors than white box methods - attempts to find errors in the following categories: o incorrect or missing functions o interface errors o errors in data structures or external database access o performance errors o initialization and termination errors - criteria in applying black box technique o test cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing o test cases that tell us something about the presence or absence of classes or errors, rather than errors associated only with the specific test at hand Software Testing Strategy - provides a road map for the software developer, the quality assurance organization and the customers - incorporate test planning, test case design, test execution and resultant data collection and evaluation - should be flexible enough to promote the creativity and customization that are necessary to adequately test all large software based systems - must be rigid enough to promote reasonable planning and management tracking as the project progresses - characteristics o testing begins at the module level and works outward toward the integration of the entire computer based system o different testing techniques are appropriate at different points in time o testing is conducted by the developer of the software and an independent test group o testing and debugging are different activities, but debugging must be accommodated in any testing strategy Verification and validation - verification refers to the set of activities that ensure that software correctly implements a specific function - validation refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements Verification: Validation: Are we building the product right Are we building the right product

Page 2 of 6

Prepared by: Cris Norman P. Olipas

IT205: Software Engineering

MIDTERM

Page 3 of 6

Prepared by: Cris Norman P. Olipas

IT205: Software Engineering Strategic Issues - specify product requirements in a quantifiable manner long before testing commences - state testing objectives explicitly - understand the users of the software and develop a profile for each user category - develop a testing plan that emphasizes rapid cycle testing - build robust software that is designed to test itself - use effective formal technique reviews as a filter prior to testing - conduct formal technical reviews to assess the test strategy and test cases themselves - develop a continuous improvement approach for the testing process

MIDTERM

Unit Testing - focuses verification effort on the smallest unit of software design the module - normally white box oriented, and the step can be conducted in parallel for multiple modules - the relative complexity of tests and uncovered errors is limited by the constrained scope established for unit testing

Checklist for Interface Tests Number of input parameters equal to number of arguments? Parameter and argument attributes match? Parameter and argument units systems match? Number of arguments transmitted to called modules equal to number of parameters? Attributes or arguments transmitted to called modules equal to attributes of parameters? Unit system of arguments transmitted to called modules equal to unit system of parameters? Number of attributes and order of arguments to built-in functions correct? Any references to parameters not associated with current point of entry? Input-only arguments altered? Global variable definitions consistent across modules? Constraints passed as arguments? Integration Testing - a systematic technique for constructing the program structure while conducting tests to uncover errors associated with interfacing - its objective is to take unit tested modules and build a program structure that has been dictated by design Page 4 of 6 Prepared by: Cris Norman P. Olipas

IT205: Software Engineering Top-Down Integration - an incremental approach to construction of program structure

MIDTERM

Bottom-Up Integration - begins construction and testing with atomic modules

Validation Testing - succeeds when software functions in a manner that can be reasonably expected by the customer - can be achieved through a series of black box tests that demonstrate conformity with requirements Alpha Testing - conducted at the developers site by a customer Page 5 of 6 Prepared by: Cris Norman P. Olipas

IT205: Software Engineering Beta Testing - conducted at one or more customer sites by the end user of the software System Testing - a series of different tests whose primary purpose is to fully exercise the computer based system

MIDTERM

Recovery Testing - a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed Security Testing - attempts to verify that protection mechanisms built into a system will in fact protect it from improper penetration Stress Testing - executes a system in a manner that demands resources in abnormal quantity, frequency or volume Performance Testing - designed to test run-time performance of software within the context of an integrated system

Page 6 of 6

Prepared by: Cris Norman P. Olipas