读书笔记-Software Testing(By Ron Patton)
Software Testing
- Part I:The Big Picture
- 1.Software Testing Background
Bug's formal definition
1.The software doesn't do something that the product specification says it should do.
2.The software does something that the product specification says it shouldn't do.
3.The software does something that the product specification doesn't mention.
4.The software doesn't do something that the product specification doesn't mention but should.
5.The software is difficult to understand,hard to use,slow,
or in the software tester's eyes will be viewed by the end user as just plain not right.
The sources of Bugs
- 1.Spesification
- The spec isn't written
- The spec isn't thorough enough
- The spec is constantly changing
- Not communicated well to the entire development team
- 2.Design
- It's rushed
- It's changed
- Not well communicated
- 3.Code
- The Software's complexity
- Poor documentation
- Schedule pressure
- Plain dumb mistakes
- 4.Other
- False positives
- Duplicate bugs
- Testing errors
- etc.
The costs increase tenfold as time increases
The goal of a software tester is to find bugs,
find them as early as possible,
and make sure they get fixed
- 2.Software Development Process
- Hidden efforts
Customer Requirements
Specification
Schedules,such as the Gantt chart
Software Design Documents,
to plan and organize the code that is to be written
Test Documents
- Test plan
- Test cases
- Bug reports
- Test tools and automation
- Metrics,statistics,summaries
- Lifecycle models
- Big-Bang
- The only virtue is simple
- Code-and-Fix
- A good introduction to software development
- Waterfall
- Three important things
- 1.There's a large emphasis on specifying what the product will be
- 2.The steps are discrete;there's no overlap
- 3.There's no way to back up.
- Disadvantage:Testing occurs only at the end
- Three important things
- Spiral
- Steps
- 1.Determine objectives,alternatives and constraints
- 2.Identify and resolve risks
- 3.Evaluate alternatives
- 4.Develop and test the current level
- 5.Plan the next level
- 6.Decide on the approach for the next level
- Virtue:the lower costs and finding problens earlier
- Steps
- Big-Bang
- Hidden efforts
- 3.The Realities of Software Testing
- Testing Axioms
- It's impossible to test a program completely
- Software testing is a risk-based exercise
- Testing can't show that bugs don't exist
- The more bugs you find,the more bugs there are
- The pesticide paradox
- The more you test software,the more immune it becomes to your tests
- Not all the bugs you find will be fixed
- There's not enough time
- It's really not a bug
- It's too risky to fix
- It's just not worth it
- When a bug's a bug is difficult to say
- Product specifications are never final
- Software tester aren't the most popular members of a project team
- Find bugs early
- Temper your enthusiasm
- Don't just report bad news
- Software testing is a disciplined technical profession
- Testing Axioms
- 1.Software Testing Background
- Part II:Testing Fundamentals
- 4.Examining the specification
- High-Level Review
Pretend to be the customer
- Don't forget about software security
Research existing standards and guidelines
- Corporate Terminology and Conventions
- Industry Requirements
- Government Standards
- Graphical User Interface(GUI)
- Security Standards
Review and test similar software:
Scale,Complexity,Testability,Quality/Reliability,Security
- Low-Level Review
Attributes checklist(Flush out oversights and omissions):
Complete,Accurate,Precise and clear,Consistent,Relevant,Feasible,Code-free,Testable
Terminology checklist:
Help assure that all the details are defined
- Always,every,all,none,never
- Certainly,therefore,clearly,obviously,evidently
- Some,sometimes,often,usually,ordinarily,customarily,most,mostly
- Etc.,and so forth,and so on,such as
- Good,fast,cheap,efficient,small,stable
- Handled,processed,rejected,skipped,eliminated
- If...then..(but missing else)
- High-Level Review
- 5.Black-Box Testing
- Dynamic Black-Box Testing
- Testing without knowing exactly how it works with
- Entering inputs,receiving outputs and checking the results according to the specification
- Test-to-Pass and Test-to-Fail
- Equivalence Partitioning
- Similar inputs,similar outputs and similar operation
- Data Testing
Buffer overruns are the number one cause of software security issues,it's caused by boundary condition bugs
Sub-boundary conditions:Powers-of-Two
Null:default,empty,blank,null,zero,and none
Bad data:invalid,wrong,incorrect,and garbage data
- State Testing
The one side of software:the data-the numbers,words,inputs,outputs
The other side:to verify the program's logic flow through it's various states.
Test-to-pass:State transition map
- The following items:
- Each unique state that the software can be in
- The input or condition that takes it from one state to the next
- Set condition and produced output when a state is entered or exited
- Reducing the number of state and transitions to test
- Visit each state at least once
- Test the state-to-state transitions that look like the most common or popular
- Test the least common paths betwee states
- Test all the error states and returning from the error states
- Test random state transitions
Test-to-fail:Testing states to fail
- Race conditions and bad timing
- Repetition testing
- The main reason is to look for memory leaks
- Stress testing
- Look at the software and determine what external resources and dependencies it has
- Load testing
- Don't forget about time as a load testing variable
- Other Black-Bos test techniques
- Behave like a dumb user
- Look for bugs where you've already found them
- think like a hacker
- follow experience,intuition,and hunches
- The following items:
- Dynamic Black-Box Testing
- 6.Examining the Code:white-box testing
reason
Obvious reason:to find bugs early
Other reason:gives the team's black-box testers ideas for test cases to apply when they receive the software for testing
Formal review(structural analysis):
Static white-box testing
- Essential elements
- Identify problems
- Follow rules
- Prepare
- Write a report
- Indirect results:communications,quality,team camaraderie,solutions
- The method
- Peer reviews:the easiest way
- Walkthroughs:having at least one senior programmer as a reviewer
- Inspections:the presenter or reader isn't the original programmer
- Check the coding standards and guidelines
- Generic code review checklist
Data reference errors:the primary cause of buffer overrun
Caused by using a vareable,constant,array,string,or record that hasn't been properly declared or initialized for how it's bing used and referenced
Data declaration errors:
Caused by improperly declaring or using variables or constants.
Computation errors:math
Comparison errors:Suseptible to boundary condition problems
Control flow errors:The result of loops and other control constructs in the language not behaving as expected
Subroutine parameter errors:incorrent passing of data
Other:languages,Protable,Compatibility,'warning' or 'informational' messages
7.Dynamic white-box testing(structural testing):
Seeing what the code does,directly testing and controlling the software
- Unit testing
Bottom-up----test driver
Top-down----test stub
Data coverage:
Data flow,Sub-boundaries,Formulas and Equations,Error forcing
Code coverage:
Statement coverage,Path testing(branch coverage),Condition coverage
- Iintegration testing
- 4.Examining the specification
- Part III:Applying Your Testing Skills
8.Configuration Testing
The different configuration possibilities:
The PC,Components,Peripherals,Interfaces,Options and memory,Device drivers
Decision-making process
- 1.Decide the types of hardware you'll need
- 2.Decide whar hardware Brands,models,and device drivers are available
- 3.Decide which hardware features,modes,and options are possible
- 4.Pare down the identified hardware configurations to a manageable set
- 5.Identify your software's unique features that work with the hardware configurations
- 6.Design the test cases to run on each configuration
- 7.Execute the testing and rerun until the results satisfy your team
9.Compatibility Testing
The job:checking that your software interacts with and shares information correctly with other software
The goal:to make sure that this interaction works as users would expect
1.Platform and application versions
Backward and forward compatibility
The inpact of testing multiple versions:
Popularity,Age,Type,Manufacturer
2.Standards and guidelines
- High-level:Guide your product's general operation
- Low-level:The nitty-gritty details
3.Data sharing compatibility
- File save and file load
- File export and file import
- Cut,copy,and paste
- DDE,COM,and OLE
10.Localization Testing/Internationalization Testing
(Foreign-Language Testing)Translation Issues
Text expansion
- A good rule:to expect up to 100 percent increase in size of individual words on a button
ASCII,DBCS,and Unicode
Hot keys and shortcuts
Extended characters
- to look for all the places that your software can accept character input or send output
Computations on characters
- word sorting
- uppercase and lowercase conversion
- Spellchecking ,etc.
Reading left to right and right to left
Text in graphics
Keep the text out of the code:
all text strings, error messages, and really anything that could possibly be translated should be stored in a separate file independent of the source code
Localization Issues(native culture):
Content,Data formats(formats for data units)
Configuration and Compatibility Issues
- Foreign platform configurations
- Keyboards:the largest language dependencies piece of hardware
- Print,Paper sizes
- Communication protocol
- Data compatibility
11.Usability Testing:
The appropriate, functional, and effective of interaction
GUI testing:
Graphical user interfaces
Important trait:Follows standards and guidelines,Intuitive,Consistent,Flexible,Comfortable,Correct,Useful
Accessibility Testing:
For the disabled
12.Testing the Documentation
Packaging text and graphics
Marketing material,ads,and other inserts
Warranty/registration
EULA:End User License Agreement
Labels and stickers:
the box,printed material,serial number stickers and labels that seal the EULA envelopeInstallation and setup instructions,User's manual,Online help
Tutorials,wizards,and CBT(Computer based training)
Samples,examples,and templates
Error messages
13.Testing for Software Security
It is a test-to-fail activity
Buffer Overrun
- Buffer overruns caused by improper handling of strings are by far the most common coding error
- Using safe string functions
Latent data:
Data that "stays around" and isn't deleted from user to user
- RAM slack
- Disk slack
14.Website Testing
Black-Box Testing
Text:the regular text and text what's contained in the graphics, scrolling marquees, forms, and so on
Don't forget the text layout issues
Hyperlinks:Look for orphan pages
Graphics:make sure that the text wraps properly around the graphics
Forms:the text boxes, list boxes, and other fields for entering or selecting information
Objects and other simple miscellaneous functionality
Gray-Box Testing:
HTML and web pages
White-Box Testing
Dynamic content:
such as the time
Database-Driven web pages:
Such as the inventories of e-commerce web pages
Programmatically created web pages
Server performance and loading
Security
Configuration and Compatibility Testing
- Hardware platform,browser software and version
- Browser plug-ins,Options
- Video resolution and color depth
- Text size
- Modem speeds
Usability Testing
- Gratuitous Use of Bleeding-Edge Technology
- Scrolling Text, Marquees, and Constantly Running Animations
- Long Scrolling Pages
- Non-Standard Link Colors
- Outdated Information
- Overly Long Download Times
- Lack of Navigation Support
- Orphan Pages
- Complex Website Addresses (URLs)
- Using Frames
- Part IV:Supplementing Your Testing
- 15.Automated Testing and Test Tools
The Benefits
Speed,Efficiency,Accuracy and precision,
Resource reduction,Simulation and emulation,Relentlessness
Test Tools:
Non-invasive and invasive
- Viewers and monitors
- Drivers and stubs
- Stress and load tools
- Interference Injectors and Noise Generators
- Analysis Tools
Test Automation
Macro Recording and Playback
The biggest problem is lack of verification
Playback speed can be another difficulty with macros
Setting the playback position to be relative to the program's window
rather than absolute to the screen can help
Programmed Macros
Can pause their execution to prompt the tester with an expected result
and a query for her to okay whether the test passed or failedCan also solve many timing problems of recorded macros by
waiting for certain conditions to occur before they go onDefect:lack of verification,can only loop and repeat
Fully Programmable Automated Testing Tools:
Have the ability to perform verification
Important issuse
The software changes
There's no substitute for the human eye and intuition
Verification is hard to do
It's easy to rely on automation too much
Don't spend so much time working on tools and
automation that you fail to test the software
Some tools are invasive and can cause
the software being tested to improperly fail
- 16.Bug Bashes and Beta Testing:omit
- 15.Automated Testing and Test Tools
- Part V:Working with Test Documentation
17.Test Plan
- The Goal
To prescribe the scope, approach, resources, and schedule of the testing activities.
To identify the items being tested, the features to be tested, the testing tasks to be performed,
the personnel responsible for each task, and the risks associated with the plan
- The Topics
High-Level expectations,People-Places-and Things,Definitions,
Inter-groug responsibilities,What will and won't be tested,Test phases,
Test strategy,Resource requirements,Tester assignments,Test schedule,
Test cases,Bug reporting,Metrics and statistics,Risks and issues
18.Test Cases:
organization, repeatability, tracking, and proof
Test Design:
Identifiers,Features to be tested,Approach,Test case identification,Pass/fail criteria
Test Cases:
Identifiers,Test item,Input specification,Output specification,Environmental needs,Special procedural requirements,Intercase dependencies
Test Procedures:
Identifier,Purpose,Special requirements,Procedure steps
Test Case Organization and Tracking
19.Test Report
- The Reasons for not fixing a bug
- There's not enough time
- It's really not a bug
- It's too risky to fix
- It's just not worth it
- Ineffective bug reporting
- Fundamental Principles
Report bugs as soon as possible
Effectively describe the bugs:
Minimal,Singular,Obvious and general,Reproducible
Be non-judgmental in reporting bugs
Follow up on your bug reports
- Bugs
Severily
- 1.System crash, data loss, data corruption, security breach
- 2.Operational error, wrong result, loss of functionality
- 3.Minor problem, misspelling, UI layout, rare occurrence
- 4.Suggestion
Priority
- 1.Immediate fix, blocks further testing, very visible
- 2.Must fix before the product is released
- 3.Should fix when time permits
- 4.Would like to fix but the product can be released as is
Life cycle:
New,Open,Review,Fixed,Closed,Rejected,Reopen,Deferred
20.Measuring Your Success:omit
- The Goal
读书笔记-Software Testing(By Ron Patton)的更多相关文章
- 读书笔记-实用单元测试(英文版) Pragmatic Unit Testing in C# with NUnit
读书笔记-实用单元测试(英文版) Pragmatic Unit Testing in C# with NUnit Author: Andrew Hunt ,David Thomas with Matt ...
- 【读书笔记】《Computer Organization and Design: The Hardware/Software Interface》(1)
笔记前言: <Computer Organization and Design: The Hardware/Software Interface>,中文译名,<计算机组成与设计:硬件 ...
- 《Small Memory Software:Patterns For System With Limited Memory》读书笔记
原文地址:http://blog.csdn.net/jinzhuojun/article/details/13297447 虽然摩尔定律让我们的计算机硬件得以以指数速度升级,但反摩尔定律又不断消减这些 ...
- The Pragmatic Programmer 读书笔记之中的一个 DRY-Don’t Repeat Youself
The Pragmatic Programmer读书笔记之中的一个 DRY-Don't Repeat Youself 尽管自己买了非常多软件project方面的书,可是由于时间的问题.一直没有静 ...
- think in java 读书笔记 2 —— 套接字
目录 think in java 读书笔记 1 ——移位 think in java 读书笔记 2 —— 套接字 think in java 读书笔记 3 —— 数据报 概要 1. 套接字基本知识 2 ...
- Exploratory Software Testing
最近找到去年上半年看过一本关于测试方面书籍的总结笔记,一直放在我的个人U盘里,当时是用Xmind记录的,现在重新整理下分享给大家了! James A.Whittaker [美] 詹姆斯·惠特克(软件测 ...
- 《Linux/Unix系统编程手册》读书笔记7 (/proc文件的简介和运用)
<Linux/Unix系统编程手册>读书笔记 目录 第11章 这章主要讲了关于Linux和UNIX的系统资源的限制. 关于限制都存在一个最小值,这些最小值为<limits.h> ...
- C语言深度解剖读书笔记(6.函数的核心)
对于本节的函数内容其实就没什么难点了,但是对于函数这节又涉及到了顺序点的问题,我觉得可以还是忽略吧. 本节知识点: 1.函数中的顺序点:f(k,k++); 这样的问题大多跟编译器有关,不要去刻意追求 ...
- 读书笔记:《梦断代码Dreaming in Code》
读书笔记:<梦断代码Dreaming in Code> 拿到<梦断代码>书后,一口气翻了一遍,然后又用了3天时间仔细读了一遍,也不禁掩卷长叹一声,做软件难.虽难,仍要继续走下去 ...
随机推荐
- Linux C 程序的开发环境
1.开发环境的构成 编辑器 vim,vi 编译器 gcc 调试器 gdb 函数库glibc 系统头文件glibc_header 2.gcc编译器 功能强大.性能优越的多平台编译器,gcc可以将c.c+ ...
- IO回忆录之怎样过目不忘(BIO/NIO/AIO/Netty)
有热心的网友加我微信,时不时问我一些技术的或者学习技术的问题.有时候我回微信的时候都是半夜了.但是我很乐意解答他们的问题.因为这些年轻人都是很有上进心的,所以在我心里他们就是很优秀的,我愿意多和努力的 ...
- 省市联动_简单的Demo,适用于各种二级菜单联动
最近搞了一个功能,是查询页面需要用到二级菜单联动,获取到选中的属性value传入到后台. 平常都是用AJAX或者JQuery ,通过XML或者JSON的方式,这样的话需要调用数据库,像典型得到省市联动 ...
- MySQL 主从复制与读写分离概念及架构分析 (转)
1.MySQL主从复制入门 首先,我们看一个图: 影响MySQL-A数据库的操作,在数据库执行后,都会写入本地的日志系统A中. 假设,实时的将变化了的日志系统中的数据库事件操作,在MYSQL-A的33 ...
- (基础篇 走进javaNIO)第一章-java的i/o演进之路
Java 是由 SUN公司在 1995 年首先发布 的编程语 言和计算平 台.这基础技术 支持最新 的程序 ,包括 实用程序 .游 戏和业 务应用程序 .J ava 在世界各地 的 8.5 亿 多 ...
- 开涛spring3(3.2) - DI之循环依赖
3.2.1 什么是循环依赖 循环依赖就是循环引用,就是两个或多个Bean相互之间的持有对方,比如CircleA引用CircleB,CircleB引用 CircleC,CircleC引用CircleA ...
- 浅析Web缓存
在前端开发中,性能一直都是被大家所重视的一点,然而判断一个网站的性能最直观的就是看网页打开的速度.其中提高网页反应速度的一个方式就是使用缓存.一个优秀的缓存策略可以缩短网页请求资源的距离,减少延迟,并 ...
- RFM模型——构建数据库营销的商业战役!(转)
RFM模型:R(Recency)表示客户最近一次购买的时间有多远,F(Frequency)表示客户在最近一段时间内购买的次数,M (Monetary)表示客户在最近一段时间内购买的金额.一般原始数据为 ...
- (原创)Maven+Spring+CXF+Tomcat7 简单例子实现webservice
这个例子需要建三个Maven项目,其中一个为父项目,另外两个为子项目 首先,建立父项目testParent,选择quickstart: 输入项目名称和模块名称,然后创建: 然后建立子项目testInt ...
- webApi签名验证
还是一如既往先上结构图如下: 上一讲说明了redis,也谢谢心态的建议.这里经过改进后的redis的地址 当然这里是加密了的,具体实现如下图: 这里提供的解密. 先把加密解密的帮助类放上来. usin ...