第16章缺陷轰炸和beta测试

1.       让别人测试你的软件

A让其他人检查软件有助于打破杀虫剂的怪现象

B人们互相之间不仅看到的不同,而且测试方法也不同

C让别人帮忙测试有助于消除烦躁心情

D观察别人解决问题的方式是学习新测试技术的上佳方法.

2.       测试共享

缺陷轰炸(bug bash):缺陷轰炸是在一段时间(一般为几个小时)内整个测试小组停下来指定的常规测试任务,参加轰炸.在缺陷轰炸中,选择软件中某一个区域,所有测试员集中测试这个区域或者这组特性.选择区域可能是软件缺陷聚集之处,看是否还有更多潜伏的问题,也可能是怀疑不存在软件缺陷的区域.

第五部分使用测试文档

第17章计划测试工作        

1.       计划测试的目标

规定测试活动的范围,方法,资源和进度,明确正在测试的项目,要测试的特性,要执行的测试任务,每个任务的负责人,以及与计划相关的风险.

1)      高级期望

A测试计划过程和软件测试计划的目的是什么?

B测试的是什么产品?

C产品的质量和可靠性目标是什么?

2)      人,地点和事

测试计划需要明确在项目中工作的人,他干什么,怎样和他联系.以及文档存放在哪里,执行测试的硬件的安排等.

3)      定义:定义小组成员的用语和术语,对差异进行辨别,并得到一致的同意,使全体人员说法一致.

常用术语和松散的定义

A构造:程序员放在一起需要测试的代码和内容的搜集.测试计划应该定义构造的频率和期望的质量等级.

B测试发布文档(TRD):程序员发布的文档,对每一个构造都声明的新特性,不同特性,修复问题和准备测试的内容.

C说明书完成:说明书预计完成并且不再更改的日程安排.

D特性完成:程序员不再向代码增加新的特性,并集中修复缺陷的日期安排.

E软件缺陷会议:由测试经理,项目经理,开发经理和产品支持经理组成的团队,每周召开的会议审查软件缺陷,并确定哪些需要修复,应该如何修复.

4)      团队之间的责任

团队之间的责任是明确指出可能影响测试工作的任务和交付内容.

5)      哪些要测试,哪些不要测试

6)      测试阶段

要计划测试阶段,测试小组就会查看预定的开发模式,并决定项目期间是采用一个测试阶段还是分阶段测试.

7)      测试策略

测试策略描述测试小组用于测试整体和每个阶段的方法.

8)      资源需求

A人员

B设备

C办公室和实验室空间

D外包测试公司

E其他配备

9)      测试员的任务分配

明确测试员负责软件的哪些部分,哪些测试特性.

10)   测试进度

进度破坏(schedule crunch)

是测试任务摆脱进度破坏的一个方法是测试进度避免定死启动和停止任务的日期,应该根据测试阶段定义的进入和退出规则采用相对的日期.

进入和退出规则:从一个测试阶段转移到另一个测试阶段的要求必须满足,一个阶段满足退出规则才会结束,新的阶段满足进入规则才会开始.

11)   测试用例

12)   软件缺陷报告:用于记录和跟踪所发现的软件缺陷的技术

13)   度量和统计:跟踪项目发展,成效和测试的手段

14)   风险和问题:明确指出项目的潜在问题或者风险区域

第18章编写和跟踪测试用例

1.       测试用例计划的目标

计划测试用例的重要性

A组织.以便全体测试员和其他项目小组成员有效的审查和使用.

B重复性.

C跟踪

D测试(或者不测试)证实

特别测试(ad hot testing),没有实际计划执行测试,没有测试用例计划,甚至没有高级测试计划,只是测试员坐在软件前面开始乱敲键盘.

2.测试用例计划综述

1)      测试设计

A标识符:用于引用和标记测试设计说明的唯一标识符.

B要测试的特性.包含软件特性的描述,还要明确指出作为主要特性的辅助特性需要间接测试的特性和不被测试的特性.

C方法.描述测试软件特性的通用方法.

D测试用例确认.用于检查特性的具体测试用例的高级描述和引用.它应该列出所选的等价划分,并提供测试用例的引用信息以及用于执行测试用例的程序.

E通过/失败规则.描述测试特性的通过和失败由什么构成.

2)      测试用例:编写用于输入的实际数值和预期输出结果数值,测试用例还明确指出使用具体测试用例产生的测试程序的任何限制.

A标识符.由测试过程和测试程序说明引用的唯一标识符.

B测试项.描述被测试的详细特性,代码模块等.

C输入说明.列举送到软件执行测试用例的所有输入内容或者条件.

D输出说明.描述执行测试用例预期的结果.

E环境要求.执行测试用例的必要的硬件,软件,测试工具,实用工具,人员等.

F特殊过程要求.描述执行测试必须做到的特殊要求.

G用例之间的依赖性.说明测试用例之间的依赖关系.

3)      测试程序(test procedure):明确指出为实现相关测试设计而操作软件系统和试验具体测试用例的全部步骤.

A标识符:把测试程序与相关的测试用例和测试设计捆绑在一起的唯一标识符.

B目的:程序的目的以及将要执行测试用例的引用信息.

C特殊要求:执行程序所需要的其他程序,特殊测试技术或者特殊设备.

D程序步骤.执行测试的详细描述:

  日志

  设置

  启动

  程序

  度量

  关闭

  重启

  终止

  重置

  偶然事件

2.       测试用例的组织和跟踪

第13章软件安全性测试

1.       战争游戏-电影

驾驶攻击

2.       了解动机

1)      挑战/称名

2)      好奇

3)      使用/借用

4)      恶意破坏

5)      偷窃

3.       威胁模式分析(threat modeling)

威胁模型分析过程的步骤:

1)      构建威胁模型分析小组

2)      确认价值

3)      创建一个体系结构总体图:确认计划用在软件中的以及如何实现互连的技术.确认在不同技术和其证明之间的信任边界(trust boundaries),以及为了访问数据必须发生的授权.

4)      分析应用程序

5)      确认威胁:

6)      记录威胁

7)      威胁等级评定:恐怖公式(DREAD Formula):

A潜在的损害

B可反复性

C可利用性

D受影响的用户

E可发现性

4.       软件安全是一项功能吗?软件漏洞是一个缺陷吗?

测试安全缺陷是失效性测试行为,也常常覆盖产品中没有被完全理解和说明的部分.

5.       了解缓冲区益处

由于字符串的不正确的处理引起的缓冲区溢出是目前为止最为常见的一种代码编写错误,其结果是导致安全漏洞.

6.使用安全的字符串函数

开发或改进一组新的函数，即用强壮，完全测试过的，文档齐全的新函数替代这些容易引起问题的函数集。这些新的函数，叫做安全字符串函数（safe string functions）。使用新函数的好处：

1）  每个函数接收目标缓冲的长度作为输入，这样函数就能确保在写入时不会超过缓冲区的长度。

2）  函数空字符中止所有的输出字符串，即使操作截断了预计的结果。

3）  所有的函数返回一个NTSTATUS值，该值只有一个可能成功的代码。

4）  每个都提供版本。

