系统测试的基本认识

系统测试

1 什么是系统测试？

系统测试是将集成好的软件系统，与计算机硬件、外设、某些支持软件、数据和人员等元素结合在一起，在实际运行（使用）环境下，对软件系统进行一些里的组装测试和确认测试。

系统测试的目的在于通过系统的需求定义作为比较，发现软件与系统定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规约所制定的要求。系统测试的测试用例应依据需求分析说明书来设计。

2 系统测试类型

2.1 功能测试

功能测试是系统测试中最基本的测试，它不管软件内部的实现逻辑，主要根据产品的需求规格说明书和测试需求列表，验证产品的 功能实现是否符合产品的需求规格。功能测试主要是为了发现以下几类错误：

（1） 是否有不正确或遗漏了的功能？

（2） 功能实现是否满足用户需求和系统设计的隐藏需求？

（3） 能否正确的接受输入？能否正确的输出结果？

功能测试，首先需要对《需求规格说明书》进行分析：

（1） 明确的功能需求：对每个明确的功能需求进行标号，需求规格文档中已经有标号的可以直接引用。

（2） 隐含的功能需求：对每个可能隐含的功能需求进行标号。

（3） 功能异常：对可能出现的功能异常进行分类分析，并标号。

（4） 对获得的功能需求进行分级

（5） 对每个功能进行测试分析，分析其是否可测，如何测试，可能的输入，可能的输出等。

（6） 脚本化和自动化。

功能测试要点：

（1） 考虑用户是在什么情况下如何来使用该功能的，比如网络断掉的时候访问网站，用键盘进行操作等。

（2） 多考虑用户对多个功能的组合运用

（3） 对于服务器软件，多考虑多用户同时访问、操作的情况，需要检查用户的同时使用是否会导致功能的失效。

2.2 性能测试

性能测试的目标是度量系统相对于预定义目标的差距。

一些性能信息：

（1） CPU使用情况

（2） IO使用情况

（3） 每个指令的IO数量

（4） 信道使用情况

（5） 主要存储内存使用情况

（6） 第二存储内存使用情况

（7） 每个模块执行时间百分比

（8） 一个模块等待IO完工的百分比时间

（9） 模块使用在主存储上的时间百分比

（10） 指令随时间的跟踪路径

（11） 控制从一个模块到另一个模块的次数

（12） 遇到每一组指令等待的次数

（13） 系统反映时间

（14） 系统吞吐量，即每个 时间单元的处理数量

（15） 所有主要指令的单元执行时间

2.3 压力测试

压力测试研究系统在一个短时间内活动处在峰值时的反映目的是调查系统在其超负荷的情况下的表现。压力测试是边界测试。例如测试最大的活动终端数量，压上比需求规定更多的终端，一些负载测试的资源达到了超负荷，这些资源包括：缓冲区、控制器、显示终端、终端处理、内存、网络、打印机、内存、网络、打印机、存储设备、事务队列、事务程序、系统用户。

压力测试的例子：

（1） 对于一个固定输入速率的单词处理响应时间，例如每分钟120个单词。

（2） 在一个非常短的时间内引入超负荷的数据容量。

（3） 改变交互、实时、过程控制方面的负荷。

（4） 同时引入大量的操作。

（5） 成千上万的用户在同一时间登录。

（6） 手机短信列表查看，短信越多时打开列表所花的时间越长。考虑在手机短信已满的情况下打开短信列表，看在这种极限情况下花费的时间是多少。

（7） 电子商务网站的服务器的cpu占用率达到100%时，再访问该电子商务网站，看网页响应时间是多少。

（8） 新建word空白文档到不能新建为止，然后在任意一个空白文档中进行输入，然后保存，看保存所花费的时间。

2.4 容量测试

容量测试是面向数据的，并且显示系统可以处理目标内确定的数据容量，目的是使系统承受超额的数据容量来发现它能够处理的数据容量。

容量测试执行步骤：

（1） 分析外部数据源，并进行分类。

（2） 对每类数据源分析可能的容量限制，对于记录类型数据需要分析记录长度限制，记录中每个域长度限制，记录数量限制。

（3） 对每类型数据源，构造大容量数据对系统进行测试。

（4） 分析测试结果，并与期望值比较，确定目前系统的容量瓶颈。

（5） 对系统进行优化并重复1-4步骤，知道系统达到期望的容量处理能力。

2.5 安全性测试

安全性测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。一些功能性的安全性问题包括：

