系统测试

一、系统测试定义

系统测试（System Testing）是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持的软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的测试活动。

---

1、系统测试的目的：是通过与系统的需求定义做比较，发现软件与系统定义不符合与之矛盾的地方。

测试的依据是 需求说明书（需求任务书）SRS

二、系统测试的对象

有纯软件，有的是软硬件结合。

三、系统测试类型

1、功能测试
2、性能测试
3、压力测试
4、容量测试
5、安全性测试
6、GUI测试
7、可以性测试
8、安装测试
9、配置测试
10、异常测试（恢复性测试）
11、备份测试
12、健壮性测试
13、文档测试
14、在线帮助测试
15、网络测试
16、稳定性测试

1、功能测试

功能测试是根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品需求规格。
测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能。
2、功能实现是否满足用户需求和系统设计的隐藏需求。
3、输入呢能否正确接受，能否正确输出结果。

上面的需求主要分 显性 、隐性
1、显性：是正向的需求 、需求书上明确的那些可以做，那些不可以做，显性需求不容易出现bug，但四一旦出现，就是比较严重的bug。
2、隐性：是逆向的需求，就是虽然需求书上面没有明确规定，但是按照常理应该有的，隐性需求容易出现bug，但是一般没有显性严重。

2、性能测试

性能测试就是同来测试软件在集成系统中的运行性能的。


性能测试的目的是度量系统相对于预定义目标的差距。(就是在教研功能是否正常，而不是关注指标达成情况)，

所以性能测试是在功能测试通过之后在执行的。

性能测试关注的各类指标：
1、cpu使用情况
2、内存使用情况
3、系统反应时间
4、功耗
5、流量
…

3、压力测试

压力测试的目的是调查系统在其资源超负荷的情况下的表现。
通过基线测试方法，发现系统在基线或恶劣环境下的自我保护能力，主要是验证系统的可靠性。

4、容量测试

容量测试的目的是使系统城市超额的数据容量来发现它是否能到正确处理。
容量测试是详细数据的，并且它的目的是像是系统可以处理目标内确定的数据容量。
测试要点：关键是在于测试一个最大值。

5、GUI 测试

GUI测试是针对软件系统GUI 界面记性的测试。
主要测试内容：
1、界面实现与界面设计的吻合情况。
2、确认界面处理的正确性。
GUI系统分为3个层次 -----界面层、界面与功能的接口层、功能层
GUI测试重点在界面层和界面与功能的接口层。

6、可以性测试

可用性测试是为了检测用户在理解和使用系统方面到底有多好。主要是保证用户能够舒适的和系统交互。

7、安装性测试

安装性测试的目的就是要验证成功安装系统的能力。
安装测试要点：

安装测试包含3部分：
1、安装前测试：
		a、不仅要检查安装包文件是否齐全，还要检查安装手册。
2、安装中测试：
		a、主要检查安装流程，并检查安装时文件、注册表、数据库的变动。
3、安装后测试：
		a、主要检查安装好后软件能否运行，基本功能是否正常，
		b、检查安装后的文件、文本、目录结构是否正确。
		c、能否正常卸载、和升级。

8、配置测试

配置测试主要测试系统在各软硬件配置、不同的参数配置下具有的功能和性能。
验证全部配置的可操作性和有效性。

9、异常测试

系统异常测试又叫系统容错测试和可恢复性测试，它是通过人工干预手段使系统产生软、硬件异常，通过验证系统异常前后的功能和运行状态。达到检验系统的容错、和可恢复的能力。（是系统可靠性评价的重要手段）

10、备份测试

备份测试是恢复性测试的一个补充，目的是验证系统在软件或者硬件故障的情况 下备份数据的能力。

11、健壮性测试

健壮性测试有时候也叫容错性测试，主要看是否能够自动恢复，或者忽略故障继续运行。

12、文档测试

文档测试主要是对系统提交给用户的文档是否正确，并且保证操作手册的过程能够正确工作。

13、在线帮助测试

在线帮助测试主要用于验证系统的实时在线帮助的可用性和正确性。

14、网络测试

是在网络环境下和其他设备进行对接，进行系统功能、性能与指标方面的测试，保证对接设备正常。
通信产品的协议测试主要关注以下及格方面：
1、一致性测试：测试所实现的系统与协议规范的符合程度。
2、性能测试：检测协议实体或系统的性能指标（数据传输速率、链接时间、吞吐量、并发性）
3、互操作性测试：不同厂商之间、同一协议在不同实现版本之间的互通能力，和互操作能力。
4、坚固性测试：检测协议实体或系统在各种恶劣环境下运行能力。

四、系统测试过程

