4. 第四阶段_全栈通用测试技术

4.第四阶段_全栈通用测试技术

第一章 软件测试概述

软件和软件测试

软件的分类

• 按层次划分
  • 系统软件
  • 支持软件
  • 应用软件
• 按结构划分
  • 单击软件
  • 分布式软件
    • C/S
    • B/S
• 按组织划分
  • 开源软件
  • 闭源(商业)软件

缺陷的由来和定义

• bug

• defect - 表示的范围比较广

• 软件缺陷的定义

  • 软件未实现产品说明书要求的功能
  • 软件出现了产品说明书指明不应该出现的功能
  • 软件实现了产品说明书未提到的功能
  • 软件未实现产品说明书虽未明确提及但应该实现的目标
  • 软件难以理解、不易使用、运行缓慢或者(从测试角度看)最终用户会认为不好
  • ( 所有不满足需求或者超出需求的都是缺陷 )
  • (没有不存在缺陷的软件,只有迄今为止尚未发现的缺陷 )

软件测试的定义

正向思维的定义

出发点 : 使自己确信产品是能够正常工作的.评价一个程序和系统的特性和能力,并确定他是否达到期望的结果,软件测试就是以此为目的的任何行为

*反向思维的定义

• 出发点 : 测试时为发现错误而执行一个程序或者系统的过程
• 测试时为了证明程序有错,而不是证明程序无错误
• 一个好的测试用例在于它能发下以前未发现的错误
• 一个成功的测试是发现了以前未发现的错误的测试

IEEE定义的软件测试

• 在规定的条件下运行系统或构件的过程: 观察和记录结果,并对细条绒或构件的某些方面给出评价
• 分析软件项目的过程 : 检测现有状况和所需状况之间的不同,并评估软件项目的特性

*广义的软件测试

• 软件测试是对软件形成过程中的所有工作产品(包括程序以及相关文档)进行的测试,而不仅仅是对程序的运行进行测试
• 验证 (Verification)
  • 通过检查和提供客观证据来证实指定的需求是否满足
• 确认 (Validation)
  • 通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现

*软件测试的目的

• 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,保证各种错误和缺陷得以修复, 避免软件在发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险
• 同时利用测试过程中得到的测试结果和测试信息,作为后续项目开发和测试过程改进的重要输入,避免在将来的项目开发和测试中重复同样的错误
• 采用更加高效的测试管理手段,提高软件测试的效率和软件产品的质量

测试和调试的区别

• 在主体、目标、方法和思路上有所不同
• 测试是从已知的条件开始,使用预先定义的过程,并且有预知的结果,调试是从未知的条件开始,结果的过程不可预计
• 测试可以计划,可以预先制定测试用例和过程,工作进度可以度量; 描述调试的过程或持续时间相对比较困难
• 测试的对象包括软件开发过程中的文档、数据以及代码, 而调试的对象一般来说只是代码

软件测试的对象

**软件的定义 : **程序 = 数据 + 文档

• 软件测试贯穿于整个人软件生命周期中
  • 文档
  • 单元测试
  • 集成测试
  • 确认测试
  • 系统测试
  • 验收测试

软件的典型错误

• 美国爱国者导弹防御系统 (1991)
• 迪斯尼的狮子王游戏 (1994-1995)
• 英特尔奔腾浮点触发缺陷 (1994)
• 美国宇航局火星登陆者号探测器 (1999)
• 千年虫问题 (1999)
• Windows 2000漏洞 (2000)
• 北京奥运会门票订票网站瘫痪 (2007)
• 温州高铁事故 (2011)

第二章 软件生命周期和测试过程模型

一、软件生命周期和软件工程

• 软件生命周期
  • 立项 → 需求分析 → 设计、编码、测试 → 发布 → 运行维护 → 淘汰

二、软件开发过程模型

• 瀑布模型

  项目计划 - 需求分析 - 软件设计 - 程序开发 - 软件测试 - 集成维护
  优点 :
  	1. 为项目提供了按阶段划分的瀑布模型检查点
  	2. 当前一阶段完成后,只需要去关注后续的阶段
  缺点 :
  	1. 各个阶段的划分完全固定,阶段之间产生大量文档,增加工作量
  	2. 由于开发模型是线性的的,用户只有等到整个过程结束才能见到开发成果,增加开发风险
  	3. 瀑布模型不适应用户需求的变化
  