（1） 控制特性是否工作正确？

（2） 无效的或者不可能的参数是否被检测并且适当的处理？

（3） 无效的或者超出范围的指令是否被检测所并且适当的处理？

（4） 错误和文件访问是否适当的被记录？

（5） 是否有变更安全性表格的过程？

（6） 系统配置数据是否能这确保存，系统故障时是否能回复？

（7） 系统配置数据能否导出，在其他机器上进行备份？

（8） 系统配置数据能否导入，导入后能否正常使用？

（9） 系统配置数据保存时是否加密？

（10） 没有口令是否可以登录到系统中？

（11） 有效的口令是否被接受，无效的口令是否被拒绝？

（12） 系统多次无效口令是否有适当的反应？

（13） 系统初始的权限功能是否正确？

（14） 各级用户权限划分是否合理？

（15） 用户的生命期是否有限制？

（16） 低级别的用户是否可以操作高级别用户命令？

（17） 高级别的用户是否可以操作低级别用户命令？

（18） 用户是否会自动超时退出，超市的时间是否设置合理，用户数据是否会丢失？

（19） 登录用户修改其他用户的参数是否立即生效？

（20） 系统在最大用户数量时是否有安全方面的特性？

（21） 防火墙是否能被激活和取消激活？

（22） 防火墙功能激活后是否会引起其他问题？

评价安全机制的性能与安全性功能本身一样重要，一些问题就集中在安全性的性能上，包括：

（1） 有效性：执行严格的安全性功能所占有的时间比例？安全性控制一般需要比系统其他部分更高的有效性。

（2） 生存性：系统在抵制主要错误或者自然灾难方面的能力如何？这包括错误期间紧急操作的支持、随后的备份操作和恢复到正常操作的功能。

（3） 反应时间：反应时间是否可接受？慢的反应时间可能导致用户绕过安全控制。当安全表格动态修改的时候，反应时间还对控制管理很关键。

（4） 吞吐量:安全性控制是否支持需要的使用吞吐量？吞吐量包含用户和服务请求的峰值和平均值。

安全性测试实例：

B/S模式应用开发程序，SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的web页面访问没什么区别，所以目前市面的防火强都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，坑内被入侵很长时间都不会发觉。例如将http://www.yanshi.com/index.asp?ID=1000改成http://www.yanshi.com/index/asp?ID=(select count(1) from user)就是一种简单的SQL注入尝试。

常见的web系统安全测试要点：

（1） 不登录系统，直接输入登录后的页面url是否可以访问？

（2） 不登录系统，直接输入下载文件的url是否可以下载，如输入http://url/doenload?name=file是否可以下载文件file。

（3） 退出登录后按后退按钮能否访问之前的页面？

（4） ID/密码验证方式中能否使用简单密码。如密码标准为6位以上，字母和数据混合。不能包含ID，连续的字母或数字不能超过n位。

（5） 重要信息（如密码、身分证号码、信用卡号等）在输入或查询时是否用明文显示；在浏览器地址栏里输入命令javascri pt:alert(doucument.cookie)时是否有重要信息；在html源码中能否看到重要信息。

（6） 手动更改url中的参数值能否访问没有权限访问的页面。如普通用户对应的url中的参数为1=e，高级用户对应的url中的参数为1=s，以普通用户的身份登录系统后将url中的参数e改为s来访问本没有权限访问的页面。

（7） url里不可修改的参数是否可以被修改。

（8） 上传与服务器端语言（jsp、asp、php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行。

（9） 注册用户时是否可以以 ’-- 、 ’or 1=1-- 等做为用户名。

（10） 传送服务器的参数（如查询关键字、url中的参数等）中包含特殊字符（’、 ’and 1=1-- 、 ’and 1=0-- 、 ’or 1=0--）时是否可以正常处理。

（11） 执行新增操作时，在所有的输入框中输入脚本标签后能否保存。

（12） 在url中输入下面的地址是否可以下载：http://url/download.jap?file=C:\windows\system32\drivers\etc\hosts http://url/download.jap?file=/etc/passwd

（13） 是否对session的有效期进行处理

（14） 错误信息中是否含有sql语言、sql错误信息以及web服务器的绝对路径等

（15） ID/密码验证方式中，同一个帐号在不同的机器上不能同时登录

（16） ID/密码验证方式中，连续数次输入错误密码后该账户是否被锁定

