1. Trang chủ
  2. » Kinh Doanh - Tiếp Thị

software testing concepts and operations

396 0 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Software Testing: Concepts and Operations
Tác giả Ali Mili, Fairouz Tchier
Trường học NJIT, USA
Chuyên ngành Software Engineering
Thể loại Book
Định dạng
Số trang 396
Dung lượng 3,62 MB

Cấu trúc

  • PART III TEST DATA GENERATION 141 (12)
  • PART IV TEST DEPLOYMENT AND ANALYSIS 233 (13)
  • PART V MANAGEMENT OF SOFTWARE TESTING 311 (14)
    • F. T CHIER A. M ILI (19)
      • 1.1 A YOUNG, RESTLESS DISCIPLINE (22)
      • 1.2 AN INDUSTRY UNDER STRESS (24)
      • 1.3 LARGE, COMPLEX PRODUCTS (24)
      • 1.4 EXPENSIVE PRODUCTS (26)
      • 1.5 ABSENCE OF REUSE PRACTICE (28)
      • 1.6 FAULT-PRONE DESIGNS (28)
      • 1.7 PARADOXICAL ECONOMICS (29)
        • 1.7.1 A Labor-Intensive Industry (29)
        • 1.7.2 Absence of Automation (30)
        • 1.7.3 Limited Quality Control (30)
        • 1.7.4 Unbalanced Lifecycle Costs (31)
        • 1.7.5 Unbalanced Maintenance Costs (31)
      • 1.8 CHAPTER SUMMARY (32)
      • 1.9 BIBLIOGRAPHIC NOTES (32)
      • 2.1 FUNCTIONAL ATTRIBUTES (34)
        • 2.1.1 Boolean Attributes (34)
        • 2.1.2 Statistical Attributes (34)
      • 2.2 OPERATIONAL ATTRIBUTES (36)
      • 2.3 USABILITY ATTRIBUTES (37)
      • 2.4 BUSINESS ATTRIBUTES (38)
      • 2.5 STRUCTURAL ATTRIBUTES (39)
      • 2.6 CHAPTER SUMMARY (40)
      • 2.7 EXERCISES (40)
      • 2.8 BIBLIOGRAPHIC NOTES (41)
      • 3.1 A SOFTWARE ENGINEERING LIFECYCLE (42)
      • 3.2 A SOFTWARE TESTING LIFECYCLE (46)
      • 3.3 THE V-MODEL OF SOFTWARE TESTING (51)
      • 3.4 CHAPTER SUMMARY (52)
      • 3.5 BIBLIOGRAPHIC NOTES (53)
      • 4.1 PRINCIPLES OF SOUND SPECIFICATION (56)
        • 4.1.1 A Discipline of Specification (56)
      • 4.2 RELATIONAL MATHEMATICS (57)
        • 4.2.1 Sets and Relations (57)
        • 4.2.2 Operations on Relations (57)
        • 4.2.3 Properties of Relations (59)
      • 4.3 SIMPLE INPUT OUTPUT PROGRAMS (60)
        • 4.3.1 Representing Specifications (60)
        • 4.3.2 Ordering Specifications (64)
        • 4.3.3 Specification Generation (66)
        • 4.3.4 Specification Validation (71)
      • 4.4 RELIABILITY VERSUS SAFETY (78)
      • 4.5 STATE-BASED SYSTEMS (79)
        • 4.5.1 A Relational Model (80)
        • 4.5.2 Axiomatic Representation (82)
        • 4.5.3 SPECIFICATION VALIDATION (88)
      • 4.6 CHAPTER SUMMARY (90)
      • 4.7 EXERCISES (90)
      • 4.8 PROBLEMS (94)
      • VX- operations: These are operations that return values but do not change (94)
        • 4.9 BIBLIOGRAPHIC NOTES (96)
        • 5.1 CORRECTNESS: A DEFINITION (98)
        • 5.2 CORRECTNESS: PROPOSITIONS (101)
          • 5.2.1 Correctness and Refinement (101)
          • 5.2.2 Set Theoretic Characterizations (103)
          • 5.2.3 Illustrations (104)
        • 5.3 VERIFICATION (106)
          • 5.3.1 Sample Formulas (107)
          • 5.3.2 An Inference System (109)
          • 5.3.3 Illustrative Examples (112)
        • 5.4 CHAPTER SUMMARY (116)
        • 5.5 EXERCISES (117)
        • 5.6 PROBLEMS (118)
        • 5.7 BIBLIOGRAPHIC NOTES (118)
        • 6.1 FAILURE, ERROR, AND FAULT (119)
        • 6.2 FAULTS AND RELATIVE CORRECTNESS (121)
          • 6.2.1 Fault, an Evasive Concept (121)
          • 6.2.2 Relative Correctness (122)
        • 6.3 CONTINGENT FAULTS AND DEFINITE FAULTS (125)
          • 6.3.1 Contingent Faults (125)
          • 6.3.2 Monotonic Fault Removal (127)
          • 6.3.3 A Framework for Monotonic Fault Removal (132)
          • 6.3.4 Definite Faults (132)
        • 6.4 FAULT MANAGEMENT (134)
          • 6.4.1 Lines of Defense (134)
          • 6.4.2 Hybrid Validation (136)
        • 6.5 CHAPTER SUMMARY (139)
        • 6.6 EXERCISES (140)
        • 6.7 PROBLEMS (141)
        • 6.8 BIBLIOGRAPHIC NOTES (142)
        • 7.1 THE TROUBLE WITH HYPHENATED TESTING (143)
        • 7.2 A CLASSIFICATION SCHEME (144)
          • 7.2.1 Primary Attributes (145)
          • 7.2.2 Secondary Attributes (149)
        • 7.3 TESTING TAXONOMY (154)
          • 7.3.1 Unit-Level Testing (154)
          • 7.3.2 System-Level Testing (156)
        • 7.4 EXERCISES (157)
        • 7.5 BIBLIOGRAPHIC NOTES (158)
        • 8.1 TEST GENERATION AND TARGET ATTRIBUTES (160)
        • 8.2 TEST OUTCOMES (163)
        • 8.3 TEST GENERATION REQUIREMENTS (165)
        • 8.4 TEST GENERATION CRITERIA (169)
        • 8.5 EMPIRICAL ADEQUACY ASSESSMENT (172)
        • 8.6 CHAPTER SUMMARY (177)
        • 8.7 EXERCISES (178)
        • 8.8 BIBLIOGRAPHIC NOTES (179)
        • 8.9 APPENDIX: MUTATION PROGRAM (180)
    • case 4: m4(a,N); case 5: m5(a,N);} (180)
      • 9.1 DOMAIN PARTITIONING (182)
      • 9.2 TEST DATA GENERATION FROM TABULAR EXPRESSIONS (188)
      • 9.3 TEST GENERATION FOR STATE BASED SYSTEMS (193)