7.计算机取证

用户变更时未被删除的保留数据叫做潜在数据（latent data）。

RAM损耗（RAM slack）

磁盘损耗（disk slack）

第14章网站测试

1.       网页基础

网页就是由文字，图片，声音，视频和超级链接组成的文档。

2.       黑盒测试

1）  文本

检查核实读者的水平，术语，内容以及题目素材，准确度－特别是可能过期的信息，经常不断的检查拼写。

文字标签（ALT text），用于替代文字（ALTernate text）。

2）  超级链接

3）  图片

如果图片丢失或者名称不对，就无法载入，网页将在位置图片的位置显示错误提示。

4）  表单

表单是指网页中用于输入的选择信息的文本框，列表框和其他域。

3.       灰盒测试（grey－box testing）：把软件当作黑盒来测试，但是通过简单查看软件内部的工作机制作为补充。

4.       白盒测试

1）  动态内容：根据当前条件发生变化的文字和图片.客户端(client-side),服务器端(server-side)

2）  数据库驱动网页:许多显示分类目录或者货物清单的电子商务网页是数据驱动的.

3）  用编程方法创建的网页:许多网页,特别是包含动态内容的网页是用编程的方法创建的,HTML甚至可能编程都是由软件创建的.

4）  服务器的性能和加载

5）  安全性

5.       配置和兼容测试

1)      硬件平台

2)      浏览器软件和版本:

3)      浏览器插件

4)      浏览器选项

5)      视频分辨率和色深

6)      文字大小

7)      调制解调器速率

6.       易用性测试

 Top Ten Mistakes in Web Design:

1)      盲目使用不成熟的新技术:

2)      滚动文字,滚动块和不停运行的动画:不要让网页有不停移动的元素.

3)      滚动显示长页面:用户通常不喜欢滚动查看屏幕上看不见的信息.所有重要的内容和导航选项应该位于页面的顶端.

4)      非标准的链接颜色:指向用户未曾看到过的页面的超级链接应该是蓝色的,指向已经看过的页面的链接应该是紫色或是是红色.

5)      过期信息:对网站维护

6)      下载时间过长:

7)      缺少导航支持

8)      孤页:所有网页一定要包含本身所属网站的明确指示,因为用户可能不经过主页而直接访问网页,同样的原因,每个网页应该与主页链接,以及它在信息空间结构的位置指示.

9)      复杂的网站地址(URL)

10)   使用框架:框架是允许在一个网页中显示其他网页的HTML技术.

第四部分测试的补充

第9章兼容性测试

1.软件兼容性综述

软件兼容性测试（software compatibility testing）是指检查软件之间是否能够正确的交互和共享信息。

2.平台和应用程序的版本

1）向后和向前兼容

向后兼容（backward compatible），可以使用软件以前的版本

向前兼容（forward compatible），可以使用软件以后的版本

2)测试多个版本的影响

3.标准和规范

1)高级标准和规范

Mirosoft Windows的认证徽标

2)低级标准和规范

通信协议,编程语言语法及程序用于共享信息的任何形式都必须符合公开的标准和规范.

4.数据共享兼容性

1)文件的保存和读取

2)文件的导出和文件的导入

3)剪切,复制和粘贴

4)DDE,COM,和OLE是windows中两个数据传输的方式,DDE表示动态数据交换,而OLE表示对象链接和嵌入.

第10章外国语言测试

1.       使文字和图片有意义

2.       翻译问题

1)      文本扩展问题(text expansion)

2)      ASCII,DBCS和Unicode

3)      热键和快捷键

4)      扩展字符(extended characters)

5)      字符计算

6)      从左向友和从友向左

7)      图形中的文字

8)      让文本与代码脱离

3.       本地化问题

1)      内容:范例文档,图标,图片,声音,视频,帮助文件,有 边界争端的地图,市场宣传资料,包装,web链接

2)      数据格式

4.       配置和兼容问题

1)      国外平台配置

2)      数据兼容性

5.       测试量有多大

本地化测试量的要求是一个有风险的抉择,与所有的测试一样,随着测试经验的增长,就会知道决定过程中有哪些变数.

第11章应用性测试

易用星测试(usability)是交互的适应性,功能性和有效性的集中表现.

1.       用户界面测试

用于与软件程序交互的方式称为用户界面或UI.

2.       优秀的UI由什么构成

优秀UI具备的7个要素:

.符合标准和规范

.直观

.一致

.灵活

.舒适

.正确

.实用

1)      符合标准和规范

最重要的用户界面要素是软件符合现行的标准和规范-或者是有真正站的住脚的不符合的理由.

2)      直观:考虑以下问题来衡量软件的直观程度

a.       用户界面是否洁净,不唐突,不拥挤?UI不应该为用户使用制造障碍.所需要的功能或者期待的响应因该明显,并在预期出现的地方.

b.       UI的组织和布局合理吗?是否允许用户轻松的从一个功能转到另一个功能?下一步做什么明显吗?任何时候都可以决定放弃或者退回,退出吗?输入得到确认吗?菜单或者窗口是否太深了?

c.       有多余功能吗?软件整体抑或局部是否做的太多?是否有太多特性把工作复杂化了?是否感到信息太庞杂?

d.       如果其他所有努力都失败了,帮助系统真能帮忙吗?

3)      一致

a.快捷键和菜单选项

b.术语和命名

c.听众

d.诸如OK和CANCEL按钮的位置

4）灵活：用户喜欢选择－不要太多，但是足以允许他们选择想要做的和怎样做。

a.状态跳转。灵活的软件在实现同一个任务上有更多的选择和方式。结果是增加了通向软件各种状态的途径。

b.状态终止和跳过。保证跳过所有的状态或提前终止变量被正确设置。

c.数据输入和输出。多种方法输入数据和查看结果。

5）舒适

a.恰当。外观和感觉应该与所做的工作和使用者相符。

b.错误处理。程序应当在用户执行关键操作之前提出警告，并且允许用户恢复由于错误操作而丢失的数据。

c.性能。

6）正确

需要注意的情况：

a.       市场定位的偏差。

b.       语言和拼写

c.       不良媒体

d.       WYSIWYG（所见即所得）－what you see is what you get

7）实用

软件业界描述不必要或者不合理特性的术语是“跳动的腊肠”（dancing bologna）

3.为有残疾障碍人员的测试：辅助选项测试（accessibility testing）

下列几种残疾对使用计算机和软件会造成极大的困难。

A视力损伤

B听力损伤

C运动损伤：疾病和受伤可以致使人的手或者手臂丧失部分或者全部运动能力。

D认知和语言障碍

软件中的辅助特性

软件有两种方式提供辅助，最容易的方式是利用平台或者操作系统内置的支持。软件只要遵守启用辅助选项与键盘，鼠标，声卡和显示器通信的平台标准就行了。如果测试软件不在这些平台上运行，就需要定义，编制和测试自己的辅助选项。

Windows提供了以下能力：

A粘滞键，允许shift，ctrl或者alt键持续生效，直至按下其它键

B筛选键，主要防止简短，重复（无意的）击键被认可

C切换键，在caps Lock，Scroll Lock或者NumLock键盘模式开启时播放声音