• 快速原型模型

  快速创建一个可以运行的软件原型,以便理解和澄清问题,是开发人员和用户达成一致.
  优点 : 
  	克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险
  缺点 :
  	所选用的开发技术和工具不一定符合主流的发展,快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
  

• 增量模型

  把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次分析、设计、编码和测试这些增量组件
  优点 : 
  	1. 可以分批次提交软件产品
  	2. 以组件为单位进行开发降低了软件开发的风险
  	3. 开发顺序灵活
  限制 :
  	要求项目管理人员把握全局的水品较高
  

• 迭代模型

  	迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他元素,强调开发的深入
  	在莫衷程度上,开发迭代是一次完整地经过所有工作流程的过程 :需求分析、设计实施和测试工作流程
  优点 :
  	1. 降低了在一个增量上的开支风险
  	2. 降低了产品无法按照既定进度进入市场的风险
  	3. 加快了整个开发工作的进度
  	4. 迭代模型使适应需求的变化会更容易些
  

• 螺旋模型

  螺旋模型使一种演化软件开发过程模型,兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控
  优点 :
  	1. 引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失
  	2. 更适合大型的昂贵的系统级的软件应用
  

三、软件测试过程模型

1. 软件测试过程概述

• 软件测试过程是一种抽象的模型,用于定义软件测试的流程和方法
• 测试过程的质量将直接影响测试结果的准确性和有效性.
• 一个标准的软件测试过程中,应包含但不限于包含 : 需求分析、测试计划、测试设计、测试执行、测试总结… …

2. V模型

V模型 :

用户需求						 验收测试
	需求分析与系统				 系统测试
		概要设计			集成测试
			详细设计	单元测试
				  编码

• V模型揭示了开发过程与测试过程中各阶段的对应关系
• 缺点 :
  • 仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段,忽视了测试对需求分析、系统设计的验证
  • 需求的满足请款一直到后期的验收测试才被验证
  • 没有体现出 "尽早地和不断地进行软件测试"的原则

3. W模型

• 由两个V字型模型组成,分别代表测试与开发过程,明确表示出了测试与开发的并行关系
• 优点 :
  • 测试的活动与软件开发同步进行
  • 测试对象不仅仅是程序,包括需求和设计
  • 尽早发现软件缺陷可降低软件开发的成本
• 局限性 :
  • 在W模型中,需求、设计、编码等活动被视为串行的,这样就无法支持迭代开发模型

4. H模型

• H模型将测试活动完全独立出来,形成了一个完全独立的流程,将测试准备活动和测试执行活动清晰地体现出来
• H模型揭示了一个原理 : 软件测试是一个独立的流程
• H模型指出软件测试要尽早准备,尽早执行,只要某个测试达到准备就绪点,测试执行活动就可以开展,并且不同的测试活动可以按照某个次序先后进行,也可以反复进行

5. X模型

• X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合称为可执行的程序
• X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误

6. 测试过程理念

• 尽早测试
  • 测试人员早期参与软件项目
  • 尽早的开展测试执行工作
• 全面测试
  • 对软件的所有产品进行全面的测试
  • 软件开发及测试人员(有时包括用户)
• 全过程测试
  • 测试人员要充分关注开发过程
  • 测试人员要对测试的全过程进行全程的跟踪
• 独立的、迭代的测试
  • 测试活动是独立的
  • 测试活动应该是循环往复、不断的进行

第三章 软件测试常用方法

一. 软件测试分类 *

1. 按照开发阶段划分 *

• 单元测试
  • 单元测试又称模块测试,是针对软件设计的最小单位 – 程序模块进行正确性检验的测试工作
  • 目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求,发现各模块内部可能存在的各种错误.
• 集成测试
  • 集成测试也叫组装测试, 通常在单元测试的基础上, 将所有的程序模块进行有序的、递增的测试.
• 确认测试
  • 确认测试也叫有效性测试,是在模拟的环境下,验证软件的所有功能和性能及其他特性是否与用户的预期要求一致,通过确认测试,才具备进入系统测试阶段的资格
• 系统测试
  • 系统测试是在真实的系统运行的环境下,检查完整的程勋系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接，并最终满足用户的所有需求。
• 验收测试
  • 验收测试是软件产品检验的最后一个环节,按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接受或者拒收系统