（17） 新增或修改重要信息（密码、身份证号、信用卡号等）时是否有自动完成功能（在form标签中使用autocomplete=off来关闭自动完成功能）

2.6 GUI测试

GUI测试主要包括两方面的重要内容，一方面是界面实现与界面设计的吻合情况；另一方面是确认界面处理的正确性。

设计GUI测试用例的时候，可以从以下几个方面考虑：

（1） 划分界面元素，三个层次。层次一，界面原子（不可再分的界面组成元素），如：一个菜单项、一个按钮、一个列表框、一个编辑框、工具条中的一个图标、一个快捷键、一个静态文本等等。层次二，界面组合元素，如：工具条、组合框、表格、菜单条等等。层次三，一个完整的窗口，如一个对话框、一个单文档窗口、多文档系统的父窗口和子窗口等等。

（2） 一般在界面原子层，主要考虑该界面原子的显示属性、触发机制、功能行为、可能的状态集等内容。对于界面原子可能接收的输入可以从等价类划分，边界值分析等。对于界面组合元素，主要考虑界面原子组合顺序，排列组合、整体外观、组合后功能行为的多个角度进行测试。对于一个完整的窗口，主要考虑窗口的整体外观、窗口元素的排列组合、窗口属性值、窗口可能的各种组合行为（或可能的操作路径）等。

（3） 进行测试数据分析，提取测试用例

对于界面元素的外观，可以从以下几个角度获取测试数据：界面元素大小、形状、色彩、对比度、明亮度、文字属性（如：字体、排序方式、大小等）

对于界面元素的布局，可以从以下几个角度获取测试数据：各界面元素位置、各界面元素的对齐方式、各界面元素间间隔、Tab顺序、各界面元素间色彩搭配。

对于界面元素的行为，可以从以下几个角度获取测试数据：回显功能、输入限制和输入检查、输入提醒、联机帮助、缺省值、激活或取消激活、焦点状态、功能键或快捷键、操作路径、行为回退（Undo）。

GUI测试实例：（主要考虑两个方面：界面显示和控件功能）

（1） 多次弹出的同一界面显示的位置坐标是否相同

（2） 焦点初始位置以及tab键顺序

2.7 可用性测试

可用性测试和可操作性测试都是为了检测用户在理解和使用系统方面到底有多好。一些测试人员应当关注的可用性问题包括：

（1） 过分复杂的功能或者指令

（2） 困难的安装过程

（3） 错误信息过于简单，例如系统错误

（4） 语法难于理解和使用

（5） 非标准的GUI接口

（6） 用户被迫去记住太多的信息

（7） 难以登录

（8） 帮助文本上下文不敏感或者不够详细

（9） 和其他系统之间的连接太弱

（10） 默认不够清晰

（11） 接口太简单或者太复杂

（12） 语法、格式和定义不一致

（13） 没有给用户提供所有输入的清晰的知识。

2.8 安装测试

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

（1） 安装前测试：检查安装包文件是否齐全，尤其是dll文件，还有检查安装手册。

（2） 安装中测试：主要是安装流程的测试以及检查安装时的文件、注册表、数据库的变动。所谓安装流程的测试就是检查用户按照不同的顺序点击back、next、cancel是否能安装成功或者放弃安装。

（3） 安装后测试：主要是检查安装好的软件是否能运行，基本功能能否使用。

（4） 另外还要进行卸载测试以及升级测试。卸载测试主要注意能否恢复到软件安装之前的状态，包括文件夹、文件、注册表等等是否能把安装时做的修改都去掉。升级测试主要注意升级对于已有数据的影响。

安装测试用例设计从以下方面考虑：

（1） 安装过程测试（按钮“上一步”“下一步”“取消”是否能执行正确）

（2） 安装选项测试（“典型安装”“全部安装”“自定义安装”）

（3） 是否需要设置快捷键按钮的提示文字

（4） 安装后检查注册表

（5） 检查后台生成的文件（何种文件、文件夹、路径、内容、名称、类型）

（6） 支持什么平台

（7） 是否有提示文字创建桌面快捷方式

（8） 卸载是否正常

（9） 卸载后能否再正常安装

（10） 安装过程中止或出错了，还能否继续安装

（11） 新版本安装或旧版本升级，老版本存在时，是先卸载老版本还是直接覆盖

（12） 机器配置是否符合安装要求

（13） 安装后功能是否正常使用

（14） 通过控制面板中管理工具下的服务，查看是否加载了新的服务以及其默认状态

（15） 查看安装后是否生成了环境变量

