BOOK REPORT:How to Break Software
2011-05-28 13:41
633 查看
BOOK NAME:How to Break Software
AUTHOR:James A. Whittaker
Here's a paper to get a tiny taste of this book:
http://wenku.baidu.com/view/2b2988eb19e8b8f67c1cb9aa.html
Most books that purport to be about testing are really about something else. They're
generally about planning, or process, or mathematics, or graph theory. Often, they're
about making models of software so that you can demonstrate that there are indeed
jillions of paths through a given piece of software--hardly news to anyone who's
bothered to think about it for a while. Sometimes they're about the underlying theory
of the thing you're supposed to be testing, such as "Web applications" or "security".
All of these are useful things to think about, to be sure. Many of these books are large,
and this one is small. I would venture to say, though, that few books talk about actual
bugs as much as this one does, and provide such entertaining, cringeworthy examples.
This book is about testing, and it's about thinking about testing. It provides a set of
theories of error, and follows these with worked-out examples of using those theories
of error to find bugs in real software.
If there is an area of software development that needs to be codified and formalized, it
is the procedures for testing the software before release. With the exception of software
that does only a few tasks, it is not possible to test all possible paths. The number of
possible paths expands very quickly so that it is effectively infinite, which means that it
is so large that it might as well be infinite. Furthermore, this problem will only get worse
as software continues to increase in complexity. Finally, the testing phase of software is
relegated to the last step and is often considered to be a menial task by developers.
Given these conditions and the general pressure of meeting a release date, it follows that
testing is often cut short.
With all of this as a background, it would appear that testing is a hopeless task. That is
not the case if the testing is done in a systematic manner, which is what this book will
teach you. Whittaker is a computer science professor whose area of expertise is that of
testing software. He breaks the process into two broad categories: user interface attacks
and system interface attacks. Each of these areas is then split into separate attacks,
seventeen for user interface attacks and six for system interface attacks.
The attacks for user interface are:
* Apply inputs that force all the error messages to occur.
* Apply inputs that force the software to establish default values.
* Explore allowable character sets and data types.
* Overflow input buffers.
* Find inputs that may interact and test combinations of their values.
* Repeat the same input or series of inputs numerous times.
* Force different outputs to be generated for each input.
* Force invalid outputs to be generated.
* Force properties of an output to change.
* Force the screen to refresh.
* Apply inputs using a variety of initial conditions.
* Force a data structure to store too many or too few values.
* Investigate alternate ways to modify internal data constraints.
* Experiment with invalid operand and operator combinations.
* Force a function to call itself recursively.
* Force computation results to be too large or too small.
* Find features that share data or interact poorly.
The attacks for system interface are:
* Fill the file system to capacity.
* Force the media to be busy or unavailable.
* Damage the media.
* Assign an invalid file name.
* Vary file access permissions.
* Vary or corrupt file contents.
Each of the attacks is presented using the subsections:
* When to apply this attack.
* What software faults make this attack successful?
* How to determine if this attack exposes failures.
* How to conduct this attack.
This approach leads to a very thorough demonstration of how to perform rigorous
software testing in a limited amount of time. If I ever teach a course in software
testing, this is what I will use as a text.
The book contains two software testing tools, one of which is particularly useful.
While it is running, you can move a slider to have it bind memory resources and
learn the point of memory use where your software performance begins to suffer.
This is very useful, and is much easier than trying to load up many other applications.
Software testing is a critical area of development that is still in the process of being
codified into patterns for reuse. This book demonstrates many of the currently available
strategies which can be used as reference.
AUTHOR:James A. Whittaker
Here's a paper to get a tiny taste of this book:
http://wenku.baidu.com/view/2b2988eb19e8b8f67c1cb9aa.html
Most books that purport to be about testing are really about something else. They're
generally about planning, or process, or mathematics, or graph theory. Often, they're
about making models of software so that you can demonstrate that there are indeed
jillions of paths through a given piece of software--hardly news to anyone who's
bothered to think about it for a while. Sometimes they're about the underlying theory
of the thing you're supposed to be testing, such as "Web applications" or "security".
All of these are useful things to think about, to be sure. Many of these books are large,
and this one is small. I would venture to say, though, that few books talk about actual
bugs as much as this one does, and provide such entertaining, cringeworthy examples.
This book is about testing, and it's about thinking about testing. It provides a set of
theories of error, and follows these with worked-out examples of using those theories
of error to find bugs in real software.
If there is an area of software development that needs to be codified and formalized, it
is the procedures for testing the software before release. With the exception of software
that does only a few tasks, it is not possible to test all possible paths. The number of
possible paths expands very quickly so that it is effectively infinite, which means that it
is so large that it might as well be infinite. Furthermore, this problem will only get worse
as software continues to increase in complexity. Finally, the testing phase of software is
relegated to the last step and is often considered to be a menial task by developers.
Given these conditions and the general pressure of meeting a release date, it follows that
testing is often cut short.
With all of this as a background, it would appear that testing is a hopeless task. That is
not the case if the testing is done in a systematic manner, which is what this book will
teach you. Whittaker is a computer science professor whose area of expertise is that of
testing software. He breaks the process into two broad categories: user interface attacks
and system interface attacks. Each of these areas is then split into separate attacks,
seventeen for user interface attacks and six for system interface attacks.
The attacks for user interface are:
* Apply inputs that force all the error messages to occur.
* Apply inputs that force the software to establish default values.
* Explore allowable character sets and data types.
* Overflow input buffers.
* Find inputs that may interact and test combinations of their values.
* Repeat the same input or series of inputs numerous times.
* Force different outputs to be generated for each input.
* Force invalid outputs to be generated.
* Force properties of an output to change.
* Force the screen to refresh.
* Apply inputs using a variety of initial conditions.
* Force a data structure to store too many or too few values.
* Investigate alternate ways to modify internal data constraints.
* Experiment with invalid operand and operator combinations.
* Force a function to call itself recursively.
* Force computation results to be too large or too small.
* Find features that share data or interact poorly.
The attacks for system interface are:
* Fill the file system to capacity.
* Force the media to be busy or unavailable.
* Damage the media.
* Assign an invalid file name.
* Vary file access permissions.
* Vary or corrupt file contents.
Each of the attacks is presented using the subsections:
* When to apply this attack.
* What software faults make this attack successful?
* How to determine if this attack exposes failures.
* How to conduct this attack.
This approach leads to a very thorough demonstration of how to perform rigorous
software testing in a limited amount of time. If I ever teach a course in software
testing, this is what I will use as a text.
The book contains two software testing tools, one of which is particularly useful.
While it is running, you can move a slider to have it bind memory resources and
learn the point of memory use where your software performance begins to suffer.
This is very useful, and is much easier than trying to load up many other applications.
Software testing is a critical area of development that is still in the process of being
codified into patterns for reuse. This book demonstrates many of the currently available
strategies which can be used as reference.
相关文章推荐
- How to write software Testing Weekly Status Report
- Exploiting Software: How to Break Code
- How to use iPhone with File I/O Functions: A Tutorial for Software Developers
- How to use iPhone with File I/O Functions: A Tutorial for Software Developers
- [tfs] How to add report builder into report site
- Software-Building-HOWTO_1
- How to download OES Client Software
- 如何学习软件测试?How to study software testing?
- 如何学习软件测试?How to study software testing?
- How To Reconcile Accrual Reconciliation Report And GL [ID 414169.1]
- how to become a software architect
- How to Apply Conditional Style on Jasper Main Report Variable
- Software Engineering vs. CS, how to teach SE?(团队阅读作业)
- How to display a line break with outputText?
- How to Write a Weekly Report
- How to install VXDIAG Honda, Toyota and JLR SDD software
- How to get FlowLayoutPanel.AutoSize to work with FlowBreak
- gdb faq: how to set/cancel a break
- How To Uninstall Software Using The Ubuntu Command Line
- How to Become a Software Engineer