非功能性测试的指南.docx

非功能性测试的指南.docx

《非功能性测试的指南.docx》由会员分享，可在线阅读，更多相关《非功能性测试的指南.docx（15页珍藏版）》请在冰豆网上搜索。

非功能性测试的指南

非功能性测试指南

文档名称:

非功能性测试指南

状态:

初始版本

版本号:

1.0

版本提交日期:

2012/08/13

-文档信息-

项目名称

上海银行测试体系咨询

文档版本编号

1.0

起草人

张红辉

文档版本日期

2010/3/31

复审人

复审日期

-变更记录–

版本号

更新内容

更新日

更新者

1.0

初始版本

2010/3/31

张红辉

-审批人–

签字

姓名

角色

审批日

批语

-评审记录–

评审人姓名

评审日期

评审相关文档部分

评审建议

作者对评审意见的回应

1

目的和范围

本文档阐述了常用的非功能性测试类型及其测试方法，供相关测试人员安排测试计划、设计测试和执行测试时参考。

功能测试、回归测试和性能测试不在本文档讨论范围，另有专门文档讨论。

本文档适用于上海银行信息技术部所有测试服务的非功能性测试工作。

2术语和缩写

术语和缩写

解释

备注

安全性测试

测试应用或系统的安全机制

安装测试

测试被测软件在各种需要的软硬件配置下

能正确安装

配置/兼容性测试

测试被测软件在各种需要的软硬件配置下

能正确运行

易用性测试

考虑软件使用时人的因素和感受

数据和数据库完整性测试

测试数据存取方法和过程等能正确运行，

在整个数据操作过程中和结束后没有数据被破坏

接口测试

测试内部单元组合到一起后能够按照设计的意

图协作运行，接口的调用正确

文档测试

验证发布的软件产品中的文档的正确性，尤其对与用户相关的文档

失效恢复测试

测试被测软件能成功地从硬件、软件或网络故障中失效恢复而不会有数据的丢失

3参考资料

参考文件

备注

TMMiFrameworkv2.0

ProducedbytheTMMiFoundation

上海银行信息技术部ISO9001

2009.09版（发布版）

4角色对应关系

角色

对应关系

业务人员

来自产品开发部/业务部门的业务需求发起者

测试需求分析人员

通常由信息技术部指派

测试组长

通常由信息技术部指派

测试设计人员

通常由信息技术部指派

测试执行人员

通常由信息技术部指派

开发组长

通常由信息技术部指派

5非功能性测试类型及其测试方法

5.1安全性测试

软件安全性轻则造成操作的不方便，重则造成数据的破坏或丢失甚至系统的崩溃和人身的安全，因此，软件安全性是一个不容忽视的重要问题，我们可以简单地把软件的安全性作为一个或多个特定的功能来考虑，从而在软件生命周期的早期就加以考虑。

为了帮助设计一个安全的信息系统，在产品设计的最开始就必须注意安全的问题，比如需求中应有安全性的相关项目、设计和代码评审应有专门针对安全性的内容等等，然后才是测试。

测试员仅仅能测试验证软件的安全性。

当然，对于没有在软件需求书上标明的可能影响系统运行安全的隐性需求测试人员也要努力的发现，这也是一个有经验的安全性测试人员的可贵之处。

当然，理论上没有任何一个信息系统是安全的，因为只要进行攻击，任何系统都能被攻破，只不过付出的代价的大小。

而我们一般说某个信息系统是安全的就是基于如果要攻破该系统所必须付出的代价要高于或远远高于攻破系统后获得的利益。

测试目标

测试应用或系统的安全机制，保证系统运行和使用的安全性

测试策略

采取静态分析技术和功能测试两种方式拦截系统开发时存在的漏洞

软件生命周期早期的代码、设计评审（由开发人员完成）对软件安全性的提高非常有效和重要，可以人工评审和自动化工具结合的方法进行

更详细的测试策略描述请参看下文软件安全性测试详细策略参考

测试重点考虑

●相关信息安全法律法规的要求

●测试环境

●网络安全

●日志评审

●文件完整性检查

●系统软件安全