Nội dung

Software engineering is the only engineering discipline where product testing is amajor technical and organizational concern, as well as an important cost factor.Several factors contribu

TEST DATA GENERATION 141

8.1 Test Generation and Target Attributes / 143 8.2 Test Outcomes / 146

8.3 Test Generation Requirements / 148 8.4 Test Generation Criteria / 152 8.5 Empirical Adequacy Assessment / 155 8.6 Chapter Summary / 160

8.7 Exercises / 161 8.8 Bibliographic Notes / 162 8.9 Appendix: Mutation Program / 163

9.1 Domain Partitioning / 165 9.2 Test Data Generation from Tabular Expressions / 171 9.3 Test Generation for State Based Systems / 176 9.4 Random Test Data Generation / 184

9.5 Tourism as a Metaphor for Test Data Selection / 188 9.6 Chapter Summary / 190

10.1 Paths and Path Conditions / 194 10.1.1 Execution Paths / 194 10.1.2 Path Functions / 196 10.1.3 Path Conditions / 201 10.2 Control Flow Coverage / 202

10.2.1 Statement Coverage / 202 10.2.2 Branch Coverage / 204 10.2.3 Condition Coverage / 207 10.2.4 Path Coverage / 209 10.3 Data Flow Coverage / 214

10.3.1 Definitions and Uses / 214 10.3.2 Test Generation Criteria / 217 10.3.3 A Hierarchy of Criteria / 220 10.4 Fault-Based Test Generation / 220

