软件测试培训资料课件.pptx

1、软件测试培训资料内容软件测试理论基础软件测试流程软件项目运作流程软件测试工作流程软件测试用例设计方法软件缺陷测试的技巧测试工具的选择软件的测试整个过程软件测试理论基础测试行业简介 软件测试在软件生命周期中占据重要作用。 软件生命周期的每个阶段都应该包含测试从而检验本阶段的成果是否接近预期的目标，尽可能早的发现错误并加以修正。 由于测试的重要性和复杂度，它慢慢的独立发展成为一个行业，并且在迅猛发展。 在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的 40 以上。而在软件开发的总成本中，用在测试上的开销要占 30 到 50 软件测试概论（概述） 1975年，“测试数据选择的原理”（T

2、oward a theory of Test Data）的文章，软件测试才被确定为一种研究方向。 1979年，“软件测试时为发现错误而执行一个程序或者系统的过程” 1983年，“测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的一种度量”。 2002年，“测试是为了度量和提高被测试软件的质量，对测试软件进行工程设计、实施、维护的的整个生命周期过程”。软件测试概论（行情）国外： A、软件测试在软件公司中占有重要的地位 B、软件测试理论研究蓬勃发展，引领软件测试理论研究的国际潮流 C、软件测试市场繁荣国内： 1、我国著名的软件公司都已经或者正在建立独立的专职软件测试队伍 2、

3、国家开始对软件测试职业高度重视和认可（软考中级资格中增加软件评测师）软件测试概论（行情） 3、用户对软件质量要求越来越高，通过第三方测试机构的严格测试来判定 4、市场需求量不断增大，软件测试工程师的待遇也在不断提高。北京地区的薪资趋势大致如图1-1所示。图1-1 薪资趋势图测试工程师的职业发展 软件测试工程师一般有几个方向可走，如图1-2所示。 一个理想的测试工程师应该有开发经验，至少要有开发的概念。仅仅发现Bug是测试的初步，而分析出根本原因，却要有很深的功底。初级测试工程师中级测试工程师开发工程师测试管理者高级测试工程师图1-2 职业发展规划图企业需要怎样的测试人才？v一年以上软件测试经验

4、v计算机相关专业大专以上学历v了解软件工程，熟悉软件测试过程和标准，熟悉配置管理技术和工具v能够编制测试计划、设计测试用例、编写Bug报告和测试总结报告、使用测试工具、开发测试脚本v熟练使用Windows或Unix或Linux操作系统企业需要怎样的测试人才？v熟练C、C+、Java、VB、Delphi、C#中的一种以上v熟练使用SQL Server或Oracle数据库v了解业务领域（ERP、OA、电子商务、税务系统、电信计费系统）v熟练掌握至少一种以上的测试工具，如TestDirector、QTP、LoadRunner、Robotv进取、合作、表达、沟通、责任心、耐心、认真程度测试学习路线 对

5、于软件测试初学者，我们要切合实际、循序渐进的学习，在学习中可参考图1-3所示的软件测试学习路线图，从软件测试的理论基础，到项目实战，逐步学习，掌握技术技能，最终胜任软件测试工作。初初学学者者软件测试理论基础学习缺陷管理知识学习Web测试环境搭建学习Linux操作系统知识学习配置管理知识学习数据库知识学习QTP功能测试工具学习LoadRunner性能测试工具学习项目实战岗前培训面试技巧工工作作图1-3 软件测试学习路线图软件测试由来v调试 在已知错误的情况下，对软件程序代码做出的一系列检查，校正的过程。v测试 在未知错误的情况下，检查程序代码是否有问题的过程。v区分：软件测试从软件质量保证的角度

6、来检查程序代码是否有误，而调试是为了解决当前已知的错误，调试活动无法替代软件测试活动。软件测试定义 定义：定义：软件测试就是为了发现错误而审查软件文档、检查软件数据和执行程序代码的过程。 软件测试应该是对软件形成过程的文档,数据以及程序进行的测试,而不仅是对程序进行的测试。 60%以上的软件错误并不是程序错误,而是分析和设计的错误,提倡软件全生命周期测试的理念。什么是软件质量 1991年国际标准ISO 9126中定义为:软件满足规定或潜在用户需求的总和。 1999年国际标准ISO 14598中定义为:软件特性的总和，软件满足规定或潜在用户需求的能力。 2001年国际标准ISO 9126中定义为