●客户端应用安全

●客户端到服务端应用通讯安全

●服务端应用安全

测试通过准则

应用满足和符合采用的安全机制，在应用规定的程度上能保证系统正常运行和安全使用

软件安全性测试详细策略参考：

软件安全性测试包括应用软件、网络系统、数据库和系统软件安全性测试。

根据系统安全指标不同测试策略也不同。

1.用户认证安全的测试要考虑问题：

●系统中是否有不同的用户使用权限

●系统会不会因用户的权限的改变造成混乱

●系统中会不会出现用户冲突

●用户登陆密码是否可见、可复制

●是否可以通过绝对路径登陆系统（拷贝用户登陆后的链接直接进入系统）

●用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通

过输入口令进入系统

2.应用方面安全的测试要考虑问题：

●缓冲区溢出

●无效的数据类型

●关键信息是否采用加密技术

●是否可以通过绝对路径进入系统

●使用的端口号

●远程进入服务（如有）

●文件完整性检查

●日志评审

●模拟黑客攻击

3.系统网络安全的测试要考虑问题

●物理连接上的安全，包括无线部分（如有）

●防火墙、防病毒软件的安全

●测试采取的防护措施是否正确装配好，有关系统的补丁是否打上

●模拟非授权攻击，看防护系统是否坚固

●采用成熟的网络漏洞检查工具检查系统相关漏洞

●入侵网络监察系统和防护系统

●采用各种木马检查工具检查系统木马情况

●采用各种防外挂工具检查系统各组程序的外挂漏洞

4.数据库安全考虑问题：

●系统数据是否机密

●系统数据的完整性

●系统数据可管理性

●系统数据的独立性

●系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否

可以完整）

5.系统级别软件安全考虑问题：

●系统级别软件（如操作系统、数据库系统和中间件系统等）是否最新的，

尤其如果使用开源软件或免费软件

●系统软件是否有相应的补丁，尤其是安全性方面的补丁包

●从安全性考虑，系统级别软件是否是最可靠的（如使用Tomcat还是

Weblogic）

●从安全性考虑，系统级别软件是否匹配应用设计技术

5.2安装测试

安装测试有两个目的。

第一个目的是确保软件能够在不同的条件下进行安装，例如，首次安装、升级安装、完整或自定义安装；在正常和异常条件下的安装。

异常条件例如磁盘空间不足、安装用户缺少目录创建权限等。

第二个目的是验证软件在安装后能正确操作。

这通常意味着要运行大量为功能测试开发的测试用例。

建议对于安装测试，其重点应该放在第一个目的上，对于第二个目的可以根据需要和实际情况穿插在后续的测试，如冒烟测试、功能测试中体现。

测试目标

验证被测软件在各种需要的软硬件配置下正确安装，包括下列情况：

●新安装。

一新的机器，先前从未安装过该软件

●更新。

该机器先前安装过该软件同样的版本

●更新。

该机器先前安装过该软件的老版本

测试策略

手工或自动化

不管是手工安装还是自动化脚本安装，都要严格按照用户安装手册规定的操作步骤进行

测试重点考虑

有没有安装手册

对于第二个目的的安装测试，怎样选取预先规定的功能测试的子集

测试通过准则

对于第一个目的：

确保软件能够在不同的条件下进行安装。

成功的安装应该是在整个安装过程中和安装完成后没有任何异常错误出现，能成功登录该应用

对于第二个目的：

验证软件在安装后能正确操作。

这个需要运行预先规定的一功能测试的子集

5.3配置和兼容性测试

配置和兼容性测试验证被测软件在不同的软硬件配置下的操作和表现。

在大多数生产环境中，特定的硬件规格，如客户端工作站、网络情况、服务器配置甚至型号都会不同。

另外，不同客户端工作站上也许有不同的软件负载，如不同的应用软件、不同的浏览器、浏览器的不同版本的插件、驱动程序等等；甚者不同的操作系统，如WindowsXP,WindowsVista等等；服务器软件也会不一致，如数据库软件，如Oracle,MicrosoftSQLServer、中间件软件等等。

