1 系统测试的概念
系统测试（System Testing）的定义：将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）的环境下，对计算机系统进行一系列的组装测试和确认测试。
系统测试的对象：软硬件集合在一起的系统，集成后的产品，不应是独立的软件与硬件环境。不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设，甚至包括某些数据、某些支持软件的系统等。
目的：通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方，以验证软件的功能和性能等满足其规约所指定的要求。
常见的系统分类：
纯软件：QQ.................
软件和硬件：手机，PSP，空调，电梯
软件硬件和维护人员：大型系统
2 系统测试的环境
真实环境：直接将整个系统和其交联的物理设备真实的建立链接，进行测试
优点：可以发现某些只能在真实环境下出现的问题
缺点：构建这样一个环境需要高昂的费用，它的测试运行也需要高昂的费用
仿真环境：它能够逼真的模拟被测试软件运行所需的真实物理环境的输入与输出，并且能够组织被测软件的输入，来驱动被测软件运行，同时接收被测软件的输出结果。
优点：仿真环境和真实环境的软件依赖是一样的，并且它能够保证测试的可重复性、完整性、可扩展性
Example 1：某系统环境搭建的要求
硬件环境：
CPU：主频2GHZ以上，4核及以上
内存：4GB及以上
硬盘：可用空间10G以上
软件环境：
平台要求：Windows XP/2003标准版+Apache2.2.X+Mysql5.0及以上版本
目录权限：目录/Attachment，/Cache及文件需要写的权限
推荐平台：推荐使用XAMPP作为安装介质
选用测试工具应考虑的因素：
1.测试工具与被测软件系统的匹配程度
2.测试工具提供的主要功能和辅助机制
3.测试工具的服务和技术支持
4.测试工具的价格
测试数据：
特点：
1.数据可以以消息、事物、记录、文件等形式存在
2.数据来源很多
3.真实数据最好，但在很多情况下不易或者不能得到
来源：
1.产品数据
2.手工构造数据
3.生成数据（一般由工具设备构造）
4.捕获数据（少用，与捕获数据源有关，允许手工修改）
5.随机数据（系统测试少用，它易于获得，不够真实，性能测试常用）
产品数据
1.最具真实性
2.不能覆盖所需所有场景
3.数据敏感，很难保证正确性
4.随时间变化
5.可能数据量太大（从而降低测试执行速度）
手工构造数据
1.费时间、枯燥
2.如果对系统的功能缺乏了解，数据不真实
3.有时是获得特定测试用例所需独特数据的唯一手段
生成数据
1.一般由工具或设备构造
2.数据取决于工具的完善程度和测试人员的关于如何构造数据的规格说明
捕获数据
1.与捕获数据源无关
2.允许手工修改
随机数据
1.易于获得，不够真实
2.对强度或负载测试是非常有用的
3 系统测试的类型
常见的测试类型：
功能测试（配置测试、恢复性测试、备份测试）
性能测试（压力测试、稳定性测试、容量测试）
GUI测试（可用性测试）
兼容性测试
安全性测试（网络测试）
安装性测试
文档测试
功能测试
概念：根据SRS和 需求列表，验证产品的功能实现是否符合产品的需求规格
目标:
1.是否有不正确或者遗漏了的功能（做错或少做）
2.功能实现是否满足用户需求和系统设计的隐藏需求
3.能否正确的接受输入，能否正确的输出结果
功能测试步骤：
1.对每个明确的功能需求进行标号
2.对每个隐含的功能需求进行标号
3.对可能出现的功能异常进行分类分析并且标号
4.把功能划分为关键功能和非关键功能
5.对每个功能进行测试分析，分析其是否可测，如何测试，可能的输入、输出
6.脚本化和自动化
性能测试
概念：用来测试软件在集成系统中的运行性能
目标: 度量系统各项指标，确认系统有无各种性能瓶颈
特点：混合白盒测试和黑盒测试的方法
性能测试考虑的两个方面:
1.验证系统实现的性能是否与性能需求完全一致
2.检测系统实现的具体性能到底怎样
常用方法：探针，测试驱动
常用工具：Loadrunner,WebLoad,SilkPerformer
GUI测试
概念：针对软件系统界面进行的测试
目标：1.测试界面实现与界面设计的吻合情况 2.确认界面处理的正确性
关注点：界面层与功能接口层上（GUI系统分为三个层次：界面层、界面与功能的接口层、功能层）
常用工具：QTP，QARun
兼容性测试
概念：考虑被测试软件在其他软件（例如操作系统）或硬件设备下的运行情况。
目标：1.与辅助软件的结合情况（操作系统，其他应用程序，测试软件，监控软件，浏览器等）； 2.与硬件设计的结合情况（由于兼容性测试对硬件要求较多，一般无特殊要求都只会针对软件要求做测试）。
安全性测试
概念：验证集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入，用来保护数据本身的完整性和保密性。广义的还包括物理安全和业务安全。
范围：主要从几个方面考虑：系统登录，用户管理，防火墙，系统数据，WEB安全，数据库安全，内部通讯，系统防毒测试等。
保护测试是安全测试中的一种常见的测试，主要用于测试系统的信息保护机制
安装性测试
概念：主要依据软件的测试特征列表、软件安装、配置文档、设计安装过程的测试用例，发现软件在安装过程中的错误。
目标：找出软件安装的错误，安装手册的错误。
安装测试前所要做的检查工作：
1.安装文档是否齐全
2.安装软件的程序文件是否齐全
3.被测试的安装文件是否齐全
4.软件的文件格式是否与安装指导中的要求的文件格式相符
常用自动化安装测试软件：Total Uninstall:它能够监视软件安装的所有过程，记录下它对系统所做的任何改变FileRiver:可以自动监视和准确记录下多个文件夹中的文件以及子文件的细微变化。
文档测试
概念：主要针对软件需求说明书，安装手册，配置指南等文档，测试内容主要是编写规范，内容正确性，无歧义性，完整性。
目标：验证用户文档是正确的并且保证操作手册的过程能够正确工作。
4 系统测试的过程
测试阶段的划分
系统测试计划阶段：完成系统测试计划（规划和步骤）
系统测试设计阶段：完成系统测试方案
系统测试实现阶段：完成系统测试用例，系统测试规程，系统测试预测试（冒烟测试）项
系统测试执行阶段：执行系统测试预测试，系统测试用例，开展回归测试，校验已修复的问题，提交系统预测试报告，系统测试报告，缺陷报告
过程：软件需求分析、设计（概要）、系统测试（执行）
| 阶段 | 入口准则 | 输入 | 出口准则 | 输出 |
| 计划 | SRA完成 成立了需求规格基准 | 软件开发计划 软件测试计划、SRS | 系统测试计划评审并通过 | 系统测试计划 |
| 设计 | 系统测试计划评审并通过 | 系统测试计划、SRS | 系统测试方案评审并通过 | 系统测试方案 |
| 实现 | 系统测试方案评审并通过 | 系统测试计划 系统测试方案、SRS | 系统测试用例 系统测试规程 系统测试预测试项评审并通过 | 系统测试用例 系统测试规程 系统测试预测试项 |
| 执行 | 系统测试用例、系统测试规程、系统测试预测试项评审并通过，集成测试执行结束 | 系统测试计划 系统测试方案 系统测试用例 系统测试规程 系统测试预测试项 | 系统测试报告评审并通过 | 系统预测试报告 系统测试报告 缺陷报告 |
系统测试中的角色及职责
开发代表：解决资源需求，对系统测试结果进行监督
QA：系统测试过程质量保证，参与相关评审，对过程进行审计
配置管理组：对系统测试文档，及测试代码等相关配置进行配置管理
软件开发组：
1.系统测试计划阶段，提供软件开发计划SDP，参与系统测试计划的评审
2.系统测试设计和实现阶段，提供SRS，需求分析，测试建议，响应系统测试需求，参与软件系统测试方案的评审
3.系统测试执行阶段，跟踪解决软件测试项目组的缺陷问题报告单，参与系统测试报告的评审
软件测试组：
1.系统测试计划阶段，制定系统测试计划并组织评审
2.系统测试设计和实现阶段，制定软件测试方案并组织评审，按照软件系统测试方案，实现测试用例，测试代码和测试工具等设计，编写测试规程
3.系统测试执行阶段，执行系统测试，反馈并跟踪缺陷问题报告单，完成系统测试报告并组织评审，输出测试案例、总结等经验文档
系统分析组：
1.提出系统测试需求
2.进行测试需求跟踪
3.进行软件系统可测性分析，确定系统测试的对象、范围和方法
系统测试计划的要点
1.明确系统测试的被测对象
2.完成系统测试的需求跟踪
3.明确系统的通过或失败标准
4.系统测试的挂起标准及恢复的必要条件
5.明确系统测试工作任务分配
6.系统测试结束后应交付的工作产品
系统测试设计的要点
1.测试环境和测试数据的准备
2.测试工具的开发/场景设计
3.系统测试用例设计
4.测试策略的选择（如：测试几轮）
系统测试方案和系统测试计划的区别
系统测试计划：对系统测试全过程的组织、资源、原则等进行规定和约束，并制定系统测试全过程各个阶段的任务以及时间进度安排，并提出对各项任务的评估、风险分析和管理需求。
系统测试方案：描述系统需要测试的特性，测试的方法，测试环境的规划，测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。（设计测试方法的细节文档）
注：案需要在系统测试计划的指导下进行，系统测试计划提出做什么，而系统测试方案明确提出“如何做”
系统测试执行概述
1.按一定的系统测试计划，依据系统测试用例，完成测试的各项操作任务
2.根据系统测试方案，搭建系统测试环境是系统测试执行的一个重要步骤，测试环境时候与否会严重影响测试结果的真实性和正确性
3.系统测试执行阶段应完成：环境准备、测试操作、测试记录、测试报告
4.执行的时间安排：在集成测试执行完成之后进行系统测试的执行
系统测试预测试
目的：验证软件系统基本功能或预测主要的系统功能，以确保其后的系统测试执行能够顺利进行。
时间安排：系统预测试应在开发项目组提出软件版本转系统测试申请后进行，主要是完成转系统测试评审需要输入的《软件系统与测试报告》。
人员安排：执行验证软件基本功能活动的主体可以是软件开发项目组也可以是软件测试项目组或联合的组织。
转系统测试评审
1.评审责任的主体为软件项目测试组，需要完成软件转系统测试评审表
2.软件版本转系统测试通过后，才能启动执行系统测试过程
3.启动执行系统测试过程后，系统预测试相关的软件版本，测试代码，文档，环境等均应在配置管理中基线化
系统测试报告写作和评审
1.依据系统测试计划的测试通过准责，结束系统测试后，撰写系统测试报告
2.系统测试报告需要通过评审，责任人为软件测试项目组，由软件开发项目组，配置管理小组和QA参与
3.评审不通过，系统测试报告退回。在评审不符合项和问题解决后再提交评审申请，或重新启动系统测试过程
4.评审通过后，系统测试相关文档、代码、工具等均需跟随软件代码，开发文档一起完成配置基线化，系统测试过程结束
系统测试日报的写作目的
1.测试人员总结每天的测试工作，便于了解自己的测试进度和测试情况，用以调整下一天的工作计划
2.测试人员对被测对象每天给出评估结果，用以调整后续工作的测试策略
3.测试人员向测试经理反映测试中的困难，保证测试的顺利进行
4.测试经理通过测试日报，了解每个工作人员的测试进度，把握测试的整体进度，发现进度上的风险及时调整计划
5.测试经理通过测试日报，了解各模块缺陷发展的趋势，判断测试是否可以退出
6.开发经理可以通过软件测试日报了解当前软件的质量情况，并可以调整缺陷修改的人力资源、
7.如果软件有多个测试组并行测试，测试日报可以提供彼此测试交流的手段
系统测试步骤
需求分析 -> 计划、方案 -> 用例设计 -> 环境搭建 -> 执行 -> 测试报告
需求分类： 1. 项目需求（用户自己提需求） 2．产品需求（产品人员进行调查撰写）
基线：第一种说法：软件版本相对稳定 第二种说法：文档经过多次评审修改之后封存起来，任何人需求修改都要提出申请。
这里有我整理的视频和文案，需要的可以点下方小卡片