2. 按照测试技术划分 *

• 黑河测试
  • 通过软件的外部边线来发现缺陷和错误
• 白盒测试
  • 通过对程序内部结构的分析、检测来寻找问题,白盒测试又称结构测试
• 灰盒测试
  • 介于白盒测试和黑盒测试之间的测试.灰盒测试关注输出对于输入的正确性;同时也关注内部表现

3. 按照代码运行划分

• 静态测试
  • 指不实际运行被测对象,只是形态检查程序代码、界面或者档案中不能存在的错误的过程
    • 代码测试 : 测试代码是否符合相应的标准规范
    • 界面测试 : 测试软件的实际界面与需求是否相符
    • 文档测试 : 测试用户手册和需求说明是否真实符合用户的实际需求
• 动态测试
  • 指实际运行被测对象, 驶入相应的测试数据,检查实际输出结果和预期结果是否相等的过程

4. 按照软件特性划分

• 功能测试
  • 是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求
    • 逻辑功能测试
    • 界面测试
    • 易用性测试
    • 安装/卸载测试
    • 兼容性测试
• 性能测试
  • 功能的另一个指标,主要关注软件中的某一功能在指定的时间、空间条件下，是否使用正常
  • 软件的性能包括很多方面,主要是时间性能和空间性能两种
• 安全性测试
  • 验证安装在系统内的保护机制能否在实际应用中对系统进行保护,使之不被非法入侵,不受各种因素的干扰

5. 其他分类

• 回归测试
  • 是指对软件的新版本测试时,重复执行之前某一重要版本的所有测试用例
  • 目的
    • 验证之前版本产生的所有缺陷已全部修复
    • 确认修复这些缺陷没有引发新的缺陷
• 冒烟测试
  • 是指在对一个新版本进行系统大规模测试之前,先验证一下软件的基本功能是否实现,是否具备可测性,也叫可测性测试
• 随机测试
  • 是指测试人员基于经验和直觉的测试,发现一些边缘性的错误
• 猴子测试
  • 把自己当成不懂产品的笨蛋,随机乱点,没有任何的主观意思和想法参与进来,让一些意想不到的操作造成错误的结果

二. 软件测试生命周期(流程) *

获取测试需求 →

编写测试计划 →

制定测试方案 →

开发与设计测试用例 →

执行测试 →

提交缺陷报告 →

测试分析与评审 →

提交测试总结 →

准备下一版本测试

三. 软件测试的原则 *

• 所有测试的标准都是建立在用户需求之上的
• 软件测试必须基于"质量第一"的思想去开展各项工作,当时间和质量冲突时,时间要服从质量
• 事先定义好产品的质量标准,只有只有了质量标准,才能根据测试的结果,对产品的质量进行分析和评估
• 软件项目一启动,软件测试也就开始,而不是等程序写完,才开始进行测试
• 穷举测试是不可能的
• 第三方进行测试会更客观,更有效
• 软件测试计划是做好软件测试工作的前提
• 测试用例是设计出来的,不是写出来的,因此要根据测试目的,采用相应的方法去设计测试用例,从而提高测试的效率,更多的发现错误,提高程序的可靠性
• 对发现错误较多的程序段,应进行更深入的测试,一般来说,一段程序中已发现的错误数越多,其中存在的错误概率也会越大
• 重视文档,妥善保存一切测试过程文档(测试计划、测试用例、测试报告等)
• 应当把"尽早个不断地测试"作为测试人员的座右铭
• 回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多错误出现的现象并不少见
• 测试应从"小规模"开始,逐步转向"大规模"
• 不可将测试用例置之度外,排除随意性
• 必须彻底检查每一个测试结果
• 一定要注意测试中的错误集中发生现象,这和程序员的编码水平和习惯有很大的关系
• 对测试错误结果一定要有一个确认的过程

四. 软件测试人员职业发展

第四章 测试需求及其获取

一. 需求的重要性

…

二. 需求的定义及分类

• 需求的定义

  • 用户解决问题或达到目标所需条件或权能 (Capability)
  • 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能
  • 一种反应上述1或2条所述条件或权能的文档说明
  • 它包括功能性需求及非功能性需求,非功能性需要对设计和实现提出了限制,比如性能要求,质量标准,或者设计限制