该类测试对产品显得尤其重要。

对于项目来说也有巨大的指导作用，如项目经理为了最优化配置（从成本和实用的角度等），就需要进行不同软硬件情况下的配置和兼容性测试。

该类测试也往往和性能测试相结合以决定在不同软硬件情况下的最优化配置（如从成本和实用的角度等）。

测试目标

验证被测软件在各种需要的软硬件配置下能正确运行

测试策略

使用功能测试脚本

首先，针对一特定硬件配置下：

●打开和关闭许多和被测软件无关的、但和被测软件共同在同一机器上的其它许多软件，如同机上的Microsoft应用软件，Excel或Word等等（如果有），可以在测试过程中和测试前就打开

●在此基础上执行相应的功能测试

测试重点考虑

硬件配置情况复杂多样，使用哪些硬件配置呢？

建议最好做些调研，如考虑目标用户或最终用户的使用习惯和经济承受能力？

打开哪些和被测软件无关的、但和被测软件共同在同一机器上的其它许多软件？

建议最好做些调研，如考虑目标用户或最终用户会使用哪些其它的常用软件？

尤其在使用目标软件时往往同时会打开或使用的软件？

测试通过准则

在某一特定的硬件配置下，在许多和被测软件无关的、但和被测软件共同在同一机器上的其它许多软件运行或使用情况下，相应的功能测试没有失败

5.4易用性测试

易用性是人类工程学的目标。

软件的易用性是一个比较有特点的问题，会随着具体产品或项目的特征和要求而有巨大差异，比如手机软件和一般Windows平台下的软件易用性相差很大，又如一核反应堆的关闭序列和一语音信箱的菜单系统的易用性有着天壤之别。

即使对于同一个软件，不同的用户也会有不同的感受。

当然，我们也不是说对软件的易用性就毫无测试办法和标准，对于同一类软件还是有它的通用性可言的。

因此下面尝试从一些比较通用的方面讨论之。

易用性主要考虑软件使用时人的因素和感受，因此我们先介绍两个概念。

用户与程序相互交互的介质称为用户接口（UserInterface-UI），用户接口对不同软件种类也会有巨大的差异，对于PC来说，我们现在有了精致的完善的图形用户接口（GraphicalUserInterface-GUI）。

很快我们可以对着我们的PC听和说，那时又会有新的UI。

另外，Accessibilitytesting也属于易用性测试范畴。

这种测试一般针对对软件有特殊要求的群体，比如部分残疾人。

测试目标

考虑软件使用时人的因素和感受

测试策略

使用功能测试脚本

对于一些比较通用的规则可以制成检查表的形式

测试重点考虑

●遵守通用的标准和指导方针。

如Windows平台下的软件应和Windows平台的风格一致、而Mac平台下的软件显然应该和Mac平台的风格一致

●直觉的。

如用户界面是干净的、不多余的？

用户界面是经过良好组织和布局的？

●一致性。

如快捷键和菜单选项间；术语和命名；确认和取消按钮的位置布局等

●灵活性。

如用户希望能手工键入、粘贴、插入文件内容等方式作为输入方法

●舒服的。

如较长时间的等待应有进度条提示、一般情况下程序应有较快的反应，但也不是绝对的，举个例子，高性能就一定好吗？

未必如此，例如当快速的连提示信息或出错信息都不能看清时用户反而会觉得很不舒服

●正确的。

例如拼写；图标是否有同样的大小和背景；还有是否所见即所得-WYSIWYG（whatyouseeiswhatyouget）

●有用的。

没有大量的过量功能，这个特征尤其在产品上表现突出，用户往往要面对大量的无用的或者不需要的功能

测试通过准则

该类测试对于不同产品和项目有较大的差异性，因此尤其要加强对该类测试用例的评审，在业务人员、设计人员等一致同意的基础上进行测试，测试人员也要关注软件需求中应有该方面的相关描述

5.5数据和数据库完整性测试

在整个系统测试过程中，数据库和数据库过程应作为系统的子系统进行测试。

这些测试不使用用户界面作为数据进入界面进行测试。

