软件测试基础理论知识.doc

(word完整版)软件测试基础理论知识
一、 软件测试概论
1.1 基础概念
【定义】
软件测试是使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
它是帮助识别开发完成（中间或最终的版本)的计算机软件（整体或部分）的正确度 、完全度和质量的软件过程。
【内容】
软件测试主要工作内容是验证（verification)和确认(validation ）。
验证是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。（Do the right thing）
确认是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件（Do it right）
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期问各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序.
【目的】
软件测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

软件测试的出发点就是质量，软件测试的一切工作应该围绕质量而开展,测试是保证质量的重要手段之一，测试本身就是为质量服务的。

【原则】
(1) 测试的标准是用户的需求
所有的软件测试都应追溯到用户需求,测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。
(2) 事先定义好产品的质量标准
有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标.同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
(3) 应当“尽早地和不断地进行软件测试"作为测试者的座右铭
在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50％～60%.，缺陷存在放大趋势。如需求阶段的一个错误可能会导致N个设计错误，因此，越是测试后期,为修复缺陷所付出的代价就会越大。
(4) 制定测试计划，排除随意性
在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标.测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排,资源要求,测试资料,测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式,跟踪规则，调试规则,以及回归测试的规定等以及评价标准。
(5) 周密的测试用例，不可将测试用例抛开
要根据测试的目的，采用相应的方法去设计测试用例,从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试.
(6) 充分注意群集现象
抓住80/20原则可以有针对性的优化测试，在最短的时间内发现更多的问题，同时也能保证测试者对测试过程的整体把握。特别是当项目时间紧、复杂度高时，可以分时间、阶段、模块解决问题，是有效的解决问题的方式之一.
(7) 避免测试自己的程序
由于心理因素，人们潜意识都不希望找到自己的错误.基于这种思维定势，人们难于发现自己的错误.因此，软件开发者应尽量避免测试自己的产品，应由第三方来进行测试，当然开发者需要在交付之前进行相关的自测。一定程度的独立测试（可以避免开发人员对自己代码的偏爱)，可以更加高效的发现软件缺陷和软件存在的失效.但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷。在软件开发的早期，开发人员对自己的工作产品进行认真的测试,这也是开发人员的一个职责之一.
(8) 完全测试是不可能的，测试需要终止
穷尽测试是不可能的，应结合当前实际情况当满足一定的测试出口准则时测试就应当终止。
(9) 回归测试
修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
(10) 妥善保存一切测试过程文档
1.2 软件测试要素
(1) 质量:软件质量是软件测试的目标，也是软件测试工作的中心，一切从质量出发，也就是一切从客户需求出发。任何违背质量的东西都是问题,测试就是要找出这些问题.
(2) 人员:人是决定的因素,测试人员的态度、素质、能力决定着测试的效果，对测试产品的质量也有很大的影响。测试人员因素包括测试组织结构、角色和责任的定义。
(3) 技术：软件测试技术,包括方法、工具。
(4) 资源：主要是指测试环境中所需要的硬件设备、网络环境，甚至包括测试数据。另外一个重要因素就是测试时间,时间也是测试的资源，但测试人员不能看做资源，每个人的能力千差万别，不同的测试人员担任不同的角色，不能相互代替。这也是软件图书的经典之作--《人件》的作者反对将人作为资源对待的原因。
(5) 流程：从测试计划和测试用例的创建、评审到测试的执行、报告，设定每个阶段的进出标准。
1.3 软件测试与质量保证
1.3.1 软件质量
软件产品质量评价国际标准ISO 14598 把软件质量定义为：软件特性的总和,软件满足规定或潜在用户需求的能力。上述定义反应如下3个方面的问题:
(1) 软件需求是度量软件质量的基础；
(2) 软件人员必须遵循软件过程的规范;
(3) 如果软件只是满足规定的需求，而不能满足可能存在的隐含需求，软件质量也不能保证。
1.3.2 软件测试与软件质量保证的区别
软件测试只是质量保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作。
质量保证是通过预防、检查与改进来保证软件质量，采用全面质量管理和过程改进的原理来开展质量保证工作，主要关注软件质量的检查与测试，主要着眼于软件开发活动的过程、步骤和产物；软件测试是通过执行软件来对过程中的产物（开发文档和程序）进行走查，发现问题,报告质量.
具体说来,软件测试盒软件质量保证的区别体现在：从性质上看，软件测试属于技术性工作，而软件质量保证属于管理性工作；从对象上看，软件测试的对象是软件产品，而质量保证的对象是整个软件过程，覆盖公司层面的各个领域；从手段上看，软件测试以事后检验为主，而软件质量保证则强调缺陷的预防。

