软件测试论坛

 找回密码
 软件测试论坛注册页
查看: 2456|回复: 12

A Practitioner's Guide to Software Test Design ------ [e-book]

  [复制链接]
发表于 2007-10-31 17:39:56 | 显示全部楼层 |阅读模式
软件测试工程师就业班马上开班
Table of Contents  
A Practitioner's Guide to Software Test Design  
Preface  
Chapter 1 - The Testing Process
Chapter 2 - Case Studies
Section I - Black Box Testing Techniques
Chapter 3 - Equivalence Class Testing
Chapter 4 - Boundary Value Testing
Chapter 5 - Decision Table Testing
Chapter 6 - Pairwise Testing
Chapter 7 - State-Transition Testing
Chapter 8 - Domain Analysis Testing
Chapter 9 - [b][url=http://www.ltesting.net/html/94/category-catid-94.html]Use Case[/url][/b] Testing
Section II - White Box Testing Techniques
Chapter 10 - Control Flow Testing
Chapter 11 - Data Flow Testing
Section III - Testing Paradigms
Chapter 12 - Scripted Testing
Chapter 13 - Exploratory Testing
Chapter 14 - Test Planning
Section IV - Supporting Technologies
Chapter 15 - [b][url=http://www.ltesting.net/html/98/category-catid-98.html]Defect[/url][/b] Taxonomies
Chapter 16 - When to Stop Testing
Section V - Some Final Thoughts
Appendix A - Brown & Donaldson Case Study
Appendix B - Stateless University Registration System Case Study
Bibliography  
Index  
List of Figures  
List of Tables  
List of Examples
ISTQB
 楼主| 发表于 2007-10-31 17:42:13 | 显示全部楼层
软件测试工程师就业班马上开班
PrefaceA Practitioner's Guide to Software Test Design contains today's important current test design approaches in one unique book. Until now, software testers had to search through a number of books, periodicals, and Web sites to locate this vital information.
Importance of Test Design
"The act of careful, complete, systematic, test design will catch as many bugs as the act of testing. ... Personally, I believe that it's far more effective."
- Boris Beizer
The book focuses only on software test design, not related subjects such as test planning, test management, test team development, etc. While those are important in software testing, they have often overshadowed what testers really need—the more practical aspects of testing, specifically test case design. Other excellent books can guide you through the overall process of software testing. One of my favorites is [url=]Systematic Software Testing[/url] by Rick Craig and Stefan Jaskiel.
A Practitioner's Guide to Software Test Design illustrates each test design approach through detailed examples and step-by-step instructions. These lead the reader to a clear understanding of each test design technique.
Today's Testing ChallengesFor any system of interesting size it is impossible to test all the different logic paths and all the different input data combinations. Of the infinite number of choices, each one of which is worthy of some level of testing, testers can only choose a very small subset because of resource constraints. The purpose of this book is to help you analyze, design, and choose such subsets, to implement those tests that are most likely to discover defects.
It is vital to choose test cases wisely. Missing a defect can result in significant losses to your organization if a defective system is placed into production.
A Practitioner's Guide to Software Test Design describes a set of key test design strategies that improve both the efficiency and effectiveness of software testers.
ISTQB
 楼主| 发表于 2007-10-31 17:43:29 | 显示全部楼层
软件测试工程师就业班马上开班
Structure and ApproachA Practitioner's Guide to Software Test Design explains the most important test design techniques in use today. Some of these techniques are classics and well known throughout the testing community. Some have been around for a while but are not well known among test engineers. Still others are not widely known, but should be because of their effectiveness. This book brings together all these techniques into one volume, helping the test designer become more efficient and effective in testing.
Each test design technique is approached from a practical, rather than a theoretical basis. Each test design technique is first introduced through a simple example, then explained in detail. When possible, additional examples of its use are presented. The types of problems on which the approach can be used, along with its limitations, are described. Each test design technique chapter ends with a summary of its key points, along with exercises the reader can use for practice, and references for further reading. Testers can use the techniques presented immediately on their projects.
A Note from the Author
I love a good double integral sign
as much as the next tester, but we're going to concentrate on the practical, not the theoretical.

Each test design approach is described in a self-contained chapter. Because the chapters are focused, concise, and independent they can be read "out of order." Testers can read the chapters that are most relevant to their work at the moment.
 楼主| 发表于 2007-10-31 17:44:51 | 显示全部楼层
软件测试工程师就业班马上开班
AudienceThis book was written specifically for:
    Software test engineers who have the primary responsibility for test case design. This book details the most efficient and effective methods for creating test cases.
    Software developers who, with the advent of Extreme Programming and other agile development methods, are being asked to do more and better testing of the software they write. Many developers have not been exposed to the design techniques described in this book.
    Test and development managers who must understand, at least in principle, the work their staff performs. Not only does this book provide an overview of important test design methods, it will assist managers in estimating the effort, time, and cost of good testing.
    Quality assurance and process improvement engineers who are charged with defining and improving their software testing process.
  • Instructors and professors who are searching for an excellent reference for a course in software test design techniques.
 楼主| 发表于 2007-10-31 17:45:39 | 显示全部楼层
软件测试工程师就业班马上开班
Chapter 1: The Testing ProcessOverview
The flock of geese flew overhead in a 'V' formationnot in an old-fashioned-looking Times New Roman kind of a 'V', branched out slightly at the two opposite arms at the top of the 'V', nor in a more modern-looking, straight and crisp, linear Arial sort of 'V' (although since they were flying, Arial might have been appropriate), but in a slightly asymmetric, tilting off-to-one-side sort of italicized Courier New-like 'V'and LaFonte knew that he was just the type of man to know the difference. — John Dotson

If you think this quotation has nothing to do with software testing you are correct. For an explanation please read "Some Final Comments" in the Preface.

[ 本帖最后由 aken 于 2007-10-31 17:46 编辑 ]
 楼主| 发表于 2007-10-31 17:47:57 | 显示全部楼层
软件测试工程师就业班马上开班
TestingWhat is testing? While many definitions have been written, at its core testing is the process of comparing "what is" with "what ought to be." A more formal definition is given in the IEEE Standard 610.12-1990, "IEEE Standard Glossary of Software Engineering Terminology" which defines "testing" as:
"The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component."
The "specified conditions" referred to in this definition are embodied in test cases, the subject of this book.
Key Point At its core, testing is the process of comparing "what is" with "what ought to be."
Rick Craig and Stefan Jaskiel propose an expanded definition of software testing in their book, [url=]Systematic Software Testing[/url].
"Testing is a concurrent lifecycle process of engineering, using and maintaining testware in order to measure and improve the quality of the software being tested."
This view includes the planning, analysis, and design that leads to the creation of test cases in addition to the IEEE's focus on test execution.
Different organizations and different individuals have varied views of the purpose of software testing. Boris Beizer describes five levels of testing maturity. (He called them phases but today we know the politically correct term is "levels" and there are always five of them.)
Level 0 - "There's no difference between testing and debugging. Other than in support of debugging, testing has no purpose." Defects may be stumbled upon but there is no formalized effort to find them.
Level 1 - "The purpose of testing is to show that software works." This approach, which starts with the premise that the software is (basically) correct, may blind us to discovering defects. Glenford Myers wrote that those performing the testing may subconsciously select test cases that should not fail. They will not create the "diabolical" tests needed to find deeply hidden defects.
Level 2 - "The purpose of testing is to show that the software doesn't work." This is a very different mindset. It assumes the software doesn't work and challenges the tester to find its defects. With this approach, we will consciously select test cases that evaluate the system in its nooks and crannies, at its boundaries, and near its edges, using diabolically constructed test cases.
Level 3 - "The purpose of testing is not to prove anything, but to reduce the perceived risk of not working to an acceptable value." While we can prove a system incorrect with only one test case, it is impossible to ever prove it correct. To do so would require us to test every possible valid combination of input data and every possible invalid combination of input data. Our goals are to understand the quality of the software in terms of its defects, to furnish the programmers with information about the software's deficiencies, and to provide management with an evaluation of the negative impact on our organization if we shipped this system to customers in its present state.
Level 4 - "Testing is not an act. It is a mental discipline that results in low-risk software without much testing effort." At this maturity level we focus on making software more testable from its inception. This includes reviews and inspections of its requirements, design, and code. In addition, it means writing code that incorporates facilities the tester can easily use to interrogate it while it is executing. Further, it means writing code that is self-diagnosing, that reports errors rather than requiring testers to discover them.
 楼主| 发表于 2007-10-31 17:49:11 | 显示全部楼层
Current ChallengesWhen I ask my students about the challenges they face in testing they typically reply:
    Not enough time to test properly
    Too many combinations of inputs to test
    Not enough time to test well
    Difficulty in determining the expected results of each test
    Nonexistent or rapidly changing requirements
    Not enough time to test thoroughly
    No training in testing processes
    No tool support
    Management that either doesn't understand testing or (apparently) doesn't care about quality
  • Not enough time
This book does not contain "magic pixie dust" that you can use to create additional time, better requirements, or more enlightened management. It does, however, contain techniques that will make you more efficient and effective in your testing by helping you choose and construct test cases that will find substantially more defects than you have in the past while using fewer resources.
 楼主| 发表于 2007-10-31 17:54:12 | 显示全部楼层
Test CasesTo be most effective and efficient, test cases must be designed, not just slapped together. The word "design" has a number of definitions:
    To conceive or fashion in the mind; invent: design a good reason to attend the STAR testing conference. To formulate a plan for; devise: design a marketing strategy for the new product.
    To plan out in systematic, usually documented form: design a building; design a test case.
    To create or contrive for a particular purpose or effect: a game designed to appeal to all ages.
    To have as a goal or purpose; intend.
  • To create or execute in an artistic or highly skilled manner.
Key Point To be most effective and efficient, test cases must be designed, not just slapped together.
Each of these definitions applies to good test case design. Regarding test case design, Roger Pressman wrote:
"The design of tests for software and other engineering products can be as challenging as the initial design of the product itself. Yet ... software engineers often treat testing as an afterthought, developing test cases that 'feel right' but have little assurance of being complete. Recalling the objectives of testing, we must design tests that have the highest likelihood of finding the most errors with a minimum amount of time and effort."
Well designed test cases are composed of three parts:
    Inputs
    Outputs
  • Order of execution
Key Point Test cases consist of inputs, outputs, and order of execution.
 楼主| 发表于 2007-10-31 17:54:58 | 显示全部楼层
InputsInputs are commonly thought of as data entered at a keyboard. While that is a significant source of system input, data can come from other sources-data from interfacing systems, data from interfacing devices, data read from files or databases, the state the system is in when the data arrives, and the environment within which the system executes.

OutputsOutputs have this same variety. Often outputs are thought of as just the data displayed on a computer screen. In addition, data can be sent to interfacing systems and to external devices. Data can be written to files or databases. The state or the environment may be modified by the system's execution.
All of these relevant inputs and outputs are important components of a test case. In test case design, determining the expected outputs is the function of an "oracle."
An oracle is any program, process, or data that provides the test designer with the expected result of a test. Beizer lists five types of oracles:
    Kiddie Oracles - Just run the program and see what comes out. If it looks about right, it must be right.
    Regression Test Suites - Run the program and compare the output to the results of the same tests run against a previous version of the program.
    Validated Data - Run the program and compare the results against a standard such as a table, formula, or other accepted definition of valid output.
    Purchased Test Suites - Run the program against a standardized test suite that has been previously created and validated. Programs like compilers, Web browsers, and SQL (Structured Query Language) processors are often tested against such suites.
  • Existing Program - Run the program and compare the output to another version of the program.
 楼主| 发表于 2007-10-31 17:57:04 | 显示全部楼层
Order of ExecutionThere are two styles of test case design regarding order of test execution.
·
Cascading test cases - Test cases may build on each other. For example, the first test case exercises a particular feature of the software and then leaves the system in a state such that the second test case can be executed. In testing a database consider these test cases:
1.
Create a record
2.
Read the record
3.
Update the record
4.
Read the record
5.
Delete the record
6.
Read the deleted record
Each of these tests could be built on the previous tests. The advantage is that each test case is typically smaller and simpler. The disadvantage is that if one test fails, the subsequent tests may be invalid.
Independent test cases - Each test case is entirely self contained. Tests do not build on each other or require that other tests have been successfully executed. The advantage is that any number of tests can be executed in any order. The disadvantage is that each test tends to be larger and more complex and thus more difficult to design, create, and maintain.
 楼主| 发表于 2007-10-31 17:58:15 | 显示全部楼层
Types Of TestingTesting is often divided into black box testing and white box testing.
Black box testing is a strategy in which testing is based solely on the requirements and specifications. Unlike its complement, white box testing, black box testing requires no knowledge of the internal paths, structure, or implementation of the software under test.
White box testing is a strategy in which testing is based on the internal paths, structure, and implementation of the software under test. Unlike its complement, black box testing, white box testing generally requires detailed programming skills.
An additional type of testing is called gray box testing. In this approach we peek into the "box" under test just long enough to understand how it has been implemented. Then we close up the box and use our knowledge to choose more effective black box tests.
发表于 2012-2-6 10:12:09 | 显示全部楼层
路过 ...其实 我 是看不懂的
发表于 2012-3-4 13:11:00 | 显示全部楼层
表示都看不懂啊,呵呵,顶一个.....

本版积分规则

Archiver|手机版|小黑屋|领测软件测试网 ( 京ICP备10010545号-5 )

GMT+8, 2021-10-22 08:07 , Processed in 0.222425 second(s), 12 queries , Xcache On.

Powered by Discuz! X3

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表