软件测试（原书第二版）读书笔记（一）

第一章 软件测试的背景

软件缺陷

1、在本书中，所有软件问题都被称为缺陷。
2、产品说明书：对开发的产品进行定义。给出产品的细节，如何做、做什么、不能做什么。
3、至少满足下列五个规则之一才称发生了一个软件缺陷。

（1）软件未实现产品说明书要求的功能。
（2）软件出现了产品说明书指明不应该出现的错误。
（3）软件实现了产品说明书未提到的功能。
（4）软件未实现产品说明书虽未明确提及但应该实现的目标。
（5）软件难以理解、不易使用、运行缓慢。
第（3）条：多增加功能虽然有了更好，但是会增加测试的工作，甚至带来更多的缺陷。

修复缺陷并非指一定要改正软件。可以是指在用户手册中增加一段注释或为用户提供特殊的培训。

7.优秀的软件测试员应具备的素质：

他们是群探索者。
他们是故障排除员。
他们不放过任何蛛丝马迹。
他们具有创造性。
他们是群追求完美者。
他们判断准确。
他们注重策略和外交。
他们善于说服。

除了这些素质外，在软件编程受过教育也很重要。了解软件是怎样编写的，可以从不同角度找出软件缺陷，从而使得测试更加高效，有助于开发测试工具。

第二章 软件开发的过程

产品的组成部分

1、在软件行业中，用于描述制造出来并交付他人的软件产品组件的术语是可交付的部分。解释所有可交付部分内容的最简便方法是分门别类。
2、编写软件的目的是满足一些人的需求，这些人称为客户。
3、从软件产品的潜在客户中获得直接反馈的流行做法是借助焦点人群。焦点人群通常由办公室设在商业场所的独立问卷调查公司来组织。
4、产品说明书。
5、软件产品的一个关键部分是进度表。目的是了解哪项工作完成了，还有多少工作要做，何时全部完成。
6、软件设计文档：对于稍大一些的程序而言，必须要有一个设计过程来规划软件如何编写。
7、常用软件设计文档的清单：

结构文档。描述软件整体设计的文档。
数据流图。表示数据在程序中如何流动的正规示意图。也称为泡泡图，用圆圈和线画的。
状态转换图。把软件分解为基本状态或者条件的另一种正规示意图，表示不同状态间转换的方式。
流程图。用图形描述程序逻辑的传统方式。
代码注释。

8、测试文档。
比较重要的测试提交清单：

测试计划。描述用于验证软件是否符合产品说明书和客户需求的整体方案。
测试用例。列举测试的项目，描述软件的详细步骤。
缺陷 告。描述执行测试用例找出的问题。
测试工具和自动测试。如果测试小组使用自动化测试和工具测试软件，不管是购买的还是自己编写的工具，都必须有文档记录。
度量、统计和总结。测试过程的汇总。

9、错误提示信息是软件产品最容易忽视的部分。

软件项目成员

软件开发生命周期模式

1、软件产品从最初构思到公开发行的过程称为软件开发生命周期模式。
2、四种最常用的模式：

大爆炸模式
边写边改模式
瀑布模式
螺旋模式

大爆炸模式

一大堆东西（人力和资金）放在一起，巨大的能量释放——通常很野蛮——产生了优秀的软件产品——或者一堆废品。

大爆炸模式的优点是简单。计划、进度安排和正规开发过程几乎没有，所有精力都花在开发软件和编写代码上。
多数情况下，大爆炸模式几乎没有什么测试。如果有的话，也是挤在产品发布前进行。
尽量避开在此模式下进行测试。

边写边改模式

项目小组在未刻意采用其他开发模式时默认的开发模式。比大爆炸更近一步，至少考虑了产品需求。

边写边改模式适合意在快速制作而且用完就扔的小项目。

瀑布模式

采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个 步骤结束时，项目小组组织审查。如果项目未准备好，就停滞下来。

瀑布模式非常强调产品的定义。
各个步骤是分立的，没有交叉。
无法回溯。

优点：所有一切都有完整细致的说明，测试对象非常明确。
缺点：测试仅在最后进行，所以一些根本性问题可能出现在早期，直到准备发布产品时才可能发现。

螺旋模式

总体思想是一开始不必详细定义所有细节。从小开始，定义重要功能，努力实现这些功能，接受客户反馈，然后进入下一个阶段。重复上述过程，直到得到最终产品。

螺旋测试中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋测试的每一次）和一点大爆炸模式（从外界观察）。
该模式发现问题早、成本低。

PS：有一种开发过程叫敏捷软件开发。未成主流，容易偏离主题而造成混乱。

第三章 软件测试的实质

测试的原则

1、完全测试一个程序是不可能的。
2、软件测试员要学会一个关键的思想是，如何把数量巨大的可能测试减少到可以控制的范围，以及如何针对风险做出明确的抉择，哪些测试重要，哪些不重要。
3、我们的目标是找到最优的测试量，使测试不多不少。
4、可以 告软件缺陷存在，却不能 告软件缺陷不存在。任何情况下都不能保证软件缺陷没有了。唯一的方法是继续测试，可能还会找到一些。

程序员也有心情不好的时候。
程序员往往犯同样的错误。
某些软件缺陷实乃冰山一角。

5、并非所有的软件缺陷都要修复。
不需要修复软件缺陷的原因有：

没有足够的时间 。
不算真正的软件缺陷。
修复的风险太大。
不值得修复。

6、确认是保证软件符合产品说明书的过程。验证是保证软件满足用户要求的过程。