质量不是测试人员测试出来的，糟糕的早期设计结合最优的后期质量保证往往颇费力气，仍然打造不出用户满意度高的产品.

二、 软件测试过程管理
2.1 测试团队
2.1.1 测试团队的基本责任
(1) 发现软件程序、系统或产品中所有的问题
(2) 尽早地发现问题
(3) 督促和协助开发人员尽快地解决程序中的缺陷
(4) 帮助项目管理人员制定合理的开发计划
(5) 对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人员能够及时、清楚地了解产品当前的质量状态
(6) 帮助改善开发流程、调高产品开发效率
(7) 促进程序编写的规范性、易读性、可维护性等
2.1.2 测试团队的组成
如何组织一个测试团队,应当视企业的人力资源而定。
一般，一个比较健全的测试组，所具有的角色包括测试组长、实验室管理人员、自动化测试工程师、资深测试工程师、初级测试工程师。
测试组长:业务专家，负责项目的管理、测试计划的制定、项目文档的审查、测试用例的设计和审查、任务的安排、与项目经理和开发组长的沟通等
实验室管理人员：设置、配置和维护实验室的测试环境，主要是服务器和网络环境等
资深测试工程师:负责产品设计规格说明书的审查、测试用例的设计和技术难题的解决，主要参与数据库、系统性能和安全性等技术难度较高的测试
自动化测试工程师:负责测试工具的开发、测试脚本的开发等
初级测试工程师：执行测试用例和相关的测试任务,侧重功能测试用例的设计和执行
2.1.3 软件测试团队与开发团队的关系
软件测试与软件开发具有天然的联系。软件测试的输入是软件开发的产品，测试输出的结果需要开发人员相应处理，处理后的结果再次需要测试人员的验证。因此，软件测试与软件开发如影相随，互为服务对象。
开发人员和测试人员需要不断的沟通合作,才能持续优化项目。对于开发人员而言,利用测试人员对需求的理解，越早将测试提到项目周期，帮助就越大；对于测试人员而言,搞好和开发人员的关系，则可以在测试方向上获得更多的帮助:编写测试用例时询问可能遗漏的用例,在测试即将结束时询问测试是否有风险。
2.2 软件测试风险分析
(1) 风险类型
项目风险:指潜在的预算、进度、人力、资源、客户、需求等方面的问题，以及它们对软件项目的影响
技术风险：指潜在的设计、实现、接口、验证和维护等方面的问题
商业风险：商业风险威胁到要开发软件的生存能力
(2) 识别风险
识别风险是试图系统化地确定对项目计划的威胁,识别风险的一个方法是建立风险条目检查表,检查表包括:
产品规模:与要建造或要修改的软件的总体规模相关的风险
商业影响:与管理或市场所加诸的约束相关的风险
客户特性:与客户的素质以及开发者和客户定期通信的能力相关的风险
过程定义：与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险
开发环境：与用以建造产品的工具的可用性及质量相关的风险
建造的技术:与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险
人员数目及经验：与参与工作的软件工程师的总体技术水平及项目经验相关的风险
(3) 评估风险影响
风险的性质：当风险发生时可能产生的问题
风险的范围：结合了严重性及整体分布情况
风险的时间：主要考虑何时能够感到风险,风险会持续多长时间
(4) 风险应对
风险分析活动的目的是辅助项目组建立处理风险的策略，一个有效的策略必须考虑如下3各问题：
风险避免
风险监控
风险管理及意外事件计划
2.3 软件测试成本管理
【测试费用有效性】
测试的策略由商业的经济利益来决定，对风险测试过少，会造成软件的缺陷和系统的瘫痪，测试的过多，会增加测试成本。下图的测试费用-质量曲线可以形象的表示测试费用的有效性：