10.4.1 Sensitizing Faults / 221 10.4.2 Selecting Input Data for Fault Sensitization / 225 10.4.3 Selecting Input Data for Error Propagation / 227 10.5 Chapter Summary / 228 x CONTENTS

TEST DEPLOYMENT AND ANALYSIS 233

11.1 Dilemmas of Oracle Design / 235 11.2 From Specifications to Oracles / 238 11.3 Oracles for State-Based Products / 242

11.3.1 From Axioms to Oracles / 243 11.3.2 From Rules to Oracles / 244 11.4 Chapter Summary / 250

12.1 Selecting a Specification / 253 12.2 Selecting a Process / 255 12.3 Selecting a Specification Model / 257

12.3.1 Random Test Generation / 257 12.3.2 Pre-Generated Test Data / 263 12.3.3 Faults and Fault Detection / 266 12.4 Testing by Symbolic Execution / 269 12.5 Chapter Summary / 274

13.1 Logical Claims / 281 13.1.1 Concrete Testing / 281 13.1.2 Symbolic Testing / 282 13.1.3 Concolic Testing / 283 13.2 Stochastic Claims: Fault Density / 284 13.3 Stochastic Claims: Failure Probability / 287

13.3.1 Faults Are Not Created Equal / 287 13.3.2 Defining/Quantifying Reliability / 289 13.3.3 Modeling Software Reliability / 291 13.3.4 Certification Testing / 294

13.3.5 Reliability Estimation and Reliability Improvement / 295 13.3.6 Reliability Standards / 299

13.3.7 Reliability as an Economic Function / 300 13.4 Chapter Summary / 307 xi

MANAGEMENT OF SOFTWARE TESTING 311

T CHIER A M ILI

In this part we introduce software testing by discussing what makes software engineer- ing so special that testing should occupy such an important part of its lifecycle Then we survey software qualities that testing techniques may be used to assess Finally we review the various lifecycle models of software testing that may be followed depending on the context and goal of testing.

Software Testing: Concepts and Operations, First Edition Ali Mili and Fairouz Tchier. © 2015 John Wiley & Sons, Inc Published 2015 by John Wiley & Sons, Inc.

On the face of it, software engineering sounds like an engineering discipline among others, such as chemical engineering, mechanical engineering, civil engineering, and electrical engineering We will explore, in this chapter, in what way and to what extent software engineering differs from other engineering disciplines.

Civil engineering and mechanical engineering date back to antiquity or before, as one can see from various sites (buildings, road networks, utility infrastructures, etc.) around the Mediterranean basin Chemical engineering (Lavoisier and others) and electrical engineering (Franklin and others) can be traced back to the eighteenth century Nuclear engineering (Pierre and Marie Curie) emerged at the turn of the twentieth century and industrial engineering emerged around the time of the Second World War, with issues of logistics By contrast, software engineering is a comparatively young discipline, emerging as it did in the second half of the twentieth century The brief history of this discipline can be divided into five broad eras, lasting approximately one decade each, which are as follows:

• The Sixties: The Era of Pioneers.This era marks the first time that practitioners and researchers came face to face with the complexities, paradoxes, and anomalies of software engineering Software projects of this era were ventures into unchar- tered territory, characterized by high levels of risk, unpredictable outcomes, and massive cost and schedule overruns The programming languages that were dominant in this era are assembler, Fortran, Cobol, and (in academia) Algol.