7、：软件满足规定用户或潜在用户需求的能力，要从软件在内部，外部和使用过程中的表现来衡量，包含内部质量、外部质量、和使用质量。软件测试与质量保证的区别 软件质量保证和软件测试是软件质量工程中两个不同层面的工作。 质量保证(QA):质量保证的重要工作通过预防，检查与改进来保证软件质量(所关注的是软件质量的检查与测量,着眼于软件开发的过程,步骤和产物)。 软件测试：测试过程虽然与开发过程紧密相关但，关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。软件测试的目的和原则 基于不同的立场，存在着两种完全不同的测试目的： 用户角度用户角度：希望软件测试暴露软件中隐藏的错误和缺陷，已考虑是否接受

8、产品。 软件开发者角度软件开发者角度：希望测试成为表明软件产品中不存在错误的过程，验证被测软件已正确的实现了用户的需求，确立人们对软件质量的信心。软件测试的目的和原则换言之，测试的目的是： 想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。 测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。 实施测试收集到的测试结果数据为可靠性分析提供了依据 测试不能表明软件中不存在错误，它只能说明软件中存在错误软件测试的目的和原则 软件测试的原则： 所有的软件测试都应追溯到用户需求。 应当把“尽早地和不断地进行软件测试”作为软件测试

9、者的座右铭。 完全测试是不可能的，测试需要终止。 测试无法显示软件潜在的缺陷。也就是说测试只能证明软件存在错误而不能证明软件没有错误。软件测试的对象 根据软件定义，软件包括程序，数据和文档，所以软件测试并不仅仅是程序测试，软件测试应该贯穿整个软件生命周期中。 需求分析，概要设计，详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明，概要设计规格说明，详细设计规格说明以及源程序。软件测试的对象为了把握各个环节的正确性，人们需要进行各种验证和确认工作 ： 验证(verification)： 是保证软件正确实现特定功能的一系统活动和过程,目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段

10、所设定的目标。 确认(validation)： 是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件，用户需求相符合。软件测试的对象软件测试分类 一般的，我们将软件测试活动分为以下几类：l 黑盒测试、l 白盒测试、l 灰盒测试、l 静态测试、l 动态测试、l 手动测试、l 自动测试软件测试分类黑盒测试v黑盒测试又叫功能测试、数据驱动测试或基于需求规格说明书的功能测试。该测试类别注重于测试软件的功能性需求。v测试工程师无需了解程序代码的内部构造，完全模拟软件产品的最终端用户使用该软件，检查软件产品是否达到了用户的需求。v如图1-4所示为黑盒测试实例图。v黑盒测试能更好的从用

11、户角度来考察被测系统的功能性需求实现情况。测试用例测试结果图1-4 黑盒测试示例图软件测试分类白盒测试v白盒测试又称结构测试、逻辑驱动测试或基于程序代码内部构成的测试。v白盒测试需要测试工程师深入考查程序代码的内部结构、逻辑设计等。v就像前面的例子，我们拆开手机，观察手机电路板的设计，液晶屏的构成等。v对于白盒测试工程师来说，软件产品的内部结构是敞开的。如图1-5所示是白盒测试示例图。程序内部结构测试用例测试结果图1-5 白盒测试示例图软件测试分类灰盒测试v灰盒测试介于白盒和黑盒测试之间。v灰盒测试一方面考虑程序代码的功能性表现，另一方面，又需要考虑程序代码的内部结构。v通俗地讲，灰盒测试就是

12、白加黑。v像我们的性能测试，自动化功能测试就是采用了灰盒测试的方法。v图1-6是灰盒测试的示例图。测试用例测试结果图1-6 灰盒测试示例图软件测试分类静态测试v定义：静态的、不执行被测对象程序代码而寻找缺陷的过程。v在进行静态测试时可采用一些代码走查工具，如QAC+、C+Test等。软件测试分类动态测试 实际的执行被测对象的程序代码，输入实现设计好的测试用例，检查程序代码运行得到的结果与测试用力中设计的预期结果之间是否有差异，判定实际结果与预测结果是否一致。 动态测试有四部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告。 动态测试有三种主要方法：黑盒测试、白盒测试和灰盒测试