【测试成本】
测试实施成本：测试准备成本、测试执行成本、测试结束成本
【缺陷探测率】
缺陷探测率DDP是另一个衡量测试工作效率的软件质量成本的指标。
缺陷探测率DDP＝Bugs(tester)/ （Bugs（tester)+ Bugs（customer））
缺陷探测率越高，也就是测试者发现的错误多，发布后客户发现的错误就越少,降低了外部故障不一致成本，达到节约总成本的目的,可获得较高的测试投资回报率.
三、 测试流程
3.1 测试过程
软件测试过程一般包括：测试计划、测试设计、测试准备、测试执行、测试评估和缺陷跟踪等阶段，每个阶段都有一系列的任务。
测试过程具有以下几个特点:
(1) 测试工作开始于需求分析之后；
(2) 测试经过评估后,达到了结束的标准后才能结束；
(3) 测试也是迭代过程;
(4) 测试需求来自于软件需求；
(5) 测试过程与开发过程的关系;
(6) 都是软件过程的有机组成部分；
(7) 测试过程与开发过程同步进行；
(8) 测试过程与开发过程相互依赖，又相互独立；
(9) 开发过程、测试过程、项目管理过程以及其他支撑过程相互交织共同组成了软件过程。

3.2 测试过程的常见模型
3.2.1 V模型

映出了测试活动与分析设计活动的关系。从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系.
但V模型存在一定的局限性,它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能.
3.2.2 W模型

W模型强调:测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序,需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。
但W模型也存在局限性.在W模型中，需求、设计、编码等活动被视为串行的,同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束,才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。
3.2.3 H模型

H模型将测试活动完全独立出来，形成了一个完全独立的流程,将测试准备活动和测试执行活动清晰地体现出来。测试准备和测试执行分离，有利于资源调配,降低成本，调高效率。有组织、结构化的独立流程，有助于跟踪测试投入的流向。H模型还充分体现了测试过程（不是技术）的复杂性。