对不同的数据库管理系统，可能存在不同的工具和技术，如Oracle和MicrosoftSQLServer。

测试目标

保证数据存取方法和过程正确运行，在整个数据操作过程中和结束后没有数据破坏

测试策略

使用有效的和无效的数据或数据的请求调用各个数据库存取方法和过程

检查数据库保证数据正如预期地进入，所有的数据库事件正确地发生，或者检查数据保证对于正确的请求取得正确的数据

测试重点考虑

测试也许需要一个DBMS开发环境或驱动程序以便在数据库中直接进入或更改数据

确定哪些数据存取方法和数据过程重点测试

测试的先后顺序

测试通过准则

所有的数据库存取方法和过程正如设计要求一样运行，没有任何的数据破坏

5.6接口测试

在集成测试过程中，接口测试显得特别重要，首先要确认被测软件是否集成了规定的单元或子系统、外部系统（如有）；其次，对相应的接口要进行详细的测试；最后也应该对集成后的所有功能进行相应的测试以确保集成后整个系统功能的正确性，当然这一步属于功能测试的范畴，本文不予讨论。

测试目标

确保“测试需求”中对应的所有工作版本的内部单元组合到一起后能够按照设计的意图协作运行，接口的调用正确。

测试策略

使用功能测试脚本。

按照设计规范，对所有接口设计相应的测试用例进行手工或自动化测试，包括系统内部接口和外部接口，尤其注意和第三方的软硬件接口（如有）。

测试重点考虑

测试的顺序性

数据是否能正确传递

接口之间的调用

状态的变化是否正确（如有）

接口之间的异常处理功能

测试通过准则

所有与接口有关的测试用例功能没有失败

5.7文档测试

文档也是发布的软件产品的重要组成部分，因此也应该对文档进行相应的测试，尤其对安装手册（前面已有所述）、用户使用手册和在线帮助手册要进行重点测试。

正确的文档能减少维护费用和提高软件的可维护性、改善软件易用性、减少责任等。

测试目标

保证发布的软件产品中的文档的正确性

测试策略

按照手册描述，逐章节阅读、检查和验证相应的内容，比如严格地按照用户使用手册上的描述去操作和使用程序

测试重点考虑

与用户相关的文档的测试（如安装手册、用户使用手册和在线帮助手册）

术语的正确性和一致性

是否覆盖了产品的所有方面

功能描述的准确性

图形和屏幕截屏是否正确

举例是否正确

拼写和语法

超文本链接

测试通过准则

文档所有内容描述准确和正确

5.8失效恢复测试

失效恢复测试保证被测软件能成功地从硬件、软件或网络故障中失效恢复而不会有数据或事务的丢失。

对于必须时刻保持运行的系统，失效备援测试保证当一个失效备援条件发生时，替代或备份系统正确地接管失败的系统而不会有数据或事务的丢失。

恢复测试是一种对立的测试过程，让应用或系统遭受极端或仿真条件来引起一个故障，例如设备的输入、输出错误或无效的数据库指针和键。

调用恢复过程、监控和检查应用或系统来验证已完成正确的应用、系统和数据恢复。

测试目标

验证恢复过程（手工或自动化）正确恢复数据库、应用和系统到期望的、已知的状态。

测试策略

手工或自动化测试。

如电源中断、通讯中断、网络中断、操作中断等可以手工直接执行；操作中断，尤其是有关数据库的操作、网络操作等也可以使用一些自动化工具执行。

测试重点考虑

测试设计或执行中应考虑：

●客户端电源中断

●服务端电源中断

●客户端和服务器之间通讯中断

●网络异常问题，如瞬间的断开

●关键功能执行过程中操作异常中断

●备份系统有效性（如有）

●数据过滤过程中断、数据同步过程中断等

●无效的数据库指针或键

●数据库中无效的或被破坏的数据元素

测试通过准则

在上面所有的测试中，当恢复程序完成时，应用、数据库和系统应该成功返回到期望的、已知的状态。

【下载本文档，可以自由复制内容或自由编辑修改内容，更多精彩文章，期待你的好评和关注，我将一如既往为您服务】