13、软件测试分类手动测试 它是测试人员设计测试用例并执行测试用例，然后根据实际的结果去和预期的结果相比较并记录测试结果，最终输出测试报告的测试活动。 可充分发挥测试工程师的主观能动性，将其智力体现在测试工作中，能发现许多的缺陷，但同时又有一定的局限性和单调枯燥性。软件测试分类自动化测试 定义 利用测试工具，模拟用户业务使用流程，让他们自动运行来查找缺陷。 优点 快、广泛、可重复性工作 缺点 只可检查比较主要的问题，如崩溃、死机，无法发现一般的日常错误。编写脚本工作量 也很大，有时会超过手动测试时间。 我们要根据实际情况选择或者不选择测试工具，选择使用何种测试工具，不能为了实用工具而可以的去使用工具

14、。软件测试人员职业要求 从个人素质角度要求测试工程师需要具备以下6种素质： 责任心 沟通能力 团队合作精神 耐心、细心和信心 时时保持怀疑态度、并且有缺陷预防的意识 不断学习的能力软件测试流程软件测试流程图 软件测试虽然是软件生存周期的一个独立阶段，但测试工作却渗透到从分析、设计直到编程的各个阶段中（1-7是软件测试所经阶段的一般流程）。 需求测试、单元测试、集成测试、系统测试、性能测试、用户测试、回归测试需求测试单元测试集成测试系统测试性能测试用户测试回归测试图1-7 软件测试流程图需求测试 要从以下几个方面考虑需求测试：l 完整性 正确性l 一致性 可行性l 无二义性 健壮性l 必要性 可

15、测试性l 可修改性单元测试 又称模块测试，就是对程序代码中最小的涉及模块单元进行测试。 在单元测试中我们主要采用静态测试与动态测试相结合的办法。 单元测试要求需要几年的代码编写经验，并且要十分熟悉当前的被测系统，以及该系统是否与其他系统的接口关联情况。 单元测试在编码阶段占据非常重要的地位。 可以降低编码的错误率，提高编码质量集成测试 又称组装测试，是将软件产品各个模块组装起来，检查接口是否存在问题，以及组装后的整体功能、性能表现。 一般可采用非增式集成方法、增式集成方法（自底向上集成、自顶向下集成、组合方式集成）等策略进行测试，利用一黑盒测试为主，白盒测试为辅的测试方法进行测试。 主要解决各

16、个组成但源代码是否符合开发规范、接口是否存在问题，整体功能有无错误、界面是否符合设计规范、性能是否满足用户需求等。系统测试 将通过集成测试的软件部署到某种较为复杂的计算机永华环境进行测试。 目的：通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。 这个阶段主要进行的是安装卸载测试、兼容性测试、功能确认测试、安全测试等。 采用黑盒测试法，主要考察被测软件的功能与性能表现。性能测试 性能测试要求被测软件在业务处理速度、处理能力和所耗用的硬件系统资源比率满足用户的需求。 不要尝试用手动方式进行性能测试，应当编写一段相应的程序或者使用专门的工具进行，如利用LoadRunner自动

17、化性能测试工具。 性能测试相对难度较大，要求测试人员掌握编程语言，精通业务流程，拥有深厚的项目经验。用户测试 可称为用户确认测试。 正式验收前，需要用户对本系统做出一个评价，用户可对交付的系统做测试，并将测试结果反馈回来，进行修改、分析。 用户测试环节是被测试软件首次作为正式的系统交友用户使用，用户会根据他们的实际使用情况进行测试、使用，并提出实际使用过程中的问题。 用户测试是软件生产流程中的最后质检关。回归测试 回归测试是经过一段时间以后再回过头来对以前修复过的Bug重新进行测试，看该Bug是否会重新出现。 有些时候可采用自动化测试工具来进行回归测试，如利用QTP 一般情况下，都由测试工程师

