软件测试基础

章节摘录

插图：In Level 1 testing，the purpose is to show correctness：While a significant step upfrom the naive level 0.this has the ortunate problem that in any but the most triv-ial of programs，correctness is virtually impossible to either achieve or demonstrate.Suppose we run a collection of tests and find no failures.What do we know？Shouldwe assume that we have good software or iust bad tests？Since the goal of correct.ness is impossible，test engineers usually have no strict goal，real stopping rule，orformal test technique.If a development manager asks how much testing remains tobe done.the test manager has no way to answer the question.In fact.test managersare in a powerless position because they have no way to quantitatively express orevaluate their work.In Level 2 testing.the purpose is to show failures.Although looking for failuresis certainly a valid goal，it is also a negative goal.Testers may enjoy finding theproblem，but the developers never want to find problems-they want the softwareto work （level 1 thinking is natural for the developers）.Thus，level 2 testing putstesters and developers into an adversarial relationship，which can be bad for teammorale.Beyond that.when our primary goal is to look for failures.we are still leftwondering what to do if no failures are found.Is our work done？Is our softwarevery good.or is the testing weak？Having confidence in when testing is complete isan important goal for all testers.The thinking that leads to Level 3 testing starts with the realization that testingcan show the presence，but not the absence，of failures.This lets us accept the factthat whenever we use software，we incur some risk.The risk may be small and theconsequences unimportant，or the risk may be great and the consequences catas.trophic.but risk is always there.This allows us to realize that the entire develop-ment team wants the same thing-to reduce the risk of using the software.In level 3testing，both testers and developers work together to reduce risk.Once the testers and developers are on the same“team.”an organization canprogress to real Level 4 testing.Level 4 thinking defines testing as a mental disci-pline that increases quality.Various ways exist to increase quality，of which creatingtests that cause the sOftware to fail is only one.Adopting this mindset.test engi.neers can become the technical leaders of the Droiect（as is common in many otherengineering disciplines）.They have the primary responsibility of measuring and im-proving software quality，and their expertise should help the developers.An analogythat Beizer used is that of a spell checker.We often think that the purpose of a spellchecker is to find misspelled words。but in fact.the best purpose of a spell checkeris to improve our ability to spell.Every time the spell checker finds an incorrectlyspelled word.we have the opportunity to learn how to spell the word correctly.Thespell checker is the“expert”on spelling quality.In the same way，level 4 testingmeans that the purpose of testing is to improve the ability of the developers to pro-duce high quality software.The testers should train your developers.As a reader of this book，you probably start at level 0，1，or 2.Most softwaredevelopers go through these levels at some stage in their careers.If you work insoftware development，you might pause to reflect on which testing level describesyour company or team.The rest of this chapter should help you move to level 2thinking.and to understand the importance of level 3.

前言

This book presents software testing as a practical engineering activity，essential toproducing high-quality software．It is designed to be used as the primary textbookin either an undergraduate or graduate course on software testing，as a supplementto a general course on software engineefing or data structures，and as a resource for SOftware test engineers and developers．TlliS book has a number of uniquefeatures：●It organizes the complex and confusing landscape of test coverage criteria with  a novel and extremely simple structure．At a technical level．software testing is  based on satislying coverage criteria．The book’S central observation is that there  are feW truly different coverage criteria，each of which fits easily into one of four  categories：graphs，logical expressions，input space，and syntax structures．Tllis  not only simplifies testing，but it also allows a convenient and direct theoretica  treatment of each category．This approach contrasts strongly with the traditional  view of testing，which treats testing at each phase in the development process  differently．●It iS designed and written to be a textbook．The writing style is direct．it builds the  concepts from the ground up with a minimum of required background，and it in．  eludes lots of examples，homework problems，and teaching materials．It provides  a balance of theory and practical application，presenting testing as a collection  of objective，quantitative activities that can be measured and repeated．The the．  oretical concepts are presented when needed to support the practical activities  that test engineers follow．●It assumes that testing is part of a mental discipline that helps all IT professionals  develop higher-quality software．Testing is not an anti-engineering activity，and  it is not an inherently destructive process．Neither is it only for testing specialists  or domain expels who know little about programming or math．●It is designed with modular．interconnecting pieces；thus it can be used in multi．  pie courses．Most of the book requires only basic discrete math and introductory  programming，and the parts that need more background are clearly marked．

