第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-为一组任务确定进度计划，估计每个任务所需的时间
列出任务清单，估计所需的总时间，但是做起来难。列出任务并不是简单的事，因为很容易遗漏任务或
低估任务范围；
尝试其他估计问题的方法：测试员完成过类似的项目，可以类推；了解程序的长度和复杂度，了解当前公司
将程序长度和复杂度与测试时间关联起来的数据为基础的模型，则使用这种模型导出估计值；了解有关的风险，
针对风险测试需要什么，最终估计时间；一些其它因素会影响测试员的估计。
经验188-承担工作的人应该告诉测试经理完成该任务需要多长时间
如果要使估计更有意义，可收集承担该任务的员工所做的估计并进行统计。
经验189-在测试员和开发人员之间没有正确的比例
经验190-调整任务和不能胜任的人员
不同的测试员都有不同的强项，要鼓励测试员承担风险并扩展自己的能力，测试经理要尽可能提供指导，
但是要关注测试员的进步。不要让测试员承担不适合的工作。
经验191-轮换测试员的测试对象
不要让测试员自始至终对某个项目的同一组功能进行测试。首先，大多数测试员赶到厌烦；其次，测试员太专；
第三，如果专家离开，会留下很大知识漏洞；第四、最重要的，两个测试员会以不同方式分析同样的功能，他们
会使用不同的查错理论，创建不同的测试，并发现不同的缺陷。
经验192-尽量成对测试
测试员结成对子，一起工作，常常等于熟练的差错高手；测试时一种思想生产活动，而不是计划实现活动，
测试是一种在开放的多维空间中启发式探索过程，成对测试有利于每个测试员解放思想，并对其做出反应。
成对测试有助于两个测试员始终关注任务，更容易重现和分析程序错误。
经验193-为项目指派一位问题查找高手
问题查找高手是经验丰富、热心探索的测试员。
问题查找的一些方式：对有怀疑的部分进行初步探索式测试，形成更细致地跟踪的想法，
这个可以让经验不足的测试员执行；探索被认为是风险很低的部分；定位看起来很容易引起不可重现问题的
关键部分；找出关键程序错误，以说服项目经理推迟发布日期；
经验194-确定测试的阶段计划，特别是探索式测试的阶段计划
确定60-90分钟内要做什么，我们把这叫做阶段计划；这种方法的好处是有助于测试员集中注意力。
阶段目标可以包括要测试什么，要使用什么工具，使用什么测试技术，有什么风险，要寻找什么
程序错误，要研究什么文档，需要什么结果等。
经验195-分阶段测试
保护阶段的完整性，在一个阶段中，测试员要进行专题测试。
经验196-通过活动日志来反映对测试员工作的干扰
如果认为不需要保护自己的测试免受频繁中断，可以记录一两周的活动。
为了解决看起来生产率有问题的测试员，了解需要大量加班才能完成任务的测试员的实际问题，活动日志是有助于将
注意力集中到任务并对任务划分优先级的有效办法。
经验197-定期状态报告是一种强有力的工具
测试小组的真正力量来自沟通，不是监管。
注意永远使用中性、客观的语气；不要针对具体的某人；采用所有项目都一致的格式；按照标准进度计划提交报告；
仔细地选定状态报告的内容；要把状态报告提交给项目团队之外的人看。
经验198-再也没有比副总裁掌握统计数据更危险的了
在报告状态时，应该知道自己在统计什么数据，谁将看到这些数据；根据定义，度量就是整个图片的一小片，将
整个图片压缩为少量数据的度量是一种很大的简化。我们利用度量帮助了解项目的进展情况，以及产品各个方面
的质量情况。
经验199-要小心通过程序错误数度量项目进展
程序错误数是一种度量项目进展的很好参数。但是程序错误数是不充分的，并且常常产生误导。程序错误
数不能用来说明产品已经接近发布时所要求的质量，不赞同把程序错误到达率作为项目管理依据的统计模型，
因为没有理由相信这种方法核心的概率模型假设符合项目的实际情况。
经验200-使用的覆盖率度量越独立，了解的信息越多
可以在多个元素上度量产品已经完成的测试量：程序错误、需求、代码、配置、变更历史、开发人员、测试员、数据等，
单独测试任何一个元素都是不够的；
经验201-利用综合记分牌产生考虑多个因素的状态报告
最好的状态报告反映多个因素的参数，不是单一、平凡的数字向管理层提供信息，但是信息模式的表示要足够简单，
以便指导决策；
经验202-以下是周状态报告的推荐机构
可以把状态报告看做四页长的文档；第一页列出关键问题，如所需的决策、所需的程序错误修改、
预期的交付的工作制品、意外问题；第二页描述测试小组完成计划任务进展的情况；第三页提供错误报告
统计数字；最后一页列出本周被推延的程序错误，清单可以只包括程序错误数、总数、严重程度；
经验203-项目进展表是另一种展示状态的有用方法
向项目团队所有成员和与该项目有关的任何人公开，直观地展示项目的进展情况。
经验204-如果里程碑定义的很好，里程碑报告很有用
如果公司要在每个里程碑处评估产品，那么测试经理需要知道应对照什么进行评估。
经验205-不要签署批准产品的发布
要让项目经理或者项目团队确定什么时候发布产品；
经验206-不要签字承认产品经过测试达到测试经理的满意程度
产品经过了充分测试，完成了约定程度的测试，或在可用的时间内尽力做了最好的测试。
经验207-如果测试经理要编写产品发布报告，应描述测试工作和结果，而不是自己对该产品的看法
只描述自己知道的东西；
经验208-在产品最终发布报告中列出没有排除的程序错误
应附上产品中未排除的程序错误的清单。
经验209-有用的发布报告应列出批评者可能指出的10个最糟糕的问题
第9章 测试小组的管理
本章考虑的是一个项目接一个项目、年复一年地一起工作的员工组成的小组。
经验210-平庸是一种保守期望
不要扼杀员工的创造性；不要是员工成为不能互换的齿轮；不能标准化员工；要以创造性、可说服性、
判断力、人际敏感性等评价自己的员工；不能将员工与工作结果剥离；
经验211-要把自己的员工当做执行经理
大多数测试员都是执行经理，以此为基础进行管理；接受测试员具有不同的强项和兴趣，并有针对性管理；
经验212-阅读自己员工完成的错误报告
阅读错误报告，有助于测试经理了解产品情况，自己员工的强项和品德，以及影响自己员工的沟通和人际问题；
针对报告，可能有一些问题：报告写的好吗？直率地提出问题了吗？留下迫切要求后续测试的漏洞了吗？
发现程序的错误是例行公事还是很有见地？程序错误很难发现吗？错误出现在比较稳定的部分吗？
报告的语气怎么样？程序员能够理解吗？
经验213-像评估执行经理那样评估测试员
不要仅仅把程序错误数做为一种度量；建议可以参照以下：错误报告、编写的代码、
编写的测试文档、与其一起工作的程序员和其它有关人员的意见；
鼓励测试经理积极、随时地跟踪员工的工作。
经验214-如果测试经理确实想知道实际情况，可与员工一起测试
经验215-不要指望别人能够高效地处理多个项目
有些人会接受多项任务，但是在特定的一周内，他们只能承担这些工作中的一项；积极地
承担所有被分配的任务的测试员会把时间分得很碎，要在管理方面花很多时间。
经验216-积累自己员工的专业领域知识
可以通过多种途径积累真正的专业领域知识：阅读面向类似产品客户的杂志和书籍；
参加教授客户如何使用本公司开发产品的培训班；参加与产品的下层主题有关的学习班；
在客户现场工作；推销自己公司或竞争对手的软件；回答公司技术支持热线电话；
经验217-积累自己员工相关技术方面的专门知识
经验218-积极提高技能
对于强化测试小组在公司中的价值极有帮助；
经验219-浏览技术支持日志
思考为了某类投诉减少自己可以做些什么；思考什么类型的测试会助于发现
被测软件中类似的一些问题；
经验220-帮助新测试员获得成功
为测试员找好地方；至少安排一天时间与有关人员见面；
为新测试员指派一位指导者；
经验221-让新测试员对照软件核对文档
全面测试手册和在线帮助是很值得的；测试员应该核对所有事实描述和程序测试；
经验222-通过正面测试使新测试员熟悉产品
尝试简单但是实际的方式使用该产品；帮助测试员理解该产品或产品版本的优点；
经验223-让测试新手在编写新错误报告之前，先改写老的错误报告
一种方法是让其重新测试老程序错误，并改写出更有效的错误报告。
经验224-让新测试员在测试新程序错误之前，先重新测试老程序错误
利用三类任务，可以帮助测试员了解被测产品、产品怎么样失效、怎么测试产品等。
重现现在还没有关闭的程序错误；重新测试已经解决的程序错误；重新测试已经解决但还
没有关闭的程序错误；
经验225-不要派测试新手参加几乎完成的项目
经验226-员工的士气是一种重要资产
礼貌对待员工、尊重员工；注意他们的工作；称赞好的工作、热心和诚实努力；员工加班，测试经理
也要加班；为员工指派他们感兴趣的任务和项目；测试任务不顺利，则指派别人指导、帮助；提供培训机会；
公平对待员工；不要对任何一位员工产生误导；不要与员工叫喊；避免公开批评；不要与员工私下议论
其它小组的员工；测试经理不要与员工约会；
经验227-测试经理不要让自己被滥用
不要为了过度工作而搞垮自己和整个团队；不要承诺不可能做到的事；
经验228-不要随意让员工加班
避免让测试员长期加班；制定项目进度计划时，不要指望员工每天8小时集中在工作上，这不现实；
不要同意自己知道的不现实的进度计划，尽可能准确估计完成不同任务需要多长时间；
经验229-不要让员工滥用
提供精神支持，解决各种不公正待遇；礼貌处理表现不当的测试员；
经验230-创造培训机会
经验231-录用决策是最重要的决策
经验232-在招募期间利用承包人争取回旋余地
经验233-谨慎把其它小组拒绝的人吸收到测试小组中
经验234-对测试小组需要承担的任务，以及完成这些任务所需的技能做出规划
经验235-测试团队成员需要有不同背景
经验236-录用其它渠道的应聘者
经验237-根据大家意见决定录用
经验238-录用热爱自己工作的人
经验239-录用正直的人
经验240-在面谈时，让应聘者展示期望有的技能
经验241-在面谈时，请应聘者通过非正式能力测验展示其在工作中能够运用的技能
经验242-在录用时，要求应聘者提供工作样本
经验243-一旦拿定主意就迅速录用
经验244-要将录用承诺形成文字，并遵守诺言
第10章 软件测试职业发展
经验245-确定职业发展方向并不懈努力
- 自动化测试程序员
- 自动化测试结构分析员
- 性能和可伸缩性测试员
- 系统分析员
- 用户界面和人员因素分析员和鉴定员
- 测试计划设计员
- 专题测试专家
- 黑盒测试员
测试管理工作：
1、测试小组组长；2、测试经理；3、测试主任或质量主任；4、内部顾问；5、外部顾问；
测试调岗：
1、程序设计经理或项目经理；2、技术支持经理；3、产品经理；4、文档编写小组经理
5、销售支持经理
过程管理人员：
1、软件指标专门人员；2、软件过程改进专门人员
经验246-测试员的收入可以超过程序员的收入
经验247-大胆改变职业发展方向并追求其它目标
经验248-不管选择走哪条路，都要积极追求
经验249-超出软件测试拓展自己的职业发展方向
转换职业也许有更多的收获
经验250-超出公司拓展自己的职业发展方向
出席会议、参加协会、论坛等；相互学习、相互忠告、相互帮助；
经验251-参加会议是为了讨论
经验252-很多公司的问题并不比本公司的问题少
经验253-如果不喜欢自己的公司，就再找一份不同的工作
经验254-为寻找新工作做好准备
经验255-积累并维护希望加入的公司的名单
经验256-积累材料
掌握能够证明自己能力的一些代码、文档和其它工作样本
经验257-把简历当做推销工具
经验266-学习perl语言
经验267-学习java或c++
经验268-下载测试工具的演示版并试运行
经验269-提高自己的写作技巧
经验270-提高自己的公众讲话技巧
经验271-考虑通过认证
第11章 测试计划策略
测试计划是指导自己测试过程的一套想法，我们使用测试策略这个词表示指导整个项目的测试设计。
测试策略是好的测试计划的重要组成部分，是将测试与任务联系起来的桥梁。
经验274-有关测试策略要问的三个基本问题是“为什么担心？”“谁关心？”“测试多少？”
经验275-有很多种可能的测试策略
1、简单评审，交由又好用户使用，反馈问题；
2、用户与产品交互动作序列表示的测试用例，代表预期一般用户使用产品的各种方法；补充压力测试和异常
使用测试；还需要考虑可靠性；
3、执行并行探索性测试，开发和执行自动化回归测试。
都是测试策略。策略是不同的，实际项目，会根据产品的具体知识，设计出针对性更强的测试策略；
经验276-实际测试计划是指导测试过程的一套想法
测试计划是指导将要做什么的所有想法，是否需要创建文档，需要思考；最好的情况是测试计划内容与沟通和管理该计划的方式结合；
测试计划可以是正式的书面计划，也可以是口头计划、列在白板上的计划、一页纸的计划、一系列电子邮件，一组大纲或问题清单，最
主要的是做能够完成任务的事，方式可以有很多种。
经验277-所设计的测试计划要符合自己的具体情况
五种资源和约束：开发、需求、测试团队、测试实验室、任务；
测试经理不要指望在所有上述问题上有很大的控制能力，测试小组的控制能力在于如何应对这些资源和约束：自己要有
什么样的测试策略、保障条件和工作产品？
经验278-利用测试计划描述在测试策略、保障条件和工作产品上所做的选择
测试策略：快速找出问题？特殊测试？什么手段创建测试？等等
保障条件：实现策略如何实现？谁来测试？测试时间？测试需要什么条件？
工作产品：怎样向客户提供工作产品？如何跟踪程序错误？测试文档？测试报告？
经验279-不要让保障条件和工作产品影响实现测试策略
测试策略常常被测试计划其它部分掩盖。一定要明确如何测试改产品，并告诉测试员怎么样测试；
经验280-如何利用测试用例
只统计测试用例的个数而不管其中的内容是没有意义的。讨论测试用例的通过率时，一定要考虑风险及覆盖率，
并讨论测试用例的内容。
经验281-测试策略比测试用例重要
经验282-测试策略要解释测试
好的测试策略是：与具体的产品有关；关注风险；多样化；实用；
经验283-运用多样化的折中手段
执行达到相当水平的多种不同测试，要优于完美地执行一两种测试；这种原则叫做多样化的折中测试；
从问题发现率角度看，采用每种测试手段在发现率开始降低时，就转而使用一种新的手段；
有公司运行数以十万计的测试用例，仍然会遗漏显而易见的问题，因为他们的测试缺乏多样性；
经验284-充分利用强有力测试策略的原始材料
充分利用这些资源，以使策略选择达到最大化
部分资源：测试员测试手段的技能、产品内部技术的知识、特殊测试或工艺技能的朋友；原始测试数据库；
多种测试平台；各种测试工具；实际用户数据；植入产品的可测试性功能（例如日志文件、判断和测试菜单）；
经验285-项目的初始测试策略总是错的
建议根据风险确定测试策略。随着被测产品的任务加深，随着了解产品的弱点，随着想出测试该产品的新方法，测试
策略也应该进化。
经验286-在项目的每个阶段，可自问“我现在可以测试什么，能够怎样测试？”
测试策略要考虑进行测试的项目开发阶段以及测试结构层次，但是并不是决定性的考虑因素，建议测试经理可以在任何开发
阶段自问“我们在此时可以测试什么？怎么样才能测试好？”
经验287-根据产品的成熟度确定测试策略
项目初期，同情地测试；项目中期，积极的测试；项目末期，多样地测试；项目最后，谨慎地测试；
经验288-利用测试分级简化测试复杂性的讨论
在测试策略中简化测试的复杂性，区分测试级别会有帮助
0级：冒烟测试，独立的简单测试，失败，则直接打回；
1级：能力测试，检验产品每个函数能力的测试。保证每个函数都能够执行其任务，避免曲折的场景、富有挑战性的数据和功能交互。
2级：函数测试，各个个体函数和子函数的能力和基本可靠性。数据覆盖和符合测试结果评估方法是有意义的，使用边界、压力和错误
处理测试，避免采用曲折的场景和功能交互。
3、复合测试，多组函数之间的交互和控制流，以构成复杂场景的测试，重点已经扩张为性能评估、兼容性、资源紧张程度、内存泄露、
可靠性或其它质量评判准则；
首先宽泛、同情地测试，随着测试不断成熟，逐步进行深度和边缘测试。
经验289-测试灰盒
部分给予内部结构的测试策略也是很好的想法。如果了解一些产品的内部工作情况，就能够从外部进行更好的测试。像黑盒一样，
但是所选择的测试反映出测试员对内部组件操作和交互的了解。
灰盒测试对web和因特网应用程序尤其重要。
经验290-在重新利用测试材料时，不要迷信以前的东西
在重用测试用例或者任何测试材料时，不要将其当做黑盒使用。需要做一些了解。
经验291-两个测试员测试同样的内容也许并不是重复劳动
重复测试劳动几乎都不会是浪费，真正的问题不是浪费，而是产品的某一部分是否值得进行重复测试。
经验292-设计测试策略时既要考虑产品风险，也要考虑产品要素
好的测试策略不仅要根据产品风险制定，还要考虑产品内部要素
不要在测试员之间的缝隙中遗漏错误；经常测试客户要求测试的内容；偶尔测试客户不要测试的内容；
测试不够清晰和矛盾的内容；不要痛打落水狗；更多变更意味着更多测试；
经验293-把测试周期看做是测试过程的韵律
测试策略要根据测试周期来具体化。
接收产品；对测试系统进行配置；检测可测试性；确定哪些部分是新增加的或者是经过修改的；确定
修改了哪些程序错误；测试程序错误修改；测试新的或者经过变更的部分；测试其他部分（首先测试风险
较大的部分）；报告测试结果；