D声音卫士，每当系统发出声音时，给出可视警告

E声音显示，让程序显示其声音或者讲话的标题。

F高对比度，利用为便于视力损伤者阅读而设计的颜色和字体设置屏幕。

G鼠标键，允许用键盘来代替鼠标操作

H串行键，设置一个通信端口来读取来自外部非键盘设备的击键。

12章测试文档

1.软件文档的类型

A包装文字和图形。包括盒子，纸箱和包装纸

B市场宣传材料，广告及其它插页。

C授权/注册登记表。

D EULA，最终用户许可协议，这是要客户同意条款的法律文件。

E标签和不干胶条。

F安装和设置指导

G用户手册

H联机帮助

I指南，向导和CBT（计算机基础训练）这些工具将编程代码和书写文档融合在一起，它们一般是内容和类似宏的高级编程混合体，通常捆绑在联机帮助系统中，用户可以提出问题，然后由软件一步步引导完成任务。

J样例，示例和模板

K错误提示信息

2.文档测试的重要性

好的软件文档以下三种方式确保产品的整体质量:

1)      提高易用性

2)      提高可靠性

3)      降低支持费用

3.       审查文档时要找什么

文档测试检查清单

1)      通用部分

A听众

B术语

C内容和主题

2)      正确性

A紧扣事实

B逐步执行

3)      检查内容

A图标和屏幕的抓图

B样例和示例

C拼写和语法

4.       文档测试的实质

1)      文档常常是得不到足够的重视,预算和援助.

2)      编写文档的人可能对软件做什么不甚了解

3)      印刷文档制作需要花不少的时间,由于这个时间差,软件产品的文档需要在软件完成之前完稿-锁定.

第5章带上眼罩测试软件

1.动态黑盒测试:带上眼罩测试软件

没有产品说明书使用探索测试.

2.通过性测试和实效性测试

1)通过性测试(test-to-pass):确认软件至少能做什么,而不会考验其能力.

实效性测试(错误强制测试):破坏软件而设计和执行的测试用例

3.等价类划分(equivalence partitioning):分步骤把海量的无限的测试用例减得很小,但过程同样有效.

4.数据测试:检查用户输入的信息,返回的结果以及中间计算结果是否正确.

1)边界条件

a.边界条件的类型:软件运行在计划操作界限的边界的情况.

b.测试边界:提出边界条件时,一定要测试临近边界的有效数据,测试最后一个可能有效的数据,同时测试刚超过边界的无效数据.

2)次边界条件(Sub-boundary conditions或者内部边界条件internal boundary conditions):

a.2的幂

b.ASCII表

3)默认,空白,空值和无

4)非法,错误,不正确和垃圾数据

5.状态测试:测试程序的状态和转换

1)测试软件的逻辑流程

a.建立状态转换图

转换图表示的项目:

.软件可能进入的每一种独立状态

.从一种状态转入另一种状态所需要的输入和条件

.进入或者退出某种状态时设置的条件及输出的结果

b.减少要测试的状态及转换的数量

.每种状态至少访问一次

.测试看起来最常见和最普遍的状态转换

.测试状态之间最不常用的分支

.测试所有的错误状态及其返回值

.测试随机状态

2)失败状态的测试

a.竞争条件(race condition)和时序错乱

.两个不同的程序同时保存和打开同一个文档

.共享一台打印机,通信端口或者其它外围设备

.当软件处于读取或者改变状态时按键或者单击鼠标

.同时关闭或者启动软件的多个实例

.同时使用不同的程序访问一个共同的数据库

b.重复,压迫,和重负

重复测试(repetition testing)是不断执行同样的操作.

压迫测试(stress testing)是软件在不够理想的条件下运行-内存小,磁盘空间少,cpu速度慢,调制解调器速率低等.

重负测试(load testing)尽量提供条件任其发挥,

6.其他黑盒测试技术

1)象笨拙的用户那样做(inexperienced user) (new user)

2)在已经找到的软件缺陷的地方再找找

a.找到的软件缺陷越多,软件缺陷越多

b.许多程序员倾向于只修复报告出来的软件缺陷

3)象黑客一样考虑问题

4)凭借经验,只觉和预感

第6章检查代码

1.静态白盒测试:检查设计盒代码

静态白盒测试是在不执行软件的条件下有条理的仔细审查软件设计,体系结构和代码,从而找到软件缺陷的过程,有时称为结构化分析.

2.正式审查(formal review)

正式审查有四个要素:

a.       确定问题

b.       遵守规则

c.       准备

d.       编写报告

1)      同事审查:召集小组进行初次正式审查最简单的方法是通过同事审查.

2)      走查(Walktrough).走查中编写代码的程序员向5人小组或者其他程序员和测试员组成的小组正式陈述.审查人员应该在审查之前接到软件拷贝,以便检查并编写备注和问题,在审查过程中提问.审查人员至少有一位资深程序员.

3)      检验(inspections):是最正式的审查类型,表述代码的人-表述者(presenter)或者宣读者(reader)-不是原来的程序员.其余的参与者称为检验员(inspector),其职责从不同的角度审查代码.有些检验员还同时被委任为会议协调员(moderator)和会议记录员(recorder).

3.编码标准和规范

4.通用代码的审查清单

1)数据引用错误:使用未经正确声明和初始化的变量,常量,数组,字符串或记录而导致的软件缺陷.

2)数据声明错误:不正确的声明或使用变量和常量.

3)计算错误:

4)比较错误:

5)控制流程错误

6)子程序参数错误

7)输入/输出错误

第7章带上x光眼镜测试软件

1.动态白盒测试也称结构化测试(structural testing)

动态白盒测试包括四个部分:

a.       直接测试底层次函数,过程,子程序和库

b.       以完整的程序方式从顶层测试软件,但是根据对软件运行的了解调整测试用例.

c.       以软件获得读取变量和信息的访问权,以确定测试与预期结果是否相符,同时,强制软件以正常测试难以实现的方式运行.

d.       估算执行测试时”命中”代码量和具体代码,然后调整测试,去掉多余的测试用例,补充遗漏的用例.

2.动态白盒测试盒调试

3.分段测试

1)单元测试和集成测试

在底层进行的测试称为单元测试(unit testing),或者模块测试(module testing),单元经过测试,底层软件缺陷被找出并修复之后,就集成在一起,对模块的组合进行集成测试(integration testing).这个不断增加的测试过程继续进行,加入越来越多的软件片段,直至整个产品-至少是产品的主要部分-在称为系统测试(system testing)的过程中一起测试.

2)单元测试示例

4.数据覆盖

1)数据流(Data Flow)覆盖主要是指在软件中完全跟踪一批数据.

2)次边界

3)公式和等式

4)错误强制(error forcing)

5.代码覆盖(code coverage):通过完全访问代码以查看运行测试用例经过了哪些部分.

1)程序语句和代码行覆盖(statement coverage/line coverage)

2)分支覆盖

3)条件覆盖

6.小结

静态黑盒测试:检查产品说明书,并在软件编写之前找出问题.

动态黑盒测试:不了解软件如何工作的前提下进行测试

