Chapter 1 测试需求分析
1.1 什么是测试需求
--测试需求主要解决“测什么”的问题,即指明被测对象中什么需要测试
--测试需求通常是以软件开发需求为基础进行分析,通过对开发需求的细化和分解,形成可测试的内容。
--测试需求应全部覆盖已定义的业务流程,以及功能和非功能方面的需求
--测试需求不涉及具体的测试数据,测试数据设计是测试设计环节应解决的内容
1.2~1.5略
1.6 如何做需求分析
--熟悉需求背景及商业目标
--了解清楚项目发起的原因,是为了解决用户的什么问题。
--当前的解决方案是不是最优的,为什么会这样做?
--业务模型:
--考虑本项目与外部系统的交互,划分系统边界(除了本项目的需求中要求做的事情,其他的都可以是外部系统,本系统和外部系统之间的交互是系统的边界),
可以参考系统分析说明书。
--确定测试范围和关注点,系统的边界是测试的重点,特备需要关注边界交互时的数据交互。
--业务场景:
1.考虑用例的调用者,一般和外部有交互的用例出错概率较大。
2.考虑系统内部各个用例之间的交互,形成内容业务流程图。
1.7 如何做需求分析
--业务分解:
1.业务功能:与用户实际业务直接相关的功能或细节。
2.辅助功能:辅助完成业务功能的一些功能或者是细节,如:设置过滤条件。
3.数据约束:功能的细节,主要是用于控制在执行功能时,数据的显示范围,数据之间的关系等。
4.易用性需求:功能的细节,产品中必须提供便于功能操作使用的细节,如:快捷键
5.边际约束:功能的细节,在功能执行时,对输入数据项目的一些约束条件,如:只能输入数字。
6.参数需求:功能的细节,在功能中,需要根据参数进行不同处理的细节。
7.权限需求:功能的细节,这里的权限是指在功能执行过程,根据不同的权限进行不同的处理。如:审批
Chapter 2 测试计划
2.1 关于测试计划
--为什么要编写测试计划?
1.领导能根据测试计划做宏观调控,进行相应资源配置等。
2.测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等;
3.便于其他人员了解测试人员的工作内容,进行有关配合工作。
--什么时间开始编写测试计划?
需求分析后,在整个测试工作过程中,不断修改
--由谁来编写测试计划?
具有丰富经验的项目测试负责人
2.2 测试计划的内容
项目概述
--主要编写系统的背景、目的、各种系统概述图
--需求规格说明书中一般都有,复制过来即可
--系统概述图主要是架构图和拓扑图
术语&参考资料
角色
环境
测试工具
甘特图
里程碑
交付件
风险
三大指标
1.开始指标
1.测试环境搭建完成且达到可测要求
2.测试相关人员准备就绪
2.完成指标
1.测试用例执行覆盖率达到100%
2.测试需求覆盖率达到100%
3.系统死锁、系统奔溃、严重错误不能多于1个
4.次要错误不能多于2个
5.不合理或者别扭,文字错误,微不足道错误不能多于2个
6.以上错误均不能出现影响用户使用的bug
3.停止标准
1.测试中出现一级缺陷较多
2.测试环境不稳定。
3.客户需求变更
测试策略
Chapter 3 测试方案
目的:怎么测
测试方案&测试策略
方案内容
实战-功能测试
3.1 测试方案目的
测试方案需要在测试计划大指导下进行,测试计划提出“做什么”,而测试方案明确“怎么做”
3.2 测试方案&测试策略
有的软件公司,把测试方案纳入到测试计划中写,文档名称定为测试计划,但是该计划中的测试方案名称被变更成了测试策略
更好的方案是,测试计划解决做哪些内容和人员分配形成一个文档;测试方案解决如何处理计划中提出的内容,用什么样的对策来更快更优大解决问题,即测试方案是从技术角度出来形成的一个文档,由此形成两个文档。
3.3方案内容
功能测试
界面测试
安全测试
本地/国际化测试
数据库测试
可靠性测试
集成测试
兼容性测试
自动化测试
性能测试
回归测试
3.4实战-功能测试