四、 测试技术
4.1 软件测试类型
4.1.1 按测试阶段划分
【单元测试】
(1) 定义：又称模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作；可以从程序的内部结构出发设计测试用例，多个模块测试可以平行地独立进行测试
(2) 目的：发现模块内部可能存在的各种差错
(3) 内容：模块接口测试（IO测试，数据的流入流出）、局部数据结构测试、路径测试、错误处理测试、边界测试。
(4) 步骤：利用设计文档设计测试用例;创建被测模块的桩模块或驱动模块；利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试
【集成测试】
(1) 定义：又称组装测试或联合测试,在单元测试基础上，将所有模块按概要设计和详细设计进行组装
(2) 目的：发现模块连接中的接口可能存在的各种差错
(3) 内容：
l 穿越模块之间的数据是否会丢失；
l 一个模块组装后是否会对另一模块或其他模块存在影响；
l 各个子功能组装在一起是否会达到预期的父功能；
l 全局数据结构是否有问题；
l 单个模块的错误累积起来是否会放在
(4) 组装方法:包括一次性组装方式、增殖式组装方式两种组装方法
(5) 完成标志：成功地执行了测试计划中规定的所有测试用例；修正了所发现的错误；测试结果通过专门小组的评审
【确认测试】
(1) 目的：验证软件的功能和性能及其他特性是否与用户的要求一致
(2) 测试内容:验证所测软件是否满足需求规格说明书列出的需求；所有文档正确且便于使用；软件可移植性、易用性、兼容性进行测试；软件配置复查；保证软件配置的所有成分都齐全
【系统测试】
(1) 目的：验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试
(2) 测试内容：在真实或模拟系统运行环境下,检查完整的程序系统能否和系统（硬件设备、网络、系统软件）正确配置、连接,满足用户需求
【验收测试】
(1) 测试目的：在用户环境中进行测试，以确定系统和产品是否能够满足合同或用户所规定的需求
(2) 测试内容：根据任务书或合迥、供需双方约定的验收依据文档进行对整个系统的测试与评审，确认是否接收或拒绝系统
4.1.2 按测试实施组织划分
【产商测试】
开发方测试通常也叫“验收测试”或“a测试”，在软件开发环境中,开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。
【用户测试】
在用户的应用环境下，用户检测与核实软件实现是否符合自己预期的要求.β测试通常被认为是用户测试,把软件有计划地免费地分发到目标市场，让用户大量使用、评价检查软件。
【第三方测试】
由第三方测试机构来进行的测试，也称独立测试。
4.1.3 按测试方法划分
【静态测试】
静态测试又称为静态分析技术，不执行被测试软件，对需求分析说明书、软件设计说明书、源程序做结构检测、流图分析、符号执行等找出软件的错误.
【动态测试】
通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序，而达到发现程序错误的过程。
4.1.4 按测试技术划分
【白盒测试】
白盒测试也称为结构测试或逻辑驱动测试，是通过对程序内部结构的分析、检测来寻找问题,检查程序的结构及路径是否正确，检查程序的内部动作是否按照设计说明的规定正常进行.
【黑盒测试】
黑盒测试又称功能测试，通过运行程序发现其缺陷和错误。黑盒测试是对程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用,程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息的完整性.
【灰盒测试】
介于白盒和黑盒测试之间，关注输出对于输入的正确性，也关注程序的内部结构,但没有白盒测试那样详细、完整.
4.2 白盒测试
4.2.1 白盒测试方法
4.2.1.1 代码检查法
【检查内容】
代码检查包括桌面检查，代码审查和走查等方式，主要对以下内容进行检查：
检查代码和设计的一致性
代码对标准的遵循、可读性
代码逻辑表达的正确性
代码结构的合理性
程序编写与编写标准的符合性
程序中不安全、不明确和模糊的部分
编程风格问题等
【检查方式】
(1) 桌面检查:由程序员对源程序代码进行分析、检验，并补充相关的文档,发现程序中的错误。
(2) 代码审查：由程序员和测试员组成的审查小组通过阅读、讨论和争议，以程序进行静态分析的过程。
(3) 走查：程序员和测试员组成的审查小组通过逻辑运行程序，发现问题。
【检查项目】
检查变量的交叉引用表：检查未说明的变量和违反了类型规定的变量，变量的引用和使用情况
检查标号的交叉引用表：验证所有标号的正确性
检查子程序、宏、函数：验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致
等价性检查:检查全部等价变量的类型的一致性
常量检查:确认常量的取值和数制、数据类型
标准检查：检查程序中是否违反标准的问题
风格检查：检查程序的设计风格
比较控制流:比较设计控制流图和实际程序生成的控制流图的差异
选择、激活路径：在设计控制流图中选择某条路径，到实际的程序中激活这条路径，如果不能激活,则程序可能有错
对照程序的规格说明，详细阅读源代码,比较实际的代码，从差异中发现程序的问题和错误
4.2.1.2 静态结构分析法
在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构,生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形图表，清晰地标识整个软件的组成结构,便于理解,通过分析这些图表，检查软件有没有存在缺陷或错误。主要包括控制流分析、数据据流分析、接口分析、表达式分析。
4.2.1.3 代码质量度量法
代码质量度量法即根据ISO 9126质量模型的6个方面（即功能性、可靠性、易使用性、效率、可维护性、可移植性)对软件进行的动态测试方法.白盒测试的动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。动态测试通常在静态测试之后进行。白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：
保证每个模块的所有独立路径至少被使用一次
对所有的逻辑值均测试true和false
上下边界及可操作范围内运行所有循环
检查内部数据结构以确保其有效性
4.2.2 白盒测试综合策略
(1) 在测试中，首先尽量使用测试工具进行静态结构分析
(2) 采用先静态后动态的组合方式，先进行静态结构分析,代码检查和静态质量度量，然后现进行覆盖测试
(3) 利用静态结构分析的结果，通过代码检查和动态测试的方法对结果进一步确认，使测试工作更为有效
(4) 覆盖率测试是白盒测试的重点，使用基本路径测试达到语句覆盖标准；对于重点模块，应使用多种覆盖标准衡量代码的覆盖率
(5) 不同测试阶段，侧重点不同：
Ø 单元测试:以代码检查、逻辑覆盖
Ø 集成测试：增加静构结构分析、静态质量度量
Ø 系统测试:根据黑盒测试结果，采用白盒测试
4.3 黑盒测试
4.3.1 黑盒测试方法
4.3.1.1 等价类划分法
(1) 划分基础:需求规格说明书中输入、输出要求
(2) 等价类：某个输入域的子集合；分为有效等价类和无效等价类
有效等价类：指对于程序规格说明书来说是合理的、有意义的输入数据构成的集合.利用有效等价类可以检验程序是否实现了规格说明书中的功能和性能
无效等价类：与有效等价的定义恰巧相反
(3) 划分等价类原则
序号
输入条件（数据）
划分等价类
1
规定了取值范围
值的个数
一个有效等价类
两个无效等价类
2
规定了输入值的集合
规定了“必须如何”的条件
一个有效等价类
一个无效等价类
3
是一个布尔量
一个有效等价类
一个无效等价类
4
输入数据的一组值（n个），并且程序对每一个输入值分别进行处理
n个有效等价类
一个无效等价类
5
规定必须遵守的规则
一个有效等价类（符合规则）
若干个无效等价类
6
在确知已划分的等价类中,各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
(4) 确定测试用例步骤
第一步：为每个等价类规定一个惟一的编号
第二步:设计一个新的测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步骤,最后使得所有有效等价类均被测试用例所覆盖
第三步：设计一个新的测试用例,使其只覆盖一个无效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
4.3.1.2 边界值分析法
(1) 边界类型
边界条件:可以在产品说明书中有定义或者在使用软件过程中确定
次边界条件：在软件内部,也称为内部边界条件
其他边界条件：如输入信息为空(对于此类问题应建立单独的等价类空间)、非法、错误、不正确和垃圾数据
(2) 边界值的选择方法
序号
输入条件（数据)
输入边界值数据
1
规定了取值范围
刚刚达到这个范围
刚刚超越这个范围
2
规定值的个数
最大个数、比最大个数大1
最小个数、比最小个数少1
3
根据规格说明书的每个输出条件，使用 原则1、2
4
输入或输出是个有序集合
集合的第一个、最后一个元素
5
程序中使用一个内部数据结构
内部数据结构边界上的值
6
分析规格说明,找出其他可能的边界