静态白盒测试:通过正式审查盒检验检查代码的细节

动态白盒测试:看到软件工作方式时,根据获得的信息对软件进行测试

测试桩和测试驱动

测试桩:自顶向下的测试,它用自己替换低级模块.其对于要测试的高级代码,外表和行为就象低级模块一样.

测试驱动和测试桩相反,用于自底向上的测试,它是代替高级软件,更有效的运行低级模块的测试代码.

第三部分运用测试技术

第8章配置测试

1.配置测试综述(configuration testing)是指使用各种硬件来测试软件的运行过程.

1)分离配置缺陷

配置问题产生的原因:

a.       软件可能包含在多种配置中都会出现的缺陷

b.       软件可能包含只在某一个特殊配置中出现的缺陷

c.       硬件设备或者其设备驱动程序可能包含仅由软件揭示的缺陷.

d.       硬件设备或者其设备驱动程序可能包含一个借助许多其他软件才能看出来的缺陷-尽管它可能对测试的软件特别明显.

2)计算工作量

2.执行任务

a.确定所需的硬件类型

b.确定有哪些厂商的硬件,型号和驱动程序可用

c.确定有哪些厂商的硬件，型号和驱动程序可用

d.确定可能的硬件特性，模式和选项

e.将确定后的硬件配置缩减为可控制的范围

f.明确与硬件配置有关的软件唯一特性

g.设计在每一种配置中执行的测试用例

h.在每种配置中执行测试

i.反复测试直到小组对结果满意为止

3.获得硬件

1）只买可以或者经常使用的硬件

2）与硬件厂商联系，看他们是否能够租赁甚至赠送某些硬件

3）向全公司的人发备忘或者电子邮件，问他们办公室甚至家里有什么硬件－以及能否允许

对其进行测试。

第一部分软件测试综述

Idiosyncrasy:不良反应

第一章:软件测试的背景

1.软件失败的术语

缺点(defect) 偏差(variance) 故障(default) 失败(failure) 问题(problem) 矛盾(inconsistency)

错误(error) 特殊(feature) 事件(incident) 缺陷(bug) 异常(anomaly)

2.Software Bug

1)软件未实现产品说明书要求的功能

2)软件出现了产品说明书指明不应该出现的错误

3)软件实现了产品说明书未提到的功能

4)软件未实现产品说明书虽未明确提及但应该实现的目标

5)软件难以理解,不易实用,运行缓慢或者从测试人员的角度看,最终用户会认为不好.

3.软件测试员的目标是尽可能早找出软件缺陷,并确保其得以修复.

3.软件测试人员具备的素质

1)探索者

2)故障排除员

3)不放过任何蛛丝马迹

4)具有创造性

5)追求完美者

6)判断准确

7)注重策略和外交

8)善于说服

第二章软件开发过程

1.可交付的部分(deliverable)用于描述和制造出并交付他人的软件产品组件

2.软件产品的组成部分

1)客户需求

2)产品说明书

3)进度表

4)软件设计文档

a.结构文档

b.数据流图

c.状态转换图

d.流程图

e.代码注释

4)测试文档

a.测试计划(test plan)

b.测试用例(test cases)

c.缺陷报告(but reports)

d测试工具和自动测试(test tools and automation)

e.度量,统计和总结(metrics,statistics,summaries)

3.软件项目成员

1)项目经理,程序经理或者监制人员:自始至终驱动整个项目.

2)体系架构师,系统工程师:产品小组的技术专家.

3)程序员,开发人员或代码制作者:设计,编写软件并修复软件中的缺陷.

4)测试员或者质量保证(Quality Assurance,QA):负责找出并报告软件产品的问题.

5)技术作者,用户协助专员,用户培训专员,手册编写人员,文案专员:编制软件产品附带的文件和联机文档.

6)配置管理员或构建员:把程序员编写的代码及技术作者写的全部文档资料组合在一起,和成为一个软件包.

4.软件生命周期模式

1)大爆炸模式:一大堆东西(人力和资金)放在一起,巨大的能量释放-通常很野蛮-产生了优秀的软件产品-或者一堆废品.

2)边写边改模式:

3)瀑布模式:构思,分析,设计,开发,测试,最终产品

a.瀑布模式非常强调产品的定义

b.瀑布模式各步骤是分立的,没有交叉

c.瀑布模式无法回溯.

5)螺旋模式

螺旋模式的循环包括六个步骤:

a.       确定目标,可选方案和限制条件

b.       明确并化解风险

c.       评估可选方案

d.       当前阶段的开发和测试

e.       计划下一个阶段

f.        确定进入下一个阶段的方法

第三章软件测试的实质

1.测试的原则

1)完全测试是不可能的

a.输入量太大

b.输出结果太多

c.软件执行路径太多

d.软件说明书是主观的

2)软件测试是有风险的行为

3)测试无法显示潜伏的软件缺陷

4)找到的软件缺陷越多,就说明软件缺陷越多

5)软件测试越多,其对测试的免疫力越强.软件测试员必须不断的编写不同的,新的测试程序,对程序的不同部分进行测试,以找出更多软件缺陷.

6)并非所有软件缺陷都要修复

a.没有足够的时间

b.不算真正的缺陷

c.修复的风险太大

d.不值得修复

2.软件测试的属于

1)精确(precision)和准确(accuracy)

2)确认(verification)和验证(validation)

确认是保证软件符合产品说明书的过程.

验证是保证软件满足用户要求的过程.

3)质量和可靠性

可靠性仅仅是质量的一个方面.

4)测试和质量保证

软件测试员的目标是尽可能早的找出软件缺陷,并确保缺陷得以修复.

软件质量保证人员的主要职责是创建并执行改进软件开发过程并防止软件缺陷发生的标准和方法.

第二部分测试基础

第四章检查产品说明书

1.静态测试(static testing)和动态测试(dynamic testing)

静态测试:测试不运行的部分-只是检查和审核

动态测试:使用和运行软件

2.测试产品说明书属于静态黑盒测试

3.对产品说明书进行高级审查

1)假设自己是客户

2)研究现有的标准和规范

a.公司的惯用语和约定

b.行业要求

c.政府标准

d.图形用户界面(GUI)

e.安全标准

3)审查和测试类似软件

4.产品说明书的低层次测试技术

1)产品说明书属性检查清单(8)

a.完整

b.准确

c.精确,不含糊,清晰

d.一致

e.贴切

f.合理

g.代码无关

e.可测试性

2)产品说明书术语检查清单

1)总是,每一种,所有,没有,从不:软件测试员要考虑违反的这种情况

2)当然,因此,明显,显然,必然:这些话意图说服你接受假定情况.

3)某些,有时,常常,通常,惯常,经常,大多,几乎:太过模糊

4)等等,诸如此类,依次类推,例如:以这样词语结束的功能清单无法测试

5)良好,迅速,廉价,高效,小,稳定:无法量化的术语无法测试

6)处理,进行,拒绝,跳过,排除:这些用语可能会隐藏大量需要说明的功能.

7)如果…..那么……(没有否则).

一．软件成熟度模型