18、手动的执行一千的测试用例。来检查用例通过情况。软件项目运作流程软件项目运作图市场调研可行性研究产品立项需求调研设计开发系统测试产品发布产品维护产品升级图1-8 软件项目运作图市场调研 1、主动模式 将公司或者企业作为需求接收的被动方，而需求的提出作为主动方。 2、被动模式 在没有明确的需求提出者时，有公司或企业主动提出给特定使用用户群提供某种产品的模式。l市场调研主体：市场人员、销售人员l调研方式：客户走访，市场观察，报刊媒体等l输出文件：XXX项目市场调研分析报告可行性研究 以预测为前提，以投资效果为目的，从技术上、管理上进行全面综合分析研究的方法。 基本任务：对新开发产品或升级产品从技术经

19、济角度进行全面的分析研究，并对其投产后的经济效益进行预测，在既定的范围内进行方案论证的选择，以便最合理的利用资源，达到预定的社会效益和经济效益。l主体：市场人员、销售人员l对象：在市场调研阶段产生的XXX项目市场调研分析报告l输出文件：XXX项目可行性分析报告产品立项 在前期的市场调研、可行性研究经过评审可行后，则由需求调研人员牵头，进行产品立项，并进行产品小组的建立，同时制定产品的运作计划，如需求调研、产品设计、产品测试、产品发布等一系列的工作步骤及时间点。l立项负责人：市场调研人员l工作内容：提交产品立项申请，审批通过后，指定产品计划书，确定产品各个阶段的工作流程及时间进度表。需求调研 1

20、、主动模式 2、被动模式 需求调研参与人员：市场人员、开发人员、测试人员等 调研对象：客户或假象客户（广泛应用群） 输出：需求规格说明书设计开发 由系统架构师进行系统的概要设计，主要从稳定性、安全性、扩展性、可维持性等方面进行设计。 设计人员：系统架构师、项目开发小组 输出：项目开发计划、概要设计文档、详细设计文档、数据库文档等系统测试 按照前期的测试计划，利用测试用例进行系统的功能、性能测试。在经过多次版本的迭代后，完成系统测试，输出测试报告。 测试人员：项目测试小组 输出：测试计划、测试方案、测试用例、功能测试报告、性能测试报告等产品发布 经过开发部门、测试部门和其他部门的努力，产品在预定

21、的日期完成，有项目组择日发布。 发布人员：项目实施人员、市场部等 输出：客户现场项目实施报告等产品维护 交付使用后，需根据需求调研阶段协议，制定产品维护流程，出现问题需及时解决，直到产品使用废弃或升级，进入新的生命周期。产品升级 在软件产品使用到一定期限后，可以根据先前的约定进行升级，或根据客户新的需求，再次进行新需求的调研开发等。软件测试工作流程测试部门组织结构 1、人员构成 测试主管、测试组长、环境保障人员、配置管理员、测试设计人员、测试工程师测试主管测试组长环境保障人员软件测试部配置管理员测试设计人员测试工程师图1-9 测试部人员结构图测试部门组织结构 2、测试主管 负责测试部门日常管理

22、工作。 3、测试组长 测试主管根据项目情况，指派合适的测试人员但当测试组长。 4、环境保障人员 维护整个项目过程中的系统环境，如硬件、软件方便的。由测试人员兼任。 5、配置管理员 是软件开发过程中的一个重要工作流程面对需求变更、版本迭代、文档审核起到相当大的作用。测试部门组织结构 6、测试设计人员 一般由高级测试工程师担当，负责测试方法设计、测试用例设计及功能测试、性能测试的步骤、流程设计。 7、测试工程师 执行测试用例，进行系统的功能测试，经过多次版本迭代，完成系统测试。 8、技术构成 白盒测试技术、黑盒测试技术、自动化测试技术人员、项目管理技术人员白盒测试技术人员黑盒测试技术人员软件测试部

23、自动化测试技术人员项目测试技术人员图1-10 测试部技术构成图测试部门组织结构 9、白盒测试技术人员 该职位测试人员需要精通软件开发语言，要有几年的开发经验，能进行底层的代码review，测试桩设计等，同时能够食用百合测试工具对系统的最小功能单元进行测试，找出代码、系统架构方面的缺陷。 10、黑盒测试技术人员 要求测试人员有一定的软件工程理论、软件质量保证知识。 11、自动化测试人员 需测试人员掌握软件开发的知识，系统的调优，自动化测试工具，如QuickTest Professional LaodRunner。测试部门组织结构 12、项目管理技术人员 要求掌握一般的项目管理知识，如配置管理、版