4.3.1.3 错误推测法
错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。错误推测法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据它们选择测试用例。
4.3.1.4 因果图法
因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出条件)，通过因果图转换成判定表。
4.3.1.5 判定表驱动法
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
适合使用判定表设计测试用例的条件：
规格说明以判定表的形式给出，或很容易转换成判定表
条件的排列顺序不影响执行哪些操作
规则的排列顺序不影响执行哪些操作
当某一规则的条件已经满足，并确定要执行的操作后,不必检验别的规则
如果某一规则要执行多个操作，这些操作的执行顺序无关紧要
4.3.1.6 正交试验法
正交试验法从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试验设计。正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面,每个参数就是一个因子，参数的不同取值就是水平,这样我们可以采用正交试验法设计出最少的测试组合,达到有效的测试目的。正交试验法有如下优点:
节省测试工时
可控制生成的测试用例的数量
测试用例具有一定的覆盖率
4.3.1.7 功能图法
一个程序的功能说明通常有动态说明和静态说明组成,动态说明描述了输入数据的次序或转移的次序，静态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序，由于存在大量的组合情况,仅用静态说明组成的规格说明对于测试来说是不够的，必须用动态说明来补充功能说明。功能图法是用功能图形形象地表示程序功能说明，并机械的生成功能图的测试用例。
功能图方法实际上是一种白盒和黑盒相混合的用例设计方法,要用到逻辑覆盖和路径测试的概念和方法。
4.3.1.8 场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