1.       过程成熟度框架：建立有效的软件工程和管理实践过程基础设施。

1.1不成熟和成熟软件组织的比较

1.2构成过程成熟度基础的基本概念

软件过程：人们用以开发和维护软件及其相关产品的（例如，项目计划，设计文档，代码，测试用例，用户手册等等）的一组活动，方法，实践和变换。

软件过程能力：通过遵循软件过程能够实现预期结果的程度。

软件过程成熟度：一个特定过程被明确地定义，管理，测量，控制，并且有效的程度。成熟度意味着能力上的增长潜力，并且表明一个组织软件过程的丰富性和遍及组织的项目中运用它时的一致性。

1.3能力成熟度模型概述

2.软件过程成熟度的五个等级

1）初始级：软件过程的特点是无秩序的，偶尔甚至是混乱的。几乎没有什么过程是经过定义的，成功依赖于个人的努力。

2）可重复级：已建立基本的项目管理过程去追踪成本，进度和功能性，必要地过程纪律已经到位，使具有类似应用的项目，能重复以前的成功。

3）已定义级：管理活动和工程活动两方面的软件均已文档化，标准化，并集成到组织的标准软件过程。去不项目均采用供开发和维护软件用的组织标准软件过程的一个经批准的剪裁版本。

4）已管理级：已采集详细的有关软件过程和产品质量的度量。无论是软件过程还是产品均得到了定量了解和控制。

5）优化级：利用来自过程和来自新思想，新技术的先导性试验的定量反馈信息，使持续过程改进成为可能。

2.1成熟度等级的行为特征

2.1.1等级1－初始级

等级1组织的过程能力是不可预测的，因为随着工作进展软件过程经常被改变或修定。进度，预算，功能性和产品质量一般是不可预测的，性能依赖于个人能力，且随着个人固有的技能，知识和动机的不同而变化。

2.1.2等级2－可重复级

等级2组织的过程能力可概括为有纪律的，因为软件项目的规划和跟踪是稳定的，能重复以前的成功。由于遵循基于以前项目性能所制定的切实可行的计划，项目过程处在项目管理系统的有效控制之下。

2.1.3等级3－已定义级

等级3组织的软件过程能力可概括为标准的和一致的，因为无论软件工程活动还是管理活动，过程都是稳定的和可重复的。在所建立的产品线内，成本，进度和功能性均受控制，对软件质量也进行跟踪。这种过程能力建立在整个组织范围内对已定义过程中的活动，角色和职责的共同理解之上。

2.1.4等级4－已管理级

等级4组织的软件过程能力可概括为可预测的，因为过程是已测量的并在可测的范围内运行。该等级的过程能力使得组织能在定量限制的范围内预测过程和产品质量方面的趋势。当超过限制范围时，采取措施予以纠正。产品质量具有可预测的高质量。

2.1.5等级5－优化级

等级5组织的软件过程能力可特征化为不断改进，因为这些组织为扩大其过程能力的范围进行着不懈的努力，因而不断改善其项目的过程性能。既通过在现有过程中增量式前进的办法，也通过采用新技术，新方法的革新办法，使改进不断出现。

2.2理解成熟等级

2.2.1理解初始级

等级1组织的成功依赖于组织中人员的能力和杰出的努力。

2.2.2理解可重复级和已定义级

2.2.3理解已管理级和优化级

朱兰三部曲：（Juran Trilogy）：

质量策划的目的是向运作人员，即软件生产者提供生产能满足顾客需求的产品的方法。操作人员生产出产品，但由于质量缺陷不得不做某些返工。这种浪费是经常性的，执行质量控制是为了防止事情恶化。过程中的零星尖峰，代表消防活动，经常性的浪费提供了改进的机会，抓住这个机会进行工作就叫质量改进。

2.3软件过程的可视性

等级1的软件过程是一种无组织的整体－一个黑盒。

等级2，构造软件的过程可看作为一个接一个的黑盒子，随着活动在盒子间流动，在各过渡点上具有管理的可视性。

等级3，盒子的内部结构（即项目定义软件过程中的作业）是可视的。

等级4，已定义的软件过程被配备度量，并得到定量的控制。

等级5，为了提高生产率和质量，以受控的方式对构造软件的新的和已改进的方法进行不断的试验。

2.4过程能力和性能预测

2.5跨越成熟度等级

3.CMM的可操作定义

3.1成熟度等级的内部结构

每个成熟等级由几个关键过程区域组成，每个关键过程区域又按五个称为共同特点的部分加以组织。共同特点规定关键实践，当这些关键实践均得到实施时，就能实现关键过程区域的目标。

3.2成熟度等级

一个成熟度等级是一个妥善定义的，朝着实现成熟软件过程目标的进化途中的平台。

3.3关键过程区域

每个成熟度等级被分解成几个关键过程区域，指明为了改进软件过程组织应关注的区域。关键过程区域识别出为了达到基本个成熟度等级所必须着手解决的问题。

等级2关键过程区域：

1）  需求管理的目的是在顾客和软件项目之间建立对顾客需求的共同理解，顾客需求将由软件项目处理。

2）  软件项目策划的目的是制定进行软件工程和管理软件项目的合理的计划。

3）  软件项目的跟踪和监督的目的是建立适当的对实际进展的可视性，使管理者在软件项目性能显著偏离软件计划时能采取有效的措施。

4）  软件子合同管理的目的是选择合格的软件子承包商，并有效的管理它们。

5）  软件质量保证的目的是给管理者提供对于软件项目正采用的过程和正在构造的产品的恰当可视性。

6）  软件配置管理的目的是在项目的整个软件生存周期中建立和维护软件产品的完整性。

等级3的关键过程区域

1）  组织过程焦点的目的是规定组织在改进其整体软件过程能力的软件过程活动方面的职责。

2）  组织过程定义的目的是开发和保持一组便于使用的软件过程财富，它们能改进横跨项目的过程性能，并且为组织能获得积累性的，长期得益奠定基础。

3）  培训大纲的目的是培育个人的技能和知识，使得他们能有效地和效率高地执行其任务。

4）  集成软件管理的目的是将软件工程活动和管理活动集成为一个协调的，已定义的软件过程，该过程是剪裁组织的标准软件过程和组织过程定义中所描述的相关的过程财富而得到的。

5）  软件产品工程的目的是一致地招待一个妥善定义的工程过程，为了能有效地和效率高地生产正确的，一致的软件产品，该工程过程集成全部软件工程活动。

6）  组间协调的目的是为软件工程组织积极参与其它工程组工作制定的一种办法，使得项目更能有效地和效率高地满足顾客的需求。

7）  同行评审的目的是及早和高校的除去软件工作产品中的缺陷。法根式审查（fagan-style审查），结构化走查，或者一些其它的学院式的评审办法。

等级4的关键过程区域：

1）  定量过程管理的目的是定量的控制；软件项目的过程性能。

2）  软件质量管理的目的是建立对项目软件产品质量的定量了解和实现特定的质量目标。

等级5的关键过程区域：

1）  缺陷预防的目的是鉴别缺陷的原因并防止它们再次出现。

2）  技术改革管理的目的是识别出能获利的新技术（即工具，方法和过程），并以有序的方法将它引进到组织中去。