（16） 查看占用端口的情况

（17） 查看安装后生成的数据库情况（数据库个数、数据库名称、表个数、表名、字段个数、字段名、约束、默认数据是否存在）

 

2.9 配置测试

配置测试并不是一个完全独立的测试类型，配置可以分成：

（1） 服务器配置：如果有服务器端的话，需要考虑服务器的硬件、服务器上web服务器的选择（iis或者apche或者jboss等），服务器上数据库软件的选择（mysql或者sql server或者oracle等）等等。

（2） 用户端设置：需要考虑用户端硬件、操作系统的选择、浏览器的选择、屏幕分辨率的选择、颜色质量的选择、浏览器设置等等。

2.10 异常测试

进行异常测试关键是需要构造各种系统会出现的异常，可以从一下方面考虑：

（1） 系统断电

（2） 系统断网

（3） 系统死掉

（4） 系统数据丢失

2.11 备份测试

备份测试需要从一下几个角度进行设计：

（1） 备份文件，并且比较备份文件与最初的文件的区别

（2） 存储文件和数据

（3） 完全的系统备份步骤

（4） 检查点备份

（5） 备份引起系统性能的降级

（6） 手工操作过程备份的有效性

（7） 备份期间的安全性过程

（8） 备份过程期间的维护处理日志

备份测试要点：

（1） 既然是备份，那么备份出来的数据格式如何？

（2） 备份是否成功，还需要通过数据的导入来进行检查。

2.12 健壮性测试（容错性）

健壮性测试主要用于测试系统在出现故障的时候，是否能够自动回复或者忽略故障继续运行。思考当出现哪些故障时是有可能自动恢复或者忽略故障继续运行的，以及怎么通过设计来保证这一点。

2.13 文档测试

在进行文档测试的时候，可以考虑以下几个方面：

（1） 使用文档作为许多测试用例的一个源头

（2） 确切的按照文档所描述的方法使用系统

（3） 测试每个提示和建议

（4） 把缺陷并入缺陷跟踪库

（5） 测试每个在线帮助超连接

（6） 测试每条语句，不要想当然

（7） 表现得像一个技术编辑而不是一个被动的评审者

（8） 首先对整个文档进行一般的评审，然后进行一个详细的评审

（9） 检查所有的错误信息

（10） 测试文档中提供的每个样例

（11） 保证所有索引的入口有文档文本

（12） 保证文档覆盖所有关键用户功能

（13） 保证阅读类型不是太技术化

（14） 寻找相对比较弱的区域，这些区域需要更多的解释。

2.14 在线帮助测试

在实际操作中，在线帮助测试可以和文档测试（或资料测试）一起进行。在线帮助测试要关注以下问题：

（1） 帮助文件的索引是否正确？

（2） 帮助文件的内容是否正确？

（3） 在系统运行过程中帮助能否被正常的激活？

（4） 在系统不同的位置激活的帮助内容与当前操作内容是否相关联？

（5） 帮助是否足够详细并能解决需要被解决的问题？

2.15 网络测试

网络测试是在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常。主要进行协议测试：

（1） 一致性测试：检测所实现的系统与协议规范符合程度。

（2） 性能测试：检测协议实体或系统的性能指标（数据传输率、连接时间、执行数度、吞吐量、并发度等）

（3） 互操作性测试：检查同一协议不同实现厂商之间，同一协议不同实现版本之间、或同一类协议不同实现版本之间互通能力和互连操作能力。

（4） 坚固性测试：检查协议实体或系统在各种恶劣环境下运行的能力（信道被切断、通信设备掉电、注入干扰报文等）

2.16 稳定性测试

系统稳定性测试目的是评价系统在一定符合情况下、长时间的运行情况。包括系统在一定负荷下，再增加新的业务，原有的业务是否受影响，新的业务是否能正常工作，系统资源有无泄漏，数据有无不一致的情况。系统性能是否会降下来，关键点是长时间的运行后，系统的状况如何，系统平均无故障时间MTBF是否满足系统设计要求。稳定性测试的重点在有正常业务时的长时间系统运转情况，对于异常测试不是稳定性测试范围.

3 系统测试工具

3.1 测试管理工具：TD/QC等

3.2 缺陷管理工具：bugzilla、mantis、bugfree等

3.3 配置管理工具：vss、cvs、svn、clear case、git等

3.4 功能测试工具：qtp、robot等

3.5 性能测试工具：loadrunner、robot等