4.3.2 黑盒测试用例设计方法的选择策略
(1) 首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少测试量和提高测试效率的最有效办法
(2) 在任何情况下都必须使用边界值分析方法.此方法设计的测试用例发现程序错误的能力最强
(3) 可以用错误和推测法追加一些测试用例
(4) 对照程序的逻辑，检查已设计的测试用例的逻辑覆盖度，如果没有达到要求，应在补充
(5) 如果程序的功能说明中含有输入条件的组合情况，一开始就可以使用因果图法和判定表驱动法
(6) 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果
(7) 功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的数据
(8) 对于业务流清晰的系统，可以利用场景法贯空整个测试案例过程，在案例中综合使用各种方法
4.4 自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程.通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中,为了节省人力、时间或硬件资源，提高测试效率,便引入了自动化测试的概念。
五、 测试用例设计
5.1 测试用例设计原则
(1) 单个用例覆盖最小化原则
这条原则是所有这四条原则中的“老大“,也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。
测试用例的覆盖边界定义更清晰,则测试结果对产品问题的指向性更强。
测试用例间的耦合度最低,则彼此之间的干扰也就越低。
上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容。
(2) 测试用例替代产品文档功能原则
通常我们会在开发的初期（Scrum每个Sprint的头两天）用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息，勾勒将要实现功能的样貌，便于团队进行交流和细化，并在团队内达成对产品功能共识.但随着产品开发深入，团队会对产品的功能有更新的认识,产品功能也会被更具体细化，在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复，在不断倾听和吸收用户的反馈，多个迭代过后，原本被描述为A的功能很可能最终变为了Z.这是时候再去看看曾经的Word文档和OneNote页面，它们仍然记录的是A.之所以会这样 ，是因为很少有人会去以及能够去不断地去更新那些文档，以准确地反映出功能当前准确的状态.
(3) 单次投入成本和多次投入成本原则
成本永远是任何项目进行决策时所要考虑的首要因素，项目中的测试也是如此,对成本的考虑也应该客观和全面的体现在测试的设计、执行和维护的整个阶段中。
测试中的成本按其时间跨度可以分为：单次投入成本和多次投入成本.例如：编写测试用例可以看作是单次投入成本，因为编写测试用例一般是在测试的计划阶段进行(Scrum每个Sprint的开始阶段)的，虽然后期会有小的改动，但绝大多数是在一开始的设计阶段就基本上成型了;
(4) 使测试结果分析和调试最简单化原则
这条原则实际上是单次投入成本和多次投入成本原则 - 针对自动化测试用例的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调试更为简单，包括：用例日志、调试辅助信息输出等.
5.2 测试用例设计方法
5.2.1 常用方法
(1) 等价类划分
(2) 边界值分析
(3) 错误推测
(4) 因果图
(5) 判定表驱动分析
(6) 正交实验设计
(7) 功能图法
(8) 场景设计法
5.2.2 测试用例设计角度
(1) 从需求到测试用例
从用户需求出发，了解功能设计背景。针对不同的功能特性会有多种用例,而每个用例有可以有多个不同的应用场景,所以，从需求到功能、从功能到用例、从用例到场景，可以逐步分解，形成一对多的关系，最后为每个应用场景设计一个到多个测试用例。
(2) 基于流程图设计测试用例
Ø 从程序流程图到业务流程图
针对功能测试用例，要从业务流程图着手，把业务需求转化为流程图。
Ø 根据业务流程图设计测试用例
逐层细化业务流程,并根据业务流程设计测试用例
(3) 基于UML视图设计测试用例
UML（Unified Modeling Language）即统一建模语言，它是一种定义良好、易于表达、功能强大且普遍适用的建模语言。UML视图包括结构图和行为图。结构图描述系统及其组成部分的静态关系，常包括类图、对象图、包图、综合结构图、组件图、部署图等.行为图描述系统的动态信息，包括用例图、状态机图、活动图、和交互作用图。根据测试方法选择不同的视图能够有效帮助我们设计测试用例。