媒体关注与评论

“关于测试的书很多，但是大部分书涉及的主题范围都很窄并且讲述不详细。而Ammann和Offutt的这本书中所展示的概念和技术广泛地覆盖了业界和学术界使用的各种语言及平台，是一本全面、实用的测试书。”   　　 ——Roger Alexander，华盛顿州立大学

内容概要

Paul Ammann，在美国维吉尼亚大学获得计算机科学博士学位，现为乔治·梅森大学软件工程副教授。他于2007年获得乔治·梅森大学Volgenau信息技术与工程学院的杰出教学奖。

Jeff Offutt，在乔治亚理工学院获得计算机博士学位，现为乔治·梅森大学软件工程教授。他是（（Journal of Software Testing，Verification and Reliability））的主编，是IEEE软件测试、验证和确认国际会议指导委员会主席，还是许多期刊的编委。他于2003年获得乔治·梅森大学Volgenau信息技术与工程学院的优秀教师奖。

书籍目录

Preface

Part1 Overview

1 Introduction

1.1 ActivitiesofaTestEngineer

1.1.1 TestingLevelsBasedonSoftwareActivity

1.1.2 BeizersTestingLevelsBasedonTestProcessMaturity

1.1.3 AutomationofTestActivities

1.2 SoftwareTestingLimitationsandTerminology

1.3 CoverageCriteriaforTesting

1.3.1 InfeasibilityandSubsumption

1.3.2 CharacteristicsofaGoodCoverageCriterion

1.4 OlderSoftwareTestingTerminology

1.5 BibliographicNotes

Part2 CoverageCriteria

2 GraphCoverage

2.1 Overview

2.2 GraphCoverageCriteria

2.2.1 StructuralCoverageCriteria

2.2.2 DataFlowCriteria

2.2.3 SubsumptionRelationshipsamongGraphCoverageCriteria

2.3 GraphCoverageforSourceCode

2.3.1 StructuralGraphCoverageforSourceCode

2.3.2 DataFlowGraphCoverageforSourceCode

2.4 GraphCoverageforDesignElements

2.4.1 StructuralGraphCoverageforDesignElements

2.4.2 DataFlowGraphCoverageforDesignElements

2.5 GraphCoverageforSpecifications

2.5.1 TestingSequencingConstraints

2.5.2 TestingStateBehaviorofSoftware

2.6 GraphCoverageforUseCases

2.6.1 UseCaseScenarios

2.7 RepresentingGraphsAlgebraically

2.7.1 ReducingGraphstoPathExpressions

2.7.2 ApplicationsofPathExpressions

2.7.3 DerivingTestInputs

2.7.4 CountingPathsinaFlowGraphandDeterminingMaxPathLength

2.7.5 MinimumNumberofPathstoReachAllEdges

2.7.6 ComplementaryOperationsAnalysis

2.8 BibliographicNotes

3 LogicCoverage

3.1 Overview:LogicPredicatesandClauses

3.2 LogicExpressionCoverageCriteria

3.2.1 ActiveClauseCoverage

3.2.2 InactiveClauseCoverage

3.2.3 InfeasibilityandSubsumption

3.2.4 MakingaClauseDetermineaPredicate

3.2.5 FindingSatisfyingValues

3.3 StructuralLogicCoverageofPrograms

3.3.1 PredicateTransformationIssues

3.4 Specification-BasedLogicCoverage

3.5 LogicCoverageofFiniteStateMachines

3.6 DisjunctiveNormalFormCriteria

3.7 BibliographicNotes

4 InputSpacePartitioning

4.1 InputDomainModeling

4.1.1 Interface-BasedInputDomainModeling

4.1.2 Functionality-BasedInputDomainModeling

