軟件測試基礎(chǔ)

前言

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．

內(nèi)容概要

本書采用創(chuàng)新方法來講述軟件測試，定義測試為將幾個(gè)通用的測試準(zhǔn)則應(yīng)用于軟件結(jié)構(gòu)或軟件模型的過程。書中融入了最新的測試技術(shù)，包括現(xiàn)代軟件方法（如面向?qū)ο螅琖eb應(yīng)用程序和嵌入式軟件。另外，本書包含了大量的實(shí)例。

作者簡介

作者：(美國)阿曼(Paul Ammann) (美國)奧法特(Jeff Offutt)Paul Ammann，在美國維吉尼亞大學(xué)獲得計(jì)算機(jī)科學(xué)博士學(xué)位，現(xiàn)為喬治·梅森大學(xué)軟件工程副教授。他于2007年獲得喬治·梅森大學(xué)Volgenau信息技術(shù)與工程學(xué)院的杰出教學(xué)獎(jiǎng)。  Jeff Offutt，在喬治亞理工學(xué)院獲得計(jì)算機(jī)博士學(xué)位，現(xiàn)為喬治·梅森大學(xué)軟件工程教授。他是（（Journal of Software Testing，Verification and Reliability））的主編，是IEEE軟件測試、驗(yàn)證和確認(rèn)國際會議指導(dǎo)委員會主席，還是許多期刊的編委。他于2003年獲得喬治·梅森大學(xué)Volgenau信息技術(shù)與工程學(xué)院的優(yōu)秀教師獎(jiǎng)。

書籍目錄

PrefacePart 1 Overview　1　Introduction　　1.1 Activities of a Test Engineer　　　1.1.1 Testing Levels Based on Software Activity　　　1.1.2 Beizer's Testing Levels Based on Test Process Maturity　　　1.1.3 Automation of Test Activities　　1.2 Software Testing Limitations and Terminology　　1.3 Coverage Criteria for Testing　　　1.3.1 Infeasibility and Subsumption　　　1.3.2 Characteristics of a Good Coverage Criterion　　1.4 Older Software Testing Terminology　　1.5 Bibliographic NotesPart 2  Coverage Criteria　2　Graph Coverage　　2.1 Overview　　2.2 Graph Coverage Criteria　　　2.2.1 Structural Coverage Criteria　　　2.2.2 Data Flow Criteria　　　2.2.3 Subsumption Relationships among Graph Coverage Criteria  　　2.3 Graph Coverage for Source Code　　　2.3.1 Structural Graph Coverage for Source Code　　　2.3.2 Data Flow Graph Coverage for Source Code   2.4 Graph Coverage for Design Elements　　　2.4.1 Structural Graph Coverage for Design Elements　　　2.4.2 Data Flow Graph Coverage for Design Elements   2.5 Graph Coverage for Specifications　　　2.5.1 Testing Sequencing Constraints　　　2.5.2 Testing State Behavior of Software   2.6 Graph Coverage for Use Cases　　　2.6.1 Use Case Scenarios   2.7 Representing Graphs Algebraically　　　2.7.1 Reducing Graphs to Path Expressions　　　2.7.2 Applications of Path Expressions　　　2.7.3 Deriving Test Inputs　　　2.7.4 Counting Paths in a Flow Graph and Determining Max Path Length　　　2.7.5 Minimum Number of Paths to Reach All Edges　　　2.7.6 Complementary Operations Analysis   2.8 Bibliographic Notes　3　Logic Coverage    3.1 Overview: Logic Predicates and Clauses    3.2 Logic Expression Coverage Criteria　　　3.2.1 Active Clause Coverage　　　3.2.2 Inactive Clause Coverage　　　3.2.3 Infeasibility and Subsumption　　　3.2.4 Making a Clause Determine a Predicate　　　3.2.5 Finding Satisfying Values    3.3 Structural Logic Coverage of Programs　　　3.3.1 Predicate Transformation Issues    3.4 Specification-Based Logic Coverage　　3.5 Logic Coverage of Finite State Machines    3.6 Disjunctive Normal Form Criteria    3.7 Bibliographic Notes　4 Input Space Partitioning    4.1 Input Domain Modeling　　　 4.1.1 Interface-Based Input Domain Modeling　　　 4.1.2 Functionality-Based Input Domain Modeling　　　 4.1.3 Identifying Characteristics　　　 4.1.4 Choosing Blocks and Values　　　 4.1.5 Using More than One Input Domain Model　　　 4.1.6 Checking the Input Domain Model    4.2 Combination Strategies Criteria    4.3 Constraints among Partitions    4.4 Bibliographic Notes　5   Syntax-Based TestingPart 3 Applying Criteria in Practice　6　Practical Considerations　7　Engineering Criteria for Technologies　8　Building Testing Tools　9　Challenges In Testing SoftwareList of CriteriaBibliographyIndex

章節(jié)摘錄

插圖：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.

媒體關(guān)注與評論

“關(guān)于測試的書很多，但是大部分書涉及的主題范圍都很窄并且講述不詳細(xì)。而Ammann和Offutt的這本書中所展示的概念和技術(shù)廣泛地覆蓋了業(yè)界和學(xué)術(shù)界使用的各種語言及平臺，是一本全面、實(shí)用的測試書?！?  　　 ——Roger Alexander，華盛頓州立大學(xué)

圖書封面

圖書標(biāo)簽Tags

無

評論、評分、閱讀與下載

---

    軟件測試基礎(chǔ) PDF格式下載

---