很多应用中，功能点都存在一定的交叉，如果合理设计用例,不仅可以完成目标功能点测试，还可以覆盖其他交叉点的测试。

六、 功能测试
功能测试主要分为以下几个阶段：测试准备、测试计划、测试用例设计、测试执行、测试总结。
6.1 测试准备
接到一个项目任务时，不要立即去执行测试用例,而是要先做好测试准备工作。
(1) 了解相关项目背景及其相关技术
了解做什么、为什么做、用了什么新技术等问题，对于测试人员，了解这些对发现更多缺陷、出现问题时进行有效分析将有很大帮助。
(2) 尽早发现问题、提出问题　
从用户需求到产品需求说明书,再到用户接口规格说明书等一系列项目过程文档都是测试对象，问题发现的越早越好，可以减少不必要的麻烦，同时更好的保证质量。
(3) 画出功能图
分析业务功能点，画出功能图，方便理解需求、确定范围。
(4) 用数据流图描述业务范围
功能图描述了完成的主要功能点,而各功能点又有着一定的联系。可以通过流程图来抽象出功能点之间的数据流动及端到端的业务过程。
(5) 根据项目需求熟悉和掌握相关的系统信息
6.2 测试计划
根据项目相关文档，需要定义测试范围、测试策略、人员分配、软硬件配置、进度表以及测试过程每个阶段需要达到的目标
6.3 功能测试用例
6.3.1 功能测试用例的设计　
测试用例必须能够使测试人员能够明确理解，并能够依据测试用例的描述执行测试。其次,测试之前必须明确功能逻辑，熟知每个测试用例的场景。
测试用例主要包括用例编号、用例描述、前提条件、输入数据、测试步骤和期望结果6项关键内容：
(1) 用例编号
用例的组织要方便测试人员执行测试用例,应设计一套良好的用例编号体系.
(2) 用例描述
用例描述应使用最精简的文字，描述出用例的全貌。让测试人员不用看测试步骤,只看这个描述就可以知道这个用例是描述哪个场景、哪个功能点。
(3) 前提条件
一个测试用例一般是针对一个特点的场景，而需要测试的场景发生时通常会有一些铺垫场景，即测试用例的前提，如软硬件环境配置、权限设置，数据准备。
(4) 输入数据
一个测试用例可以有一个或多个输入数据，也可以无输入数据。
(5) 测试步骤
测试步骤是测试用例的主体，一个测试用例由一个或多个步骤组成，每个步骤之间有一定的前后关系。每个步骤必须表述详细，描述清晰,用于规范、严谨而又客观，最基本的要求是能够使其他人理解,并能正确的执行编写者希望的操作。
(6) 期望结果
期望结果是测试执行对执行结果进行对比的标尺，是测试是否通过的判断依据。测试结果必须保证其正确性。
6.3.2 功能测试用例执行窍门
(1) 不要离开测试用例,但不依赖
测试用例是经过设计、思考的，力图涵盖所有的功能点，所以它是测试执行的依据,但是因为测试的深度有限，很难覆盖所有的路径，加上需求变更,测试用例很难及时更新，而且只生搬硬套测试用例执行，效果不好。手工测试时，仅把测试用例作为一个参考即可，不要过分依赖它，我们可以进行更多的发散测试，加上不断的思考,效果要好得多。
(2) 测试执行时，学会从测试用例中生成测试用例
测试用例的描述，有个基本原则是不要写得太复杂,所以功能交叉的测试用例，一般不会写得太复杂。但测试执行时，要特别注意多种条件组合及其逻辑先后顺序，要学会从多个单一的测试用例中，基于整体考虑而生成更多的测试用例，这也是熟悉业务的测试人员比不熟悉的测试人员发现更多测试点的原因之一。
6.4 功能测试方法
6.4.1 测试步骤
功能测试一般分为走查、基本功能验证、回归测试.
(1) 走查
正式测试之前，可以安排少量熟悉需求的人员走查一遍开发提交的测试版本,把基本需求、主要功能等走查一遍.如果有很多影响测试的问题,可以拒绝测试，让开发人员继续进行单元测试。
(2) 基本功能验证
参照测试用例，适时的查找相关文档来测试，在此测试的过程中，可以由表及里，由局部到整体进行测试。
(3) 回归测试
基于主要功能点和项目整个阶段、特别是最近修复的严重缺陷，反复验证测试用例