3）  过程更改管理的目的是出于改进软件质量，提高生产率和缩短产品开发周期的目的持续不断的改进组织中所采用的软件工程。

3.4共同特点

关键过程区域按共同特点加以组织。共同特点是表明一个关键过程区域的实施和规范化是否有效，可重复且持久的一些属性。

1）  执行约定：执行约定描述组织保证过程得以建立和持续起作用所必须采取的行动。一般包括制定组织的方针和规定高级管理者的支持。

2）  执行能力：执行能力描述为了能实施软件工程，项目或组织中必须存在的先决条件。一般包括资源，组织结构和培训。

3）  执行的活动：执行的活动描述为实现一个关键过程区域所必须的角色和规程。包括制定计划和规程，进行工作，跟踪它，并在需要时采取纠正措施。

4）  测量和分析：测量和分析描述对过程进行测量和对测量结果进行分析的需要。

5）  验证和实施：验证和实施描述那些能保证遵照已建立的过程进行活动的措施。

3.5关键实践

关键实践描述对关键过程区域的有效实施和规范化贡献最大的基础设施和活动。

4.运用CMM

软件过程评估：用于确定一个组织的当前软件过程的状态，确定组织所面临的具有高优先级的与软件过程有关的问题，和获得组织对软件过程改进的支持。

软件能力评价：用户识别合格的能完成软件工作的承包商或者监控现有软件工作中所运用的软件过程状态。

4.1软件过程评估和软件能力评价方法

软件过程评估和软件能力评价的共同步骤

群组的选择－从CMM中取样，成熟度提问单－响应分析－现场访问，会谈和文档的评审－基于CMM的调查发现－KPA（关键过程区域）剖面

4.2软件过程评估和软件能力评价之间的差异

1）评估和评价的范文可能变化

2）软件过程评估和软件能力评价在动机，目的，输出结果的所有权不同。

软件过程评估是在开放，合作的环境中的，评估的成功取决于管理者和专业人员两方面对改进组织的支持。评估目的是在于暴露问题和帮助经理和工程师改进他们的组织。

软件能力评价在更为面向审计的环境中进行。评价的目的于金钱密切相关，因为评价群组的推荐将帮助挑选承包商或设置奖金。

4.3CMM在过程改进方面的其它用法

Exploratory Testing in Pairs

1.什么是Paired Testing

1)一台机器两名测试人员

2)xp中的定义:两个人自愿的一起工作,其中的一个人也许一天中是好几个人的伙伴.

            一个人主要负责测试任务,寻找另一个人,也许是新手作为帮手.

2风险与建议

1)Paired testing不是初级测试员搪塞任务的方法,pairs是合作伙伴,通常都是初级人员在键盘旁边,允许后执行尝试自己的想法.

2)责任必须归属一个人.

3)有些人性格内向,他们需要时间和小组交流.

4)有些人很有主见,不能很好的同其他人合作,需要培训.

5)指导和培训是必需的.

Test Design :Test design is a multi-dimensional challenge

1.所有的测试都包含五个方面

  Testers:执行测试的人员

  Coverage:测试什么

  Potential problems:为什么要测试,哪些风险需要测试

  Activities:如何测试

  Evaluation:如何判定测试的结果是通过还是失败

2.Factors involved in test case quality

  imformation objectives

  test attributes

  techniques

3.Information objectives

寻找缺陷

最大限度的提高bug数量

制止不成熟的产品的发布

帮助经理决定上市与否

把技术支持的成本降低到最小

评估与规格说明书是否一致

遵循规章制度

降低安全相关的法律诉讼风险到最低

找到使用产品的安全场景

评估质量

验证产品的正确性

确保质量

4.Test attributes

Power.测试能够揭露出存在的问题

Valid.暴露的问题是确实存在的问题

Value.暴露的问题正是客户想要知道的问题

Credible.客户信任测试人员.

Representative.发现的问题用户很有可能碰到.

Motivating.客户想要修复发现的问题.

Performable.按照设计执行.

Maintainable.容易修改产品.

Repeatable.可以重复进行低成本的测试.

Pop.暴露的是基本和关键的问题.

Coverage.测试没有被别的测试注意的问题.

Easy to evaluate.

Supports troubleshooting.为调试的人员提供有用的信息.

Appropriately complex.程序稳定些采用复杂的测试.

Accountable.

Cost.

Opportunity Cost.为了进行某些测试而不得不放弃其它测试.

 

Scenario Testing

一.Risks of scenario testing

1)Other approaches are better for testing early, unstable code.

场景测试复杂,包含多个功能点,如果第一个功能点就是坏的,那么接下来的测试就不能进行下去.功能点fix了,下一个坏的功能点又会阻碍测试.

场景测试之前对每一个功能点单独测试,可以尽可能快的发现问题.
2)Scenario tests are not designed for coverage of the program.

通过场景测试去覆盖所有的功能点和需求,声明并不是简单的为了完成覆盖率.

3)Reusing scenarios may lack power and be inefficient

记录和从新使用场景测试更有效,这样可以创建更好的场景.

场景测试会暴露设计的缺陷,我们也会很快发现什么样的测试暴露设计的缺陷.

场景测试组合许多功能点和数据就会暴露代码的问题,覆盖更多的组合就需要更多的测试.

场景测试不适合回归测试,单一功能点的测试和单元测试适合使用回归测试.

 

 

Risk-Based Testing

Drive testing from a perspective of risk, rather than activities,
coverage, people, or available oracle.

In risk-based testing, we create harsh tests for vulnerable areas of the program.

Bach's heuristic test strategy model:

 

 

基于风险的启发式测试模型是提醒测试人员进行测试时候需要考虑的问题.

Quality Criteria are high-level oracles. Use them to determine or argue that the product has problems. Quality criteria are multidimensional, often in conflict with each other.

Product Elements are all the things that make up the product. They're what you intend to test. Software is so complex and invisible that you should take care to assure that you don't miss something you need to examine.

Project Environment includes resources, constraints, and other forces in the project that enable us to test, while also keeping us from doing a perfect job. Make sure that you make use of the resources you have available, while respecting your constraints.

Test Techniques are strategies for creating tests. All techniques involve some sort of analysis of project environment, product elements, and quality criteria.

Perceived Quality is the result of testing. You can never know the "actual" quality of a software product, but through the application of a variety of tests, you can derive an informed assessment of it.

project-level risk analysis

一.Project risk management involves

1)对项目的不同风险的鉴别

2)分析每一个分析相关联的潜在成本

3)完善计划和行为去减少风险的可能性和造成的损失

4)持续的评估和监测风险

二.启发式的风险:哪里去寻找错误

1)New things:新的功能点

2)New technology:新的概念会产生新的错误

3)Learning Curve:由未知的知识产生的错误

4)Changed things:改变也许会破坏旧的代码

5)Late change:匆忙的决定或是由于匆忙员工进行了没有信心的改动造成的错误

6)Rushed work:项目长期经费不足或是存在各个方面的质量问题

7)Tired programmers:开发人员加班导致的效率低下和错误

