截图
简介
这是一个关于软件测试培训教程PPT（部分ppt内容已做更新升级），主要介绍了软件测试理论基础、软件测试流程、软件项目运作流程、软件测试工作流程、软件测试用例设计方法、软件缺陷、测试的技巧、测试工具的选择、软件的测试整个过程等内容。培训是给新员工或现有员工传授其完成本职工作所必需的正确思维认知、基本知识和技能的过程。是一种有组织的知识传递、技能传递、标准传递、信息传递、管理训诫行为。其中以技能传递为主，侧重上岗前进行。为了达到统一的科学技术规范、标准化作业，通过目标规划设定知识和信息传递、技能熟练演练、作业达成评测、结果交流公告等现代信息化的流程，让员工通过一定的教育训练技术手段，达到预期的水平，提高目标。目前国内培训以技能传递为主，时间在侧重上岗前。
软件测试培训教程PPT是由红软PPT免费下载网推荐的一款培训教程PPT类型的PowerPoint.
软件测试培训教程
研发部
2010年11月
培训内容
软件测试理论基础
软件测试流程
软件项目运作流程
软件测试工作流程
软件测试用例设计方法
软件缺陷
测试的技巧
测试工具的选择
软件的测试整个过程
软件测试理论基础
测试行业简介
软件测试在软件生命周期中占据重要作用。
软件生命周期的每个阶段都应该包含测试从而检验本阶段的成果是否接近预期的目标，尽可能早的发现错误并加以修正。
由于测试的重要性和复杂度，它慢慢的独立发展成为一个行业，并且在迅猛发展。
在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的 40 ％以上。而在软件开发的总成本中，用在测试上的开销要占 30 ％到 50 ％
软件测试概论（概述）
1975年，“测试数据选择的原理”（Toward a theory of Test Data）的文章，软件测试才被确定为一种研究方向。
1979年，“软件测试时为发现错误而执行一个程序或者系统的过程”
1983年，“测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的一种度量”。
2002年，“测试是为了度量和提高被测试软件的质量，对测试软件进行工程设计、实施、维护的的整个生命周期过程”。
软件测试概论（行情）
国外：
A、软件测试在软件公司中占有重要的地位
B、软件测试理论研究蓬勃发展，引领软件测试理论研究的国际潮流
C、软件测试市场繁荣
国内：
1、我国著名的软件公司都已经或者正在建立独立的专职软件测试队伍
2、国家开始对软件测试职业高度重视和认可（软考中级资格中增加软件评测师）
软件测试概论（行情）
3、用户对软件质量要求越来越高，通过第三方测试机构的严格测试来判定
4、市场需求量不断增大，软件测试工程师的待遇也在不断提高。北京地区的薪资趋势大致如图1-1所示。
测试工程师的职业发展
软件测试工程师一般有几个方向可走，如图1-2所示。
一个理想的测试工程师应该有开发经验，至少要有开发的概念。仅仅发现Bug是测试的初步，而分析出根本原因，却要有很深的功底。
企业需要怎样的测试人才？
一年以上软件测试经验
计算机相关专业大专以上学历
了解软件工程，熟悉软件测试过程和标准，熟悉配置管理技术和工具
能够编制测试计划、设计测试用例、编写Bug报告和测试总结报告、使用测试工具、开发测试脚本
熟练使用Windows或Unix或Linux操作系统
企业需要怎样的测试人才？
熟练C、C++、Java、VB、Delphi、C#中的一种以上
熟练使用SQL Server或Oracle数据库
了解业务领域（ERP、OA、电子商务、税务系统、电信计费系统……）
熟练掌握至少一种以上的测试工具，如TestDirector、QTP、LoadRunner、Robot
进取、合作、表达、沟通、责任心、耐心、认真程度
测试学习路线
对于软件测试初学者，我们要切合实际、循序渐进的学习，在学习中可参考图1-3所示的软件测试学习路线图，从软件测试的理论基础，到项目实战，逐步学习，掌握技术技能，最终胜任软件测试工作。
软件测试由来
调试
在已知错误的情况下，对软件程序代码做出的一系列检查，校正的过程。
测试
在未知错误的情况下，检查程序代码是否有问题的过程。
区分：软件测试从软件质量保证的角度来检查程序代码是否有误，而调试是为了解决当前已知的错误，调试活动无法替代软件测试活动。
软件测试定义
定义：软件测试就是为了发现错误而审查软件文档、检查软件数据和执行程序代码的过程。
软件测试应该是对软件形成过程的文档，数据以及程序进行的测试，而不仅是对程序进行的测试。
60%以上的软件错误并不是程序错误，而是分析和设计的错误，提倡软件全生命周期测试的理念。
什么是软件质量
1991年国际标准ISO 9126中定义为:软件满足规定或潜在用户需求的总和。
1999年国际标准ISO 14598中定义为:软件特性的总和，软件满足规定或潜在用户需求的能力。
2001年国际标准ISO 9126中定义为：软件满足规定用户或潜在用户需求的能力，要从软件在内部，外部和使用过程中的表现来衡量，包含内部质量、外部质量、和使用质量。
软件测试与质量保证的区别
软件质量保证和软件测试是软件质量工程中两个不同层面的工作。
质量保证(QA):质量保证的重要工作通过预防，检查与改进来保证软件质量(所关注的是软件质量的检查与测量，着眼于软件开发的过程，步骤和产物)。
软件测试：测试过程虽然与开发过程紧密相关但，关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。
软件测试的目的和原则
基于不同的立场，存在着两种完全不同的测试目的：
用户角度：希望软件测试暴露软件中隐藏的错误和缺陷，已考虑是否接受产品。
软件开发者角度：希望测试成为表明软件产品中不存在错误的过程，验证被测软件已正确的实现了用户的需求，确立人们对软件质量的信心。
软件测试的目的和原则
换言之，测试的目的是：
想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。
测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。
实施测试收集到的测试结果数据为可靠性分析提供了依据
测试不能表明软件中不存在错误，它只能说明软件中存在错误
软件测试的目的和原则
软件测试的原则：
所有的软件测试都应追溯到用户需求。
应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。
完全测试是不可能的，测试需要终止。
测试无法显示软件潜在的缺陷。也就是说测试只能证明软件存在错误而不能证明软件没有错误。
软件测试的对象
根据软件定义，软件包括程序，数据和文档，所以软件测试并不仅仅是程序测试，软件测试应该贯穿整个软件生命周期中。
需求分析，概要设计，详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明，概要设计规格说明，详细设计规格说明以及源程序。
软件测试的对象
为了把握各个环节的正确性，人们需要进行各种验证和确认工作 ：
验证(verification)： 是保证软件正确实现特定功能的一系统活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。
确认(validation)： 是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件，用户需求相符合。
软件测试的对象
软件测试分类
一般的，我们将软件测试活动分为以下几类：
黑盒测试、
白盒测试、
灰盒测试、
静态测试、
动态测试、
手动测试、
自动测试
软件测试分类—黑盒测试
黑盒测试又叫功能测试、数据驱动测试或基于需求规格说明书的功能测试。该测试类别注重于测试软件的功能性需求。
测试工程师无需了解程序代码的内部构造，完全模拟软件产品的最终端用户使用该软件，检查软件产品是否达到了用户的需求。
如图1-4所示为黑盒测试实例图。
黑盒测试能更好的从用户角度来考察被测系统的功能性需求实现情况。
软件测试分类—白盒测试
白盒测试又称结构测试、逻辑驱动测试或基于程序代码内部构成的测试。
白盒测试需要测试工程师深入考查程序代码的内部结构、逻辑设计等。
就像前面的例子，我们拆开手机，观察手机电路板的设计，液晶屏的构成等。
对于白盒测试工程师来说，软件产品的内部结构是敞开的。如图1-5所示是白盒测试示例图。
软件测试分类—灰盒测试
灰盒测试介于白盒和黑盒测试之间。
灰盒测试一方面考虑程序代码的功能性表现，另一方面，又需要考虑程序代码的内部结构。
通俗地讲，灰盒测试就是白加黑。
像我们的性能测试，自动化功能测试就是采用了灰盒测试的方法。
图1-6是灰盒测试的示例图。
软件测试分类—静态测试
定义：静态的、不执行被测对象程序代码而寻找缺陷的过程。
在进行静态测试时可采用一些代码走查工具，如QAC++、C++Test等。
软件测试分类—动态测试
实际的执行被测对象的程序代码，输入实现设计好的测试用例，检查程序代码运行得到的结果与测试用力中设计的预期结果之间是否有差异，判定实际结果与预测结果是否一致。
动态测试有四部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告。
动态测试有三种主要方法：黑盒测试、白盒测试和灰盒测试
软件测试分类—手动测试
它是测试人员设计测试用例并执行测试用例，然后根据实际的结果去和预期的结果相比较并记录测试结果，最终输出测试报告的测试活动。
可充分发挥测试工程师的主观能动性，将其智力体现在测试工作中，能发现许多的缺陷，但同时又有一定的局限性和单调枯燥性。
软件测试分类—自动化测试
定义
利用测试工具，模拟用户业务使用流程，让他们自动运行来查找缺陷。
优点
快、广泛、可重复性工作
缺点
只可检查比较主要的问题，如崩溃、死机，无法发现一般的日常错误。编写脚本工作量 也很大，有时会超过手动测试时间。
我们要根据实际情况选择或者不选择测试工具，选择使用何种测试工具，不能为了实用工具而可以的去使用工具。
软件测试人员职业要求
从个人素质角度要求测试工程师需要具备以下6种素质：
责任心
沟通能力
团队合作精神
耐心、细心和信心
时时保持怀疑态度、并且有缺陷预防的意识
不断学习的能力
软件测试流程
软件测试流程图
软件测试虽然是软件生存周期的一个独立阶段，但测试工作却渗透到从分析、设计直到编程的各个阶段中（1-7是软件测试所经阶段的一般流程）。
需求测试、单元测试、集成测试、系统测试、性能测试、用户测试、回归测试
需求测试
要从以下几个方面考虑需求测试：
完整性 正确性
一致性 可行性
无二义性 健壮性
必要性 可测试性
可修改性
单元测试
又称模块测试，就是对程序代码中最小的涉及模块单元进行测试。
在单元测试中我们主要采用静态测试与动态测试相结合的办法。
单元测试要求需要几年的代码编写经验，并且要十分熟悉当前的被测系统，以及该系统是否与其他系统的接口关联情况。
单元测试在编码阶段占据非常重要的地位。
可以降低编码的错误率，提高编码质量
集成测试
又称组装测试，是将软件产品各个模块组装起来，检查接口是否存在问题，以及组装后的整体功能、性能表现。
一般可采用非增式集成方法、增式集成方法（自底向上集成、自顶向下集成、组合方式集成）等策略进行测试，利用一黑盒测试为主，白盒测试为辅的测试方法进行测试。
主要解决各个组成但源代码是否符合开发规范、接口是否存在问题，整体功能有无错误、界面是否符合设计规范、性能是否满足用户需求等。
系统测试
将通过集成测试的软件部署到某种较为复杂的计算机永华环境进行测试。
目的：通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。
这个阶段主要进行的是安装卸载测试、兼容性测试、功能确认测试、安全测试等。
采用黑盒测试法，主要考察被测软件的功能与性能表现。
性能测试
性能测试要求被测软件在业务处理速度、处理能力和所耗用的硬件系统资源比率满足用户的需求。
不要尝试用手动方式进行性能测试，应当编写一段相应的程序或者使用专门的工具进行，如利用LoadRunner自动化性能测试工具。
性能测试相对难度较大，要求测试人员掌握编程语言，精通业务流程，拥有深厚的项目经验。
用户测试
可称为用户确认测试。
正式验收前，需要用户对本系统做出一个评价，用户可对交付的系统做测试，并将测试结果反馈回来，进行修改、分析。
用户测试环节是被测试软件首次作为正式的系统交友用户使用，用户会根据他们的实际使用情况进行测试、使用，并提出实际使用过程中的问题。
用户测试是软件生产流程中的最后质检关。
回归测试
回归测试是经过一段时间以后再回过头来对以前修复过的Bug重新进行测试，看该Bug是否会重新出现。
有些时候可采用自动化测试工具来进行回归测试，如利用QTP
一般情况下，都由测试工程师手动的执行一千的测试用例。来检查用例通过情况。
软件项目运作流程
软件项目运作图
市场调研
1、主动模式
将公司或者企业作为需求接收的被动方，而需求的提出作为主动方。
2、被动模式
在没有明确的需求提出者时，有公司或企业主动提出给特定使用用户群提供某种产品的模式。
市场调研主体：市场人员、销售人员
调研方式：客户走访，市场观察，报刊媒体等
输出文件：《XXX项目市场调研分析报告》
可行性研究
以预测为前提，以投资效果为目的，从技术上、管理上进行全面综合分析研究的方法。
基本任务：对新开发产品或升级产品从技术经济角度进行全面的分析研究，并对其投产后的经济效益进行预测，在既定的范围内进行方案论证的选择，以便最合理的利用资源，达到预定的社会效益和经济效益。
主体：市场人员、销售人员
对象：在市场调研阶段产生的《XXX项目市场调研分析报告》
输出文件：《XXX项目可行性分析报告》
产品立项
在前期的市场调研、可行性研究经过评审可行后，则由需求调研人员牵头，进行产品立项，并进行产品小组的建立，同时制定产品的运作计划，如需求调研、产品设计、产品测试、产品发布等一系列的工作步骤及时间点。
立项负责人：市场调研人员
工作内容：提交产品立项申请，审批通过后，指定产品计划书，确定产品各个阶段的工作流程及时间进度表。
需求调研
1、主动模式
2、被动模式
需求调研参与人员：市场人员、开发人员、测试人员等
调研对象：客户或假象客户（广泛应用群）
输出：需求规格说明书
设计开发
由系统架构师进行系统的概要设计，主要从稳定性、安全性、扩展性、可维持性等方面进行设计。
设计人员：系统架构师、项目开发小组
输出：项目开发计划、概要设计文档、详细设计文档、数据库文档等
系统测试
按照前期的测试计划，利用测试用例进行系统的功能、性能测试。在经过多次版本的迭代后，完成系统测试，输出测试报告。
测试人员：项目测试小组
输出：测试计划、测试方案、测试用例、功能测试报告、性能测试报告等
产品发布
经过开发部门、测试部门和其他部门的努力，产品在预定的日期完成，有项目组择日发布。
发布人员：项目实施人员、市场部等
输出：客户现场项目实施报告等
产品维护
交付使用后，需根据需求调研阶段协议，制定产品维护流程，出现问题需及时解决，直到产品使用废弃或升级，进入新的生命周期。
产品升级
在软件产品使用到一定期限后，可以根据先前的约定进行升级，或根据客户新的需求，再次进行新需求的调研开发等。
软件测试工作流程
测试部门组织结构
1、人员构成
测试主管、测试组长、环境保障人员、配置管理员、测试设计人员、测试工程师
测试部门组织结构
2、测试主管
负责测试部门日常管理工作。
3、测试组长
测试主管根据项目情况，指派合适的测试人员但当测试组长。
4、环境保障人员
维护整个项目过程中的系统环境，如硬件、软件方便的。由测试人员兼任。
5、配置管理员
是软件开发过程中的一个重要工作流程面对需求变更、版本迭代、文档审核起到相当大的作用。
测试部门组织结构
6、测试设计人员
一般由高级测试工程师担当，负责测试方法设计、测试用例设计及功能测试、性能测试的步骤、流程设计。
7、测试工程师
执行测试用例，进行系统的功能测试，经过多次版本迭代，完成系统测试。
8、技术构成
白盒测试技术、黑盒测试技术、自动化测试技术人员、项目管理技术人员
测试部门组织结构
9、白盒测试技术人员
该职位测试人员需要精通软件开发语言，要有几年的开发经验，能进行底层的代码review，测试桩设计等，同时能够食用百合测试工具对系统的最小功能单元进行测试，找出代码、系统架构方面的缺陷。
10、黑盒测试技术人员
要求测试人员有一定的软件工程理论、软件质量保证知识。
11、自动化测试人员
需测试人员掌握软件开发的知识，系统的调优，自动化测试工具，如QuickTest Professional LaodRunner。
测试部门组织结构
12、项目管理技术人员
要求掌握一般的项目管理知识，如配置管理、版本控制、评审管理、项目实施与进度控制等。
13、资源构成
14、硬件资源
需要齐备的测试环境，如测试PC机、测试服务器、测试芯片、测试手机等。
测试部门组织结构
15、软件资源
测试需要的操作系统、应用软件、管理软件等。如Windows、Linux等操作系统，SQL Server、Oracle等数据库软件，QuickTest Professional LaodRunner等自动化测试工具。
16、技术支持
当测试人元遇到问题不能解决时，可由兄弟部门给予支持。确保在一个团队合作的环境下，更高效的完成测试工作。
测试工作流程
测试工作流程
1、测试准备阶段
测试计划制定
测试小组建立
测试工作流程
需求测试启动
测试需求提取
测试工作流程
测试用例编写
测试工作流程
2、测试开展阶段
搭建测试环境—测试组长，可根据说明说中的软件产品运行环境配置要求搭建。测试环境最好与开发环境分开
文档引入—工作日报、功能测试报告、性能测试报告等模板
执行测试—根据项目的Bug管理流程，经过多次的版本迭代，完成测试工作。
测试工作流程
3、测试输出阶段
测试计划
测试方案
测试用例
测试工程师的工作日报
功能测试报告
性能测试报告
思考与练习
1、软件测试共有几种模型？具体的内容是什么？相互之间有什么区别与联系？
2、简要描述同行评审与阶段评审的区别。
3、软件测试与软件开发的关系是什么？
4、什么叫软件测试？软件测试的目的是什么？
思考与练习
5、软件测试的一般工作流程是什么？
6、软件测试的测试流程是什么？各阶段的工作内容重点是什么？
7、当你接到一个测试任务后，你如何开展测试工作？
软件测试用例设计方法
什么是测试用例
测试用例（ Test Case ）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
测试用例包含要素
每个具体测试用例都将包括下列详细信息：编制人、审定人、编制日期、版本、用例类型、设计说明书编号、用例编号、用例名称、输入说明、期望结果（含判断标准）、环境要求、备注等。
具体可以参考建行测试用例模板
黑盒测试案例设计技术
测试用例设计：将软件测试的行为活动，作为一个科学化的组织归纳。
测试用例：设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。
因为我们不可能进行穷举测试，为了节省时间和资源、提供测试效率，必须从数量极大的可用测试数据精心挑选出具有代表性或者特殊性的测试数据来进行测试。
测试测试用例的好处
在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。
功能测试模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。
常见黑盒测试用例设计方法
等价类划分法
边界值分析法
错误推测法
因果图法
判定表驱动法
正交试验设计法
功能图法
场景法
等价类划分法
等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。
划分等价类和列出等价类表
确定测试用例
划分等价类和列出等价类表
等价类是指输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效，并合理地假设：测试某等价类的代表值就等于对这类其他值的测试。
等价类划分有两种不同的情况：有效等价类和无效等价类。
划分等价类和列出等价类表
有效等价类：指对于程序的规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中所规定的功能和性能。
无效等价类：与有效等价类的定义恰巧相反。
6条确定等价类的原则
1、在输入条件规定了取值范围或者值个数的情况下，可以确定一个有效等价类和两个无效等价类。
2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确定一个有效等价类和一个无效等价类。
3、在输入条件是一个布尔量的情况下，可以确定一个有效的等价类和一个无效的等价类
6条确定等价类的原则
4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确定n个有效的等价类和一个无效的等价类。
5、在规定了输入数据必须遵守的规则的情况下，可以确定一个有效等价类类（符合规则）和若干个无效等价类（从不同角度违反规则）。
6、在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。
确定测试用例步骤
为每个等价类规定一个惟一的编号。
设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步，最后使得所有的有效等价类均被测试用例所覆盖。
设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。
等价类划分法例题
一个程序读入3个整数，把这3个数值看作一个三角形的3条边的长度值。这个程序要打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的。
构成三角形的3条边必须满足：
A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B
如果是等腰的，还要判断A=B，或者B=C，或者A=C
如果是等边的，则需要判断是否A=B，且B=C，且A=C.
等价类表
设计测试用例
边界值分析法
边界值分析：是考虑边界条件而选取测试用例的一种 黑盒测试方法，是对等价类划分方法的补充。
实践证明，软件在输入、输出域的边界附近容易出现差错， 而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
边界值分析法
使用边界值分析方法设计测试方案首先应该确定边界情况，通常输入等价类和输出等价类的边界，就是应该注重测试的程序边界情况。
选取的测试数据应该正好等于、刚刚小于和刚刚大于边界值，也就是说，按照边界值分析法，应该选取刚好等于、稍小于和稍大于等价类边界值作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。
基于边界值分析方法选择测试用例的原则
如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。
根据规格说明的每个输出条件 ，考虑值的范围情况。
基于边界值分析方法选择测试用例的原则
。根据规格说明的每个输出条件 ，考虑值的个数情况。
如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例
分析规格说明，找出其它可能的边界条件。
错误推测方法
基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法。
错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。
错误推测方法常见依据
在单元测试时曾列出的许多在模块中常见的错误。
以前产品测试中曾经发现的错误等。
已发现缺陷的测试方法的推广。
容易发生错误的情况。
补充等价类和边界值法遗漏的一些等价类组合。
一些位置使用了共享变量，设计测试用例，修改一个共享变量，看其他位置有没有同 时做修改
因果图设计方法
因果图方法是对等价类的扩展 ， 可以理解为 “ 等价类组合判定表 ” 。因果图即输入等价类与输出等价类的关系图
因果图生成测试用例的基本步骤
分析软件规格说明描述中， 那些是原因 ( 即输入条件或输入条件的等价类 ) ，那些是结果 ( 即输出条件 ) ， 并给每个原因和结果赋予一个标识符。
分析软件规格说明描述中的语义。找出原因与结果之间， 原因与原因之间对应的关系 。根据这些关系，画出因果图。
因果图生成测试用例的基本步骤
表明约束条件。由于语法或环境限制， 有些原因与原因之间，原因与结果之间的组合情况不不可能出现。 为表明这些特殊情况， 在因果图上用一些记号表明约束或限制条件。
把因果图转换成判定表
为判定表中每一列表示的情况设计测试用例。
正交试验法
正交试验设计方法：是从大量的试验数据中挑选适量的、有代表性的点，从而合理的安排测试的一种科学的试验设计方法
正交试验测试用例设计步骤
提取功能说明，构造因子 状态表。
加权筛，生成因素分析表
利用正交表构造测试数据集。
正交试验法优点
节省测试工时。
可控制测试用例的数量。
测试用例具有一定的覆盖率。
正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面，我们要选择哪种组合方式是最好的，每个参数可能就是一个因子，参数的不同取值就是平水，采用正交试验法设计出最少的测试组合，达到有效测试目的。
功能图分析方法
功能图方法：用功能图形象地表示程序功能说明，并生成功能图的测试用例。
又可以称作流程测试或状态迁移测试
类似于白盒测试中的逻辑覆盖和路径法
需要懂得控制语句（循环，顺序，选择，重复）
功能图生成测试用例过程
在每个状态生成局部测试用例。
测试路径生成：从初始状态到最后状态的测试路径
测试用例合成：合成测试路径和功能图中每个状态的局部测试用例。
测试用例合成算法：条件构造树。
场景法
事件触发控制流程，事件触发时的情景便形成场景。
同一事件不同的触发顺序和处理结果就形成事件流
用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径的有基本流和备选流。
测试用例选择的综合策略
1、首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的有效方法。
2、在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强
测试用例选择的综合策略
3、可以用错误推测法追加一些测试用例，这些需要依靠测试工程师的智慧和经验。
4、对照程序逻辑，检查已 设计的测试用例的逻辑覆盖程序，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5、如果程序的功能说明中含有输入条件的组合，则一开始就可以选因果图法和判定表驱动法。
6、对参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳的测试效果
测试用例选择的综合策略
7、功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。
8、对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
软件缺陷
什么是软件缺陷
符合下面 5 条规则之一的问题称为软件缺陷：
1、软件未达到产品说明书标明的功能。
2、软件出现产品说明书指明不会出现的错误。 （如果软件含有产品说明中根本没有存在的功能，这是缺陷）
3、软件功能超出产品说明书指明的范围。
4、软件未达到产品说明书未指出但应达到的目标。 （产品说明书虽然没有提到，但是按照常理应该达到的功能）
5、软件测试人员或用户认为软件难以理解，不易使用，运行速度缓慢等问题。
缺陷的生命周期
简单周期：
测试员找到并登记软件缺陷，软件缺陷移交到程序员=>程序员修复软件缺陷，软件缺陷移交到测试员=>测试员确定软件缺陷被修复，测试员关闭软件缺陷。
缺陷的生命周期
复杂周期：
发现缺陷（测试员发现并登记缺陷，软件缺陷转到程序员）=>软件缺陷移交到项目管理员=>（以不修复形式解决）项目管理员认为软件缺陷不重要，软件缺陷移交到测试员=>重新激活缺陷（测试员不同意，找出通用失败案例，软件缺陷移交到项目管理员）=>项目管理员同意缺陷需要修复，缺陷转给程序员=>以修复形式解决（测试员确认软件缺陷得以修复，测试员关闭软件缺陷）=>缺陷关闭
报告缺陷的要点
复杂周期：
发现了软件缺陷，需要记录下来，不但要记录结果，同时需要详细描述发现的步骤，以备程序员重现问题，并解决它。
要求报告写的清楚明了和准确。有时利用截屏技术把当时的情况保存成图片，可以达到一图胜千言的效果。
参考软件测试缺陷跟踪管理说明.pdf文档
（ vss\09_测试团队\公共\规范说明）
缺陷的严重性分类
A类——致命性：
不能完全满足系统要求，基本业务功能未实现系统崩溃、不稳定或挂起等导致系统不能继续运行、导致系统出现不可预料的严重错误的问题。
缺陷的严重性分类
B 类 —— 严重错误：
严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装 或重新启动不属于更正办法）。使系统不稳定、破坏数据、产生错误结果，部分功能无法执行 。
缺陷的严重性分类
C 类 —— 一般性错误：
1、界面错误。
2、非重要功能无法正确执行， 实现不正确， 实现不完整，但不影响功能
3、非严重性产生错误结果，但不影响一起功能。
4、正确性不受影响，但系统性能和响应时间受到影响。
缺陷的严重性分类
D 类 —— 轻微错误：
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能， 或对最终结果影响有限的问题。
缺陷的严重性分类
E 类 —— 测试建议：
不影响系统运行，对系统的可用性等提示的建议性的问题。
例如：
1、系统各个位置初始值的建议。
2、流程优化建议等等。
缺陷分析
缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标
缺陷分析主要参数
状态：缺陷的当前状态（打开的、正在修复或关闭的等）。
优先级：必须处理和解决缺陷的相对重要性。
严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。
起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件
缺陷分析报告
可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；
也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。
这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据
软件测试的技巧
测试技巧分类
结构测试相对于功能测试
动态测试相对于静态测试
手工测试相对于自动测试
结构测试技巧
压力测试
执行测试
恢复测试
操作测试
复合性测试（与过程的复合性)
安全测试
压力测试
目标
模拟出实际用户环境
怎么用
产生测试数据
测试组模拟用户处理被创建的数据
例子
确定是否分配了足够的磁盘空间
通讯的容量是否足够
测试系统过载的情况
什么时间使用
当关于容量的信息不确定的时候
性能测试技巧
目标
确定系统达到了希望达到的性能水平
如何使用
使用软件和硬件的监视器
使用模拟的监控模型，对关心的性能指标进行监控
创建一个小程序
例子
计算通信的时间
单位时间处理的信息量
什么时候使用
－ 在程序开发的早期进行
恢复测试
目标
当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作
如何使用
程序的安装，运行方式，工具的使用和关键技术经过足够的评估
系统开发完毕后，介绍一下发生失败后的处理过程
例子
人为的使一个系统在安装或者组装过程中产生错误
什么时间去使用
当操作的连续性是个重点的时候
操作测试
目标
确定计算机的操作文档已经完整
如何使用
作为计算机正常操作的一部分来执行测试
例子
操作的介绍被文档化，操作者被培训
什么时候使用
预先将程序进行产品化。操作性是系统的一个重要指标的时候。
复合性测试
目标
校验程序的开发是否依照已定义的标准，流程和操作方式进行的。
如何去使用
将文档/程序同标准相比较
比较有效的方法是检查过程
例子
代码互查（一行一行）
什么时候使用
依赖于管理的需要
安全性测试
目标
安全性的缺陷很难被发现。
大多数的情况下组织能够防止一般性的破坏者。
如何使用
对安全性的需求进行评审
分析与安全性有关的处理流程
转包给专业的人员
例子
定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可用的。
什么时间使用
当被保护的资源对于组织具有重要的价值的时候
功能测试技巧
需求测试
回归测试
错误处理测试
支持手册的测试
系统兼容测试
控制性测试
并行测试
需求测试
目标
用户的需求可以被实现
如何使用
创建测试用例和功能检查列表
例子
建立测试矩阵去证实系统需求均被文档化
什么时候使用
每一个应用程序都要进行需求测试
回归测试
目标
程序修改后，确保功能的正确性
如何使用
重新测试应用程序中没有改变的部分
例子
重新执行以前的测试用例
什么时间使用
当新的程序有可能影响老的功能的时候
错误处理测试
目标
所有可能的错误条件均经过了验证
如何使用
一组有经验的人员预测在那里会出现问题
例子
建立一个错误处理的列表
什么时候使用
贯穿整个开发生命周期
支持手册测试
目标
检验操作过程被文档化了，并且完整了。
如何使用
对过程有足够的介绍
可以协助用户正常使用
例子
系统在一定的条件下产生一个提示，用户被告知如何采取必要的操作。
什么时候使用
最佳时机是在安装测试的时候，但是应该在开发全过程中。
兼容性测试
目标
检验当使用适当的参数和数据时，需要的信息可以在两个系统中正确的交换
如何使用
文件和数据被用来在多系统之间传递。
例子
典型的由一个系统到另一个系统的数据交换程序。
什么时候使用
当两个应用程序之间的参数有可能发生变化的时候
管理能力测试
目标
验证数据交换时有足够的审计追踪能力
如何使用
关键数据或者有价值的数据
例子
从负面来看程序，是否确保了会出错的条件都被保护了。
什么时候使用
系统测试的一部分
并行测试
目的
新版本和老版本同时运行，用以确保新版本的程序运行正确。
如何使用
需要对两个系统输入相同的数据来运行
例子
运行新旧两个工资支付系统
什么时间使用
当对新系统的的运行情况不确定的时候
单元测试
关注单元一级
代码分析和测试
功能分析和测试
结构分析和测试
以错误为导向的分析和测试
测试要素/测试技巧矩阵
测试要素/测试技巧矩阵
测试工具的选择
测试工具
测试标准
边界值分析
因果图
检查表
代码比较对照
以编译为基础的分析
确认/检查
控制流分析
测试工具
能证明正确性的数据
以覆盖为基础的测试
数据字典
数据流分析
以设计为基础的功能测试
设计评审
桌面检查
灾难性测试
测试工具
错误猜测
执行的规则
全面的测试
实况调查
流程图
检查，视察
使用仪器设备
综合测试设备
映射图
测试工具
建模
并行操作
并行模拟
代码互查
风险矩阵
系统控制的评审
得分
快照(把系统一个时刻的情况保存下来)
测试工具
完成特征
系统日志
测试用例
测试用例的产生形式
跟踪
工具程序
容量的测试
走查(讲解开发思路)
选择和使用测试工具
按照用途选择匹配的工具
在适当的生命周期选择工具
按照测试人员的实际技能选择匹配的工具
选择一个可提供的工具
测试工具/测试技巧矩阵
测试工具/测试技巧矩阵
测试工具/测试技巧矩阵
测试工具/测试技巧矩阵
测试工具/测试技巧矩阵
软件开发生命周期/测试工具对照表
软件开发生命周期/测试工具对照表
软件开发生命周期/测试工具对照表
软件开发生命周期/测试工具对照表
测试工具管理
工具管理者的职责
对工具负责
帮助同事使用这些工具
培训工具得使用方法
负责同工具的厂家联系
每年给出有关工具使用和购买得计划
工具得升级
工具情况报告
工具管理者得任期不易太长
测试工具管理
工具管理者的职责
对工具负责
帮助同事使用这些工具
培训工具得使用方法
负责同工具的厂家联系
每年给出有关工具使用和购买得计划
工具得升级
工具情况报告
工具管理者得任期不易太长
软件的测试整个过程
估算
测试计划
需求
设计
编码
测试总结
安装，交付
维护
估算
估算什么
测试对软件工作量的估算的准确性
测试评估软件系统的状况的准确性
关注点：
不准确的估算
不适当的开发过程
不真实的状态报告
对工作量的估算
如何知道对工作量的估算是正确的
估算工作量的工具很容易出错
对软件工作量的估算需要策略
五个一般的方法
猜
加入一些约束条件
以一些数据为基础
模拟进行工作
将一些参数模型化
参数模型法
回归模型：将现有的参数与已有的历史数据相拟和。
启发式模型：对历史数据进行观察和解释
现象模型：假设软件开发过程可以依据一些更广泛的可适用的过程解释。
模型遵循的共同模式
估算软件的大小
将大小转化成人力的估算，并且作出可能的成本的估算
依据项目的特性进行估算的调整
将整体的估算划分到不同的项目阶段中
估算不包括技巧上面的人力和计算机的运行时间
将以上内容相加
对估算进行检验
检验估算模型的合理性
检验模型是否包含了必须的测试要素
检验模型的正确性
校验估算模型的正确性
重新进行估算
校验输入是否正确
校验输入是否合理
校验对数据的计算是否合理有效
比较延期的估算是否符合项目实际情况
让谨慎的人来作测试验证工作
对软件中的冗余价值估算
影响估算正确与否的因素
软件规模
新设计新代码的比例
复杂程度
设计和编码的困难
使用什么语言
安全性
需求的挥发性
影响估算正确与否的因素
组织因素
项目计划
人员
开发环境
计算机资源
人员利用率
膨胀因素
估算就是估算，不是保证书
软件进展测试
追踪系统的瓶颈
工作完成点
同配置管理系统紧密的结合
如何使用
模块列表
里程碑
工作完成点
用计算所有工作的完成度来检查系统工作过程。
测试计划
开发测试计划
目标
详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。
可能的不利因素：
没有得到足够的培训
心里准备不足
缺乏测试工具
缺乏管理的标准和支持
缺乏客户和最终使用者的参与
没有足够的时间进行测试
对于独立的测试人员过度信任
版本改变的太快
测试人员处于不受重视的情况中
不能说不
实施过程
听取各方面的意见和建议
标明项目风险
测试要素
联系测试矩阵
建立测试计划
对计划进行评审
建立测试计划
定义测试目标
开发测试矩阵
软件模型
结构特性
批量测试的阶段和用例
为在线系统作概念上的测试脚本
软件测试矩阵
定义测试管理
测试计划的一般性信息
定义测试里程碑
定义管理上的检查点
书写测试计划
评审测试计划
涉及评审的问题
评审测试的开始时间是否会延期
有没有抵触评审的角色
一段时间内是否很难得到工作的检查信息。
更换工具有可能导致他们反感评审工作
评审结果可能会影响对个人的工作评价
对于最终成品的检查
项目的需求规格说明书
软件返工/维护的文档
升级后的技术文档
被更改的源程序
测试计划
用户手册（包括在线帮助）
评审测试计划
正式评审中的角色
缓和剂（SQA）
读者
记录者
作者
检测员
正式评审发现的缺陷应包含的信息
起因
类型
分类
级别
评审流程
计划和组织
通篇的讲解（可选）
个人准备
评审会议
修订和反复
需求阶段的测试
测试成本
在软件开发的所有阶段进行测试
被设计用来减少测试成本
IBM的数据
大约 60个缺陷/千行
2/3的缺陷产生在需求和设计阶段
在需求和设计阶段发现的缺陷修正的花费最小
修正系统测试阶段发现的缺陷，花费是以上的10倍
发布产品以后，修正缺陷的花费是原来的100倍
生命周期的测试概念
在软件开发过程中持续的进行测试
在尽可能早的阶段点去修正缺陷
需要正式的开发流程来支持
组建测试团队
当开发开始进行的时候，测试就开始进行了
需求阶段的测试
准备风险列表
确定风险组
确定风险
风险分析
风险检查表
建立控制目标
确定有足够的控制力度
分析测试要素
需求的设计是否遵循了已定义的方法
提交了已定义的功能说明
定义了系统界面
已经估计了性能标准
容忍度被预先估计
预先定义了权限规则
需求中预先定义了文件完整性
预先定义了需求的变更流程
预先定义了失败的影响
权限定义
需求走查
建立基本规则
选择小组/通报参与者
项目介绍
问题/建议
形成最终报告
需求阶段测试
所有的花费都是值得的
大部分缺陷将不会进入到设计&编码阶段
目标
需求正确的表现出了用户的需要
需求已经被定义和文档化了
花费和收益成正比
需求的控制被明确
有合理的流程可遵循
有合理的方法可供选择
设计阶段的测试
设计阶段的测试
交付的产品
输入说明
过程说明
文件说明
输出说明
控制说明
系统流程图
硬件和软件的需求
操作手册说明书
数据保留的策略
设计阶段测试任务
给测试要素打分
分析测试要素
对设计进行评审
检查修改的部分
分析测试要素
测试涉及的内容：
设计了对数据完整性的控制
设计了权限规则
设计了对文件完整性的控制
设计了审计追踪
设计了发生意外情况时的计划
设计了如何达到服务水平的方法
定义了权限流程
定义了完整的方法学
设计了保证需求一致性的方法
进行了易用性的设计
设计是可维护的
设计是简单的
交互界面设计完毕
定义了成功的标准
需要同实际操作者沟通
对设计进行评审
选择评审组成员
对评审组进行培训
通报项目组
分配足够的时间
只对文档化的事实进行评审
和项目组一起进行评审
对评审形成建议
和项目组对建议一起进行评审
准备正式的报告
编码阶段的测试
形成的输出
编码说明书
程序文档
计算机程序列表
可执行的程序
程序流程图
操作介绍
单元测试结果
测试活动的关注点
完成对数据完整性的控制
定义完毕授权的规则
完成对文件完整性的控制
实现审计追踪
规划出意外情况发生后的处理计划
对系统如何达到预定义的服务水平做了计划
完成了对安全问题的处理流程
编码工作是依据规定的方法完成的
编码与设计相一致（正确性）
编码与设计相一致（易用性）
代码是可维护的
编码与设计相一致（简洁性）
编码与设计相一致（耦合性）
已开发了操作流程
定义出程序成功的标准（性能上）
测试的职责
编码是一个纯技术的工作，几乎不需要用户的参与
项目领导者有参与测试的责任
监督过程的有效性
建议的测试方式
桌面调试
语法上的
结构上的
功能上的
代码互查
建立基本的互查规则
选择互查的team
对成员进行培训
选择互查的方法
提供互查的材料
流程图，源程序，典型的处理流程
对互查进行必要的管理
给出互查结论
提供最终的报告
编码阶段的测试需解决的问题
系统是可维护的吗？
系统说明是否已经完成了？
编码是否按照既有的标准进行，过程是否易于实践？
是否有足够的测试计划用来评估可执行的程序？
是否编制了足够的文档。
测试关注点
在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会少一些问题。
文档
测试阶段的测试计划
测试用例
前期测试的测试结果
第三方测试反馈，例如：计算机操作人员
正式的测试总结报告
典型测试类型
手册，回归，功能点测试
一致性测试（授权）
功能点测试（完整性）
功能点测试（审计，追踪）
覆盖性的测试（测试的连续性）
压力测试（服务水平）
一致性测试（安全性）
依照预先定义的测试方法
功能点测试（正确性）
支持手册的测试（易用性）
检查（可维护性）
灾难性的测试（可携带性）
功能和回归测试（耦合性）
一致性的测试（性能）
操作性的测试（易用性）
建议测试方法
测试方法
测试用例的概念是简单的
建立有效的测试用例是复杂的
设计测试文件
测试用例应当包含合法的和非法的输入
每一个动作只进行一次关键操作
输入测试数据
分析结果
尝试将测试文件违反程序的规则进行输入
容量测试的测试工具
以大信息量的数据进行输入
这是一个昂贵的测试，应根据需要来选择
在线系统需要做压力测试
测试总结
测试报告
目标
表示出目前项目的实际状况
明确什么是测试做的工作，什么是不作的工作。
给出系统的操作性能的评价
明确什么时候系统可以进行产品化的工作
关注点
测试报告只有真正需要的时候才有用，需要配合市场和管理
测试的信息是不充分的（对于评价一个项目来说）
测试状况并不能真实的反应个人的状况
测试期间数据的收集
有关测试结果的积累数据
测试任务，测试集合和测试事件的描述
缺陷分析
由于计划的问题，导致没有发现的缺陷的数据
严重的缺陷
缺陷类型
为什么缺陷没有发现
效果
测试报告
报告目前的软件状态
功能/测试矩阵
功能测试的状态报告，侧重点分析
关于功能的工作时间轴
期望发现 VS 实际发现的缺陷比
没有发现的缺陷和改正的缺陷的差距
按照类型分类，没有改正的缺陷的平均值
缺陷分类报告
测试活动报告
最终的报告汇总
各个阶段的项目测试总结报告
继承性测试报告
系统测试报告
确认测试报告
展开