24、本控制、评审管理、项目实施与进度控制等。 13、资源构成 14、硬件资源 需要齐备的测试环境，如测试PC机、测试服务器、测试芯片、测试手机等。硬件资源软件测试部软件资源技术支持图1-11 测试部资源构成图测试部门组织结构 15、软件资源 测试需要的操作系统、应用软件、管理软件等。如Windows、Linux等操作系统，SQL Server、Oracle等数据库软件，QuickTest Professional LaodRunner等自动化测试工具。 16、技术支持 当测试人元遇到问题不能解决时，可由兄弟部门给予支持。确保在一个团队合作的环境下，更高效的完成测试工作。测试工作流程测试准备阶段测试

25、工作流程测试开展阶段测试输出阶段图1-12 测试工作流程图测试工作流程 1、测试准备阶段 测试计划制定 测试小组建立项目经理测试主管测试组长部署测试任务指派测试组长获取测试需求及相关文档图1-13 测试工作介入流程图测试组长测试主管测试工程师小组工作会议申请小组成员指定小组成员图1-14 测试小组建立图测试工作流程 需求测试启动 测试需求提取分配任务测试组装需求调研部门校正需要提供需求测试小组反馈结果图1-15需求测试流程图测试组长测试小组测试工具分配任务编写用例图1-16 部署测试需求提取任务流程图测试工作流程 测试用例编写测试组长测试小组测试工具分配任务编写用例图1-17 部署测试用例编写

26、任务流程图测试工作流程 2、测试开展阶段 搭建测试环境测试组长，可根据说明说中的软件产品运行环境配置要求搭建。测试环境最好与开发环境分开 文档引入工作日报、功能测试报告、性能测试报告等模板 执行测试根据项目的Bug管理流程，经过多次的版本迭代，完成测试工作。测试工作流程 3、测试输出阶段 测试计划 测试方案 测试用例 测试工程师的工作日报 功能测试报告 性能测试报告思考与练习 1、软件测试共有几种模型？具体的内容是什么？相互之间有什么区别与联系？ 2、简要描述同行评审与阶段评审的区别。 3、软件测试与软件开发的关系是什么？ 4、什么叫软件测试？软件测试的目的是什么？思考与练习 5、软件测试的一

27、般工作流程是什么？ 6、软件测试的测试流程是什么？各阶段的工作内容重点是什么？ 7、当你接到一个测试任务后，你如何开展测试工作？软件测试用例设计方法什么是测试用例 测试用例（ Test Case ）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。测试用例包含要素 每个具体测试用例都将包括下列详细信息：编制人、审定人、编制日期、版本、用例类型、设计说明书编号、用例编号、用例名称、输入说明、期望结果（含判断标准）、环境要求、备注等。 具体可以参考建行测试用例模板黑盒测试案例设计技术 测试用

28、例设计：将软件测试的行为活动，作为一个科学化的组织归纳。 测试用例：设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。 因为我们不可能进行穷举测试，为了节省时间和资源、提供测试效率，必须从数量极大的可用测试数据精心挑选出具有代表性或者特殊性的测试数据来进行测试。测试测试用例的好处 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试的实施重点突出、目的明确。 在软件版本更新后只修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。 功能测试模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件

29、测试易于开展，并随着测试用例的不断精化其效率也不断攀升。常见黑盒测试用例设计方法 等价类划分法 边界值分析法 错误推测法 因果图法 判定表驱动法 正交试验设计法 功能图法 场景法等价类划分法 等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。 划分等价类和列出等价类表 确定测试用例划分等价类和列出等价类表 等价类是指输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效，并合理地假设：测试某等价类的代表值就等于对这类其他值的测试。 等价类划分有两种不同的情况：有效等价类和无效等价类。划分等价类和列出等价类表 有效等价类：指对于程序的

30、规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中所规定的功能和性能。 无效等价类：与有效等价类的定义恰巧相反。6条确定等价类的原则 1、在输入条件规定了取值范围或者值个数的情况下，可以确定一个有效等价类和两个无效等价类。 2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确定一个有效等价类和一个无效等价类。 3、在输入条件是一个布尔量的情况下，可以确定一个有效的等价类和一个无效的等价类6条确定等价类的原则 4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确定n个有效的等价类和一个

