软件测试理论与经验--阅读笔记
Posted 斜杠方子
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试理论与经验--阅读笔记相关的知识，希望对你有一定的参考价值。
第1章 测试员的角色
测试人员的角色到底是什么？能够定义的很清楚吗？
经验1-测试员是项目的前灯
测试就是要找到信息，有关项目或者产品的关键信息决策都需要根据这些信息来决定。
经验2-测试员的使命决定要做的一切
使命可能决定于行业、公司、项目或者团队的个性，测试项目也是千差万别。我们的使命是以客户为中心，
明确需求，提高工作效率及降低风险。要经常动态调整自己的使命，不要侧重某一方面而疏忽另一方面。
经验3-测试员为很多客户服务
测试员提供的服务时至关重要的，客户可以是项目经理、程序员、技术文档编写员、技术支持员、市场开发员、
产品经理、管理层和项目相关人员、用户等；
经验4-测试员发现的信息会“打扰”客户
根据客户的价值定义，通知客户有关威胁产品价值的任何信息。测试员有责任报告相关问题。
经验5-迅速找出重要的程序问题
测试员不仅要找出问题，还需要快速的找出问题。需要对问题进行分类分级考虑：
首先测试经过变更的部分，然后测试没有变化的部分；首先测试核心功能，然后测试辅助功能；
首先测试能力，然后测试可靠性；首先测试常见情况，然后测试少见情况；首先测试常见
威胁，然后测试罕见威胁；首先测试影响大的问题，然后测试影响小的问题；首先测试最需要的部分，
然后测试没有要求的部分；
经验6-跟着程序员走
为程序员提供支持，很可能是测试员使命的关键部分。及时反馈程序情况，马上测试程序，修改代码后
及时测试等，尽快建立最短、最快的反馈闭环。理想的情况是，程序员为了修改测试员找出的程序问题忙的
团团转，使程序员，而不是测试员，成为项目的瓶劲。
经验7-询问一些，但不一定外露
经常提问问题，方式要含蓄，内在些，有助于启发自己的思考，利于测试；
经验8-测试员关注失效，客户才能关注成功
测试员关注失效，因为这可以增加发现失效的机会，用自己全部的创造力和技能，寻找产品中的关键问题。
发现问题，使产品做的更好，更具持续性，在市场中才可能成功。
经验9-不会发现所有问题
找出并报告重要的程序问题，但是不会发现所有的程序问题。
经验10-当心“完备的”测试
不要有完备、完成、结束等，完备的定义并不是在项目一开始就能够最终确定的，随着测试项目的进展，随着
新测试任务的突然出现，需要重新考虑。
经验11-通过测试不能保证质量
测试员既不能提高质量，也不能降低质量。质量来源于构建产品的人，测试不过是提供了项目质量保证的信息。
经验12-永远别做看门人
测试员永远不要对产品的发布具有否决权，获得这种权利之后，同时也承担了产品质量的全部责任，其他人倒是
可以轻松些。要由控制项目，条件最好的人承担发布的责任。大多数非常有效的团队，都采用某种方式的集体决定
是否发布产品；
经验13-当心测试中的不关我事理论
测试员的使命应该是尽其所能，通知团队可能会对产品的价值产生消极影响的所有问题。
经验14-当心称为过程改进小组
如果过程改进是整个团队的工作，则测试员可以成功的参与工作，并获得成功。
经验15-别指望任何人会理解测试，或理解测试员什么条件下才能搞好测试
测试员要受管理层和程序员决策的很大影响，如果他们的计划很不明确，或设计出的产品很难测试，
测试工作就会很难进行。他们不理解自己的行动会对测试过程产生的影响。
第2章-按测试员的方式思考
测试员并不抱怨，他们提供的是证据，测试员并不喜欢征服，他们喜欢打破产品没有问题的幻觉。
按测试员的方式思考意味着实践认识论。测试员的大脑是仔细调谐的推理机器，用精神力量做好事。
经验16-测试运用的是认识论
认识论研究如何认识所了解的东西，怎么知道软件足够好？如果软件并不是足够好，怎么才能知道？
怎么知道已经完成了足够的测试？
经验17-研究认识论有助于更好测试
研究认识论可帮助测试员设计有效的测试策略，更好的意识到自己工作中的错误，理解自己的测试
能够证明什么，不能证明什么，并编写出无懈可击的测试报告。
经验18-认知心理学是测试的基础
研究认知心理学有助于影响测试员工作成绩的因素，以及影响人们解释自己工作方式的因素。
经验19-测试在测试员的头脑中
优秀测试和平庸测试之间的差别在于测试员如何思考：测试设计的选择，解释观察的现象，分析描述现象的能力
经验20-测试需要推断，并不只是做输出与预期结果的比较
测试不是简单的比较活动，聪明人必须设计测试，并确定预期输出。大多数的测试设计都是基于推断，掌握
探索式推断的艺术。意味着要以一种不能实现预测的方式，通过一种思想引出另一种思想，然后再引出下一种
思想。
经验21-优秀测试员会进行技术性、创造性、批判性和实用性的思考
技术性思考，包括相关技术事实和实用工具并预测系统行为的能力；
创造性思考，产生思想并看到可能性的能力；
批判性思考，评估思想并进行推断的能力；
实用性思考，想法付诸实施的能力；
经验22-黑盒测试并不是基于无知的测试
黑盒测试强调的是有关软件的用户和环境知识，测试员对产品了解的
越多，了解产品的方式越多，越能够更好的测试。
经验23-测试员不只是游客
测试员可以浏览产品，看看产品是由什么组成，怎么工作，这样做很有价值。
经验24-所有测试都试图回答某些问题
所有测试，都要回答有关现实的产品和应该得到的产品之间的关系的某个问题。
主动去发现问题，一切可能导致现实产品与应该产品之间差距的问题都应该
注意，并主动推动自己评估测试策略。
经验25-所有测试都基于模型
测试都主要基于模型进行，模型要足够清晰、完整。学会一种对产品建模的新方法，
就像是学会了观察产品的一种新方法。
测试员对建模艺术越精通，越能够更好地测试。
经验26-直觉是不错的开始，但又是糟糕的结束
直觉可以用作指南，但不能用作合理性证明。
经验27-为了测试，必须探索
即使充分研究了产品，对产品有了很深的了解，仍然要探索问题。因为所有测试都是
采样，而且样本必须也不可能完备，探索式思考要在整个测试项目过程中，在寻求
最大化测试价值时起作用。所谓的探索，是指由目的的漫游：带着一般使命在某个空间
中漫游，但没有预先确定的路线。
经验28-探索要求大量思索
探索就是侦察，是没有边界的搜索，可以把探索看做是在太空中遨游，需要前向、后向
和侧向思索。
经验29-使用诱导推断逻辑发现推测
诱导推断又叫做假设归纳。最佳解释的推理。
经验30-使用猜想与反驳逻辑评估产品
虽然我们不能证明猜想是真，缺可以证明猜想是假的。
以下三种重要的方式应用于测试：
测试的目的是显示产品失效，要比显示正常更有力；有关软件已经形成的信念应该受到
质疑；警惕声称以超过测试员所运行的具体测试的方法，检验或确认了产品的测试。
经验31-需求是需要人物所关心的质量或条件
至于测试，产品应该具备或者满足的任何质量或条件都是需求。
经验32-通过会议、推导和参考发现需求
测试员把项目文档看作是唯一需求来源会影响其测试过程，需求信息到达测试员主要有
三种途径：会议，推导，参照；很多项目中，优秀的测试员使用的大多数需求要么来自推导
，要么来自隐士规格说明的参照。搜寻测试所需的信息，是测试员的工作。
经验33-既要使用显式规格说明，也要使用隐式规格说明
并不是包含测试所依赖重要信息的所有参照都是显式地提供给测试员的.
显式规格说明是一个有用的信息来源，经过客户的权威确认；
隐式规格说明是没有经过客户权威确认的一个有用的需求信息源。
隐式规格说明包括竞争对手的产品、相关产品、同一产品的老版本、项目团队之间的电子邮件
、顾客意见、杂志文章、相关主题的教科书、图形用户界面风格指南、操作系统兼容性需求、
测试员自己的丰富经验；
客户相信测试员能够使用所需的各种参考资料快速找出重要的问题。
经验34-“它没有问题”真正含义是它看起来在一定程度上满足部分需求
经验35-最后，测试员所能得到的只是对产品的印象
任何时候报告产品质量状态时，都应该用有关测试方法和测试过程的已知局限性
的信息，对报告进行限定。
经验36-不要将试验与测试混淆起来
测试是任何至少包含以下四种活动的活动：配置，运行，观察，评估；试验可能有很多种形式，
要关注执行这些活动的思考者，关注试验是否很好的完成了预想的策略和测试使命。
经验37-当测试复杂产品时，陷入与退出
当测试复杂和使人畏惧的功能集合时，可间歇进行，经过几个轮次的陷入与退出，就会开始明白产品
的模式和轮廓，很快就会在头脑中更系统、更具体的测试和研究策略。
经验38-运用试探法快速产生测试思路
可能的测试用例数量是无限的，选出面临的时间和预算约束条件下有效的少量测试用例，一组好的
试探方法有助于测试很快的生成。
测试边界，测试所有错误消息，测试与程序员的配置不同的配置，运行比较难设置的测试，避免冗余测试；
试探法所能够做的，是为了测试员的思考提出建议。
经验39-测试员不能避免偏向，但是可以管理偏向
多样化可以抵御过强的偏向，如果测试员集体谈论测试问题，可以将一个测试员的偏向降低到最低。
经验40-如果自己知道自己不聪明，就更难被愚弄
任何时候都要注意其他测试员所发现的自己本来也可以但是没有发现的问题。测试时谨慎一点，考虑
测试策略时认真一点。
经验41-如果遗漏一个问题，检查这种遗漏是意外还是策略的必然结果
出现问题，先检查下测试的策略是否出现了问题，是否因为忠实地执行了好的策略，只是碰巧没有
发现那个特定的问题，可以保持原来的方针不变。如果是遗漏程序错误是因为测试策略关注了
错的问题类型，可利用这个机会改进测试策略。
经验42-困惑是一种测试工具
规格说明不清楚吗？产品不清楚吗？用户文档不清楚吗？内部问题难以理解吗？测试员对产品、技术和
一般测试问题了解的越多，自己的困惑就会成为更有的指南针，指出重要问题所在。
经验43-清新的眼光会发现失效
测试员在理解了产品或功能部件之后，会在头脑中形成映射，并且头脑不再那么努力工作。对于测试员
来说这可能是个问题。
经验44-测试员要避免遵循过程，除非过程先跟随自己
一般来说，测试过程的编写和设计都比较差。
经验45-在创建测试过程时，避免“1287”
过于详细没有什么好处，当编写测试用例时，要避免与测试概念无关的细化。要让未来的测试员有创造性
和判断力地执行。让未来的测试员引入变化以使现在所编写的测试过程新鲜，高效。
经验46-测试过程的一个重要成果，是更好，更聪明的测试员
好的测试员永远都在学习，不断加深对产品的了解，提高对产品的反应能力和敏感性。
经验47-除非重新发明测试，否则不能精通测试
不要把自己限制为只是接受智慧的服务者，而应该使自己成为智慧的创造者。永远使头脑运转，观察
其它测试员，研究和不断评估如何筛选自己的思想，如果想善于做到这一点，就必须实践。
第3章 测试手段
本章的观点基本是结构化的，介绍其余内容的分类系统；本章不讨论主要如何使用手段，但是会足够详细
描述一些实际使用的手段。
经验48-关注测试员、覆盖率、潜在问题、活动和评估的组合测试手段
五要素测试系统：测试员（进行测试的人），覆盖率（测试那些内容），潜在问题（测试原因、风险等），
活动（如何测试），评估（怎么判定过还是不过）。
所有测试都包括所有这五个要素。 谁测试？测什么？怎么测？测试问题？怎么判定？
经验49-关注测试员的基于人员的测试手段
用户测试：由将使用该产品的典型人员进行输入的测试；
a测试：测试小组执行的内部测试；
b测试：产品目标市场成员的测试员实施的用户测试；将客户试用代码看做是b测试；
强力测试：利用秘书、程序员、市场开发人员和任何人所实施的测试；
有关领域的专家测试：
成对测试：两个测试员在一起发现程序错误；
自用测试：全公司使用试用版软件；
经验50-关注测试内容的基于覆盖率的测试手段
可以根据在使用这些手段时已经掌握知识的不同，把这些手段按照所关注的问题进行多种
不同的分类；
1、功能测试：逐个测试每个功能，在做涉及多个功能的更复杂的测试之前，最好先做功能测试。
特性或功能集成测试：一起测试多个功能，以检查功能一起执行的情况
2、菜单浏览：遍历GUI产品的所有菜单和对话框，使用每个可用的选项。
3、域测试：包含所有可能的函数变量取值。进行域测试时必须分析变量，然后再根据分析，以
这个变量作为输入或输出，测试涉及这个变量的每个功能。
4、等价类分析：认为等价的一组变量取值；如果相信一组测试用例“测试的都是相同的东西”
“如果其中一个有问题，其它测试也可能有问题”“如果一个没有问题，其它测试可能也没有问题”
5、边界测试：如果把成员映射到一组数字上，则边界值就是类的最小和最大值；
6、最佳代表测试：
7、输入字段测试大纲或矩阵：开发一组相当标准的测试用例。
8、用各种方式映射和测试编辑字段
9、逻辑测试：变量在程序中的关系
10、基于状态的测试：程序的状态要发生转换；
11、路径测试：
12、语句与分支覆盖率：
13、配置覆盖率：配置计划占计划运行的配置测试总数的百分比
14、基于规格说明的测试：常常包括手册、市场开发文档或广告等；
15、基于需求的测试：满足需求文档中的所有需求；
16、组合测试：相互组合测试两个或更多变量。通过程序得到的大部分好处都是
基于很多变量的交互，如果不在测试中一起改变这些变量，就会遗漏由不同的
组合触发的错误。
经验51-关注测试原因（针对风险）的基于问题的测试手段
基于风险的测试至少有两个主要含义：进行风险分析是为了确定下一步要做的测试；
为了显现错误进行风险分析；
输入约束、输出约束、计算约束、存储约束
经验52-关注测试方法的基于活动的测试手段
回归测试：软件变更后重新执行；共有三种回归测试，分别为程序错误更正回归（程序更正有误）；
老程序错误回归（老程序错误更正变为未更正）；副作用回归测试（未曾发生的问题发生了）；
脚本测试：手工测试；
冒烟测试：冒烟测试常常是自动化、标准的。检查预期没有问题的东西。
探索式测试：整个测试过程中，都要了解产品、产品的市场、产品的风险和怎样没有通过以前的测试。
不断创建并使用新测试。新测试比老测试更有力，因为新测试是建立在测试员持续增长的知识基础上的。
游击式测试：快速、有力的攻击。是一种探索式测试，通常有时间限制。
场景测试：四个属性，分别如下：测试必须是现实的，反映实际做的事；复合的测试，有一定挑战的包含
多个功能；容易并且快速的显示是否通过测试；未通过测试，强烈要求修改程序。
场景测试：用例到处的测试，叫用例流试验或者测试试验
安装测试：各种方式，在可以安装该软件的不同类型系统上安装该软件。
负载测试：通过在面临很多资源要求的系统上运行，攻击被测程序或系统。高负荷情况下，可能失效。
长序列测试：一天，几天，几周，目标是发现短序列测试遗漏的问题。经常发现的错误包括越界指针，内存泄漏、
栈溢出、超过两个特性之间的错误交互等。
性能测试：
经验53-关注测试是否通过的基于评估的测试手段
如果能够采集到一定的数据该如何评估；
自校验数据：使用的数据文件带有使测试员能够确定输出数据是否被破坏的信息；
与已保存的结果进行比较：回归测试是否通过，将当前的结果与之前的结果进行对比，如果以前的结果是正确的，
现在的有所不同，这种差别可能就是新缺陷的表现。
与规格说明或其它权威文档比较：不符合规格说明的都可能是错误；
启发式一致性：一致性是评估程序的重要评判准则。七种主要的一致性，如下：与历史一致；与我们的想象一致；与
可比较的产品一致；与所声明的内容一致；与用户的预期一致；产品内部一致；与用途一致；
基于理念的测试：理念是一种评估工具，理念一般比被测软件更可信赖，因此值得花时间和精力检查理念所给出的提示。
经验54-根据自己的看法对测试手段分类
不管怎么样对测试手段分类，在实际进行测试时，仍然需要在五个要素方面进行决策。
测试手段附录
如何针对输入字段创建测试矩阵？
简单字段例程的，如不输入、清空字段、超出上限位数或字符数的数字或字符、0、有效值、下限值-1、下限值、上限值、
上限值+1、远远低于下限值、远远高于上限值、下限位数或字符数的数字或字符、下限位数或字符数的数字或字符-1、
上限位数或字符数的数字或字符、上限位数或字符数的数字或字符+1；远远高于上限位数或字符数的数字或字符、负数、
非数字、错误的数据类型、表达式、在其它数据前加一个空格、在其它数据前加很多空格、在其它数据前加一个0、在
其它数据前加很多0、在其它数据前加一个+号、在其它数据前加很多+号、非打印字符（如Ctrl+C）、操作系统文件名保留
字符（如\*.;）、程序设计语言保留的字符、ASCII上半区字符、ASCII255、大写字符、小写字符、修饰键（如Ctrl、Alt）、
功能键（如F2、F3）、不输入-等待-回车/制表键、输入一个数字-等待-回车、输入多个数字并使用删除键编辑-再删除-插入/覆盖、
响应不同类型的中断时（如打印机活动、鼠标移动、文件存盘等）输入数字、输入一个数字-切换到另一个应用-再返回应用；
上述列表叫做测试大纲，将列表转换为矩阵形式很有用；
如何针对重复问题创建测试矩阵？
字段只是有用矩阵中的一个例子，只要某种情况在项目内部和项目之间反复出现，都要花时间和精力制定一个测试大纲的基础。
例子中，大纲尝试把文件写入磁盘的各种失败方式：保存新文件、覆盖同名文件、在结尾处续接文件、用同名文件的新版本取代
正在编辑的文件；转换到另一种文件格式；打印内容存盘、消息或错误日志存盘、保存临时文件等；
为了创建类似大纲，建议至少要召开两次有同时参加的集体讨论；
如何使用全对偶测试手段进行组合测试？
组合测试要求一起测试多个变量。压缩测试数量是一个关键问题。
从域划分开始，选出子域内最好的代表值；5*5*5=125
获得全单值，5（取1）*5（取1）*5（取1）=5，常用于配置测试中，严重问题是会遗漏可预知的重要配置。额外关键配置；
获得全对偶，5*5*5（取1）=25
如何分析与程序的某个部分或方面关联的风险？
质量属性，包括可获得性、能力、兼容性、并发性、标准符合性、可安装和可卸载性、可本地化、可维护性、性能、可移植性、
可恢复性、可靠性、可伸缩性、安全性、可支持性、可测试性、可使用性；为了确定某个特征是否有缺陷，可以问自己如何证明它没有
或与这些属性冲突。
问题起因，这些因素中的每一个看做是或大或小警告，并设计测试，以确定程序是否有这些因素所提示的脆弱性。
新功能、新技术、新市场、学习曲线、变更后的功能、后期变更、贸然的工作、差的设计或没有可维护性的实现、疲倦的程序员、其他
人员问题、意外溜入、外来品、预算外、模糊、矛盾的需求、未知需求、需求变化、复杂性、问题很多、依赖性、不可测试性、没有什么
单元测试、到目前为止没有什么系统测试、依赖狭窄的测试策略、弱的测试工具、不可修改性、程序设计语言类型错误、使用错误大纲、
第4章：程序错误分析
测试员要了解如何编写和表达自己的测试结果，以便读者能够真正得到结果。这个过程叫做“程序错误分析”。
经验55-文如其人
错误报告是大多数测试员的主要工作产品。报告写的越好，测试员的声誉越高。
经验56-测试员的程序错误分析会推动改正所报告的错误
测试员的责任不是保证所有错误都得到改正，而是准确报告问题，使读者能够理解问题的影响。深入研究并
写出好的报告，常常对错误改正的可能性产生巨大的影响。
经验57-使自己的错误报告成为一种有效的销售工具
错误报告都是一种推销工具，通过改正这个具体错误而带来质量改进。
销售策略一般包括两个目标：陈述种种好处，使得潜在客户想要它；向销售人员说明预期存在问题，并反驳他们。
经验58-错误报告代表的是测试员
经验59-努力使错误报告有更多的价值
丰富每个错误报告的信息，提高报告的可理解性。
经验60-产品的任何项目相关人员都应该能够报告程序错误
产品的项目相关人员是对产品的成功有既定利益的人，可以是公司员工，也可以是客户或用户。
经验61-引用别人的错误报告时要小心
经验62-将质量问题作为错误报告
对产品感到失望，感到产品不那么有价值，那么应该作为错误报告写出来。
经验63-有些产品的项目相关人员不能报告程序错误，测试员就是他们的代理
经验64-将受到影响的项目相关人员的注意力转移到有争议的程序错误上
写入错误报告，以引起其预算会受到这个程序错误影响的人的注意。
经验65-决不要利用程序错误跟踪系统监视程序员的表现
经验66-决不要利用程序错误奖励测试员
经验67-及时报告缺陷
经验68-永远不要假设明显的程序错误已经写入报告
经验69-报告设计错误
当发现设计问题时必须报告，很多设计问题要到系统几乎完成时才会被发现。
经验70-看似极端的缺陷是潜在的安全漏洞
经验71-使冷僻用例不冷僻
为了提高效率，常常要用到极值，测试员所发现的第一个错误常常是在边界处。
经验72-小缺陷也值得报告和修改
低成本修改（小缺陷）可以避免该产品一半以上的技术支持电话。一般性的修改对
客户满意度有重要影响。小缺陷数量增加后，客户信心会下降，测试员及公司就会容忍
越来越多的严重缺陷。
经验73-时刻明确严重等级和优先等级之间的差别
严重等级表示程序错误的影响或后果，优先等级表示什么时候要求修改错误；
经验74-失效是错误征兆，不是错误本身
当看到失效时，缺陷可能很小，但是内部问题可能会严重得多。因此，任何时候看到
看起来很小的错误，都要：执行后续测试，以发现更多严重征兆；以发现更宽范围并且
会被很多人看到；以确定使得该问题重现的关键条件，充分暴露可能问题。
经验75-针对看起来很小的代码错误执行后续测试
建议三种后续测试，变化自己的行为；变化程序选项和设置；变化软件和硬件环境；
经验76-永远都要报告不可重现的错误，这样的错误可能是时间炸弹
经验77-不可重现程序错误是可重现的
程序错误要在特定条件下出现。有助于思考的条件例子；
经验78-注意错误报告的处理成本
在判断报告的内容和如何报告上做一点讨论，错误报告有处理成本。
经验79-特别处理与工具或环境有关的程序错误
已知弱点，而造成程序失效，失效完全在程序猿控制之外，决定不报告
这样的程序错误是合理的。
经验80-在报告原型或早期个人版本的程序错误之前，要先征得同意
有时候程序员会给测试员一个个人版本，并要求进行单独测试。
经验81-重复错误报告是能够自我解决的问题
经验82-每个程序错误都需要单独的报告
经验83-归纳行是错误报告中的最重要的部分
归纳行是向这些经理推销程序错误的最佳工具；好的归纳应该包含：简要描述、
简要指出程序错误的局限性或依赖关系、简要指出程序错误的影响或后果。
挑选对于报告最重要的信息，把其它内容放入报告的信息描述部分
经验84-不要夸大程序错误
测试员的可信性是影响力的基础；
经验85-清楚的报告问题，但不要试图解决问题
测试员的工作是报告问题，而不是确定根源，不是奋力争取具体的解决方案。决定
适用于特定程序错误的解决方案时产品设计师的事；很多测试员对提出的解决方案
太感兴趣，以至于没有提供有关失效本身的清晰、准确的信息。
经验86-注意自己的语气，所批评的每个人都会看到报告
错误的报告带有责备或居高临下的语气是没有益处的。
经验87-使自己的报告具有可读性，即使对象是劳累和暴躁的人
经验88-提高报告撰写技能
经验89-如果合适，使用市场开发或技术支持数据
自己产品表现与竞争对手对比，在与客户接触时遇到的问题，与技术支持人员合作；
经验90-相互评审错误报告
核查关键信息；是否可复现；简化、概括或加强；
核查所有缺陷、自己发现的缺陷、同事发现的缺陷；
注意不要过多的增加评审测试员的负担，评审过程需要时间。
经验91-与将阅读错误报告的程序员见面
经验92-最好的方法可能是向程序员演示所发现的错误程序
经验93-当程序员说问题已经解决时，要检查是否真的没有问题了
在略有不同的环境下可能还会发现它失效。应该进行后续测试，以保证不会出现。
经验94-尽快检验程序错误修改
当测试员被告知所报告的程序错误被清除时，要尽可能迅速地检验。测试员等待的时间
越长，程序员所记得的内容越少；
经验95-如果修改出现问题，应与程序员沟通；
经验96-错误报告应由测试员封存
除非经过测试员的评审和封存，否则任何程序错误都不能标示为已封存。
经验97-不要坚持要求修改所有程序错误，要量力而行
最重要理由之一就是风险；另一个是客户不愿意为修改付费；
经验98-不要让延迟修改的程序错误消失
经验99-测试惰性不能成为程序错误修改推迟的原因
如果测试经理要求程序员不要修改程序错误，只因为修改会影响太多的检查单、脚本或其它
测试工作制品，因此要占用太多的管理时间，说明测试过程存在很大的缺陷；
经验100-立即对程序错误延迟决定上诉
经验101-如果决定据理力争，就一定要赢
所做的每个上诉都是有说服力的。
第5章 测试自动化
使一部分测试工作自动化可能有帮助，也可能没有帮助，自动化可以节省时间，加快开发，拓展测试员的能力，
并使测试更有效；自动化也可以分散测试员的注意力，并浪费资源。
如果自动化能促进测试使命的完成，就利用自动化，评估利用自动化是否成功的标准，是看它在多大程度上
帮助测试员完成自己的使命。
在决定要自动化的内容时，首先设计自己的测试；
采用与设计手工测试不同的方法设计自动化测试；
两条重要的经验：
没有好的测试设计的自动化可能会产生大量活动，但没有什么价值。
没有很好理解自动化可能性的测试设计，可能会低估一些最有价值的自动化机会。
经验102-加快开发过程，而不是试图在测试上省钱
目标是降低测试成本的自动化工作，很少能够得到为了获得成功所需要的关注和合作。
最成功的公司通过自动化测试实现其开发灵活性，他们的自动化测试部分目标是：
迅速检测出新版本中的不稳定的变更；
尽可能迅速暴露回归程序错误；
快速报告问题，因为这会使程序错误修改更容易；
支持开发节奏的手段的两个例子：
1、自动化冒烟测试；冒烟测试又叫版本确认测试；
2、自动化单元测试；这些测试也会使测试过程流畅、避免回退，并保持开发动力。
单元测试可能要程序员创建。
经验103-拓展测试领域，不要不断重复相同的测试
以下是几个例子：负载测试；性能基准测试；配置测试；耐力测试；竞争条件；
组合错误；
经验104-根据自己的背景选择自动化测试策略
测试需求：往往只有少量功能是关键的，这些功能必须可靠，可能要求值得将其自动化的
大量测试。另外，测试员也可以关注自动化测试能够如何帮助控制产品的主要风险。
软件产品体系结构；
测试人员技能；
经验105-不要强求100%的自动化
经验106-测试工具并不是策略
经验107-不要通过自动化使无序情况更严重
经验108-不要把手工测试与自动化测试等同起来
不要拿手工测试与自动化测试相比，而应该把自动化测试看做是对测试员
能力的扩充，能够完成手工测试所不能完成的工作。
经验109-不要根据测试运行的频率来估计测试的价值
测试本身是不可比较的；比较自动化测试的运行成本；
经验110-自动化的回归测试发现少部分程序错误
非正式调查显示，由自动化测试发现的程序错误百分比令人惊讶地低；
自动回归测试在测试开发阶段发现的程序错误比以后执行测试时多。
老功能的新测试也与老测试一样可能发现回归程序错误，并且增加了发现以前
没有发现过的程序错误的优势。
经验111-在自动化测试时考虑什么样的程序错误没有发现
经验112-差的自动化测试的问题是没有人注意
测试可能并不完成所想象的工作；
测试可能已不再重要；
覆盖率可能很差；
虚警可能很常见；
测试结果可能有错；
经验113-捕获回放失败
最流行的测试工具包括各种记录器。
要在构建能够持久或手工测试结合的自动化测试的技能和规划上投入，与
捕获回放相比，这两种测试通常更高效，更有效。
经验114-测试工具也有程序错误
测试工具常常程序错误更多。要计划测试工具，并花时间找出解决程序错误的方法。
有时测试工具会受其他组件中的程序错误的影响。
有些工具可能会对正在测试的产品产生很大的影响。
经验115-用户界面变更
要抽象测试自动化设计的界面。当用户界面变更时，只需升级抽象层，而不是升级访问修改后
界面的所有测试。
产品GUI抽象的一些手段：窗口映射；数据驱动的自动化测试；任务库；关键词驱动的自动化测试；
基于API的自动化测试；
经验116-根据兼容性、熟悉程度和服务选择GUI测试工具
经验117-自动回归测试消亡
自动回归测试所面临的最大问题是退化和过早消亡，
经验118-测试自动化是一种软件开发过程
经验119-测试自动化是一种重要投资
自动化测试需要时间和成本。
经验120-测试自动化项目需要程序设计、测试和项目管理方面的技能
测试：自动化测试的目标、用途，怎么发现程序错误、发现什么错误、需要理解产品
的用户领域吗？
编程：测试自动化就是编程，测试自动化并不容易，不遵循软件工程原则是不会成功的。
项目管理：如果不重视管理，自动化项目就可能不会实际达到最初预想的目标。
经验121-通过试点验证可行性
试点有助于展示测试小组的能力，使保证得到全面实施测试自动化的成功所需的资源和
协作更容易一些。
经验122-请测试员和程序员参与测试自动化项目
产品测试员：定义自动化需求、检验自动化可用性、可理解性和可信赖性。
产品程序员：是软件开发专家，评审自动化测试的体系结构。可评审行、可维护性、完整性；
经验123-设计自动化测试以推动评审
1、测试自动化针对自动化测试的代码；
2、评审测试代码；
经验124-在自动化测试设计上不要吝啬
经验125-避免在测试脚本中使用复杂逻辑
使测试线性化有助于关注测试的目的，而不是自动支持。
经验126-不要只是为了避免重复编码而构建代码库
如果把所看到的重复代码都另行存放，最终会得到一种杂烩库。测试自动化
有很多重复代码，有用的库应该遵循更强的设计原则，而不只是为了避免重复编码。
经验127-数据驱动的自动化测试更便于运行大量测试变种
为了通过相同的测试过程测试不同的输入和输入组合，可利用数据驱动的自动化测试。
将测试输入和预期输出组织为表，表中的一行对应一个测试，然后创建一个从表中逐行
读入的自动化测试过程，执行每个输入步骤，并检验预期结果。
经验128-关键词驱动的自动化测试更便于非程序员创建测试
关键词驱动的自动化测试建立在数据驱动手段上，但是表中包含指令，而不只是数据。
首先，这种方法要求既支持运行测试，又支持设置库、结果分析和报告的一般框架。
其次，必须创建一个任务库，封装由被测产品的支持的用户任务。
最后，增加对读取电子表格数据的支持，每次读入一行。
通常便于非程序员的创建和评审，测试员可以将注意力集中到测试，而不是控制语言上。
经验129-利用自动化手段生产测试输入
创建大文件、创建大量测试输入、设置测试床、创建随机数据、覆盖所有输入组合、
减少所需的测试用例，或者可以描述预期结果。
覆盖等价类的所有代表对偶（如果测试所有关键等价类成员的成对组合，可发现大多数交互程序错误）；
覆盖逻辑条件中的交互（如果变量不独立，就不能使用类似的全对偶组合测试手段，因果图是一种更
健壮的方法）；
通过状态模型创建测试场景；
经验130-将测试生成与测试执行分开
将执行代码与测试数据分开的一种策略是数据驱动的自动化测试，这种分离有利于测试生成，有如下优点：
测试易于理解和评审；
可以使用不同的工具或程序设计环境生成和执行测试；
独立的测试用例生成器比较容易测试；
如果预先生成数据，则更容易重复测试；
报告所发现的程序错误更容易；
不同的测试专业人员会各自关注自动化测试的不同方面；
经验131-使用标准脚本语言
经验132-利用编程接口自动化测试
编程接口更可能提供稳定性，而且还有利于错误检测和隔离。
经验133-鼓励开发单元测试包
单元测试：程序员所创建的函数、类和方法；
经验134-小心使用不理解测试的测试自动化设计人员
经验135-避免使用不尊重测试的测试自动化设计人员
经验136-可测试性往往是比测试自动化更好的投资
驻留在产品内部提供控制或可视性的测试代码；
经验137-可测试性是可视性和控制
访问源代码；日志；诊断；错误模拟；测试点；事件触发器；读入老的数据格式；
测试接口；定制控制支持；允许多实例；
经验138-尽早启动测试自动化
经验139-为集中式测试自动化小组明确章程
经验140-测试自动化要立即见效
系统配置与准备；辅助诊断；会话记录；测试生成；
经验141-测试员拥有的测试工具会比所意识到的多
第六章-测试文档
文档是形式化测试过程的一个重要组成部分，IEEE软件测试文档标准829提供了一种很好的测试
文档描述，以及测试文档相互之间和测试过程之间关系的描述。
经验142-为了有效地应用解决方案，需要清楚地理解问题
经验143-不要使用测试文档模板，除非可以脱离模板，否则模板就没有用
经验144-使用测试文档模板：模板能够促进一致的沟通
经验145-使用IEEE标准829作为测试文档
经验146-不要使用IEEE标准829
经验147-在决定要构建的产品之前先分析需求，这一点既适用于软件也同样适用于文档
决定什么内容要包含到测试文档中，什么内容不包含，应该以项目需求为基础。
经验148-为了分析测试文档需求，可采用类似以下给出的问题清单进行调查
测试小组的使命是什么，测试这个产品的目标是什么？文档无太多用处的话，则没有价值。
自己的测试文档是产品还是工具？文档是产品一部分的话，则需要付费。
软件质量是受法律问题驱动还是受市场驱动？如果需要管理审查，则需要文档；
设计变更有多频繁？变更太频繁，则不要编写大量测试文档。
反映设计变更的规格说明变更有多频繁？如果规格说明长期不完整并且过时，不能把
测试文档捆绑在这种规格说明的内容上；
在测试时，是希望证明与规格说明一致，还是希望证明与客户预期不一致？
要采用的测试风格更依赖于预先定义的测试，还是探索性测试？
测试文档应该关注要测试什么，还是应该关注怎么测试？
文档应该控制测试项目吗？
如果文档控制部分测试项目，那么是在项目的初期还是后期进行控制？
谁是这些测试文档的主要读者？这些读者有多重要？
需要多强的可跟踪性？要反向跟踪哪些文档？谁来控制跟踪？
测试文档要在多大程度上支持项目状态与测试进展的跟踪和报告？
文档要在多大程度上支持向新测试员指派工作？
对新测试员的技能和知识做哪些假设？
要使用测试文档记录项目团队的过程，以提供一套别人做测试可依据的产品
模型或描述，或给出发现程序错误的结构吗？
测试包应该提供预防、检测和预测收益。对于本项目来说，哪一种收益最重要？
测试文档的可维护性有多高？这些测试文档在多大程度上能够保证测试变更能够跟上
代码变更？
测试文档会有助于标识程序风险模式的永久转移吗？
经验149-用简短的语句归纳出核心文档需求
第7章 与程序员交互
经验150-理解程序员怎样思考
程序员和测试员是在不同的条件下工作的，扮演者不同的角色；
测试员了解如何与程序员交互的最好方法，是成为一名程序员，并在一段时间内
成员与其它程序员一样的工作。
大多数程序员都很专一；
程序员关注自己的系统理论；
程序设计师一种复杂活动；
程序员常常要与各种困难做斗争；
很多程序员不喜欢例行工作，常常构建工具和脚本
来自动化自己所面临的重复性工作；
经验151-获得程序员的信任
测试员越早与程序员接触情况就越好。
经验152-提供服务
主动直接为程序员提供帮助。
测试第三方组件；测试非正式个人版本和原型；为程序员建立测试环境；评审需求文档的可测试性；
经验153-测试员的正直和能力需要尊重
如果测试员发现令人信服的问题，并准确、直接地报告，那么测试员应该得到尊重。
当报告问题时，注意下列问题：要干脆的报告问题；将自己的判断建立在产品行为的实际观察基础之上；
如果失效是不可重现的，要展示为了重现失效所做的各种尝试；直接报告坏消息；不要假装了解自己并不
了解的东西；不要夸张错误报告；如果测试员是正直的，就可以展示自己的能力；
经验154-把关注点放在产品上，而不是人上
测试员只做自己分内的事；
经验155-程序员喜欢谈论自己的工作，应该问他们问题
一个很好的切入点是讨论程序员所使用的设计文档；问问题；索要系统框图；
测试员的目的是更多的了解在建系统，了解系统可能失败的方式，了解人们构建系统所做的假设；
作为测试员，工作就是考虑产品怎样才会失效，作为团队的一员，测试员需要理解在建产品的价值所在。
经验156-程序员乐于通过可测试性提供帮助
对于测试员来说，可测试性是能够便于测试软件的任何功能。
三点注意事项：用程序员的语言谈话；尽早提出要求；要现实；
第8章 管理测试项目
管理测试项目在某些方面与管理任何其他类型的项目一样。测试员的工作是对程序员工作的反映。
经验157-建设一种服务文化
测试员是为整个项目团队提供服务，典型的服务是发现并报告程序错误。
经验158-不要尝试建立一种控制文化
经验159-要发挥耳目作用
测试员在公司中的权力建立在自己的调查技能和自如沟通的基础上，而不是建立在命令链上，因为
测试员在项目团队的命令链中的位置并不很高。
测试员必须评估自己公司的文化，要在不被解雇或排斥的限度内发挥作用，在这个限度内，我们建议测试员
要称为能够为别人带来价值的守信用、高度正直的信息提供者，以此来施展和扩大自己的影响力。
经验160-测试经理管理的是提供测试服务的子项目，不是开发项目
测试工作是整个项目的一个子项目，要申请资源并提供服务。项目经理在如何运作测试项目上有很大的控制权，
应该仔细选择自己的管理风格，从而与项目经理的管理风格协调。
经验161-所有项目都会演变，管理良好的项目能够很好地演变
每个项目的整个过程中，测试经理都应该准备对整个计划的大小细化或更正。
项目就是一组任务，随着时间的推移，项目团队会发现有些任务比预期的要困难，或要花费更长的时间，有些
任务还不能完成，有些任务与前一周相比，对市场开发经理或者客户来说很紧迫，此外，每次测试员提出一份
错误报告时，都会在大堆的任务中再增加一项。
经验162-总会有很晚的变更
所有项目管理方法都必须处理变更
需求实在我们想要和我们能够得到的功能之间进行不断斗争的结果。随着项目的展开，需求会有变化。
经验163-项目涉及功能、可靠性、时间和资金之间的折中
项目经理的任务就是按时并在预算限度内支付一组合适的功能，达到合适水平的可靠性。这是一种具有挑战性的折中。
经验164-让项目经理选择项目生命周期
生命周期模型是从最初考虑构建这种产品，到向公众发放并投入使用为止，产品设计和开发过程的描述。
有些公司遵循标准生命周期模型，但是根据我们的经验，项目经理总是有一定的定制余地。明智的项目经理
会挑选能够流畅地控制自认为很难管理的方面的方法，而预留出自己特别有能力解决的方面。
经验165-瀑布生命周期把可靠性与时间对立起来
瀑布模型是一种描述按阶段推进项目管理的具体生命周期方法。这些阶段包括：问题定义；需求定义；内部和外部设计；
编码；测试；安装；安装后支持；失望客户的法律诉讼；问题定义（针对产品的下一个版本）；
软件项目有大量的风险。总会有很晚的变更。
在瀑布模型下，到测试员得到代码时，所有功能都已经设计，且大部分或所有功能都已经编码，大部分软件开发经费已经
支出。关键的折衷要素是时间和可靠性。要么修改错误而晚一些交付产品，要么较快交付产品，但是有较多错误。
这是项目经理和测试员之间的经典争持：要交付错误很多的产品，还是延迟交付。
经验166-进化生命周期把功能与时间对立起来
在软件开发进化方法中，项目团队每次增加一个功能，他们设计该功能、编码、测试，并更正其错误。如果
集成了这个功能的产品满足了项目团队的质量标准，他们就会增加下一个功能。今天的版本和下个月的版本
之间的差别是下个月的版本有更多的功能。这两个版本都能使用，不存在项目结束时的时间和可靠性之间的
折中考虑。
经验167-愿意在开发初期将资源分配给项目团队
可以评审需求文档的可理解性、可测试性和模糊性；
随着项目工作制品的开发，再对他们进行测试，不要等到真个产品完成才测试；
推动代码评审；代码评审是收效很大的一种质量改进工作。
拟定硬件配置和准备购置或借用设备的初步清单；
要求提供可测试性的功能。
准备测试自动化；
研究测试工具；
如果可能，订购用于被测软件的外部开发的测试包；
了解产品的市场和竞争情况；
经验168-合同驱动的开发不同于寻求市场的开发
在合同驱动的项目中，测试员的主要活动是对一组规格说明测试软件；
在寻求市场的项目中，测试员更可能根据不同客户的预期，来研究和测试产品；
经验169-要求可测试性功能
越早提出可测试性功能要求，程序员和项目经理越有可能把它列入预算和进度计划。
经验170-协商版本开发进度计划
制定版本进度计划，内容包括测试小组接受软件的频度，对提交的被测试软件的要求，
以及在最近版本中发现的程序错误如何在新版本中重现。
经验171-了解程序员在交付版本之前会做什么（以及不会做什么）
有些编程小组会做大量的单元测试，有些没有；有些会把冒烟测试作为其开发的一部分，有些没有；
不要指望他们完成或不完成某种类型的测试，也不要指望对交付给测试员的版本做各种准备。
经验172-为被测版本做好准备
当被测版本就绪时测试环境也应该就绪，这一点很重要。
经验173-有时测试员应该拒绝测试某个版本
偶尔测试员也会回绝某个版本，拒绝测试。理由
1、由于这个版本中应该加入某个关键功能，但是测试员发现没有加，或马上失效；
2、以前正常的关键功能现在不能正常使用了，测试小组的冒烟测试应该发现这种失效，当冒烟测试
失败后，一般都要拒绝该版本。
3、如果收到一个版本，并且已经另一个版本在几个小时之后就会完成；
一般来说，如果会使测试工作不能得到明显收益的情况下效率受到很大影响，或对某个版本的测试结果会被忽略，则
应该拒绝该版本的测试。
经验174-使用冒烟测试检验版本
冒烟测试或接受测试是一种测试包，目标是检查版本的基本功能。如果该版本没有通过，则可宣布
该版本不太稳定，不值得测试。
经验175-有时正确的决策是停止测试，暂停改错，并重新设计软件
如果不管进行了多少次程序错误的修改，在同一位置总发现问题，或不管对用户界面做了多少小修改，
仍然存在使用户困惑的问题，也许应该停止测试并对有关代码进行调试。这部分内容可能需要重新设计
或重写；
经验176-根据实际使用的开发实践调整自己的测试过程
除非程序员向测试员提供完整的规格说明，建议测试员拒绝测试产品。这是很糟糕的建议。
我们建议不要改变程序员的工作方式。
经验177-项目文档是一种有趣的幻想：有用，但永远不足
即使对于试图充分描述产品的项目团队，开发文档也和想象有很大差别。不要对抗这个事实，
这是一个基本问题。
经验178-测试员除非要用，否则不要索要
如果要求提供规格说明就要使用它，否则以后他们不会向测试员提供任何材料；
经验179-充分利用其它信息源
如果没有人向测试员提供规格说明，测试员还有很多其它的信息源可以帮助。
以下是补充规格说明所没有提供的信息：
用户手册草稿；产品市场开发文献；市场开发人员向管理层推销产品概念的演讲；
程序软件变更的备忘录；内部备忘录；已出版的风格指南和用户界面标准；
已出版的标准；第三方兼容的测试包；已出版的规定；错误报告；程序逆向工程；与人员面谈；
头文件、源代码、数据库的表定义；第三方的规格说明和问题清单；原型以及针对原型的所有试验记录；
前一个版本的客户电话记录；可使用性测试结果；B测试结果；常见错误；兼容产品；
与仿制的产品进行比较；内容参考材料；
经验180-向项目经理提出配置管理问题
程序错误修复损坏产品中的其它功能，或使得以前解决了的问题再次出现的可能性有多大？
对于不同的公司和项目团队，出现副作用的可能性有很大不同。不管是那种情况，都要与
项目经理讨论这个问题，并要求提出解决意见。如果这个问题还得不到解决，在状态报告
中说明需要高级别的回归测试。
经验181-程序员就像龙卷风
程序员就像龙卷风，把他们看做是一种自然力量。程序员会按照自己的方式做，而且在不同的公司中
程序员的工作方式也有很大不同，测试经理应该相应地设计自己的实践。
经验182-好的测试计划便于后期变更
如果后期变更是不可避免的，那么测试经理的责任是设计能够适应后期变更的测试过程。
不要在测试之前开发大的测试包，而是在需要测试包时再开发；
不要编写维护成本很高的大量测试文档；
不要把手动或自动化测试捆绑到特定的用户界面；
通过最大化可维护性和跨平台可移植性来设计自动化测试；
构建一组能够在不同程序中重复使用的通用测试；
构建一组很强的冒烟测试，以快速检测被测软件中的基本失效；
慎重考虑使用极限编程法开发自动化的测试；
开发一种产品用户和用户要通过产品获得效益的模型；
帮助程序员开发大的单元测试包；
经验183-只要交付工作制品，就会出现测试机会
任何时候产品的任何部分可以提交评审，测试机会都会出现，通过这种方式可以把测试融入到产品的整个
开发过程中。只要工作制品已经能够完成，都要尽快测试。
经验184-要多少测试才算够？这方面还没有通用的计算公式
不要费心寻找计算公式，还是英爱多开动脑筋。
经验185-足够测试意味着有足够的信息可供客户做出好决策
当有理由相信产品任由有重要的未发现的问题可能性很低，就可以停止测试。
判断测试是够足够好有多种因素：知道发现的重要问题的种类；知道产品的不同部件如何表现出严重问题；
对产品做了与这些风险相应的检查；测试策略具有合理的多样化；使用了所有可用的资源进行测试；满足
客户期望满足的所有测试过程标准；尽自己的可能，清晰地表示测试策略、测试结果和质量评估。
交付之后可能会有大的问题有以下原因：
测试员不想按照自己想象的那样了解风险的动态；测试员在测试中出现错误；风险评估是正确的，管理层决定
冒风险；
在测试中遗漏问题不算问题，粗心、不认真思索或不通过实践吸取教训才是问题。
经验186-不要只为两轮测试做出预算
第一轮会暴露问题，第二轮检查所有错误修改，但是产品测试不得不进行的次数也许比两次多得多。
经验187-为一组任务确定进度计划，估计每个任务所需的时间
列出任务清单，估计所需的总时间，但是做起来难。列出任务并不是简单的事，因为很容易遗漏任务或
低估任务范围；
尝试其他估计问题的方法：测试员完成过类似的项目，可以类推；了解程序的长度和复杂度，了解当前公司
将程序长度和复杂度与测试时间关联起来的数据为基础的模型，则使用这种模型导出估计值；了解有关的风险，
针对风险测试需要什么
以上是关于软件测试理论与经验--阅读笔记的主要内容，如果未能解决你的问题，请参考以下文章