8)Tired programmers:喝酒了,亲人离去,或是开发人员没有代码的交流等等

9)Just slipping it in:一些功能点没有按照计划完成,影响了其他的代码

10)N.I.H.:外部因素导致的问题

11)N.I.H.:没有预算的任务完成的不好

12)Ambiguity:specs和文档中不明确的描述引起的错误的执行

13)Conflicting requirements:

14)Unknown requirements:

15)Evolving requirements:坚持项目开始的需求会满足合同但是也会产出一个失败的产品.

16)Complexity:复杂的代码会有很多问题

17)Bugginess:有许多bug的功能点也会有许多未知的bug

18)Dependencies:错误会引发其他的错误

19)Untestability:低风险效率低的测试

20)Little system testing so far:

21)Previous reliance on narrow testing strategies:

22)Weak testing tools:

23)Unfixability:不能修复bug的风险

24)Language-typical errors:

25)Criticality:重要功能点的严重缺陷

26)Popularity:经常使用的功能点的缺陷

27)Market:

28)Bad publicity:

29)Liability:

Project environment factors

1)Customers.测试项目的客户.

2)Information.测试需要的信息.

3)Team.执行和协助项目的人员

4)Equipment & Tools.测试中需要的硬件软件和文档.

5)Schedules.事件的顺序周期和同步情况.

6)Test Items.被测试的产品,包括Volatility,Volatility,Testability.

7)Deliverables.测试项目中看的见的成品.包括Content,Purpose,Standards,和Media.

8)Logistics:测试中需要的设备和支持

9)Budget:

Failure Modes

1)failure mode就是程序出错的方式

2)Analyze failure modes three angles

a.Quality attribute failures:比如产品中暴露出的可达性(accessibility),可用性(usability)和可维护性(maintainability)的问题.

b.Product element (or, component) failures:比如使用产品进行实际操作的时候,哪种情况会发生错误.

c.Common programming errors:

Quality criteria

Quality criteria是一种高级的oracles,用来判定产品是否存在问题,Quality criteria是多维的,常彼此冲突.

1)Quality criteria categories

a.Operational criteria

.Capability.是否实现了必须的功能

.Reliability.是否工作正常,并且在某些情况有一定的容错性.

  Error handling:产品遇到问题有错误提示,并很容易的恢复.

  Data Integrity:数据能被保护没有遗失和损坏.

  Security:产品有保护限制,未经授权的用户不能使用.

  Safety:在涉及到要伤害生命和财产问题上,产品不能出现故障

.Usability.对于实际要使用的用户是否容易操作.

  Learnability:用户能否快速的精通产品.

  Operability:能够运行产品所需要的最小资源

  Throughput:用户能否快速的完成一个操作

  Accessibility:有缺陷或残疾的用户能否易用产品

.Performance.产品的速度和反应情况.

.Concurrency.能够很好的同时处理多个任务.

.Scalability.能够升级用户数和作业数.

.Installability and Uninstallability.

.Compatibility.与外部模块和配置的兼容程度.

  Application Compatibility:同其它软件产品的兼容性的问题.

  Operating System Compatibility:

  Hardware Compatibility:

  Backward Compatibility:能够兼容以前版本

  Resource Usage:产品没有消耗不必要的hog memory等系统资源

b.Development criteria

.Supportability.可支持性

.Testability.可测试性

.Maintainability.可维护性

.Portability.

.Localizability.

.Conformance to Standards.遵循一些标准的情况.

  Coding Standards.程序员之间的协议或是某个客户的规定.

  Regulatory Standards.一些权威机构关于程序质量和开发过程的规章制度.

  Industry Standards.包括广泛公认的指导方针和正式出台的标准.

Product elements

1)Structures:产品的物理结构的组成部分

  Code:

  Interfaces:

  Hardware:

  Non-executable files:程序以外的文件,包括文本文件,样本数据,帮助文档和图形视频 等等.

  Ephemera and collaterals:除了软件和硬件的任何事务,如文档,web连接和内容,打包和许可协议等.

2)Functions:产品所要完成的事情

  User Interface:同用户的数据交换

  System Interface:同其它程序,硬盘,网络,打印机等的数据交换

  Application:定义和区别产品并完成了核心的功能需求

  Multimedia:

  Error Handling:

  Interactions:产品中各功能的交互和接口

  Interactions:用来帮助测试的log文件,诊断,警告等

3)Data:产品处理的事物

  Input:

  Output:

  Preset:

  Persistent:经过多次操作之后,数据能够长久保存.包括产品的模式和状态,如选项的设置,观察模式和文档内容等等.

  Temporal:数据和时间的对应关系,包括每秒的键击数,文件的日期标志,和分布式系统的同步性.

4)Platform:产品为之依赖的平台.

  External Hardware:

  External Software:如操作系统,驱动,字体等等.

5)Operations:如何使用产品

  Users.

  Usage Profile:

  Environment:

Programming errors and attacks

1)User interface attacks:检测所有输入值

  Attack 1:输入能有错误提示信息的值

  Attack 2:数人能让软件设立默认值的值

  Attack 3:检测所有允许的字符和数据类型

  Attack 4:输入值溢出

  Attack 5:输入互有影响的值,测试其组合

  Attack 6:重复输入相同的值

2)User interface attacks:检测所有输出

  Attack 7:促使每次输入会有不同的结果输出

  Attack 8:促使非法输出

  Attack 9:促使输出属性的改变

  Attack 10:促使屏幕的刷新

3)Exploring stored data

  Attack 11:采用使用不同初始条件的输入值

  Attack 12:使得数据结构存储很多或很少的值

  Attack 13:采用交替的方式改变内部数据的约束条件

4)Exploring computation and feature interaction

  Attack 14:使用无效的操作数进行组合运算

  Attack 15:递归调用函数

  Attack 16:使得计算结果太大或太小

  Attack 17:对共享数据的功能点进行测试

5)Testing from the file system interface: Media-based attacks

  Attack 1:填充文件系统的容量

  Attack 2:使媒体文件被占用或不被使用

  Attack 3:损坏媒体文件

6)Testing from the file system interface: File-based attacks

  Attack 4:命名不合法的文件名

  Attack 5:改变访问允许

  Attack 6:改变和损坏文件内容

7)Code changes cause side effects

  测试更改的功能点

  测试与更改功能有交互作用的功能点

  测试与更改的功能点相关联的日期和日期的设置

  对更改的功能点进行场景测试

基于风险测试的步骤

1.获得风险的想法

2.对于每个想法,要决定测试行为,准备测试,准备测试的资源来收集信息,并要不断的完善.

3.保持风险和测试的可追溯性.

4.记录和报告项目进行中风险的状态.

5.评估测试覆盖的情况,给出一组基于风险的测试,并找出突破口.

6.如果判定了风险很小,就停止测试.

7.对一个部分进行重测,回顾目前为止的测试经历,明确哪些风险测过,哪些要要加强强度测试.

8.添加非基于风险的测试,避免风险测试分析错误.

9.构建bug历史记录,配置问题,技术支持请求和明显的客户混淆问题-进一步深化失败模式的清单.

 

 

 

Combination Testing（组合测试）