• 需求的分类

  • 用户需求 (user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例 (use case) 文档或方案脚本 (scenario) 说明中予以说明
  • 业务需求 (business requirement ) 反应了组织机构或客户对系统、产品高层次的目标要求,他们在项目视图与范围文档中予以说明
  • 功能需求 (functional requirement ) 定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求

• 需求分析

三. 需求对测试的重要性 *

• 测试的根本出发点
• 8020原则 (bug出现的分布)
  • 54% 规格说明
  • 25% 设计
  • 15% 代码
  • 6% 其他
• 缺陷的修复成本

四. 需求跟踪矩阵 *

需求开发是一个不断反复的过程

• 需求分析

• 需求规格说明书

  • 人间需求规格说明的特点
    • 完整性
    • 一致性
    • 可修改性
    • 可跟踪性

• 测试需求跟踪矩阵 *

  • 根据软件开发需求说明书逐条列出软件开发需求,并判断其可测试性
  • 形成可测试的描述并界定出测试范围
  • 根据质量标准,逐条制定质量需求,即测试通过标准
  • 分析测试执行时需要实施的测试类型
  • 建立测试需求跟踪矩阵,对测试需求实施严格有效的管理

• 测试需求跟踪矩阵模板

需求编号	功能点名称	需求描述	需求拆分	测试类别	测试要点	测试负责人	优先级
Req_项目名称_模块名称_功能名称_0001	增加用户	在添加用户页面,输入用户信息,点击提交按钮	用户名要求: 6~18位 、字母、数字…	正向	用户名符合要求,点击提交按钮,提示成功	XXX	High
Req_项目名称_模块名称_功能名称_0002			用户名为空	反向	不填写用户名,点击提交按钮,提示	xxx	…
Req_项目名称_模块名称_功能名称_0003			用户名超过位数限定	反向	提示信息	xxx	…

• 编写测试需求跟踪矩阵的步骤
  • 阅读理解各类需求
  • 结合界面原型图理解软件各部分功能
  • 从叶级别的功能点开始编写矩阵
  • 保证每个功能点都有正反测试思路覆盖,正反测试配比达到1:4 (部分功能点没有反向测试)
  • 只写清测试思路和预期结果,不用具体展开
  • 写好的测试需求跟踪矩阵必须通过评审才算最终完成

第五章 评审及其意义

评审概述

• 评审的定义

  • 在正式的会议上将软件项目的成果 (包括各阶段大的文档、产生的代码等) 提交给用户、客户或有关部分人员对软件产品进行评价和批准

• 评审的目的

  • 找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷
  • 采取补救措施
  • 找出在性能、安全性和经济方面的可能的改进

• 评审的目标

• 评审的分类

  • 同行评审 *
  • 单人评审
  • 管理评审
  • 代码检查

评审的准备和流程

• 评审的一般步骤
  • 指定评审计划 → 举行评审会议 → 评审的准备 → 对评审结果采取行动 → 评审结果被跟踪直至完成 → 提交和归档
• 评审的准则
• 同行评审

评审的误区

• 参与人员不了解评审
• 评审没有被安排进项目计划
• 评审会议变成了问题解决方案讨论会
• 评审人员事先对评审工件没有足够了解
• 评审人员关注于非实质性问题
• 忽视组织细节
• 会议时间过长

需求评审的过程

第六章 软件测试计划

测试计划概述

• 测试计划的定义

  • 规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险

  • 5W1H

    who when where what why how
    

• 测试计划的目的

测试计划的内容

• 测试目的
• 测试项目简介
• 测试参考文档
• 测试提交文档
• 术语和定义
• 测试策略
• 确定测试内容
• 资源
• 测试进度
• 测试人员的任务分配
• 风险和问题

测试计划案例分析

第七章 测试用例和设计方法一

测试用例概述

• 测试用例
  • 设计一个情况,软件程序在这种情况下,保修能够正常运行并且达到程序锁设计的预期结果
• 测试用例应包含以下内容
  • 标识符
  • 测试项
  • 输入说明
  • 输出说明
  • 环境要求
  • 特殊要求
  • 用例之间的依赖性

测试用例模板和实践

• 测试用例模板

  测试用例编号	测试项	依赖用例	测试步骤	输入数据	预期结果	测试结果	测试人	测试时间	备注
  TestCase_项目名称_模块名称_二级模块_测试类型_001	测试目的: 简单描述测试目标	若需要依赖用例,填写用例编号即可	详细描述测试的步骤和流程 : 包括使用的浏览器、输入的网址、点击的按钮或超链接名称、输入的测试数据	只包含输入过程中的数据
  测试类型 : 功能测试 : Function 性能测试 : Performance 界面测试 : UI(UserInterface) 文档测试 : Documentation 单元测试 : Unit 接口测试 : Interface

用例编写注意

• 不要设计 “穷举测试用例”
• 在详细测试用例与有效测试时间中找到平衡点
• 好的测试用例应该多关注"反向测试问题"
• 测试用例库应该不断更新和维护
• 测试用例可以复用,但要注意数据有效性和环境变化
• 测试用例是设计出来的,不是写出来的
• 多去学习经验丰富的测试工程师所设计的测试用例
• 针对不同的需求类型和测试对象,灵活采用不同的测试用例设计方案

黑盒测试用例设计方法 (一)

• 等价类划分法

  • 把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据作为测试用例;
  • 每一类的代表性数据在测试中的作用等价于这第一类中的其他值

• 确定等价类的原则

  • 在输入条件规定了取值范围或值的个数的情况下,可以确立一个有效等价类和两个无效等价类
  • 在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可以确立一个有效等价类和一个无效等价类
  • 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类
  • 在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类

• 边界值分析法

• 因果图法

  • 因果图法是一种适合于描述对于多种输入条件组合的测试方法
  • 根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法
  • 适用于价差程序输入条件涉及的各种组合情况
  • 根据功能说明在因果图中加上约束条件
  • 其中互斥、包含、唯一、要求时对原因的约束,屏蔽是对结果的约束,他们的含义如下
    • 互斥 : 表示不同时为1 , 即a,b,c中至多只有一个1
    • 包含 : 表示至少有一个1,即a,b,c中不同时为0
    • 唯一 : 表示a,b,c中有且仅有一个1
    • 要求 : 表示若a=1,则b必须为1,即不可能a=1且b=0
    • 屏蔽 : 表还若a=1则b必须为0

• 判定表驱动法

  是分析和表达多逻辑条件下执行不同操作的情况的工具

  • 条件桩 (Condition Stub) : 列出了问题的所有条件,通常认为列出的条件的次序是无关紧要的
  • 动作桩 (Action Stub) : 列出了问题规定可能采取的操作,这些操作的排列顺序没有约束
  • 条件项 (Condition Entry) : 列出针对它左列条件的取值,在所有可能情况下的真假值
  • 动作项 (Action Entry) : 列出在条件项的各种取值情况下应采取的动作

• 适合使用判定表设计测试用例的条件

  • 规格说明以判定表的形式给出,或很容易转换成判定表
  • 条件的排序顺序不影响执行哪些操作
  • 规则的排列顺序不影响执行哪些操作
  • 当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则
  • 若果某一规则要执行多个操作,这些操作的执行顺序无关紧要

第八章 黑盒测试用例设计方法二

黑盒测试用例设计方法二

正交实验法 **

• 正交实验法
  • 利用排列整齐的表对试验进行整体设计、综合比较、统计分析，实现通过少数的试验次数找到较好的生产条件，以达到最好效果 （从大量的试验点中挑选适量的具有代表性的点）
  • 基本思想
    • 在一项实验中,把影响试验结果的量称之为试验因素
    • 每列中不用梳子出现的次数相等
    • 在任意2列其横向组成的数字对中,每种数字对出现的次数相等
  • 基本步骤
    • 确定因素 :这里的因素指对软件运行结果有影响的因素
      • 确定因素的取值范围或集合
    • 确定每个因素的水平
      • 根据因素的取值范围或集合采用等价类划分、边界值分析以及其他软件测试技术，在每个因素的取值范围或集合内挑选出有效等价类、无效等价类、正好等于、刚好大于或刚刚小于边界值等有代表性的测试值
    • 选择正交表
      • 根据确定的因素和水平,选择适合的正交表
      • 若没合适的正交表可用,或需要的测试用例个数太多,要对因素和水平进行调整
• 使用正交设计助手生成正交表

场景法 **

状态迁徙图法 *

• 状态迁徙图法的目标
  • 设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖
  • 状态图法步骤
    • 列出所有可能的输入事件,以ip N的方式命名 (N为1,2,3,…)
    • 把软件的打开的初始状态,定义为"空闲"状态
    • 在 "空闲"状态上加所有可能的输入 (只加一次)
    • 为上一步产生的所有新状态,分别加所有可能的输入(只加一次)
    • 循环执行上一步
    • 直到再没有任何新状态产生,列出所有的状态,生成状态表
    • 组合任意可能的状态组合,写出相应的测试用例

测试大纲法 *

• 一种着眼于需求的方法
• 为列出各种测试条件,将需求转换为大纲的形成

其他测试用例设计方法

• 探索性测试法
  • 基于测试人员经验与直觉的测试方法
  • 是对测试用例设计的有效补充
  • 探索性测试也必须生成测试用例
• 猴子测试(随意性测试)

用例设计方法选择的总和策略 ***

• 首先进行等价类划分
• 在任何情况下都必须使用边界值分析方法
• 若程序的功能说明中含有输入条件的组合情况,则一开始就可以选用因果图法和判定表驱动法
• 对于参数配置类的软件,要用正交实验法选择较少的组合方式达到最佳效果
• 状态迁徙图法页数很好的测试用例设计方法,可通过不同时期条件的有效性设计不同的测试数据
• 对于业务流清晰地系统,可以利用场景法贯穿整个测试案例过程
• 可以用错误推测法追加一些测试用例 (探索性测试)
• 对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,若没达到要求的覆盖标准,应该再补充足够的测试用例

第九章 WEB测试方法

一 Web功能测试

• 链接测试
  • 链接是否正确
  • 链接页面是否存在
  • 是否有孤立的页面 (没有链接指向的页面)
• 表单测试
  • 测试重点
    • 表单控制的正确性
    • 提交信息的完整性、正确性
    • 是否有错误处理
• Cookie测试
  • Cookie通常标识用户信息,记录用户状态
• 设计语言测试
  • 在Web应用系统开发初始,根据软件工程的要求用文档的新式确定Web应用系统使用哪个版本的HTML标准,允许使用何种脚本语言及版本,允许使用何种空间,这样可有效避免Web应用系统开发过程中出现设计语言问题

二 Web性能测试

• 速度测试
  • 通常情况下,响应时间不超过5秒
  • 有些Web应用洗头工有超时限制,如果响应时间太慢,用户可能没有来得及浏览内容,就需要重新登录
  • 影响响应时间的原因
    • 应用程序服务器需要从数据库的大量数据中心检索信息
    • 服务器硬件影响(CPU、内存)
    • 所访问页面文件大小
    • 网络连接宽带
• 负载测试
  • 是为了测量Web应用系统在一定负载情况下的系统性能,通常得出的结论是Web应用系统在一定的硬件条件下可以支持的并发用户数目或者单位时间数据 (或事件) 的吞吐量
• 压力测试
  • 压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下回崩溃,崩溃以后会怎样

三 Web安全性测试

• Web应用系统多采用登录的方式
  • 确保应用刺痛实际应用中可修改默认管理员账号和密码
  • 用户名和密码设置要求 (长度、大小写敏感、复杂度)
  • 允许错误登录的次数
  • 是否可以不登录而直接浏览某个页面
• 保证日志文件记录了Web应用系统的主要操作过程,并可根据日志文件追查到系统使用情况;同时还需要保证日志文件本身的安全性、完整性,防止被入侵者删除、获得
• 当Web应用系统采用了SSL等加密技术之后,需要确认加密、解密后信息传递的正确性和完整性
• 需要确认Web应用系统是否有超时设置,如有,则保证在超时设置时间内,若未操作Web应用系统,当再次访问系统,需要重新登录

四 Web配置兼容性测试

五 Web易用性测试

• 有效性
• 效率
• 满意度
• 可以从以下几方面考虑
  • 能否成功的完成一个任务
  • 对应普通用户,完成典型任务需要多长时间
  • 完成典型任务需要访问的页面数
  • 系统是否提供了层次结构明确、表达清楚的导航功能
  • 对整个系统的感觉如何
  • 信息是否正确、精确(内容)
  • 帮助系统是否准确并容易使用
  • 系统是否提供搜索、网站地图等功能
  • 页面下载时间用户能否接受

第十章 缺陷和缺陷报告

缺陷概述

• 缺陷的定义

  • 软件未实现产品说明书要求的功能
  • 软件出现了产品说明书指明不应该出现的功能
  • 软件实现了产品说明书未提到的功能
  • 软件未实现产品说明书虽未明确提及但应该实现的目标
  • 软件难以理解、不易使用、运行缓慢或者 (从测试的角度看)最终用户会认为不好

• 缺陷的属性

  属性名称	描述
  缺陷类型	缺陷类型是根据缺陷的孜然属性划分的缺陷种类
  缺陷严重程度	缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度
  缺陷优先级	缺陷的优先级值缺陷必须被修复的紧急程度
  缺陷状态	缺陷状态是指缺陷通过一个跟踪修复过程的进展情况
  缺陷起源	缺陷来源是指缺陷引起的故障或事件第一次被检测到的阶段
  缺陷原因	缺陷来选是指引起缺陷的原因
  缺陷根源	缺陷根源是指发生错误的根本因素

• 缺陷类型

  缺陷类型	描述
  功能	影响了各种系统功能、逻辑的缺陷
  用户界面	影响用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷
  文档	影响发布和维护，包括注释、用户手册、设计文档
  软件包	由于软件配置库、变更管理或版本控制引起的错误
  性能	不满足系统可测量的属性值，如执行时间、事务处理速率等
  系统/模块接口	与其他组件、模块或设备驱动程序、调用函数、控制块或参数列表等不匹配、冲突

• 缺陷的严重程度

  缺陷严重等级	描述
  致命 (Fatal)	系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机或者危机人身安全
  严重 (Critical)	系统的主要功能部分丧失,数据不能保存,洗头工的次要功能完全丧失,系统所提供的功能或服务受到明显的影响
  一般 (Major)	系统的次要功能没有完全实现,但不影响用户的正常使用,例如提示信息不太准确或用户界面差、操作时间长等
  较小(Minor)	操作者不方便或遇到麻烦,但不影响功能的操作和执行,如个别不影响产品理解的错别字,文字排列不整齐等小问题

• 缺陷的修复优先级

  缺陷优先级	描述
  立即解决 (P1级)	缺陷导致系统几乎不能使用或测试不能继续,需理解修复
  高优先级 (P2级)	缺陷严重,影响测试,需要优先考虑
  正常排队 (P3级)	缺陷需要正常排队等待修复
  低优先级 (P4级)	缺陷可在开发人员有时间的时候被纠正

• 缺陷的状态

  缺陷状态	描述
  激活或打开 (Active Open)	问题还没解决,存在源码中,确认"提交的缺陷",等待处理,如新的缺陷
  已修正或修复(Fixed or Resolved)	已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没被测试人员验证
  关闭或非激活(Close or Inactive)	测试人员验证后,确认缺陷不存在之后的状态
  重新打开(Reopen)	测试人员验证后,依然存在的缺陷,等待开发人员进一步修复
  推迟(Deferred)	这个软件缺陷可在下一个版本中解决
  保留 (On hold)	由于技术原因或第三者软件的缺陷,开发人员不能修复的缺陷
  不能重现 (Cannotduplicate)	开发不能再现这个软件缺陷,需要测试人员检查缺陷复现的步骤
  需要更多信息(Needmoreinfor)	开发能再现这个软件缺陷,但开发人员需要一些信息,例如缺陷的日志文件、图片等
  重复 (Duplicate)	这个软件缺陷已经被其他的软件测试人员发现
  不是缺陷(Notbug)	这个问题不是软件缺陷
  需要修改软件规格说明书(Specmodified)	由于软件规格说明书对软件设计的要求,软件开发人员无法修复这个软件缺陷,必须要修改软件规格说明书

缺陷的生命周期

发现缺陷 → 提交缺陷 → 确认缺陷 → 分配缺陷 → 修复缺陷 → 验证缺陷 → 关闭缺陷

​ ↑ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ↓

缺陷的识别和描述

• 缺陷的识别
  • 通过测试用例中的预期结果进行识别
  • 通过需求规格说明书进行识别
  • 通过用户手册及其他文档进行识别
  • 通过同行业相类似成熟的商业软件来识别
  • 通过和有经验的测试人员沟通进行识别
  • 参照同行业隐式需求进行识别
• 缺陷的记录
  • 缺陷跟踪数据库信息(软件)
    • Bugzilla (英文),安装比较繁琐
    • Bugfree 中文 安装简单 用例 缺陷的跟踪 功能单一
    • 禅道 中文 国产 项目 产品 测试 齐全 足迹机构 人员 开源 免费
    • QC(ALM) 外国 英文 功能齐全
    • JIRA 外国 Java环境 主流 (商业)
    • 企业自己开发
• 缺陷描述时的准则

缺陷报告

• 缺陷报告编写准则 (5C准则)

  • Correct(准确) : 每个组成部分的描述准确,不会引起误解
  • Clear (清晰) : 每个组成部分的藐视清晰,易于理解
  • Concise (简洁) : 只包含必不可少的信息,不包含任何多余的内容
  • Complete(完整) : 包含复现该缺陷的完整步骤和其他本质信息
  • Consistent (一致) : 按照一致的格式书写全部缺陷报告

• 缺陷报告模板

  缺陷编号	所属模块	优先级	严重程度	缺陷概述	缺陷描述	提交人	备注
  Bug_		P1/P2/P3/P4	S1/S2/S3/S4	一句话描述(时间、地点、人物、事件)	复现步骤、实际结果、预期结果		特殊条件、产生该缺陷的测试用例编号

第十一章 测试总结报告

一 软件测试总结报告的作用

二 评估系统测试的覆盖程度

• 软件测试评估的目的
• 基于需求的测试覆盖评估
• 基于代码的测试评估
• 基于测试执行的覆盖评估
  • 假定Tx已执行的测试过程数或测试用例数,Rft是测试需求的总和
    • 已执行的测试覆盖 = Tx / Rft
  • 假定Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数
    • 成功的测试覆盖 = Ts / Rft

三 软件缺陷分析 **

• 缺陷分布报告
• 缺陷趋势报告
• 缺陷年龄报告
• 缺陷解决进度报告

四 基于缺陷分析的产品质量评估

五 测试报告及模板

一、引言

• 1.1 编写目的
• 1.2 项目背景
• 1.3 系统简介
• 1.4 术语和缩写词
• 1.5 参考资料

二、 测试概要

• 2.1 测试用例设计
• 2.2 测试环境与配置
• 2.3 测试方法 (和工具)

三 、测试结果

• 3.1 测试执行情况与记录
  • 3.1.1 测试组织
  • 3.1.2 测试时间
  • 3.1.3 测试版本
• 3.2 覆盖分析
  • 3.2.1 需求覆盖
  • 3.2.2 测试覆盖
• 3.3 缺陷的统计与分析
  • 3.3.1 缺陷汇总
  • 3.3.2 缺陷分析
  • 3.3.3 残留缺陷与未解决问题

四、测试结论与建议

的测试用例编号 |
| | | | | | | | |

第十一章 测试总结报告

一 软件测试总结报告的作用

二 评估系统测试的覆盖程度

• 软件测试评估的目的
• 基于需求的测试覆盖评估
• 基于代码的测试评估
• 基于测试执行的覆盖评估
  • 假定Tx已执行的测试过程数或测试用例数,Rft是测试需求的总和
    • 已执行的测试覆盖 = Tx / Rft
  • 假定Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数
    • 成功的测试覆盖 = Ts / Rft

三 软件缺陷分析 **

• 缺陷分布报告
• 缺陷趋势报告
• 缺陷年龄报告
• 缺陷解决进度报告

四 基于缺陷分析的产品质量评估

五 测试报告及模板

一、引言

• 1.1 编写目的
• 1.2 项目背景
• 1.3 系统简介
• 1.4 术语和缩写词
• 1.5 参考资料

二、 测试概要

• 2.1 测试用例设计
• 2.2 测试环境与配置
• 2.3 测试方法 (和工具)

三 、测试结果

• 3.1 测试执行情况与记录
  • 3.1.1 测试组织
  • 3.1.2 测试时间
  • 3.1.3 测试版本
• 3.2 覆盖分析
  • 3.2.1 需求覆盖
  • 3.2.2 测试覆盖
• 3.3 缺陷的统计与分析
  • 3.3.1 缺陷汇总
  • 3.3.2 缺陷分析
  • 3.3.3 残留缺陷与未解决问题

四、测试结论与建议