1、测试过程分为四个阶段

1、系统测试计划阶段：完成系统测试计划
2、系统测试设计阶段：完成系统测试方案
3、系统测试实现阶段：完成系统测试用例、测试规程、系统测试预测试
4、系统测试执行阶段：执行系统测试预测试项、系统测试用例，修改发现的问题并进行回归测试，提交系统测试预测试报告、系统测试报告、缺陷报告。

2、计划阶段：

计划由测试经理或测试组长完成
虽然不是经理或组长 面试也可能问你这个部分的内容，因为虽然不写 但是你要看，我们要根据计划开展工作
强调做什么

1、入口准则：满足什么条件才进入该测试阶段。
需求规格说明书已经基线化（基线化：就是通过了评审，取得了项目组和甲方的认可，是一个标准化的文件）。
2、输入：该阶段工作需要参考的资料。

	1、软件开发书：因为开发不结束工作，无法进行测试
		a、注意：1、开发的计划可能分阶段，然后测试也是可以根据开发的阶段开始测。
		b、注意：2、开发也可能分系统或模块完成代码，测试也将开展对应的测试工作。
	2、软件测试计划：指的是整个测试计划（总计划、集成、系统、验收、α， β），系统测试计划是针对系统测试的详述）
	3、c.需求规格说明书：参考需求说明书 --评估测试对象  测试时间， 任务如何分配

计划大概内容：

		1.测试对象：（系统， 子系统， 模块）
		2.测试类型：功能，性能，兼容，GUI 前面讲的一嘟嘟
		3.测试任务分配：张三 李四 .... 负责什么
		4.时间安排：整体时间 和里程碑时间（模块的里程碑， 测试类型的里程碑）；时间颗粒度：敏捷：刻钟, 小时，一般：天， 周 ，月 注意我们安排时间只考虑工作日
		5.环境搭建(可能出现在方案中)
		6.通过失败标准
		7.风险评估及解决方案(可能出现在方案中)
		8.挂起恢复条件(可能出现在方案中)

出口准则：达到什么目标才能结束该阶段的工作

输出：每个阶段的工作产出 分成阶段性和完整的 ; 对内和对外的；是下一阶段工作的输入
系统测试计划： 阶段性的对内的产出

3、设计阶段

方案也是由经理或组长完成
虽然不是经理或组长 面试也可能问你这个部分的内容，因为虽然不写 但是你要看，我们要根据方案写测试用例
强调怎么做
注意：现在很多企业已经没有方案了，方案部分合并到了计划中

输入：需求规格说明书—》 贯穿整个项目的生命周期；需求在不同阶段和不同情况下会发生改变
为什么每一步都要看需求?
1.验证：看当前步骤的对象是否正确 如测试代码本身是否正常
2.确认：回去看是否和最初的目标一致（需求）
方案：

1.模块的拆分并给出对应的指导
	a.模块拆分 
		i.位置相对集中 功能类似
		ii.模块可以进一步拆分子模块  注意 一般拆分到3层即可
	b.对应指导
		i.手动 检视 点点  用例设计方法（等价类 边界值 判定表 流程分析法......）
		ii.自动（用什么工具， postman jemeter adb  monkey  selenium appium）
		iii.注意甚至可以细化到测试用例程度
2.环境搭建(可能出现在计划中)
3.风险评估及解决方案(可能出现在计划中)
4.挂起恢复条件(可能出现在计划中)

这个阶段的产出属于：阶段性，对内的

4、实现阶段

开始交由测试工程师开始入手完成。

出口准则：
系统测试用例、
根据测试用例设计方法按标准化的格式（编号，模块，子模块，标题， 重要级别， 前置条件， 数据， 操作步骤， 预期结果)编写测试用例

系统测试规程、

1.测试用例执行的先后顺序
	a.优先级
	b.不同用例如果有先后关联关系 要一起完成 不再考虑优先级的问题

系统测试预测试项评审并通过
	1.预测试: 全面展开系统测试前进行的测试，主要测核心功能，测试时间比较短、也是有对应的测试用例
	2.评审并通过：必须预测通过才能进行 系统测试 如果不通过要打回至开发处

这部分的产出: 阶段性的和对内的

5、执行阶段

就是在软件开发将开发好的产品，交到测试工程师这版，然后测试工程师根据测试用例按照等级，进行测试。

这个阶段开始测试了

1.先进行预测试（冒烟测试） 当通过测试后才进行全面的系统测试
	a.如果有bug需要进行bug管理
	b.测试结束后要写测试报告 并 进行评审
	
2.进行全面的系统测试
	a.根据用例执行(手动或工具或代码)
	b.有bug需要进行bug管理
	c.测试完成后要写测试报告并进行评审
	