组合测试的方法（三种）

1） Mechanical (or procedural). The tester uses a routine procedure to determine a good set of tests
2） Risk-based. The tester combines test values (the values of each variable) based on perceived risks associated with noteworthy combinations
3） Scenario-based. The tester combines test values on the basis of interesting stories created for the combinations

Test Matrices

1)A matrix is a concise organizer of simple tests, especially useful for function tests and domain tests

2)The matrix groups test cases that are essentially the same.

What is equivalence?

4 views of what makes values equivalent.

1)Intuitive Similarity: two test values are equivalent if they are so similar to each
other that it seems pointless to test both.

2)Specified As Equivalent: two test values are equivalent if the specification says
that the program handles them in the same way.

3)Equivalent Paths: two test values are equivalent if they would drive the
program down the same path (e.g. execute the same branch of an IF).对于子集中的任一数据，如果执行路径并不完全相同，那么这个子集不是等价类.

4)Risk-Based: two test values are equivalent if, given your theory of possible
error, you expect the same result from each.

6条确定等价类的原则：
1、在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，则可以确立一个有效等价类和一个无效等价类。
3、在输入条件是一个布尔量的情况下，可以确立一个有效等价类和一个无效等价类。
4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类。
5、在规定了输入数据必须遵守的规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
6、在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

Domain testing-域测试

1)AKA partitioning, equivalence analysis, boundary analysis

2)测试方法

a) Divide the set of possible values of a field into subsets, pick values to represent
each subset. The goal is to find a “best representative” for eachsubset,and to run tests with these representatives.Best representatives of ordered fields will typically be boundary values.
b) Multiple variables: combine tests of several “best representatives” and find a
defensible way to sample from the set of combinations.

3)Strengths and weaknesses

a)• Strengths
– Find highest probability errors with a relatively small set of tests.
– Intuitively clear approach, easy to teach and understand
– Extends well to multi-variable situations

b)• Blind spots or weaknesses
– Errors that are not at boundaries or in obvious special cases.The "competent programmer hypothesis" can be misleading.
– Also, the actual domains are often unknowable.
– Reliance on best representatives for regression testing leads us to overtest    these cases and undertest other values that were as, or almost as, good.

测试新代码的基本方法

1)Start with obvious and simple tests.使用一些容易pass的值或case测试,如果fail,说明程序存在严重的问题.

2)Test each function sympathetically.弄懂功能存在的因由和给用户带来的价值.知道了用户希望这个feature做些什么,能够发现和解释功能错误的原因和这项功能和剩下的程序的交互性.

3)Test broadly before deeply.早期测试的目标就是尽快发现大的问题.当程序比较稳定的时候再进行更深度的测试.

4)Look for more powerful tests.系统通过简单测试之后,就要想出更强大的更系统的测试案例,头脑风暴是一种很好的集思广益的办法.

5)Pick boundary conditions.精选case,减轻测试负担.

6)Do some freestyle exploratory testing.从项目开始的第一周到最后一周,每周都应该尝试新的测试.

本地化 全球化 国际化测试概念

1)I18N-Internationalization 具有不同国际市场的普遍适应性。

2)G11N-Globalization 使产品或软件进入全球市场还进行有关的商务活动。

3)L10N-Localization 将产品或软件针对国际的语言和文化进行加工，使之符合特定区域市场的过程。

What is test oracle？

An oracle is the principle or mechanism by which you recognize a problem.

It really means “...it appeared to meet some requirement to some degree.”

A test oracle is the set of predicted result for a set of tests。

An oracle is as a source of expected results.

What is heuristic？

中文意思是“启发式的”，作为一个形容词，形容通过推断以及猜测，而不是通过现成的公式来获得知识。可以用来形容那种未知结果的探索过程，或者试图证明一个猜想的正确性的方法。也就是通过反复试验获取的知识。当作为名词使用时，heuristic表示“探索性的方法或过程”。通过启发式方法来解决问题的程序称为heuristics。启发式方法（试探法）是一种帮你寻求答案的技术，但它给出的答案是具有偶然性的（subject to chance），因为启发式方法仅仅告诉你该如何去找，而没有告诉你要找什么。

 

一.Sakeholder:A stakeholder is a person who is affected by the product.A stakeholder is someone whose preference or opinion might result in change to the product.

二.Computer words

1)tooltips-工具提示

2)scroll bar-滚动条

3)dialogbox-对话框

4)pull-down menu-下拉菜单

5)child windwo-子窗口

6)click on a push button-点击按钮

7)system crash－系统崩溃

8)CAT-core automated testing

9)ABFT-Automated Basic Funtionality Testing

一.A brief introduction of 5M

1)APQP-Advanced product quality planning:is a quality framework used for developing new products in the automotive industry.

2)PPAP-Production Part Approval Process:outlines the method used for approval of production and service commoditics,incluing bulk materials,up to and including part submission warrant in the advanced quality planning process.

3)FEMA-Failure Modes and Effects Analysis is methodology for analyzing potential reliability problems early in the development cycle where it is easier to take actions to overcome these issues,thereby enhancing reliability through design.

4)SPC-Statistical Process Control is the application of statistical cause of variation in a process.

5)MSA-Measurement System Analysis:测量系统分析,使用数理统计和图表的方法对测量系统的误差进行分析,以评估测量的参数是否合适,并确定测量,系统误差的主要成分.

二.The brief of 7S

1)检查表(Data collection form)

2)分层法(Stratification)

3)散步图(scatter)

4)排列图(Pareto)

5)直方图(histogram)

6)因果图(Cause-effect diagram)

7)控制图(control chart)

1.Testing terminology

1)race conditon:竞争状态

2)instrumentation:插装,在程序中插入额外的代码以获得程序在执行时行为的消息.

3)error seeding:错误播种,错误插值

4)code walkthrough:代码走读-一个非正式的同行评审手段,在该评审中,代码被使用一些简单的测试用例进行人工执行,程序变量的状态被手工分析,以分析程序的逻辑和假设.

 

  我有一个习惯把新接收到的东西写在本子上,今天突然想把本子上的东西整理到空间里,算是对过去的一个回顾吧.

1.缺陷类型

F-Function 影响了重要特性

A-Assignment 需要修改少量代码

I-Interface 与其他组件相互影响的缺陷

C-Checking 不适当的数据验证

B-Build/package/Merge 配置库,版本引起的错误

D-Document 影响发布和维护,包括注释

G-Algorithm 算法错误

U-User interface 人机交互缺陷

P-Performance 不满足系统可测量的属性值

N-Norms 不符合多种标准要求 

2.测试名词

1.SOP-standard operatiing procedures标准的操作过程

2.spiral model螺旋模型

3.SQL-structured query language

4.test suite测试套:测试用例或测试脚本的集合

5.test harness测试用具

6.test completion criterion测试完成标准

7.test comparator测试比较器

8.structured walkthrough结构化走读

9.symbolic evaluation符号评价

10.syntax testing语法分析

11.state transition状态转换

12.statistical testing统计测试

13.stepwise refinement逐步优化

14.feasible path可达路径

15.SLA=service level agreenment服务级别协议