Lessons Learned in Software Testing
美 Cem kaner、James Bach、Bret Pettichord著
本书的三位作者具有多年的测试经验，知道成功的测试都需要什么。在这本革命性的新书中，他们汇总了293条测试经验建议，阐述了如何做好测试工作，如何管理测试，以及如何澄清有关软件测试的常见误解。读者可直接将这些经验用于自己的测试工作中。这些经验中的每一条都是与软件测试有关的一个观点，后面是运用这条经验的方法、时机和原因的解释或例子。
第3章 测试手段
本章的观点基本是结构化的，介绍其余内容的分类系统；本章不讨论主要如何使用手段，但是会足够详细描述一些实际使用的手段。
经验48-
关注测试员、覆盖率、潜在问题、活动和评估的组合测试手段
五要素测试系统：测试员（进行测试的人），覆盖率（测试那些内容），潜在问题（测试原因、风险等），活动（如何测试），评估（怎么判定过还是不过）。
所有测试都包括所有这五个要素。 谁测试？测什么？怎么测？测试问题？怎么判定？
经验49-
关注测试员的基于人员的测试
手段
用户测试：由将使用该产品的典型人员进行输入的测试；
alpha测试：测试小组执行的内部测试；
beat测试：产品目标市场成员的测试员实施的用户测试；将客户试用代码看做是beat测试；
强力测试：利用秘书、程序员、市场开发人员和任何人所实施的测试；有关领域的
专家测试；
成对测试：两个测试员在一起发现程序错误；
自用测试：全公司使用试用版软件；
经验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-如果决定据理力争，就一定要
赢
所做的每个上诉都是有说服力的。