3.bug管理工具（禅道， jira， 一般有实力的公司（银行，车机）有自己的管理系统）
4.注意如果出现bug 要先回测bug 再 继续当天到测试
5.报告
	a.日报（周报）：今天做了啥，又没达标，明天准备干啥，如果有需要帮助的或困难需要说明
	b.测试总结报告：
		1.用例的执行情况
			1.执行率
			2.通过率（分重要级别， 模块）
		2.bug情况
			a.模块
			b.严重程度
			c.趋势
			d.遗留情况
		3.总结 根据1和2的情况 评估测试是否通过

系统预测试报告 ------>阶段性 可以是对内也可以是对外
系统测试报告 ------->完整的，对外的 要给甲方
缺陷报告-------------->对内的 不要给甲方权限进缺陷管理系统看的权限

五、执行测试

按照系统测试计划，依据辞退测试用例，完成测试的各项操作任务。

1、系统测试执行分以下阶段：

• 构造系统测试环境
• 系统测试预测试
• 转系统测试评审
• 执行系统测试、进行系统测试记录，填写测试日报
• 提交缺陷报告并反馈和跟踪缺陷解决，进行缺陷管理
• 撰写并评审系统系统测试报告

系统环境:
1.有可能是开发，运维，或者是我们自己搭建
2.环境有可能有多套：比如 按不同的测试类型搭建，功能，性能
测试记录：测试用例执行后，需要对用例进行标注： pass fail block NA NS
测试报告：由组长或经理汇总完成，测试工程师提供自己负责部分的数据

2、系统测试环境

根据系统测试方案，搭建系统测试环境是系统测试执行的一个重要步骤，测试环境适合与否会严重影响测试结果的真实性和正确性。

• 系统测试环境包含

1、支撑北侧软件运行的硬件设备。
2、被测软件
3、被测软件配套的操作系统、数据库等系统软件
4、被测数据
5、相关资料文档

3、系统测试预测试

验证软件系统基本功能或预测主要的系统功能，以确保其后的系统测试执行能够顺利进行。
系统测试预测试也被称为冒烟测试。

4、执行系统测试

• 按照软件测试规程执行系统测试、进行系统测试记录，每日调教测试日报。
• 执行测试过程中，发现缺陷，要及时填写缺陷报告，并跟踪缺陷的解决，做好问题的追踪和解决记录。
• 软件系统测试规程：如果没有这个文件，就按照用例的重要程度和用例的先后关联关系执行
• 测试记录：主要是指标注测试例的执行情况
• 缺陷报告：key bug（不一定都是key给开发， 有可能key给需求， 美工）
• 做好问题跟踪和解决记录: key bug后 对bug的处理（开发修复bug， 测试进行回归测试）需要在管理系统中有记录
• 分析回溯软件产品产生问题的原因，（测试做初步定位，如前端，后端，代码的问题，数据库的问题----》开发根据我们提供的方向进一步分析根源，并解决）
• 通过缺陷分析，判断软件产品与设计要求的符合度。：排除环境，操作后就是bug。一般 测试发现40%以上的bug 就可以叫停了

5、系统测试日报

• 测试人员总结每天的测试工作，便于了解自己的测试进度和测试情况，用以调整下一天的工作计划
• 测试人员对被测对象每天给出评估结果，用以调整后续工作中的测试策略
• 测试人员向测试经理反映测试中的困难，保证测试的顺利进行
• 测试经理通过测试日报，了解每个测试人员的工作进度，把握测试的整体进度，发现进度上的风险及时调整计划
• 测试经理通过测试日报，了解各模块缺陷发展趋势，判断测试是否可以退出
  （缺陷发展趋势
  1.逐渐减少趋于0 可以退出
  2.每天都很平稳 不能
  3.越来越多 不能推出）
• 开发经理可以通过软件测试日报了解当前被测试软件的质量情况，并可以调整缺陷修改的人力资源
• 如果产品有多个测试组并行测试，测试日报可以提供彼此测试交流的手段

6、系统测试报告写作和评审

• 依据系统测试计划的测试用过准则，结束系统测试后，撰写系统测试报告。
• 系统测试报告需要通过评审，责任人为软件测试项目组，评审不过，报告将退回。
• 评审通过后，系统测试相关文档代码、工具等均需要跟随软件代码、开发文档一起归档。系统测试过程结束。
• 测试通过准则：

1.用例情况分析 a.执行度 b.覆盖度 c.通过率
2.bug情况分析 a.分布模块 b.趋势 c.遗留情况（bug的严重程度具体分析）

结语

未完待补充…