软件测试概论
基础概念
【定义】
软件测试是使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度 、完全度和质量的软件过程。
【内容】
软件测试主要工作内容是验证(verification)和确认(validation )。
验证是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。(Do the right thing)
确认是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do it right)
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期问各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。
【目的】
软件测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
| 软件测试的出发点就是质量，软件测试的一切工作应该围绕质量而开展，测试是保证质量的重要手段之一，测试本身就是为质量服务的。 |
【原则】
- 测试的标准是用户的需求
所有的软件测试都应追溯到用户需求，测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。
- 事先定义好产品的质量标准
有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
- 应当"尽早地和不断地进行软件测试"作为测试者的座右铭
在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%～60%。，缺陷存在放大趋势。如需求阶段的一个错误可能会导致N个设计错误，因此，越是测试后期，为修复缺陷所付出的代价就会越大。
- 制定测试计划，排除随意性
在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等以及评价标准。
- 周密的测试用例，不可将测试用例抛开
要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。
- 充分注意群集现象
抓住80/20原则可以有针对性的优化测试，在最短的时间内发现更多的问题，同时也能保证测试者对测试过程的整体把握。特别是当项目时间紧、复杂度高时，可以分时间、阶段、模块解决问题，是有效的解决问题的方式之一。
- 避免测试自己的程序
由于心理因素，人们潜意识都不希望找到自己的错误。基于这种思维定势，人们难于发现自己的错误。因此，软件开发者应尽量避免测试自己的产品，应由第三方来进行测试，当然开发者需要在交付之前进行相关的自测。一定程度的独立测试（可以避免开发人员对自己代码的偏爱），可以更加高效的发现软件缺陷和软件存在的失效。但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷。在软件开发的早期，开发人员对自己的工作产品进行认真的测试，这也是开发人员的一个职责之一。
- 完全测试是不可能的，测试需要终止
穷尽测试是不可能的，应结合当前实际情况当满足一定的测试出口准则时测试就应当终止。
- 回归测试
修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
- 妥善保存一切测试过程文档
软件测试要素
- 质量：软件质量是软件测试的目标，也是软件测试工作的中心，一切从质量出发，也就是一切从客户需求出发。任何违背质量的东西都是问题，测试就是要找出这些问题。
- 人员：人是决定的因素，测试人员的态度、素质、能力决定着测试的效果，对测试产品的质量也有很大的影响。测试人员因素包括测试组织结构、角色和责任的定义。
- 技术：软件测试技术，包括方法、工具。
- 资源：主要是指测试环境中所需要的硬件设备、网络环境，甚至包括测试数据。另外一个重要因素就是测试时间，时间也是测试的资源，但测试人员不能看做资源，每个人的能力千差万别，不同的测试人员担任不同的角色，不能相互代替。这也是软件图书的经典之作——《人件》的作者反对将人作为资源对待的原因。
- 流程：从测试计划和测试用例的创建、评审到测试的执行、报告，设定每个阶段的进出标准。
软件测试与质量保证
软件质量
软件产品质量评价国际标准ISO 14598 把软件质量定义为：软件特性的总和，软件满足规定或潜在用户需求的能力。上述定义反应如下3个方面的问题：
- 软件需求是度量软件质量的基础；
- 软件人员必须遵循软件过程的规范；
- 如果软件只是满足规定的需求，而不能满足可能存在的隐含需求，软件质量也不能保证。
软件测试与软件质量保证的区别
软件测试只是质量保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作。
质量保证是通过预防、检查与改进来保证软件质量，采用全面质量管理和过程改进的原理来开展质量保证工作，主要关注软件质量的检查与测试，主要着眼于软件开发活动的过程、步骤和产物；软件测试是通过执行软件来对过程中的产物（开发文档和程序）进行走查，发现问题，报告质量。
具体说来，软件测试盒软件质量保证的区别体现在：从性质上看，软件测试属于技术性工作，而软件质量保证属于管理性工作；从对象上看，软件测试的对象是软件产品，而质量保证的对象是整个软件过程，覆盖公司层面的各个领域；从手段上看，软件测试以事后检验为主，而软件质量保证则强调缺陷的预防。
| 质量不是测试人员测试出来的，糟糕的早期设计结合最优的后期质量保证往往颇费力气，仍然打造不出用户满意度高的产品。 |
软件测试过程管理
测试团队
测试团队的基本责任
- 发现软件程序、系统或产品中所有的问题
- 尽早地发现问题
- 督促和协助开发人员尽快地解决程序中的缺陷
- 帮助项目管理人员制定合理的开发计划
- 对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人员能够及时、清楚地了解产品当前的质量状态
- 帮助改善开发流程、调高产品开发效率
- 促进程序编写的规范性、易读性、可维护性等
测试团队的组成
如何组织一个测试团队，应当视企业的人力资源而定。
一般，一个比较健全的测试组，所具有的角色包括测试组长、实验室管理人员、自动化测试工程师、资深测试工程师、初级测试工程师。
测试组长：业务专家，负责项目的管理、测试计划的制定、项目文档的审查、测试用例的设计和审查、任务的安排、与项目经理和开发组长的沟通等
实验室管理人员：设置、配置和维护实验室的测试环境，主要是服务器和网络环境等
资深测试工程师：负责产品设计规格说明书的审查、测试用例的设计和技术难题的解决，主要参与数据库、系统性能和安全性等技术难度较高的测试
自动化测试工程师：负责测试工具的开发、测试脚本的开发等
初级测试工程师：执行测试用例和相关的测试任务，侧重功能测试用例的设计和执行
软件测试团队与开发团队的关系
软件测试与软件开发具有天然的联系。软件测试的输入是软件开发的产品，测试输出的结果需要开发人员相应处理，处理后的结果再次需要测试人员的验证。因此，软件测试与软件开发如影相随，互为服务对象。
开发人员和测试人员需要不断的沟通合作，才能持续优化项目。对于开发人员而言，利用测试人员对需求的理解，越早将测试提到项目周期，帮助就越大；对于测试人员而言，搞好和开发人员的关系，则可以在测试方向上获得更多的帮助：编写测试用例时询问可能遗漏的用例，在测试即将结束时询问测试是否有风险。
软件测试风险分析
- 风险类型
- 项目风险：指潜在的预算、进度、人力、资源、客户、需求等方面的问题，以及它们对软件项目的影响
- 技术风险：指潜在的设计、实现、接口、验证和维护等方面的问题
- 商业风险：商业风险威胁到要开发软件的生存能力
- 识别风险
识别风险是试图系统化地确定对项目计划的威胁，识别风险的一个方法是建立风险条目检查表，检查表包括：
- 产品规模：与要建造或要修改的软件的总体规模相关的风险
- 商业影响：与管理或市场所加诸的约束相关的风险
- 客户特性：与客户的素质以及开发者和客户定期通信的能力相关的风险
- 过程定义：与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险
- 开发环境：与用以建造产品的工具的可用性及质量相关的风险
- 建造的技术：与待开发软件的复杂性及系统所包含技术的"新奇性"相关的风险
- 人员数目及经验：与参与工作的软件工程师的总体技术水平及项目经验相关的风险
- 评估风险影响
- 风险的性质：当风险发生时可能产生的问题
- 风险的范围：结合了严重性及整体分布情况
- 风险的时间：主要考虑何时能够感到风险，风险会持续多长时间
- 风险应对
风险分析活动的目的是辅助项目组建立处理风险的策略，一个有效的策略必须考虑如下3各问题：
- 风险避免
- 风险监控
- 风险管理及意外事件计划
软件测试成本管理
【测试费用有效性】
测试的策略由商业的经济利益来决定，对风险测试过少，会造成软件的缺陷和系统的瘫痪，测试的过多，会增加测试成本。下图的测试费用-质量曲线可以形象的表示测试费用的有效性：
【测试成本】
- 测试实施成本：测试准备成本、测试执行成本、测试结束成本
【缺陷探测率】
缺陷探测率DDP是另一个衡量测试工作效率的软件质量成本的指标。
缺陷探测率DDP＝Bugs（tester）/ （Bugs（tester）+ Bugs（customer））
缺陷探测率越高，也就是测试者发现的错误多，发布后客户发现的错误就越少，降低了外部故障不一致成本，达到节约总成本的目的，可获得较高的测试投资回报率。
测试流程
测试过程
软件测试过程一般包括:测试计划、测试设计、测试准备、测试执行、测试评估和缺陷跟踪等阶段，每个阶段都有一系列的任务。
测试过程具有以下几个特点：
- 测试工作开始于需求分析之后；
- 测试经过评估后，达到了结束的标准后才能结束；
- 测试也是迭代过程；
- 测试需求来自于软件需求；
- 测试过程与开发过程的关系；
- 都是软件过程的有机组成部分；
- 测试过程与开发过程同步进行；
- 测试过程与开发过程相互依赖，又相互独立；
- 开发过程、测试过程、项目管理过程以及其他支撑过程相互交织共同组成了软件过程。
测试过程的常见模型
V模型
映出了测试活动与分析设计活动的关系。从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。
W模型
W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。
但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。
H模型
H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。测试准备和测试执行分离，有利于资源调配，降低成本，调高效率。有组织、结构化的独立流程，有助于跟踪测试投入的流向。H模型还充分体现了测试过程（不是技术）的复杂性。
测试技术
软件测试类型
按测试阶段划分
【单元测试】
- 定义：又称模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作；可以从程序的内部结构出发设计测试用例，多个模块测试可以平行地独立进行测试
- 目的：发现模块内部可能存在的各种差错
- 内容：模块接口测试（IO测试，数据的流入流出）、局部数据结构测试、路径测试、错误处理测试、边界测试。
- 步骤：利用设计文档设计测试用例；创建被测模块的桩模块或驱动模块；利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试
【集成测试】
- 定义：又称组装测试或联合测试，在单元测试基础上，将所有模块按概要设计和详细设计进行组装
- 目的：发现模块连接中的接口可能存在的各种差错
- 内容：
- 穿越模块之间的数据是否会丢失；
- 一个模块组装后是否会对另一模块或其他模块存在影响；
- 各个子功能组装在一起是否会达到预期的父功能；
- 全局数据结构是否有问题；
- 单个模块的错误累积起来是否会放在
- 组装方法：包括一次性组装方式、增殖式组装方式两种组装方法
- 完成标志：成功地执行了测试计划中规定的所有测试用例；修正了所发现的错误；测试结果通过专门小组的评审
【确认测试】
- 目的：验证软件的功能和性能及其他特性是否与用户的要求一致
- 测试内容：验证所测软件是否满足需求规格说明书列出的需求；所有文档正确且便于使用；软件可移植性、易用性、兼容性进行测试；软件配置复查；保证软件配置的所有成分都齐全
【系统测试】
- 目的：验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试
- 测试内容：在真实或模拟系统运行环境下，检查完整的程序系统能否和系统（硬件设备、网络、系统软件）正确配置、连接，满足用户需求
【验收测试】
- 测试目的：在用户环境中进行测试，以确定系统和产品是否能够满足合同或用户所规定的需求
- 测试内容：根据任务书或合迥、供需双方约定的验收依据文档进行对整个系统的测试与评审，确认是否接收或拒绝系统
按测试实施组织划分
【产商测试】
开发方测试通常也叫"验收测试"或"a测试"，在软件开发环境中，开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。
【用户测试】
在用户的应用环境下，用户检测与核实软件实现是否符合自己预期的要求。β测试通常被认为是用户测试，把软件有计划地免费地分发到目标市场，让用户大量使用、评价检查软件。
【第三方测试】
由第三方测试机构来进行的测试，也称独立测试。
按测试方法划分
【静态测试】
静态测试又称为静态分析技术，不执行被测试软件，对需求分析说明书、软件设计说明书、源程序做结构检测、流图分析、符号执行等找出软件的错误。
【动态测试】
通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序，而达到发现程序错误的过程。
按测试技术划分
【白盒测试】
白盒测试也称为结构测试或逻辑驱动测试，是通过对程序内部结构的分析、检测来寻找问题，检查程序的结构及路径是否正确，检查程序的内部动作是否按照设计说明的规定正常进行。
【黑盒测试】
黑盒测试又称功能测试，通过运行程序发现其缺陷和错误。黑盒测试是对程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息的完整性。
【灰盒测试】
介于白盒和黑盒测试之间，关注输出对于输入的正确性，也关注程序的内部结构，但没有白盒测试那样详细、完整。
白盒测试
白盒测试方法
代码检查法
【检查内容】
代码检查包括桌面检查，代码审查和走查等方式，主要对以下内容进行检查：
- 检查代码和设计的一致性
- 代码对标准的遵循、可读性
- 代码逻辑表达的正确性
- 代码结构的合理性
- 程序编写与编写标准的符合性
- 程序中不安全、不明确和模糊的部分
- 编程风格问题等
【检查方式】
- 桌面检查：由程序员对源程序代码进行分析、检验，并补充相关的文档，发现程序中的错误。
- 代码审查：由程序员和测试员组成的审查小组通过阅读、讨论和争议，以程序进行静态分析的过程。
- 走查：程序员和测试员组成的审查小组通过逻辑运行程序，发现问题。
【检查项目】
- 检查变量的交叉引用表：检查未说明的变量和违反了类型规定的变量，变量的引用和使用情况
- 检查标号的交叉引用表：验证所有标号的正确性
- 检查子程序、宏、函数：验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致
- 等价性检查：检查全部等价变量的类型的一致性
- 常量检查：确认常量的取值和数制、数据类型
- 标准检查：检查程序中是否违反标准的问题
- 风格检查：检查程序的设计风格
- 比较控制流：比较设计控制流图和实际程序生成的控制流图的差异
- 选择、激活路径：在设计控制流图中选择某条路径，到实际的程序中激活这条路径，如果不能激活，则程序可能有错
- 对照程序的规格说明，详细阅读源代码，比较实际的代码，从差异中发现程序的问题和错误
静态结构分析法
在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表，检查软件有没有存在缺陷或错误。主要包括控制流分析、数据据流分析、接口分析、表达式分析。
代码质量度量法
代码质量度量法即根据ISO 9126质量模型的6个方面（即功能性、可靠性、易使用性、效率、可维护性、可移植性）对软件进行的动态测试方法。白盒测试的动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。动态测试通常在静态测试之后进行。白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：
- 保证每个模块的所有独立路径至少被使用一次
- 对所有的逻辑值均测试true和false
- 上下边界及可操作范围内运行所有循环
- 检查内部数据结构以确保其有效性
白盒测试综合策略
- 在测试中，首先尽量使用测试工具进行静态结构分析
- 采用先静态后动态的组合方式，先进行静态结构分析，代码检查和静态质量度量，然后现进行覆盖测试
- 利用静态结构分析的结果，通过代码检查和动态测试的方法对结果进一步确认，使测试工作更为有效
- 覆盖率测试是白盒测试的重点，使用基本路径测试达到语句覆盖标准；对于重点模块，应使用多种覆盖标准衡量代码的覆盖率
- 不同测试阶段，侧重点不同：
- 单元测试：以代码检查、逻辑覆盖
- 集成测试：增加静构结构分析、静态质量度量
- 系统测试：根据黑盒测试结果，采用白盒测试
黑盒测试
黑盒测试方法
等价类划分法
- 划分基础：需求规格说明书中输入、输出要求
- 等价类：某个输入域的子集合；分为有效等价类和无效等价类
- 有效等价类：指对于程序规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中的功能和性能
- 无效等价类：与有效等价的定义恰巧相反
- 划分等价类原则
序号
输入条件（数据）
划分等价类
1
规定了取值范围
值的个数
一个有效等价类
两个无效等价类
2
规定了输入值的集合
规定了"必须如何"的条件
一个有效等价类
一个无效等价类
3
是一个布尔量
一个有效等价类
一个无效等价类
4
输入数据的一组值（n个），并且程序对每一个输入值分别进行处理
n个有效等价类
一个无效等价类
5
规定必须遵守的规则
一个有效等价类（符合规则）
若干个无效等价类
6
在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
- 确定测试用例步骤
- 第一步：为每个等价类规定一个惟一的编号
- 第二步：设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
- 第三步：设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
边界值分析法
- 边界类型
- 边界条件：可以在产品说明书中有定义或者在使用软件过程中确定
- 次边界条件：在软件内部，也称为内部边界条件
- 其他边界条件：如输入信息为空（对于此类问题应建立单独的等价类空间）、非法、错误、不正确和垃圾数据
- 边界值的选择方法
序号
输入条件（数据）
输入边界值数据
1
规定了取值范围
刚刚达到这个范围
刚刚超越这个范围
2
规定值的个数
最大个数、比最大个数大1
最小个数、比最小个数少1
3
根据规格说明书的每个输出条件，使用 原则1、2
4
输入或输出是个有序集合
集合的第一个、最后一个元素
5
程序中使用一个内部数据结构
内部数据结构边界上的值
6
分析规格说明，找出其他可能的边界
错误推测法
错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。错误推测法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
因果图法
因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出条件），通过因果图转换成判定表。
判定表驱动法
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
适合使用判定表设计测试用例的条件：
- 规格说明以判定表的形式给出，或很容易转换成判定表
- 条件的排列顺序不影响执行哪些操作
- 规则的排列顺序不影响执行哪些操作
- 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
- 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要
正交试验法
正交试验法从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试验设计。正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面，每个参数就是一个因子，参数的不同取值就是水平，这样我们可以采用正交试验法设计出最少的测试组合，达到有效的测试目的。正交试验法有如下优点：
- 节省测试工时
- 可控制生成的测试用例的数量
- 测试用例具有一定的覆盖率
功能图法
一个程序的功能说明通常有动态说明和静态说明组成，动态说明描述了输入数据的次序或转移的次序，静态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序，由于存在大量的组合情况，仅用静态说明组成的规格说明对于测试来说是不够的，必须用动态说明来补充功能说明。功能图法是用功能图形形象地表示程序功能说明，并机械的生成功能图的测试用例。
功能图方法实际上是一种白盒和黑盒相混合的用例设计方法，要用到逻辑覆盖和路径测试的概念和方法。
场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
黑盒测试用例设计方法的选择策略
- 首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少测试量和提高测试效率的最有效办法
- 在任何情况下都必须使用边界值分析方法。此方法设计的测试用例发现程序错误的能力最强
- 可以用错误和推测法追加一些测试用例
- 对照程序的逻辑，检查已设计的测试用例的逻辑覆盖度，如果没有达到要求，应在补充
- 如果程序的功能说明中含有输入条件的组合情况，一开始就可以使用因果图法和判定表驱动法
- 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果
- 功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的数据
- 对于业务流清晰的系统，可以利用场景法贯空整个测试案例过程，在案例中综合使用各种方法
自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
测试用例设计
测试用例设计原则
- 单个用例覆盖最小化原则
这条原则是所有这四条原则中的"老大"，也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。
测试用例的覆盖边界定义更清晰，则测试结果对产品问题的指向性更强。
测试用例间的耦合度最低，则彼此之间的干扰也就越低。
上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容。
- 测试用例替代产品文档功能原则
通常我们会在开发的初期（Scrum每个Sprint的头两天）用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息，勾勒将要实现功能的样貌，便于团队进行交流和细化，并在团队内达成对产品功能共识。但随着产品开发深入，团队会对产品的功能有更新的认识，产品功能也会被更具体细化，在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复，在不断倾听和吸收用户的反馈，多个迭代过后，原本被描述为A的功能很可能最终变为了Z。这是时候再去看看曾经的Word文档和OneNote页面，它们仍然记录的是A。之所以会这样 ，是因为很少有人会去以及能够去不断地去更新那些文档，以准确地反映出功能当前准确的状态。
- 单次投入成本和多次投入成本原则
成本永远是任何项目进行决策时所要考虑的首要因素，项目中的测试也是如此，对成本的考虑也应该客观和全面的体现在测试的设计、执行和维护的整个阶段中。
测试中的成本按其时间跨度可以分为：单次投入成本和多次投入成本。例如：编写测试用例可以看作是单次投入成本，因为编写测试用例一般是在测试的计划阶段进行（Scrum每个Sprint的开始阶段）的，虽然后期会有小的改动，但绝大多数是在一开始的设计阶段就基本上成型了；
- 使测试结果分析和调试最简单化原则
这条原则实际上是单次投入成本和多次投入成本原则 - 针对自动化测试用例的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调试更为简单，包括：用例日志、调试辅助信息输出等。
测试用例设计方法
常用方法
- 等价类划分
- 边界值分析
- 错误推测
- 因果图
- 判定表驱动分析
- 正交实验设计
- 功能图法
- 场景设计法
测试用例设计角度
- 从需求到测试用例
从用户需求出发，了解功能设计背景。针对不同的功能特性会有多种用例，而每个用例有可以有多个不同的应用场景，所以，从需求到功能、从功能到用例、从用例到场景，可以逐步分解，形成一对多的关系，最后为每个应用场景设计一个到多个测试用例。
- 基于流程图设计测试用例
- 从程序流程图到业务流程图
针对功能测试用例，要从业务流程图着手，把业务需求转化为流程图。
- 根据业务流程图设计测试用例
逐层细化业务流程，并根据业务流程设计测试用例
- 基于UML视图设计测试用例
UML（Unified Modeling Language）即统一建模语言，它是一种定义良好、易于表达、功能强大且普遍适用的建模语言。UML视图包括结构图和行为图。结构图描述系统及其组成部分的静态关系，常包括类图、对象图、包图、综合结构图、组件图、部署图等。行为图描述系统的动态信息，包括用例图、状态机图、活动图、和交互作用图。根据测试方法选择不同的视图能够有效帮助我们设计测试用例。
| 很多应用中，功能点都存在一定的交叉，如果合理设计用例，不仅可以完成目标功能点测试，还可以覆盖其他交叉点的测试。 |
功能测试
功能测试主要分为以下几个阶段：测试准备、测试计划、测试用例设计、测试执行、测试总结。
测试准备
接到一个项目任务时，不要立即去执行测试用例，而是要先做好测试准备工作。
- 了解相关项目背景及其相关技术
了解做什么、为什么做、用了什么新技术等问题，对于测试人员，了解这些对发现更多缺陷、出现问题时进行有效分析将有很大帮助。
- 尽早发现问题、提出问题
从用户需求到产品需求说明书，再到用户接口规格说明书等一系列项目过程文档都是测试对象，问题发现的越早越好，可以减少不必要的麻烦，同时更好的保证质量。
- 画出功能图
分析业务功能点，画出功能图，方便理解需求、确定范围。
- 用数据流图描述业务范围
功能图描述了完成的主要功能点，而各功能点又有着一定的联系。可以通过流程图来抽象出功能点之间的数据流动及端到端的业务过程。
- 根据项目需求熟悉和掌握相关的系统信息
测试计划
根据项目相关文档，需要定义测试范围、测试策略、人员分配、软硬件配置、进度表以及测试过程每个阶段需要达到的目标
功能测试用例
功能测试用例的设计
测试用例必须能够使测试人员能够明确理解，并能够依据测试用例的描述执行测试。其次，测试之前必须明确功能逻辑，熟知每个测试用例的场景。
测试用例主要包括用例编号、用例描述、前提条件、输入数据、测试步骤和期望结果6项关键内容：
- 用例编号
用例的组织要方便测试人员执行测试用例，应设计一套良好的用例编号体系。
- 用例描述
用例描述应使用最精简的文字，描述出用例的全貌。让测试人员不用看测试步骤，只看这个描述就可以知道这个用例是描述哪个场景、哪个功能点。
- 前提条件
一个测试用例一般是针对一个特点的场景，而需要测试的场景发生时通常会有一些铺垫场景，即测试用例的前提，如软硬件环境配置、权限设置，数据准备。
- 输入数据
一个测试用例可以有一个或多个输入数据，也可以无输入数据。
- 测试步骤
测试步骤是测试用例的主体，一个测试用例由一个或多个步骤组成，每个步骤之间有一定的前后关系。每个步骤必须表述详细，描述清晰，用于规范、严谨而又客观，最基本的要求是能够使其他人理解，并能正确的执行编写者希望的操作。
- 期望结果
期望结果是测试执行对执行结果进行对比的标尺，是测试是否通过的判断依据。测试结果必须保证其正确性。
功能测试用例执行窍门
- 不要离开测试用例，但不依赖
测试用例是经过设计、思考的，力图涵盖所有的功能点，所以它是测试执行的依据，但是因为测试的深度有限，很难覆盖所有的路径，加上需求变更，测试用例很难及时更新，而且只生搬硬套测试用例执行，效果不好。手工测试时，仅把测试用例作为一个参考即可，不要过分依赖它，我们可以进行更多的发散测试，加上不断的思考，效果要好得多。
- 测试执行时，学会从测试用例中生成测试用例
测试用例的描述，有个基本原则是不要写得太复杂，所以功能交叉的测试用例，一般不会写得太复杂。但测试执行时，要特别注意多种条件组合及其逻辑先后顺序，要学会从多个单一的测试用例中，基于整体考虑而生成更多的测试用例，这也是熟悉业务的测试人员比不熟悉的测试人员发现更多测试点的原因之一。
功能测试方法
测试步骤
功能测试一般分为走查、基本功能验证、回归测试。
- 走查
正式测试之前，可以安排少量熟悉需求的人员走查一遍开发提交的测试版本，把基本需求、主要功能等走查一遍。如果有很多影响测试的问题，可以拒绝测试，让开发人员继续进行单元测试。
- 基本功能验证
参照测试用例，适时的查找相关文档来测试，在此测试的过程中，可以由表及里，由局部到整体进行测试。
- 回归测试
基于主要功能点和项目整个阶段、特别是最近修复的严重缺陷，反复验证测试用例
| 空或0值是数值的临界值，也常用作标记软件中某种特殊运行状态（如初始状态）或数据状态（如初始默认值），因此置零是软件边界测试重点，也是容易出现错误的地方，类似的还有空格、null、最大值、最小值等数据。 |
查找遗漏问题的方法
- Spec是基础和标准
测试的执行，通常按测试用例来进行，但测试用例的设计编写是依据产品规格说明书、需求规格说明书、界面设计规范等。写测试用例时难免有考虑不到的地方，因此反复阅读说明文档，也许会有一些新的思路和启发。在项目后期，回归测试阶段，容易思维定势、疲惫，这是可以把这些文档拿出来，再看一下功能点是否覆盖，覆盖到的是不是和需求一致，没有偏差。
- 相关变动邮件，讨论记录
变动是一个项目过程中不可少的部分，而这些变动，通常是通过讨论的方式定下来的，因此会有一些文档记录和邮件。反复阅读这些邮件和文档记录，可以更深入的理解项目。
- 不定期阅读别人的缺陷
每个人的思路、考虑的角度和操作习惯各不相同，因此发现的问题就会不一样。多阅读别人的缺陷可以拓宽思路，看多了，也会不自觉把多种思路集中到一起，慢慢得应用到测试实践中了。
- 多和开发人员沟通
功能测试对测试人员来说大多是黑盒测试，只有开发人员最清楚哪个函数调用哪个函数、哪块单元测试不够充分、哪个逻辑结构比较复杂，多和他们沟通，可以知道哪里还需要多关注一下。
- 有选择的重新验证以前的缺陷
特别在回归测试、验收测试阶段，除了验证前面发现的缺陷，还要重视那些与缺陷相关的模块。一个底层参数的变动，可能会引起很多相关功能的问题，继而造成缺陷的遗漏。
- 关注变化
一段代码的改动，需要开发人员和测试人员去识别。开发人员知道改动的地方会被哪些模块调用或者会引起哪些模块的变化，但由于时间紧、任务重、很难做好单元测试，因此开发人员要通知测试人员需要关注的测试点。
- 简单思维方式，以主线为主，减少大遗漏
一个项目的成功不是把缺陷全报出来，而是在有限的代价下达到预期的质量。按计划进行的项目，主要功能的质量在一定程度上决定了产品的好坏。在项目工期紧张时，全部走完所有测试用例是很难的，可以基本功能为主线，做好相关测试用例的执行，保证不会发生大的质量事故。
| 在测试后期，测试人员可能对质量已经很有信心，受思维和经验的局限性，可能仅限于此。若此时，在产品发布之前，调动其他组的员工参与限时测试并给予奖励，必然能有效减少软件缺陷带来的风险，提高产品质量。 |
缺陷预防
测试发现软件中的缺陷，避免问题在软件发布之后还遗留在系统里，实际上就是事后检查，确保所发布的产品满足用户需求，并具有较高的质量。但是当我们做测试时，问题已经发生了，我们只是去找问题，找到问题后让开发人员修正问题。修正问题需要返工，造成人力成本的浪费。如果是代码问题，返工比较少；如果是设计、需求的问题，就需要重新定义需求、修改设计，然后再修改代码。除了开发人员返工之外，测试人员在开发修改之后还要进行回归测试，会占用更多的人力成本。因此，我们要降低开发成本，就必须减少缺陷，根本方法就是预防问题的产生，从一开始就将事情做对、做好。
- 做好前期工作
自软件开发项目启动之时，从需求定义、系统设计到编程，就不断引入问题，质量也就取决于这个过程中引入多少问题。在这个工程中，引入的问题越少，质量就越高；引入的问题越多，质量就越低。要想减少问题、避免缺陷的引入，就要抓住每个入口，让每个入口符合标准、满足事先预定的要求。而在软件开发中就要做好需求评审、设计评审和代码评审等工作，以保证开发的各个环节都能获得高质量的阶段性成果。
- 缺陷的统计分析
通过软件缺陷根本原因分析（Root Cause Analysis，RCA），可以找到问题发生的根本原因。对缺陷进行分类统计，了解缺陷主要发生在哪些模块、哪一类缺陷最多或排在前三位缺陷的是哪几类，制订相应的防护措施，以避免今后发生类似的问题。需记录的缺陷信息包括：软件缺陷产生所属模块、缺陷来源（如需求设计文档、技术设计、源代码等）、缺陷被发现的阶段、缺陷所表现出的现象（如不清晰或错误的需求规范、不正确的行为、数据不一致、计算错误、设计不合理等）、测试跟踪（如新引进的缺陷、迟发现的缺陷、回归缺陷等）、缺陷对应的测试用例ID。
- 深度分析找到根本原因
只有找到问题的根本原因，才能消除问题产生的根源。主要从人员、技术、流程、业务四个方面出发，通过和团队讨论，一起回顾产品测试过程，就能发现问题的根本原因。
- 找到问题的解决办法
真正的原因被挖掘之后，找到解决的办法就不难了。当然，找到解决办法还不够，还需要设定相应的目标，跟踪这个改进过程，直至达到目标，如果没有达到效果，就需要进行新一轮的根本原因分析。在软件测试管理中，这是一个持续分析、持续改进的过程。
如何有效开展测试
- 周期性进行头脑风暴，促成知识交流、共享、升值
不同的测试人员对于测试软件的看法、实践经验都会有所不同，即使对于同一个软件，测试人员发现的缺陷也相差甚远，因此周期性进行头脑风暴，在一起讨论测试的系统、测试可能疏忽的问题，可以集众人智慧，促成知识融合，加快测试进度，保证测试质量。
- 项目中创造好的测试条件
在测试时间较紧的情况下，使得测试人员可能疲于"奔命"，这种情况下，测试人员学习的速度可能比较快，但是也可能因为疲劳、时间紧而放弃利用学过的知识及时调整测试的方法或细节。因此在项目进行中，权衡项目时间与测试质量是必须要考虑的。可以考虑给测试人员一定的时间自由轻松的去思考，去完善测试，从而持续优化质量。
- 根据具体项目、测试人员经验决策测试开展
项目的难度、测试人员的工作经验直接影响测试开展的时间、方式和效果。如果项目比较简单、测试人员经验丰富，在项目计划和测试设计阶段可完成大多数测试的设计，相反，如果测试项目难度大、测试人员经验不足，在测试计划阶段就要思索如何学习要测试的系统、如何有效的测试等问题。
敏捷测试
敏捷
开发
敏捷开发要求在短时间内开发出高质量的软件产品，并且符合客户需求。极限编程（XP）就是敏捷型开发的一种。与传统开发方法相比，敏捷开发有如下特点：
- 敏捷型方法是"适配性"而非"预设性"。传统开发方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。
- 敏捷型方法是"面向人"的(people-oriented) 而非"面向过程"的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。
以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。
敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。
【敏捷开发的理念】
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
【遵循的原则】
- 通过尽早的、持续的交付有价值的软件来使客户满意
- 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
- 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
- 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作
- 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈
- 工作的软件是首要的进度度量标准
- 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
- 不断地关注优秀的技能和好的设计会增强敏捷能力
- 简单是最根本的
- 最好的构架、需求和设计出于自组织团队
- 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整
敏捷测试
针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试，在敏捷团队中，测试是整个项目组的"车头灯"，它告诉大家现在到哪了，正在往哪个方向走。测试人员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试人员要保证质量，而是整个项目组的每一个人都要对质量负责。测试人员不跟开发人员纠缠错误，而是帮助他们找到目标，共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。
敏捷测试流程
根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：
- 验证需求和设计
需求和设计具体来说一般包括：
- 由项目经理根据需求文本而编写的功能设计文本（功能设计说明书）；
- 由开发人员根据功能文本而编写的实施设计文本（设计规范），包括架构文档、项目范围说明书、 使用案例 )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。
在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。
- 测试计划，测试用例
在敏捷开发的过程中由于是根据每个用户故事（user story）来估算时间的，开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。
测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的两种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。
在传统项目开发测试中，测试工程师需要花很多时间设计测试用例，这些测试用例具有详尽的数据准备、输入数据、严格的步骤和期望结果。对于敏捷开发团队来说，编写并维护一份系统功能和测试方法相结合的测试用例是个高效的方法。没有测试用例的测试是不可靠的，敏捷团队更需要设计易于阅读和测试的测试用例，来对系统功能及其测试方法的依据进行描述。适用于敏捷开发的测试用例应具有以下特点：
- 精简的：不需要列出那些可有可无的步骤和那些面面俱到的数据准备。
- 方法突出：列出被测试功能的测试点列表，输入数据可以是类似功能通用的和公共的数据，这些公共数据保存在一个公共测试用例中。
- 实施运行测试
在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。
- 单元测试
在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。
- 验证测试
测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。
在实施运行测试过程中，需要关注以下几项工作：
- 每日提供bug趋势
为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug，对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免。
- 测试用例的维护
在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时（敏捷项目中功能设计的更改频繁），所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。
- 根据项目不断补充常识（Common Sens）
在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的Common Sense标准。在以后的项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。
- 控制中间版本
为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。
- 发布版本前编写版本说明（Release Note）
在每次发布版本之前，测试人员要根据待发布的版本情况编写版本说明，使客户对发布的版本情况一目了然。版本说明主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug；New Features部分写明此版本新增加了哪些功能；Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。
- 需求管理
采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步。
- 项目开发末期开展"bug大扫除"
在项目开发的末期，可以开展"bug大扫除"活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员，目的是要集思广益。要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug。为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。测试活动可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。
敏捷测试总结
敏捷测试不能简单的理解为测得更快，绝对不是比以前用更少的时间进行测试，也不是将测试的范围缩小或将质量降低来减少测试任务。敏捷测试应该是适应敏捷开发方法而采用的新的测试流程、方法和实践。由于敏捷开发方法中迭代周期短，测试人员应尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单的说，敏捷测试就是持续地对软件质量问题进行及时的反馈。
文档测试
文档测试的范围
- 用户文档：用户手册、安装和设置指导、联机帮助、指南向导、样例事例模板、最终拥护许可协议、宣传材料等
- 开发文档：需求说明书、概要设计、数据库设计、详细设计、可行性研究报告
- 管理文档：项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告
用户文档
- 用户文档分类：包括包装上的文字及图案；宣传材料、广告及其他插页；授权/注册登记表；最终用户许可协议；标签和不干胶条；安装和设置指导；用户手册；联机帮助；指南、向导；样例、示例和模板；错误提示信息；
- 用户文档的作用
- 改善易安装性
- 改善软件的易学性及易用性
- 改善软件可靠性
- 降低技术支持成本
- 用户文档测试的方法及要点
用户文档测试方法及要点
【测试方法】
- 技术校对：对文档进行静态测试，发现文档中的错误，包括文档质量（如错别字）及技术描述（如是否符合逻辑、与其他文档是否一致）
- 功能测试：通过运行系统对文档进行测试
- 其他辅助方式：通过进行相关活动的同时对用户文档进行测试
【测试要点】
- 明确读者群：根据读者群（如初级、中级、高级用户）的不同来检查文档内容，保证用户能够看得懂、能理解
- 术语：文档中术语的描述要适合定位的读者群，用法一致，标准定义与业界规范相吻合
- 文档内容的正确性：要保证所有信息是真实正确的
- 文档内容的完整性：要完全根据提示逐步操作，检查是否存在遗漏的地方
- 文档与程序的一致性：按照文档操作后，检查软件返回的结果与文档描述是否一致
- 文档的易用性：检查是否便于用户查找相应的内容
- 图表与界面截图：检查所有图表与界面截图与发布的程序版本一致
- 样例和示例：检查所有的样例和示例能够正确完成；
- 语言：中文文档保证无错别字和二义性
- 印刷与包装：印刷质量，包装质量
【用户手册的测试】
- 准确的按照手册的描述使用程序
- 尝试每一条建议
- 检查每条陈述
- 查找容易误导用户的内容
【联机帮助的测试】
- 准确性
- 用户的查询：是否包含了索引和主题列表、是否能通过多种途径进入特定的主题中、是否可以通过超链接的方式进入主题页面等
- 帮助主题的完整性：是否有一些主题在索引中遗漏、超链接的层次是否全面、分类是否合理和完备
- 帮助的风格
缺陷管理
BUG的定义
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其应有功能的缺陷。一般定义缺陷有以下5条原则：
- 软件未实现产品说明书要求的功能。
- 软件出现产品说明书指明不应该出现的错误。
- 软件实现了产品说明书未说明的功能。
- 软件未实现产品说明书虽未明确提及但应该实现的目标。
- 软件难以理解，不易使用，运行速度慢，或者软件测试员认为最终用户会认为不好。
报告新的BUG
发现BUG
测试过程中，当发现某个界面不正确，某个功能不正常时，我们可以判为发现bug了。一般来说，bug会存在于下列情况之中：
- 用户体验不够好
用户体验不仅要求在满足功能需求的情况下简化操作、尽量减少用户界面新元素的个数，还包括用户视觉甚至是听觉等方面的感官体验。用户体验目标总结为：
- 引导新手快速成长、通过少量学习即可成为中间用户
- 避免或减少为那些想成为专家用户的中间用户设置障碍
- 让绝大多数的中间用户体验到愉悦，他们的技能将稳定的处于中间层
- 界面上有明显的错误信息
- 功能不完备，没有按照需求说明书编写代码，致使某些功能缺失
- 功能不完善，不能正常运行或者运行的过程中出现程序崩溃、停止运行的情况
- 逻辑不正确，与说明书不符
- 模块之间的交互性不好，与其他模块做集成测试时遇到问题
- 程序的性能不好，不能承载压力考验
隔离分析BUG
找到bug后，发现bug的测试人员不应该满足于记录bug的表面症状，重要职责是发现bug的根本原因。常用的隔离分析方法如下：
- 矩阵隔离法
例如，要隔离一个出现在某个平台上某个浏览器上的功能性bug，可以通过下面列出的矩阵分析记录：
平台/浏览器 | IE8(32bit/64bit) | Chrome3 | Firefox3.6 |
Win XP SP3 | |||
Win vista SP2 | |||
Win7（32bit/64bit） |
- 分段式隔离法
假如一个bug是因为经过了A、B、C、D操作以后产生的，我们可以对操作步骤进行分段隔离找出一个最简单的步骤。
- 对比隔离法
如果发现了一个bug，不能确定是不是bug时，可以采用对比法，检查下系统中其他类似的功能是如何设置的，这个bug是否是系统自身的特性。
提交BUG
Bug描述的基本要求是分类准确、叙述简洁、步骤清楚、实际结果描述准确、复杂问题有据可查（截图或其他形式的附件）。基本要求如下：
- 问题描述的一般格式
问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其他信息
- 单一：尽量一个bug只针对一个软件缺陷
- 简洁：每个步骤尽量简单明了
- 再现：问题必须能在自己机器上重现方可上报（个别严重问题重现不了也可上报，但必须标明）
- 复杂的问题：应附截图补充说明或直接通知指定的修改人，截图文件格式建议用JPG或GIF
- 报告中不允许使用抽象的词语：如"有错误"、"有时候"之类的不确定语句
- 有关操作系统特征问题：应在不同的操作系统上进行操作，并在bug中标识
处理提交的BUG
Bug提交后，测试人员要时刻准备向开发人员展示所发现的bug，同时需要说服开发人员，报告中的bug都是真实存在且需要解决的。在这个过程中，软件测试人员一定要为下面的几种情况做好准备：
- 开发人员反馈bug不存在
报告这个bug的最好方法是向开发人员展示它，这样他们可以真实的看到并了解我们是如何操作应用的，如何和应用交互的。测试人员应避免在最短时间内报告大量不能重现的bug。
- 缺陷在特定环境中偶尔才发生
面对这种问题，测试人员要有耐心，同时要保留测试数据和截屏等信息。
- 测试人员与开发人员看法不一致
有时因为配置问题或需求理解不一致等问题，开发人员不能重现问题，或与测试人员存在不同的看法。对于同一个测试结果，测试人员认为是错的，而开发人员认为是正确的，为了避免这种情况，最好找出客户原始的真实的需求是什么、我们真正看到了什么、发生了什么、从这几个方面说明我们的观点。
- 测试人员注意事项
发现bug时不要嘲笑开发人员，不要大声嚷嚷，并请留意另外一种极端：测试人员与开发人员关系很好，可能会导致测试的时候"手下留情"，这对项目也是一种伤害。
公司测试工作规范
