对手的程序死掉叫崩溃。自己的程序死掉叫”身体不良反应(idiosyncrasy)”。通常，崩溃之后会显示”ID02”这样的信息。”ID”是idiosyncrasy的缩写，后面的数字表示产品应该测试多少个月。 —- Guy Kawasaki
0x00 写在前面的话
读书笔记所指的《软件测试》是Ron Patton的著作，而不是其他同名的书。说到《软件测试》这个名字，有必要吐槽一下，在图书馆里搜索”软件测试”关键词的时候，冒出来十几本叫《软件测试》的书，而且大部分都是国内的，起名字的时候能不能别那么随便= =。Ron Patton的书也有些年头了，第一版是在2002年出的，但是作为一本入门的书籍，它足够基础，足够通俗易懂，因此将其选为我的第一本软件测试书籍。
本部分由三章组成：
- 软件测试背景
- 软件开发过程
- 软件测试的实质
0x01 软件测试背景
软件测试员的目标
找出软件缺陷，尽可能早一些，并确保其得以修复。
什么是软件缺陷
此处引入一个辅助性术语：产品说明书，这是开发小组的协定，对开发的产品进行定义，包括产品有何细节，有何功能，有何限制等。
符合以下5个规则就认为是软件缺陷：
- 软件未达到产品说明书标明的功能；
- 软件出现了产品说明书指明不会出现的错误；
- 软件功能超出了产品说明书的指明范围；
- 软件未达到产品说明书虽未指明但应达到的目标；
- 软件测试员认为软件难以理解，不易使用，运行速度缓慢，或者最终用户认为不好。(有点主观的规则)
其中，需要注意第3个规则，以计算器为例，如果产品说明书里没有指明有求平方根的功能，但是最终软件产品可以求平方根，也认为这是软件缺陷。
为什么会出现软件缺陷
因为软件是人做的(无法反驳)。
出现软件缺陷的原因(由大到小)：
- 产品说明书；
- 设计方案；
- 编写代码；
- 其他
产品说明书和设计方案造成软件缺陷的原因是一样的，设计不够全面，经常改动，开发小组沟通不足。
软件缺陷的修复费用
随之时间的增长，软件缺陷的修复费用几乎呈几何级数增长。 
0x02 软件开发过程
软件产品的投入
软件产品的投入除了最终构成软件的代码，还有许多看不见的东西。
客户需求
获取客户需求的办法有问卷调查，以前产品反馈，收集竞争产品信息，舆论评论等。客户需求无法描述要做的产品，只是确定了哪些功能需要完成。
产品说明书
产品说明书综合客户需求，定义了软件产品，包括了软件有何功能，外观如何，有何限制等。
进度表
一般常用甘特图(Gantt)来管理进度。
软件设计文档
相当于程序员编写软件前的大纲，常用软件设计文档清单：
- 架构
- 数据流示意图
- 状态变化示意图
- 流程图
- 代码注释
测试文档
与代码编写人员类似，测序员在测试中也需要编写测试文档。常见测试文档清单：
- 测试计划：描述用于验证软件是否符合产品说明书和客户需求的整体方案。
- 测试案列：列举测试的项目，描述验证软件的详细步骤；
- 软件缺陷报告：描述测试案列中找出的问题；
- 归纳，统计和总结：以图表和报告的形式。
软件产品的组成部分
软件产品除了实际代码外，还有许多其他的支持。
那些非软件的部分，也是测试的内容。
软件项目成员
主要人员有：
- 项目管理员(产品经理？)：负责编写产品说明书，管理进度，进行重大决策等。
- 系统工程师(架构师？):负责整个系统的架构和软件构思。
- 开发人员
- 测试员
- 技术作者/手册编写人员：编制软件产品附带的文件。(居然还有这种人员)
- 结构管理员/制作人员:负责把全部资料文档合成为一个软件包。
软件开发模式
作者在本书中罗列了4种，我平常常听说的敏捷开发不在其列，不知道是否是因为出书时间太早没有收入？还是已经包括在4种之中了？
软件开发模式是指从最初构思到公开发行软件产品的过程。
大棒模式
把一大堆东西(人力和财力)放在一起，然后boom，就出现了软件产品或者废物。
大棒模式的优点是简单，没有计划，进度安排等，把所有精力都放在了代码编写上。
但是在大棒模式下，测试人员很难介入，测试最有可能的位置是在产品发布之前，但是根据之前说的软件缺陷修复费用，在这个时候发现的软件缺陷修复费用将非常巨大，甚至有时候无法回头。
边写边改模式
比大棒模式好一点是考虑到了产品需求，中间有一段漫长的时间用于编写，测试和修复。
优点是可以快速开发，因为几乎没有计划和文档编写。
测试员在修复缺陷过程中有介入的空间，但是因为需要不断的测试修复，可能测试未完成就有新版本出现了，测试对象不确定。
流水模式(瀑布模式)
流水模式中，一个产品从构思到发布需要经过一系列的步骤，而且每个步骤都是独立的，只有上一个步骤完成了才进行下一个步骤。
优点是每个步骤职责都很明确，测试在其中更为有利，因为当软件提交到测试员手中，软件的所有细节都已经非常明确，测试员得以指定精确的测试计划和进度。
缺点也是非常明显，每个步骤不能后退，测试在最后发现软件缺陷，修复的成本将非常大。另外开发的周期长。
螺旋模式
开始不必实现所有细节，只定义重要功能，然后接受测试或用户反馈，然后进入下一个阶段。
优点是测试得以参与最初的设计阶段，可以尽可能早的找到软件缺陷。
但是开发的周期长。
0x03 软件测试的本质
测试原则
1. 完全测试程序是不可能的
原因：
- 输入量太多
- 输出结果太多
- 软件实现途径太多
- 软件说明书没有客观标准(软件缺陷标准不同)
以计算器为例，测试加法，必须测试所有可能的输入，包括错误的输入以及不同位数的相加，如果你没有测试1024+1024，那么测试就不能称为是完全测试。
2. 软件测试是有风险的行为
原因是不可能完全测试，测试员的工作就是找到一个最佳的测试量。
3. 测试无法显示潜伏的软件缺陷
可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷。
4. 找到的软件缺陷越多，说明软件缺陷越多
软件缺陷经常是成群出现的，但是这个也不是绝对的。
5. 杀虫剂怪事
以螺旋模式为例，经过每一轮测试之后，软件缺陷越来越难被发现，就像产生了抗体。解决办法是不断编写不同的测试程序，对不同的部分进行测试。
6. 并非所有软件测试都能够修复
或者说是不需要被修复，不需要的原因有：
- 没有足够的时间
- 不算真正的软件缺陷，比如计算器产品说明书里没有指明有求平方根功能，但是本身软件有这个功能，如果修改了产品说明书，这就不是一个缺陷，而是一个功能了。
- 修复的风险太大
- 不值得修复，或者说出现概率很小。
7. 没有被发现的问题不叫软件缺陷，只能说是未知软件缺陷
8. 产品说明书是会变化的
因为市场和客户需求的变化，产品说明书可能会改动，这时候要求测试员需要灵活改变测试计划。
9. 测试员在产品小组中不受欢迎
因为报忧不报喜嘛。
10. 软件测试是一项讲究条理的技术专业
软件测试术语
比较了4条容易混淆的软件测试术语。
精确和准确
一张图就够了
验证和合法性检查
验证是保证软件符合产品说明书的过程。
合法性检查是保证软件满足用户要求的过程。
一般产品说明书和用户要求是不矛盾的，所以多数情况下是一致的。但是如果产品说明书有误，两者就不统一了。
质量和可靠性
质量是指产品性能优越，高于同类产品。而可靠性只是质量的一个方面。
测试和质量评判(QA)
- 软件测试员的目标是找出软件缺陷，尽可能早一些，并确保得以修复。
- 质量评判人员的只要职责是创建和加强促进软件开发并防止软件缺陷的标准和方法。
一般两种人员会做对方的工作。