禅道安装教程：https://www.cnblogs.com/syq1851046443/p/6603370.html
目录
第一部分 软件测试综述
第一章 软件测试的背景
1.1臭名昭著的软件错误用例研究
1.2软件缺陷是什么
1.2.1软件失败的术语
确实严重，甚至是危险的情况：故障（fault）、失败（failure）、缺点（defect）
不那么尖锐，主要指未按预料运行，而不指全部失败：异常（anomaly）、事件，插曲（incident）、偏差（variance）
最常用的术语：问题（problem）、错误（error）、缺陷（bug）
其他术语：矛盾（inconsistency）、特殊（feature）
软件测试中出现的其他术语：
产品说明书（product specification）：简称为说明（spec）或产品说明（product spec）。它对开发的产品进行定义，给出产品的细节、如何做、做什么、不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。之后《软件开发的过程》会讲述产品说明书和开发过程中的更多内容。
在每个公司，不同的开发小组里会有不同的术语，但在用词上过多的计较是没有意义的。在这本书中，所有的软件问题都被称为缺陷
1.2.2软件缺陷的官方定义 ☟
至少满足下列5个规则之一才称发生了一个软件缺陷（software bug）
1）软件未实现产品说明书要求的内容（产品说明书：计算器能够准确无误的进行加减乘除；按下（+）键，没有反应，或者得到错误答案）
2）软件出现了产品说明书指明不应该出现的错误（产品说明书：计算器永远不会崩溃、锁死或者停止反应；狂敲键盘，计算器停止接受输入）
3）软件实现了产品说明书未提到的内容（计算器求加减乘除还可以求平方根，这也是缺陷，虽然有了更好，但会增加测试的工作，甚至带来更多的缺陷）
4）软件未实现产品说明书虽未明确提及但应该实现的目标（目的为了捕获那些产品说明书上的遗漏之处。比如在测试计算器时，会发现电池没电会导致计算不准确。没有人考虑到这种情况下计算器会如何反应，而是想当然的假定电池一直都是充足电了的。测试要考虑到让计算器持续工作知道计算器完全没电，或者至少用到出现电力不足的提醒。电力不足无法正确显示计算，但产品说明书未指出这个问题）
5）软件难以理解、不易使用、运行缓慢或者——从测试员角度看——最终用户会认为不好
（要全面，最重要的是客观评价，并非所有测试发现的缺陷都要修改。测试人员应该是第一个真正使用软件的人。如果软件测试人员发现某些地方不对劲，无论什么原因，都要认定是缺陷。比如，测试人员觉得计算器的按键太小，也许“=”的位置极其不好按，也许在明亮光下显示屏难以看清。这些都是缺陷）
反思：第3个添加功能的，开发应该和产品人员商量，而不是擅自把功能添加进去
第3个应该放在单独的一类，标明“是开发人员额外设计的功能”，因为这些功能之后可能会被采用，不能和那些明显的错误放在一起，然后一棒子打死
第4、5个也是应该单独分类的。里面有很多不确定的因素，但只要觉得不对劲都应该提出来。要知道并非所有测试发现的缺陷都要更改，这里是最容易产生矛盾的地方（要与开发和产品讨论：开发不认为这个是缺陷怎么办，觉得吹毛求疵——首先反思一下自己的想法是否客观，问对方为什么不认可，我再从这个缺陷对用户/客户引发的后果谈，如果两人是在拿不定主意或者无法达成一致意见就去问问项目经理，由项目经理协调解决）
最终要考虑的是：存不存在这种进行分类的缺陷管理工具呢?
1.3为什么会出现软件缺陷
说明书>设计>编码>其他
说明书：说明书没有写或者不够全面、经常更改；或者开发小组没有很好的沟通。为软件做计划是极其重要的，如果没做好，软件缺陷就会出现（我个人的理解是产品说明或者需求写的模棱两可或者就没有写，在没有明确评判标准下，开发人员凭着大概做出来的东西就会很容易出错）
设计：随意、易变、沟通不足。这是程序员规划软件的过程，好比是建筑师为建筑物绘制蓝图（我个人的理解是程序员没有完全了解清楚规划好，就直接动手做，做完发现不对又继续改，中间就很容易出错）
编码：软件复杂、文档不足（特别是升级或者修订过的代码的文档）、进度压力、普通低级错误
注意：许多看起来像是编程错误的其实实际上是由产品说明书和设计方案造成的，比如程序员说：“这是按要求做的。如果有人早这么告诉我，我就不会这样编程了”
其他：测试误把本来正确的当成缺陷了；或者缺陷多处反复出现，实际上是由一个原因引起的；或者归咎于测试错误。一般此类缺陷只占很小的比例，不用担心
1.4软件缺陷的修复问题
发布时修复缺陷的费用=测试时修复缺陷的费用*10=编码时修复缺陷的费用*100=设计时修复缺陷的费用*1000=说明书时修复缺陷的费用*10000
1.5软件测试员究竟做些什么
软件测试员的目标是尽可能早的找出软件缺陷，并确保其得以修复
1.6优秀的软件测试员应具备的素质
（√）他们是群探索者。喜欢拿到新软件，安装在自己的机器上，观看结果
（√）他们是故障排除员。善于发现问题的症结
（？）不放过任何蛛丝马迹。碰到转瞬即逝或者难以重现的软件缺陷，也不轻易放过，会想尽一切可能去发现他们
（？）具有创造性。用超常的手段来寻找缺陷
（√）追求完美。不去苛求完美，而是尽力接近目标
（？）判断准确。决定测试内容、测试时间、以及看到的问题是否是真正的缺陷
（？）注重策略和外交。知道怎么策略和职业的告诉程序员，你的孩子（程序）很丑。知道如何与不够冷静的程序员合作
（？）善于说服。当找出的缺陷被认为不重要，不用修复时，要善于清晰的说明软件缺陷为何必须修复，并推进缺陷的修复。
（√）在编程方面受过教育。从第六章“检查代码”可知，了解软件是怎样编写的，可以从不同角度找出缺陷，是测试更高效。同时，有助于开发第15章“自动测试和测试工具”中讨论的测试工具
（？）了解金融方面的知识
1.7小结
第一部分的第2章将讲述软件开发以及软件测试如何融入到开发中。这些知识对于运用本书其他章节所属的测试知识极有帮助
1.8小测验
第二章 软件开发的过程
本章的目的不是讲述软件开发过程中的每一个细节，这需要一本书来讲。
本章的目的是纵观软件产品构成的各个部分，了解目前常用的一些方法。这些知识有助于更好的理解如何恰当的运用本书后面个字节讲述的软件测试技术。
本章重点：
1. 软件产品构成的主要部分
2. 软件产品包含哪些人劳动和技术
3. 软件从构想到最终产品的构成
2.1产品的组成部分
2.1.1软件产品需要多少投入
2.1.1.1客户需求
利用焦点人群审视软件功能
2.1.1.2产品说明书
产品说明书综合上述对客户需求的研究结果以及没有提出但必须要实现的需求，真正的定义产品是什么、有哪些功能、外观如何。
产品说明书的格式千差万别。特别是金融机构开发产品的公司，采用严格的过程，要进行大量的检查和对比。结果是产品说明书极其详细完整，而且是“锁定”的，也就是说，没有极特殊的理由决不能变。开发小组的每一个成员都清楚地知道他们在做的是什么。
但通常有一些开发小组，通常是开发不很关键一个的小组，在餐巾纸上就写出产品说明书。好处是非常灵活，存在的风险是并非所有人都“站在一起”。此外，最终产品是什么样在发布之前也无从得知。
2.1.1.3进度表
软件产品的一个关键部分是进度表。随着项目的不断庞大和复杂，制造产品需要投入很多人力和物力，因而必须要有某种机制来跟踪进度。制定进度的目的是了解哪项工作完成了，还有多少工作要做，何时全部完成。
从简单的在Gantt图标上列出任务，到使用项目管理软件详细跟踪每一分钟的任务，各种机制不一而足。
2.1.1.4软件设计文档
以本书为例，在落笔之前需要有一个大纲，软件也应该有同样的计划。根据公司和项目合作小组的不同，程序员的文档千差万别，但其目的都是规划、组织即将编写的代码。
下面是一些常用软件设计文档的清单：
结构文档：描述软件整体设计的文档，包括软件所有主要部分的描述以及相互之间的交互方式。
数据流图：表示数据在程序中如何流动的正规示意图。有时被称为泡泡图，因为它是由圆圈和线画的
状态转换图：把软件分解为基本状态或者条件的另一种正规示意图，表示不同状态间转换的方式。
流程图：用图形描述程序逻辑的传统方式。流程图现在不流行了，但是一旦投入使用，根据详细的流程图编写程序代码还是很简单的
代码注释：在软件代码中嵌入有用的注释是极其重要的，这样便于维护代码的程序员轻松掌握代码的内容和执行方式
2.1.1.5测试文档
测试文档将在第17-20章详细讨论。测试员也必须写测试文档，软件测试小组提交的文档比程序员还多的情况并不少见。
下面是比较重要的测试提交清单：
测试计划：描述用于验证软件是否符合产品说明书和客户需求的整体方案。包含质量目标、资源需求、进度表、任务分配、方法等。
测试用例：列举测试的项目，描述验证软件的详细步骤
缺陷报告：描述执行测试用例找出的问题。可以记录在纸上，但通常记录在数据中
测试工具和自动测试：将在第15章详细讨论。如果测试小组使用自动化测试工具测试软件，不管是自己购买的还是自己编写的工具，都必须有文档记录。
度量、统计和总结：测试过程的汇总。采用图形、表格和报告等形式。
2.1.2软件产品由哪些部分组成
当产品打包分发时，不仅仅分发的是代码，许多支持包含在内。由于所有这些部分客户都要查看或使用，所以也需要测试。
本章后面将讲述这些非软件部分，以及如何正确测试。在此之前，请牢记下面的清单：
- 帮助文件
- 样本和示例
- 产品支持信息
- 错误信息
- 安装
- 用户手册
- 标签和不干胶
- 图标和标志
- 广告和宣传材料
- 说明文件
别忘了测试错误提示信息
错误提示信息是软件产品最容易忽略的部分，通常由程序员而不是训练有素的高手来写。
他们很少计划这些信息，在修复软件缺陷时常常造成麻烦。软件测试员也难以找到并显示全部信息。千万不要让以下的错误提示信息出现在软件中：
Error：Keyboard not found.Press F1 to continue
Can’t instantiate the video thing.
Windows has found an unknown device and is installing a driver for it.
A Fatal Exception 006 has occurred at 0000:0000007
2.2软件项目成员
下面的清单不按次序的列出了主要人员及其职责。给出了最常用的名称，但是不包括变动和增加等情况：
项目经理/程序经理/监制人员：至始至终驱动着整个项目。他们通常负责编写产品说明书、管理进度、进行重大决策
体系架构师/系统工程师：产品小组的技术专家。他们一般经验丰富，可以胜任设计整个系统的体系架构或软件。他们的工作与程序员关系紧密。
程序员/开发人员/代码制作者：设计、编写软件并修复软件中的缺陷。他们与项目经理和设计师密切合作制作软件，然后与项目经理和测试员密切合作修复缺陷。
测试员/质量保证员（QA）：找出并报告软件产品的问题。他们与开发小组全部成员在开发过程中密切合作，进行测试并报告发现的问题。
第21章“软件质量保证”完整的讲述了软件测试和软件质量保证任务的差别。
技术作者/用户协助专员/用户培训专员/手册编写员/文案专员：编制软件产品附带的文件和联机文档
配置管理员/构建员：把程序员编写的代码及技术作者写的全部文档资料组合在一起，合成一个软件包