4.1.3 IdentifyingCharacteristics

4.1.4 ChoosingBlocksandValues

4.1.5 UsingMorethanOneInputDomainModel

4.1.6 CheckingtheInputDomainModel

4.2 CombinationStrategiesCriteria

4.3 ConstraintsamongPartitions

4.4 BibliographicNotes

5　Syntax-Based Testing

5.1 Syntax.Based Coverage Criteria

5.1.1 BNF Coverage Criteria

5.1.2 Mutation Testing

5.2 Program.Based Grammars

5.2.1 BNF Grammars for Languages

5.2.2 Program.Based Mutation

5.3 Integration and Object-Oriented Testing

5.3.1 BNF Integration Testing

5.3.2 Integration Mutation

5.4 Specification.Based Grammars

5.4.1 BNF Grammars

5.4.2 Specification.Based Mutation

5.5 Input Space Grammars

5.5.1 BNF Grammars

5.5.2 Mutation for Input Grammars

5.6 Bibliographic Notes

Part 3 Applying Criteria In Practice

6 PractlcaI COnsIderatIOnS

6.1 Regression Testing

6.2 Integration and Testing

6.2.1 Stubs and Drivers

6.2.2 Class Integration Test Order

6.3 Test Process

6.3.1 Requirements Analysis and Specification

6.3.2 System and Software Design

6.3.3 Intermediate Design

6.3.4 Detailed Design

6.3.5 Implementation

6.3.6 Integration

6.3.7 System Deployment

6.3.8 Operation and Maintenance

6.3.9 Summary

6.4 Test Plans

6.5 Identifying Correct Outputs

6.5.1 Direct Verification of Outputs

6.5.2 Redundant Computations

6.5.3 Consistency Checks

6.5.4 Data Redundancy

6.6 Bibliographic Notes

7　Engineering Criteria for Technologies

7.1 Testing Object.Oriented Software

7.1.1 Unique Issues with Testing OO Software

7.1.2 Types of Obiect-Oriented Faults

7.2 Testing Web Applications and Web Services

7.2.1 Testing Static Hyper Text Web Sites

7.2.2 Testing Dynamic Web Applications

7.2.3 Testing Web Services

7.3 Testing Graphical User Interfaces

7.3.1 Testing GUIs

7.4 Real.Time Software and Embedded Software

7.5 Bibliographic Notes

8　Building Testing Tools

8.1 Instrumentation for Graph and Logical Expression Criteria

8.1.1 Node and Edge Coverage

8.1.2 Data Flow Coverage

8.1.3 Logic Coverage

8.2 Building Mutation Testing Tools

8.2.1 111e Interpretation Approach

8.2.2 T]he Separate Compilation Approach

8.2.3 The Schema.Based Approach

8.2.4 Using Java Refle~ion

8.2.5 Implementing a Modem Mutation System

8.3 Bibliographic Notes

9　Challenges In Testing Software

9.1 Testing for Emergent Properties：Safety and Security

9.1.1 Classes of Test Cases for Emergent Properties

9.2 Software Testability

9.2.1 Testability for Common Technologies

9.3 Test Criteria and the FUture of Software Testing

9.3.1 Going Forward with Testing Research

9.4 Bibliographic Notes

Listofcriteria

Bibliography

Index

·收起全部<<

作者简介

《软件测试基础(英文版)》内容简介：Introduction to Software Testing（ISBN 978-0-521-88038-1）by Paul Ammann and Jeff Offuttfirst published by Cambridge University Press in 2008.

All rights reserved.

This reprint edition for the People'S Republic of China is published by arrangement with thePress Syndicate of the University of Cambridge，Cambridge，United Kingdom.

◎Cambridge University Press&China Machine Press in 2009.

This edition is for sale in the mainland of China only，excluding Hong Kong SAR，Macao SARand Taiwan，and may not be bought for export therefrom.

《软件测试基础(英文版)》由机械工业出版社和剑桥大学出版社合作出版。

图书封面

---

 软件测试基础下载

---