Kkk Gfhfgh Gfhgfhfg

Testing Overview and Black-Box Testing Techniques
Software testing is an important technique for assessing the quality of a software product. In this chapter, we will explain the following: • the basics of software testing, a verification and validation practice, throughout the entire software development lifecycle • the two basic techniques of software testing, black-box testing and white-boxtesting • six types of testing that involve both black- and white-box techniques. • strategies for writing fewer test cases and still finding as many faults as possible • using a template for writing repeatable, defined test cases

1

Introduction to Testing

Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (thatis, bugs) and to evaluate the features of the software item [9, 12]. Software testing is an activity that should be done throughout the whole development process [3]. Software testing is one of the “verification and validation,” or V&V, software practices. Some other V&V practices, such as inspections and pair programming, will be discussed throughout this book. Verification (the first V) is theprocess of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase [11]. Verification activities include testing and reviews. For example, in the software for the Monopoly game, we can verify that two players cannot own the same house. Validation is the process of evaluating a system or component duringor at the end of the development process to determine whether it satisfies specified requirements [11]. At the end of development validation (the second V) activities are used to evaluate whether the features that have been built into the software satisfy the customer requirements and are traceable to customer requirements. For example, we validate that when a player lands on “Free Parking,” theyget all the money that was collected. Boehm [4] has informally defined verification and validation as follows: Verification: Are we building the product right? Through verification, we make sure the product behaves the way we want it to. For example, on the left in Figure 1, there was a problem because the specification said that players should collect $200 if they land on or pass Go. Apparentlya programmer implemented this requirement as if the player had to pass Go to collect. A test case in which the player landed on Go revealed this error. Validation: Are we building the right product? Through validation, we check to make sure that somewhere in the process a mistake hasn’t been made such that the product build is not what the customer asked for; validation always involves comparisonagainst requirements. For example, on the right in Figure 1, the customer specified requirements for the Monopoly game – but the programmer delivered the game of Life. Maybe the programmer thought he or she

Testing Overview and Black-Box Testing Techniques

“knew better” than the customer that the game of Life was more fun than Monopoly and wanted to “delight” the customer with somethingmore fun than the specifications stated. This example may seem exaggerated – but as programmers we can miss the mark by that much if we don’t listen well enough or don’t pay attention to details – or if we second guess what the customer says and think we know better how to solve the customer’s problems. Verification Are we building the product right? Validation Are we building the right product?“I landed on “Go” but didn’t get my $200!”

“I know this game has money and players and “Go” – but this is not the game I wanted.”

Figure 1: Verification vs. Validation

Both of Boehm’s informal definitions use the term “right.” But what is “right”? In software we need to have some kind of standard or specification to measure against so that we can identify correct results from incorrect...