《软件测试经验与教训》摘录
最近拜读了《软件测试经验与教训》一书，其中给出的很多经验和教训都富有参考价值，摘录了一些个人觉得比较有用的条目。与大家一起分享学习。
- 迅速找出重要程序问题
先测试经过变更的部分，后测试没有变化的部分。
先核心功能，后辅助功能。
先能力，后可靠性。
先常见情况，后少见情况
先常见威胁，后罕见威胁。
先影响大的问题，后影响小的问题。
先最需要的部分，后没有要求的部分。
测试如果对产品、产品必须与之交互的软件和硬件以及将使用软件的人越了解，越有可能更快的找出重要问题。
- 黑盒测试
为了做好黑盒测试，就要了解用户，了解他们的期望和需求，了解技术，了解软件运行环境的配置，了解这个软件要与之交互的其他软件，了解软件必须管理的数据，了解开发过程等等。
- 通过会议、推到和参照发现需求
需求文档经常是不完整、不准确的。从以下三种途径搜集需求信息。
1.会议，找出其有关质量的意见具有影响力的人，与他们交流，了解他们最关心什么。
2.推到，通过外推已知项目和产品其它信息，确定什么需求最重要。
3.参照，发现显示、隐式规格说明。
- 既要使用显示规格说明，也要使用隐式规格说明
显示规格说明是一个有用的需求信息源，经过客户的权威确认。隐式规格说明是没有经过客户权威确认的一个有用的需求信息源。
隐式规格说明的形式：1、竞争对手的产品；2、相关产品；3、统一产品的老版本；4、项目团队之间的电子邮件讨论；5、顾客意见；6、图形用户界面风格指南；7、操作系统兼容性需求；8、测试自己的丰富经验。
- 不要将试验和测试混淆起来
测试任何产品至少包含以下四种活动：1、配置，准备要测试的产品，将其置于正确的其实状态。否则测试结果会受到不良变量的影响。2、运行，向产品输入数据，向产品发命令，以某种方式与产品交互。3、观察，收集有关产品行为信息，输出数据，系统整体状态，与其他产品的交互等方面的信息。4、评估，运用规则、推理或可检测所观察到数据中存在问题的机制。
- 运用试探法快速产生测试思路
试探法是一种基于经验做出猜测的方法。由于可能的测试用例数量是无限的，因此要选出在所面临的时间和预算约束条件下有小的少量测试用例。一组好的试探方法有助于很快地生成测试。采用试探法测试的一些例子：
1.测试边界。边界更可能暴露规格说明的模糊问题。
2.测试所有错误信息。错误处理代码与主流功能代码相比，一般比较弱。
3.测试与程序员的配置不同的配置。
4.运行比较南设置的测试。在其它条件相同的情况下，易于设置的测试更有可能已经被执行过了。
5.避免冗余测试。如果某个测试实际上是重复其它测试，就不会产生新价值。
- 如果遗漏一个问题，检查这种遗漏是意外还是策略的必然结果
如果出现遗漏问题，需要思考出现问题是因为执行了好的测试策略，碰巧没有发现这个特定问题？如果是这样，可以保持原有方针不变。但是如果遗漏程序错误是因为测试策略关注了错的问题类型，可以利用这个机会改进测试策略。
- 关注测试员、覆盖率、潜在问题、活动和评估的组合测试手段
测试五要素：
1.测试员。
2.覆盖率。测试了那些哪些内容。
3.潜在问题。测试的原因。
4.活动。如何测试。
5.评估。怎样判定测试通过还是不通过。
测试手段不一定只涉及一种要素，也不应该这样，所有的测试应该都要涉及五个要素。应该期望跨多个要素的更综合的测试手段。
- 关注测试员的基于人员的测试手段
以执行测试的人来区分的常见手段。
用户测试：将使用该产品的典型人员进行输入测试。
α测试：有测试小组执行的内部测试。
β测试：利用不属于开发机构并且是产品的目标时长成员的测试员实施的用户测试。
强力测试：利用秘书、程序员、时长开发人员和可以找到的任何人所实施的内部测试。
有关领域的专家测试：向软件目标领域内的专家提供产品，并寻求反馈意见。
成对测试：两个测试员在一起发现程序错误。
自用测试：全公司使用并依靠自己软件的试用版，通常要等到软件足够可靠能够实际使用时，才像市场销售。
- 关注测试内容的基于覆盖率的测试手段
功能测试：逐个测试每个功能。
特性或功能集成测试：一起测试多个功能，以检查功能在一起执行的情况。
菜单浏览：遍历GUI产品中所有菜单和对话框，使用每个可用的选项。
域测试：搜集所有的输入输出变量，把其可能取值集合划分为等价类。以这个变量作为输入或输出，测试涉及这个变量的每个功能。
等价类划分：等价类是认为等价的一组变量取值。一旦找出一个等价类，可只测试其一两个成员。
边界测试：边界值就是类的最小和最大值。在边界测试中，要测试这些值，还要测试相邻类的边界值。
最佳代表测试：等价类的最佳代表是暴露软件中的错误的可能性方面至少与类中其它值一样的值。但有时候不一定是数值，要根据具体问题选择这个类的最佳代表。
输入字段测试大纲或矩阵：对于每组输入字段，可以开发一组相当标准的测试用例。
用各种方式映射和测试编辑字段：可以是手动输入，或者拷贝或者其它等等。
逻辑测试：试图检查程序中的所有逻辑关系，因果图是一种用于设计大量基于逻辑测试的手段。
基于状态的测试：在基于状态的测试中，每次都要通过经过大量状态前移，并自洗检查结果来检验程序。
路径测试：一条路径包含测试员所执行的所有步骤，或程序为了得到正确状态所通过的所有语句。路径测试包括测试通过程序的很多条路径。
语句与分支覆盖率：如果测试执行了程序中所有的语句，则达到了100%的语句覆盖率。如果执行了所有语句和一个语句到另一个语句之间的所有分支，则达到100%的语句和分支覆盖率。设计自己的测试，达到高的语句与分支覆盖率，
配置覆盖率：配置覆盖率度量测试员已经运行的配置测试占计划运行的配置测试总数的百分比。
基于规格说明的测试：这种测试关注验证在规格说明中所做的有关产品的每个事声明。
基于需求的测试：测试关注证明程序满足需求文档中的所有需求。
组合测试：相互组合两个或更多便利。
- 关注测试原因（基于风险测试）的基于问题的测试手段
基于风险的测试至少有两个主要含义。进行风险分析是为了确定下一步要做的测试。另一个含义就是进行风险测试时为了发现错误。
- 关注测试方法的基于活动的测试手段
回归测试：回归测试涉及相同测试的重用，使得在软件变更以后可以重新执行。
脚本测试：手工测试，采用由更高级的测试员编写的测试过程步骤，一般由低级程序员执行。
冒烟测试：这种副作用回归测试的目标，是证明新版本不值得测试。
探索式测试：不断创建并使用新测试。
游击式测试：对程序快速，有力的攻击。
场景测试：这种测试涉及四个属性，1.测试必须是现实的，反映客户实际要做的事；2.测试应该是复合的，要以能够对程序构成一定挑战的方式包含多个功能；3.应该能够容易并快速的显示出程序是否通过测试；4.如果程序没有通过测试，有关人员会强烈要求修改程序。
安装测试：以各种方式，在可以安装该软件的不同类型系统上安装该软件。
负载测试：在面临很多资源要求的系统上运行，攻击被测程序或系统。
可靠性测试：测试需要持续一定的时间来暴露问题。
性能测试：运行这些测试通常要确定程序运行有多快，以便确定是否需要优化。
- 关注测试是否通过的基于评估的测试手段
评估手段描述确定程序是否通过测试的方法，说明如果能够采集到一定的数据该如何评估。
- 不可重现程序错误是可重现的
程序错误要在特定的条件下出现。如果遇到自己不能重现的程序错误，可以尝试找出条件是什么。列举了一些有助于思考的条件例子：1.程序错误可能有延迟效应；2.程序错误可能只是在安装、使用产品或使用产品的特定功能时出现一次。3.程序错误可能依赖于特定的数据取值或被破坏了的数据库。4.程序错误可能只在特定的时间点发生。5.缺陷可能依赖于特定顺序执行一系列相关的任务。6.程序错误可能是前面失效的残余。7.程序错误可能是由被测应用程序与后台运行的其他软件，或和与被测应用程序竞争访问的软件交互引起的。
- 有关测试策略要问的三个基本问题是”为什么担心？”、“谁关心”、“测试多少？”
为什么担心？测试是昂贵的，除非测试策略解决足够重要，需要花时间测试的问题，否则测试策略中不要包含活动。
谁关心？只在测试策略中包含与他们利益有关的活动
测试多少？到底打算实际测试多少？
- 实际测试计划是指导测试过程的一套想法
- 所设计的测试计划要符合自己的具体情况
测试计划的目标，是所选的测试过程能够使测试控制在项目环境中，同时又能充分利用资源，完成自己的任务。给定五种资源和约束是：
开发；产生将要测试的产品和系统。如何接收该产品？该产品的可测试性如何？
需求；成功产品的评判准则。该产品的风险是什么？有关质量谁的意见最重要？
测试团队；能够投入该产品测试的人员。有合适人选吗？能够及时完成任务吗？
测试实验室；使测试团队能够完成测试任务的系统、工具和材料。有合适的设备吗？程序错误跟踪系统的状态是否良好？
任务；测试团队必须按照客户认可的成功标准解决的问题。快速找出重要问题?对质量做出准确评估？
- 利用测试计划描述在测试策略、保障条件和工作产品上所做的选择
测试计划必须描述三类选择：
1.策略。如何测试产品以快速找出重要问题？需要对哪些部分进行特殊测试？要运用什么手段创建测试？当程序错误出现时怎样识别？测试策略要规定测试项目与测试任务之间的关系。
2.保障条件。如何利用资源实现测试策略？谁来测试？什么时候测试？要想成功需要什么条件？
3.工作产品。怎样向客户提供工作产品？如何跟踪程序错误?需要编写什么测试文档？需要编写什么报告？
- 测试策略要解释测试
好的测试策略是：
1.与具体产品有关。
2.关注风险。显示测试过程中可以怎样描述重要问题。
3.多样化。多样化测试策略要包含各种不同的测试手段和方法。
4.实用。测试策略必须能被执行。
- 根据产品的成熟度确定测试策略
项目初期，同情的测试。
项目中期，积极地测试。
项目末期，多样地测试。
项目最后，谨慎地测试。
总体目标是随着产品开发的进展，不断地调整测试策略，使得产品开发整个过程中，重要错误的发现率都保持比较高的水平。