31、无效的等价类。 5、在规定了输入数据必须遵守的规则的情况下，可以确定一个有效等价类类（符合规则）和若干个无效等价类（从不同角度违反规则）。 6、在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。确定测试用例步骤 为每个等价类规定一个惟一的编号。 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步，最后使得所有的有效等价类均被测试用例所覆盖。 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。等价类划分法例题 一个程序读入3个整数，把这3个数值看作一个三角形的3条边的长度值。这个程序要

32、打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的。 构成三角形的3条边必须满足： A0,B0,C0，且A+BC,B+CA,A+CB 如果是等腰的，还要判断A=B,或者B=C,或者A=C 如果是等边的，则需要判断是否A=B,且B=C,且A=C.等价类表输入条件输入条件有效等价类有效等价类无效等价类无效等价类是否三角形的是否三角形的3条边条边(A0） (1) (B0） (2) (C0） (3) (A+BC) (4) (B+CA) (5) (A+CB) (6) (A0） (7) (B0） (8) (C0） (9) (A+BC) (10) (B+CA) (11) (A+CB) (12) 是否

33、等腰三角形是否等腰三角形(A=B）(13)(B=C) (14)(C=A) (15)(AB)and (BC)and (CA)(16)是否等边三角形是否等边三角形(A=B）and (B=C) and (C=A)(17)(AB) (18)(BC) (19)(CA) (20)设计测试用例边界值分析法 边界值分析：是考虑边界条件而选取测试用例的一种 黑盒测试方法，是对等价类划分方法的补充。 实践证明，软件在输入、输出域的边界附近容易出现差错， 而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。边界值分析法 使用边界值分析方法设计测试方案首先应该确定边界情况，通常输入等价类和输

34、出等价类的边界，就是应该注重测试的程序边界情况。 选取的测试数据应该正好等于、刚刚小于和刚刚大于边界值，也就是说，按照边界值分析法，应该选取刚好等于、稍小于和稍大于等价类边界值作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。基于边界值分析方法选择测试用例的原则 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。 根据规格说明的每个输出条件 ，考虑值的范围情况。基于边界值分析方法选择测试用例的原则 。根据规格说明的每个输出

35、条件 ，考虑值的个数情况。 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例 分析规格说明，找出其它可能的边界条件。错误推测方法 基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法。 错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。错误推测方法常见依据 在单元测试时曾列出的许多在模块中常见的错误。 以前产品测试中曾经发现的错误等。 已发现缺陷的测试方法的推广。 容易发生错误

36、的情况。 补充等价类和边界值法遗漏的一些等价类组合。 一些位置使用了共享变量，设计测试用例，修改一个共享变量，看其他位置有没有同 时做修改因果图设计方法 因果图方法是对等价类的扩展 ， 可以理解为 “ 等价类组合判定表 ” 。因果图即输入等价类与输出等价类的关系图因果图生成测试用例的基本步骤 分析软件规格说明描述中， 那些是原因 ( 即输入条件或输入条件的等价类 ) ，那些是结果 ( 即输出条件 ) ， 并给每个原因和结果赋予一个标识符。 分析软件规格说明描述中的语义。找出原因与结果之间， 原因与原因之间对应的关系 。根据这些关系，画出因果图。因果图生成测试用例的基本步骤 表明约束条件。由于语

37、法或环境限制， 有些原因与原因之间，原因与结果之间的组合情况不不可能出现。 为表明这些特殊情况， 在因果图上用一些记号表明约束或限制条件。 把因果图转换成判定表 为判定表中每一列表示的情况设计测试用例。正交试验法 正交试验设计方法：是从大量的试验数据中挑选适量的、有代表性的点，从而合理的安排测试的一种科学的试验设计方法正交试验测试用例设计步骤 提取功能说明，构造因子 状态表。 加权筛，生成因素分析表 利用正交表构造测试数据集。正交试验法优点 节省测试工时。 可控制测试用例的数量。 测试用例具有一定的覆盖率。 正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面，我们要选择哪种组合方式

38、是最好的，每个参数可能就是一个因子，参数的不同取值就是平水，采用正交试验法设计出最少的测试组合，达到有效测试目的。功能图分析方法 功能图方法：用功能图形象地表示程序功能说明，并生成功能图的测试用例。 又可以称作流程测试或状态迁移测试 类似于白盒测试中的逻辑覆盖和路径法 需要懂得控制语句（循环，顺序，选择，重复）功能图生成测试用例过程 在每个状态生成局部测试用例。 测试路径生成：从初始状态到最后状态的测试路径 测试用例合成：合成测试路径和功能图中每个状态的局部测试用例。 测试用例合成算法：条件构造树。场景法 事件触发控制流程，事件触发时的情景便形成场景。 同一事件不同的触发顺序和处理结果就形成事

39、件流 用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径的有基本流和备选流。测试用例选择的综合策略 1、首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的有效方法。 2、在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强测试用例选择的综合策略 3、可以用错误推测法追加一些测试用例，这些需要依靠测试工程师的智慧和经验。 4、对照程序逻辑，检查已 设计的测试用例的逻辑覆盖程序，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。 5、如果程序的功能说明中含有输入条件的组合，则一开始

40、就可以选因果图法和判定表驱动法。 6、对参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳的测试效果测试用例选择的综合策略 7、功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。 8、对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。软件缺陷什么是软件缺陷符合下面 5 条规则之一的问题称为软件缺陷：1、软件未达到产品说明书标明的功能。2、软件出现产品说明书指明不会出现的错误。 （如果软件含有产品说明中根本没有存在的功能，这是缺陷）3、软件功能超出产品说明书指明的范围。4、软件未达到产品说明书未指出但应达到的目标

41、。 （产品说明书虽然没有提到，但是按照常理应该达到的功能）5、软件测试人员或用户认为软件难以理解，不易使用，运行速度缓慢等问题。缺陷的生命周期简单周期： 测试员找到并登记软件缺陷，软件缺陷移交到程序员=程序员修复软件缺陷，软件缺陷移交到测试员=测试员确定软件缺陷被修复，测试员关闭软件缺陷。 缺陷的生命周期复杂周期： 发现缺陷（测试员发现并登记缺陷，软件缺陷转到程序员）=软件缺陷移交到项目管理员=（以不修复形式解决）项目管理员认为软件缺陷不重要，软件缺陷移交到测试员=重新激活缺陷（测试员不同意，找出通用失败案例，软件缺陷移交到项目管理员）=项目管理员同意缺陷需要修复，缺陷转给程序员=以修复形式解

42、决（测试员确认软件缺陷得以修复，测试员关闭软件缺陷）=缺陷关闭报告缺陷的要点复杂周期： 发现了软件缺陷，需要记录下来，不但要记录结果，同时需要详细描述发现的步骤，以备程序员重现问题，并解决它。 要求报告写的清楚明了和准确。有时利用截屏技术把当时的情况保存成图片，可以达到一图胜千言的效果。 参考软件测试缺陷跟踪管理说明.pdf文档（ vss09_测试团队公共规范说明）缺陷的严重性分类 A类致命性： 不能完全满足系统要求，基本业务功能未实现系统崩溃、不稳定或挂起等导致系统不能继续运行、导致系统出现不可预料的严重错误的问题。缺陷的严重性分类 B 类 严重错误：严重地影响系统要求或基本功能的实现，且没

43、有办法更正（重新安装 或重新启动不属于更正办法）。使系统不稳定、破坏数据、产生错误结果，部分功能无法执行 。缺陷的严重性分类 C 类 一般性错误： 1、界面错误。 2、非重要功能无法正确执行， 实现不正确， 实现不完整，但不影响功能 3、非严重性产生错误结果，但不影响一起功能。 4、正确性不受影响，但系统性能和响应时间受到影响。缺陷的严重性分类 D 类 轻微错误： 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能， 或对最终结果影响有限的问题。缺陷的严重性分类 E 类 测试建议： 不影响系统运行，对系统的可用性等提示的建议性的问题。 例如： 1、系统各个位置初始值的建议。 2、流程优

44、化建议等等。缺陷分析 缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标缺陷分析主要参数 状态：缺陷的当前状态（打开的、正在修复或关闭的等）。 优先级：必须处理和解决缺陷的相对重要性。 严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。 起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件缺陷分析报告 可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告； 也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。 这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据

45、软件测试的技巧测试技巧分类 结构测试相对于功能测试 动态测试相对于静态测试 手工测试相对于自动测试结构测试技巧 压力测试 执行测试 恢复测试 操作测试 复合性测试（与过程的复合性) 安全测试压力测试 目标 模拟出实际用户环境 怎么用 产生测试数据 测试组模拟用户处理被创建的数据 例子 确定是否分配了足够的磁盘空间 通讯的容量是否足够 测试系统过载的情况 什么时间使用 当关于容量的信息不确定的时候性能测试技巧l目标确定系统达到了希望达到的性能水平l如何使用使用软件和硬件的监视器使用模拟的监控模型，对关心的性能指标进行监控创建一个小程序l例子计算通信的时间单位时间处理的信息量l什么时候使用 在程序

46、开发的早期进行恢复测试l目标 当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作l如何使用 程序的安装，运行方式，工具的使用和关键技术经过足够的评估 系统开发完毕后，介绍一下发生失败后的处理过程 例子 人为的使一个系统在安装或者组装过程中产生错误 什么时间去使用 当操作的连续性是个重点的时候操作测试 目标 确定计算机的操作文档已经完整 如何使用 作为计算机正常操作的一部分来执行测试 例子 操作的介绍被文档化，操作者被培训 什么时候使用 预先将程序进行产品化。操作性是系统的一个重要指标的时候。复合性测试 目标 校验程序的开发是否依照已定义的标准，流程和操作方式进行的。 如

47、何去使用 将文档/程序同标准相比较 比较有效的方法是检查过程 例子 代码互查（一行一行） 什么时候使用 依赖于管理的需要安全性测试 目标 安全性的缺陷很难被发现。 大多数的情况下组织能够防止一般性的破坏者。 如何使用 对安全性的需求进行评审 分析与安全性有关的处理流程 转包给专业的人员 例子 定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可用的。 什么时间使用 当被保护的资源对于组织具有重要的价值的时候功能测试技巧 需求测试 回归测试 错误处理测试 支持手册的测试 系统兼容测试 控制性测试 并行测试需求测试 目标 用户的需求可以被实现 如何使用 创建测试用例和功能检查列表 例子 建立

48、测试矩阵去证实系统需求均被文档化 什么时候使用 每一个应用程序都要进行需求测试回归测试 目标 程序修改后，确保功能的正确性 如何使用 重新测试应用程序中没有改变的部分 例子 重新执行以前的测试用例 什么时间使用 当新的程序有可能影响老的功能的时候错误处理测试 目标 所有可能的错误条件均经过了验证 如何使用 一组有经验的人员预测在那里会出现问题 例子 建立一个错误处理的列表 什么时候使用v贯穿整个开发生命周期支持手册测试 目标 检验操作过程被文档化了，并且完整了。 如何使用 对过程有足够的介绍 可以协助用户正常使用 例子 系统在一定的条件下产生一个提示，用户被告知如何采取必要的操作。 什么时候使

49、用 最佳时机是在安装测试的时候，但是应该在开发全过程中。兼容性测试 目标 检验当使用适当的参数和数据时，需要的信息可以在两个系统中正确的交换 如何使用 文件和数据被用来在多系统之间传递。 例子 典型的由一个系统到另一个系统的数据交换程序。 什么时候使用 当两个应用程序之间的参数有可能发生变化的时候管理能力测试 目标 验证数据交换时有足够的审计追踪能力 如何使用 关键数据或者有价值的数据 例子 从负面来看程序，是否确保了会出错的条件都被保护了。 什么时候使用 系统测试的一部分并行测试 目的 新版本和老版本同时运行，用以确保新版本的程序运行正确。 如何使用 需要对两个系统输入相同的数据来运行 例子

50、 运行新旧两个工资支付系统 什么时间使用 当对新系统的的运行情况不确定的时候单元测试 关注单元一级 代码分析和测试 功能分析和测试 结构分析和测试 以错误为导向的分析和测试测试要素/测试技巧矩阵测试要素压力执行恢复操作复合性安全性需求回归错误处理手工支持系统兼容管理并行单元可靠性授权文件完整性审查追踪过程连续性测试要素/测试技巧矩阵测试要素压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元服务水平权限控制一致性正确性易用性可维护性兼容性耦合性性能可操作性测试工具的选择测试工具 测试标准 边界值分析 因果图 检查表 代码比较对照 以编译为基础的分析 确认/检查 控制流分析测