Software Testing: Concepts and Operations, First Edition Ali Mili and Fairouz Tchier. © 2015 John Wiley & Sons, Inc Published 2015 by John Wiley & Sons, Inc.

• The Seventies: Structured Software Engineering.This era is characterized by the general belief that software engineering problems are of a technical nature and that if we evolved techniques for software specification, design, and verification to control complexity, all software engineering problems would be resolved.

Given that structure is our main intellectual tool for dealing with complexity, this era has seen the emergence of a wide range of structured techniques, including structured programming, structured design, structured analysis, structured speci- fications, etc The programming languages that were dominant in this era are C and (in academia) Pascal.

• The Eighties: Knowledge-Based Software Engineering.This era is characterized by the realization that software engineering problems are of a managerial and organizational nature more than a technical nature This realization was concur- rent with the emergence of the Fifth Generation Computing initiative, which started in Japan and spread across the globe (the United States, Europe, Canada), and was focused on thinking machines designed with extensive use of artificial intelligence techniques This general approach permeated the discipline of soft- ware engineering with the emergence of knowledge-based software engineering techniques The programming languages that were dominant in this era are Prolog, Scheme/Lisp, and Ada.

• The Nineties: Reuse-Based Software Engineering As it became increasingly clear that fifth-generation computing was not delivering on its promise, and worldwide fifth-generation initiatives were fading, software researchers and practitioners turned their attention to reuse as a possible savior of the discipline.

Software engineering is, after all, the only discipline where reuse is not an inte- gral part of the routine engineering process It was felt that if only software engi- neers had large databases of reusable software components readily available, the industry would achieve great gains in productivity, quality, time to market, and reduced process risk This evolution was concurrent with the emergence of object-oriented programming, which supports a bottom–up design discipline that facilitates product reuse The programming languages that were dominant in this era are C, C++, Eiffel, and Smalltalk.

• The First Decade of the Millennium: Lightweight Software Engineering.While software reuse is not practical as a general paradigm in software engineering, it is feasible in limited application domains, giving rise toproduct line engineer- ing Other attributes of this era include Java programming, with its focus on web applications; agile programming, with its focus on rapid and flexible response to change; and component-based software engineering, with its focus on software architecture and software composition The programming languages that were dominant in this era are Java, C++, and (in academia) Python.

Perhaps as result of this young and eventful history, the discipline of software engi- neering is characterized by a number of paradoxes and counter-intuitive properties, which we explore in this chapter.

Nowadays, software runs all aspects of modern life and accounts for a large and increasing share of the world economy This trend started slowly with the advent of computing in the middle of the twentieth century and was further precipitated by the emergence of the World Wide Web at the end of the twentieth and the begin- ning of the twenty-first century This phenomenon has spawned a great demand for software products and services and generated a market pressure that the software industry takes great pains to cater to.

Many fields of science and engineering (such as bioinformatics, medical informat- ics, weather forecasting, and modeling and simulation) are so dependent on software that they can almost be considered as mere applications of software engineering Also, it is possible to observe that many computer science curricula are slowly inching toward more software engineering contents at the expense of traditional theoretical material, which may be perceived as less and less relevant to today’s job market.

Some engineering colleges are preempting the trend by starting software engineering degrees in computer science departments or by starting complete software engineering departments alongside traditional computer science departments.

As software proliferates into diverse and critical domains, its dependability has become paramount The burgeoning demand for software necessitates high product quality, particularly in applications that impact lives, missions, and financial stability Ensuring software's ability to perform its intended function with unwavering reliability is now indispensable for safeguarding crucial operations and sensitive data.

This requires that we deploy a wide range of techniques, including the following:

• Process controls, ensuring that software products are developed and evolved according to certified, mature processes.

• Product controls, ensuring that software products meet quality standards com- mensurate with their application domain requirements; this is achieved by a com- bination of techniques, including static analysis, dynamic testing, reliability estimation, fault tolerance, etc.

m4(a,N); case 5: m5(a,N);}

for (int k=0; k

Ngày đăng: 14/09/2024, 17:07