1、软件测试的背景
1、缺陷是什么（缺陷的官方定义）
产品说明书：对开发的产品进行定义，给出产品的细节、如何做、做什么、不做什么。
只有至少满足下列5个规则之一才称发生了一个软件缺陷：
- 软件未实现产品说明书要求的功能
- 软件出现了产品说明书指明不会出现的错误
- 软件实现了产品说明书未提到的功能
- 软件未实现产品说明书虽未明确提出但应该实现的目标
- 软件难以理解，不易使用，运行缓慢或者--从测试员的角度看--最终用户会认为不好
注意：软件测试员在运用第5条测试规则时，要全面，最重要的是要客观评价，并非所有测试发现的缺陷都要修改。
2、缺陷产生的原因
最大原因：产品说明书（说明书--没有写或者不够全面、经常更改、沟通不足）；
第二：设计（程序员规划软件的过程--随意、易变、沟通不足）；
其次：把本来正确的当成缺陷、测试错误。这类缺陷只占极小的比例，不必担心。
最大原因：需求规格说明书；第二：设计方案；其次：编写代码，其他
1） 需求理解错误，编写过程中引起的错误
2） 需求不断变更：项目失败的最大杀手，会引起重新设计，工程重新安排
3） 开发过程中缺乏有效的沟通，或没有进行沟通：导致设计不正确
4） 编程中产生错误
5） 软件开发工具本身隐藏的问题：选择较为成熟的产品
6） 不重视开发文档
7） 软件复杂度越来越高
8） 项目进度的压力
3、软件测试员的目标
尽可能早地找出软件缺陷、并确保其得以修复。（注意：修复缺陷并非一定要改正软件。可以是指在用户手册中增加一段注释或为用户提供特殊的p）
4、测验
1、在千年虫例子中，dave有错吗？
如果dave是个好的程序员，他应该对这个‘显然的’疏忽产生疑问而不是仅仅将程序涉及到只能有效工作到1999年，由于他没有这样做，软件测试源就应该测试并发现该缺陷，然后又开发小组确定是否修正。
2、判断是非：公司或开发小组用户称呼软件问题的术语很重要。
错。这虽然不重要，但使用什么术语常常反映了小组的个性及其寻找、报告、确定问题的方法。他们提及软件问题的方式反映出他们处理整个开发过程的方式。他们是谨慎、小心、直接，还是简单生硬。
3、仅仅测试程序是否按预期方式运行有何问题？
这最多只能算测试问题的一半。用户不一定遵守规则，软件测试员需要证实不按标准操作有何后果。此为，如果测试员进行测试没有打破砂锅问到底的态度就会遗漏某些软件缺陷。
4、产品发行后修复软件缺陷比项目开发早期这样做的费用要高出多少？
10~100倍，甚至更高。
5、软件测试员的目标是什么？
尽可能早一些找出软件缺陷，并确保其得以修复
6、判断是非：好的测试员坚持不懈地追求完美。
错。他们力求完美，但当知道某些无法企及时，不去苛求，而是尽力接近目标。好的测试员知道何时完美无法企及，何时达到‘够好’。
7、给出几个理由说明产品说明书为什么通常是软件产品中制造缺陷的最大来源。
产品说明书常常没写。不要忘了，说不出来就做不出来。其他原因是产品说明书虽然有，但是不完整，不停更改，或者产品说明书内容没有通开发小组其他成员沟通过。
2、软件开发的过程
1、软件产品的组成部分
在软件行业中，用于描述制造出来并交付给他人的软件产品组件的术语是可交付部分。
软件产品需要的投入：客户需求、产品说明书、进度表、软件设计文档、测试文档。
产品打包分发时，不仅分发的是代码，许多支持包含在内。支持包括：帮助文件、用户手册、样本和示例、标签和不干胶、产品支持信息、图标和标志、错误信息、广告和宣传材料、安装、说明文件。
2、软件开发生命周期
软件产品从最初构思到公开发行的过程称为软件开发生命周期模式。以下是4中最常用的模式。
1、大爆炸模式
优点是简单。计划、进度安排和正规开发过程几乎没有，所有精力都花在开发软件和编写代码上。如果产品需求无需很好理解，且最终发布日期可随便更改，这样的开发过程很理想。
2、边写边改模式
是项目小组在未刻意采用其他开发模式时默认的开发模式。通常最初只有粗略的项目，接着进行一些简单的设计，然后开始漫长的来回编写、测试和修改缺陷的过程。等到觉得足够了，就发布产品。
3、瀑布模式
构思、分析、设计、开发、测试、最终产品。采用该模式的项目从最初的构思到最终的产品要经过一系列步骤。每个步骤结束时，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来，直到准备好。有三点需要强调：
- 瀑布模式非常强调产品的定义。注意，开发或代码编制阶段只是其中单独的一块。
- 瀑布模式各步骤时分立的，没有交叉。
- 瀑布模式无法回溯。一旦进入某一个步骤，就要完成该步骤的任务，然后才能向下继续。
4、螺旋模式
总体思想是一开始不必详细定义所有细节。从小开始，定义重要功能，努力实现这些功能，接受客户反馈，然后进入下一阶段。重复上诉过程，直到得到最终产品。每次循环包括6个步骤：
- ?确定目标、可选方案和限制条件。
- 明确并化解风险。
- 评估可选方案。
- 当前阶段开发和测试。
- 计划下一阶段。
- 确定进入下一阶段的方法。
3、测验
1、说出在程序员开始编写代码之前要完成哪些任务？
开发小组需要了解客户的要求，在产品说明书中定义功能特性。应该建立详细的进度，是小组程序知道哪些工作已经完成，哪些工作还要做。软件应该形成体系，经过设计，测试小组应该开始计划工作。
2、正式并被锁定不能修改的产品说明书有何缺点？
如果软件开发过程中市场转移到不同的方向上或者客户要求改变，就没有调整软件的灵活性。
3、软件开发大爆炸模式的最大优点是什么？
简单。仅此而已。
4、采用边写边改模式时，如何得知软件发布的时间？
边写边改模式没有真正的退出标准，除非某人或进度决定该结束了。
5、瀑布模式为什么不好用？
像大马哈鱼一样，很难向上流。每一步都是跟着上一步的独立、离散的过程。如果走到头发现有些事情应该早些做时，想退回来就来不及了。
6、软件测试员为什么最喜欢螺旋模式？
他们很早就参与开发过程，有机会尽早发现问题，为项目节省时间和金钱。
3、软件测试的实质
1、测试的原则
1、完全测试程序是不可能的
原因：输入量太大、输出结果太多、软件执行路径太多、软件说明书是主观的。
如果觉得某些测试条件是重复的、无必要的，或者为了节省空间，而将其剔除，那么采用的就是不完全测试。
2、软件测试是有风险的行为
如果决定不去测试所有的情况，那就是选择了冒险。软件测试员要学会的一个关键思想，如何把数量巨大的可能测试减少到可以控制的方位，以及如何针对风险做出明智的抉择，哪些测试重要，哪些不重要。每一个软件项目都有一个最优的测试量，如图：
该图说明了测试量和发现的软件缺陷数量之间的关系。如果试图测试所有情况，费用将大幅增加，而缺陷漏掉的数量在到达某一点后没有显著变化。如果减少测试或错误地确定测试对象，虽然费用很低，但会漏掉大量缺陷。我们的目标是，找到最优的测试量，使测试不多不少。
3、测试无法显示潜伏的软件缺陷
软件测试工作，可以报告软件缺陷存在，却不能报告缺陷不存在。你可以进行测试，发现并报告软件缺陷，但是任何情况下都不能保证软件缺陷没有了。唯一的方法使继续进行的是，可能还会找到一些。
4、找到的软件缺陷越多，就说明软件缺陷越多
通常，软件测试员会在很长时间内找不到软件缺陷。接着找到一个，之后很快就会接二连三地找到更多。原因是：
- 程序员也有心情不好的时候。
- 程序员往往犯同样的错误。
- 某些软件缺陷实乃冰山一角。
5、杀虫剂怪事
软件测试的越多，其对测试的免疫力越强。为了克服杀虫剂怪事，软件测试员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试，以找出更多软件缺陷。
6、并非所有软件缺陷都要修复
软件测试员需要进行良好的判断，搞清楚在什么情况下不能追求完美。项目小组需要进行取舍，根据风险决定哪些缺陷需要修复，哪些不需要修复。不需要修复的原因：
- 没有足够的时间。软件功能太多，进度没有足够的开发和测试人员来完成项目，但必须按时完成交付软件。
- 不算真正的软件缺陷。很多情况下，理解错误、测试错误和说明书变更，会把可能的软件缺陷当作功能来对待。
- 修复的风险太大。这些情形很常见。修复一个缺陷可能导致其他软件缺陷出现。在紧迫的产品发布进度压力下，修复软件将冒很大的风险。不去理睬已知的软件缺陷，以避免造成新的、未知的缺陷的做法也许是安全知道。
- 不值得修复。不常出现的缺陷和在不常用功能中出现的缺陷是可以放多的，可以躲过和用户有办法预防或避免的缺陷通常不用修复。这些都要归结为商业风险决策。决策过程通常由测试员、项目经理和程序员共同参与，他们站在各自的立场看待缺陷，对缺陷是否应该修复都有自己的观点和看法。
7、什么时候才叫缺陷难以说清
遵守软件缺陷定义规则，有助于澄清什么样的缺陷才算缺陷这个问题。注意：尚未发现或未观察到的缺陷只能说是潜在缺陷。
8、产品说明书从没有最终版本
测试员必须想到产品说明书可能改变。未曾计划测试的功能会增加，经过测试并报告缺陷的功能可能发生变化甚至被删除。
9、软件测试员在产品小组不受欢迎
测试员的工作是检查和批评同事的工作、挑毛病、公布发现的问题。下面是保持小组成员和睦的建议：
- 早点找出缺陷。在三个月之前而不是在产品即将发布前夕找出严重的缺陷，会产生更小的影响，更容易让人接受。
- 控制情绪。测试员喜爱自己的工作，发现严重的缺陷时很兴奋。但是，如果兴冲冲地跑到开发面前告诉他代码中存在缺陷，他是不会高兴的。
- 不要总是报告坏消息。加入发现某段代码没有缺陷，就大声宣扬。花一点时间找程序员聊聊天。
10、软件测试是一项讲究调理的技术专业
不少计算机游戏和短期开发项目公司依然采用相当松散的开发模式--大爆炸模式或边写边改模式。但是大多数软件都采用井然有序的方式开发，把测试员当做必不可少的核心小组成员。现在软件测试成为一个职业选择--需要训练和规范，而且有发展空间。
2、软件测试的术语和定义
1、精确和准确
软件测试要精度还是准度很大程度上取决于产品是什么，最终取决于开发小组的目标。计算器软件需要两者都达到，正确答案就是正确的，错误的就是错误的。但是，可能会决定计算只精确到5位十进制数，那么，精度可以有所偏差。下图演示了精确和准确之间的区别：
2、确认和验证
确认时保证软件符合铲平说明数的过程；验证时保证软件满足用户要求的过程。
3、质量和可靠性
如果说软件产品质量高，是指它能够满足客户要求。客户会感到该产品性能卓越，由于其他产品。
软件使用者心中的质量可能包括：软件功能的多少、在自己的旧PC上运行的能力、软件公司的服务电话好不好打，以及软件的价格。产品的可靠性或者产品多长时间崩溃的问题，也许重要，但常常不被考虑到。
测试员常常会错误地以为质量和可靠性是一回事。他们认为如果测试程序一直稳定、可靠，就可以认定这是高质量的产品，但这不完全正确，可靠性仅仅是质量的一方面。为了确保程序质量高而且可靠性强，软件测试员必须在整个开发过程中进行确认和验证。
4、测试和质量保证（QA）
软件测试员的目标时尽可能早地找出软件缺陷，并确保缺陷得以修复。
软件质量保证人员的主要职责时创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法。
当然，他们存在一些交叉之处。软件测试员会做一些QA工作，QA人员会进行一些测试，双方的工作和任务是交织在一起的。重要的是了解自己的工作职责，并与开发小组的其他成员交流。小组成员如果搞不清楚谁再做测试，谁不做测试的话，将会在许多项目中造成不少麻烦。
3、测验
1、假定无法完全测试某一程序，在决定是否应该停止测试时要考虑哪些问题？
终止测试没有一定的时间，每一个项目都会有所不同。决定时需要考虑的因素有：仍然会发现大量软件缺陷？软件小组对已执行的测试满意吗？报告的软件缺陷是否经过评估定下来哪些修复，哪些不修复？产品按照客户的要求验证了吗？
2、windows计算机程序，输入5,000-5=0（逗号被自动转换未小数点），这是软件缺陷吗？为什么？
要确定这是否是软件缺陷，就需要根据产品说明书进行合法性检查，也许在产品说明书上声明逗号会被转换为小数点。还要对用户需求进行验证，看大多数用户是接受这点，还是产品迷惑。
3、假如测试模拟飞行或模拟城市之类的模拟游戏，精确度和准确度哪一个更值得测试？
模拟游戏的目的是使游戏者置身于与现实情形接近的虚构环境中。在模拟器中飞行应该感觉想在真飞机上一样。城市模拟就应该反映真实城市的各种情况。最重要的是如何精确地模拟实际情形。飞机像是波音757一样还是像一只小鸟一样飞行？城市航线与实际路线相仿吗？软件有了准确性，才能逃到精确。这是关心建筑物中的窗户位置是否准确以及飞机的移动是否与游戏杆操作完全协调的第一点。
4、有没有质量很高但可靠性很差的产品？举例说明。
有可能，但它取决于客户对质量的期望。不少人购买高性能跑车，认为提速、时速、式样、舒适度和装饰好就是高质量。此类汽车一般可靠性交叉，经常抛锚、修理费用昂贵，而车主不把可靠性当作严重的质量问题。
5、为什么不可能完全测试程序？
除了极短小的简单程序，完全测试需要太多输入、输出和分支组合。此外，软件说明书也许不客观，可以用多种方式解释。
6、假如周一测试软件的某一功能，每小时发现一个新的软件缺陷，你认为周二将会以什么样的频率发现软件缺陷？
这里有两个基本要素。首先，余下的软件缺陷与发现的软件缺陷成比例，意味着周二不会比周一的情况好多少。其次，杀虫剂现象表明，除非增加新的测试，否则反复执行同样的测试，不会发现不同的新软件缺陷。综合这两个软件要素，可能发现软件缺陷的速度继续保持原有频率，甚至更低。