空或0值是数值的临界值，也常用作标记软件中某种特殊运行状态（如初始状态）或数据状态（如初始默认值），因此置零是软件边界测试重点，也是容易出现错误的地方，类似的还有空格、null、最大值、最小值等数据.

6.4.2 查找遗漏问题的方法
(1) Spec是基础和标准
测试的执行，通常按测试用例来进行，但测试用例的设计编写是依据产品规格说明书、需求规格说明书、界面设计规范等。写测试用例时难免有考虑不到的地方，因此反复阅读说明文档,也许会有一些新的思路和启发。在项目后期,回归测试阶段,容易思维定势、疲惫，这是可以把这些文档拿出来，再看一下功能点是否覆盖，覆盖到的是不是和需求一致，没有偏差。
(2) 相关变动邮件，讨论记录
变动是一个项目过程中不可少的部分，而这些变动，通常是通过讨论的方式定下来的，因此会有一些文档记录和邮件.反复阅读这些邮件和文档记录,可以更深入的理解项目。
(3) 不定期阅读别人的缺陷
每个人的思路、考虑的角度和操作习惯各不相同，因此发现的问题就会不一样.多阅读别人的缺陷可以拓宽思路，看多了，也会不自觉把多种思路集中到一起，慢慢得应用到测试实践中了。
(4) 多和开发人员沟通
功能测试对测试人员来说大多是黑盒测试,只有开发人员最清楚哪个函数调用哪个函数、哪块单元测试不够充分、哪个逻辑结构比较复杂，多和他们沟通，可以知道哪里还需要多关注一下。
(5) 有选择的重新验证以前的缺陷
特别在回归测试、验收测试阶段，除了验证前面发现的缺陷,还要重视那些与缺陷相关的模块.一个底层参数的变动，可能会引起很多相关功能的问题，继而造成缺陷的遗漏.
(6) 关注变化
一段代码的改动,需要开发人员和测试人员去识别。开发人员知道改动的地方会被哪些模块调用或者会引起哪些模块的变化，但由于时间紧、任务重、很难做好单元测试,因此开发人员要通知测试人员需要关注的测试点。
(7) 简单思维方式，以主线为主，减少大遗漏
一个项目的成功不是把缺陷全报出来，而是在有限的代价下达到预期的质量。按计划进行的项目，主要功能的质量在一定程度上决定了产品的好坏.在项目工期紧张时，全部走完所有测试用例是很难的,可以基本功能为主线,做好相关测试用例的执行，保证不会发生大的质量事故。

在测试后期，测试人员可能对质量已经很有信心，受思维和经验的局限性,可能仅限于此.若此时，在产品发布之前,调动其他组的员工参与限时测试并给予奖励,必然能有效减少软件缺陷带来