1、 非功能性测试指南文档名称: 非功能性测试指南状态: 初始版本版本号 : 1.0版本提交日期: 2012/08/13- 文档信息 -项目名称 上海银行测试体系咨询 文档版本编号 1.0起草人 张红辉 文档版本日期 2010/3/31复审人 复审日期- 变更记录 版本号 更新内容 更新日 更新者1.0 初始版本 2010/3/31 张红辉- 审批人 签字 姓名 角色 审批日 批语- 评审记录 评审人姓名 评审日期 评审相关文档部分 评审建议 作者对评审意见的回应目 录1 目的和范围 .42 术语和缩写 .43 参考资料 44 角色对应关系 .55 非功能性测试类型及其测试方法 55.1 安全性测
2、试 .55.2 安装测试 85.3 配置和兼容性测试 85.4 易用性测试 .95.5 数据和数据库完整性测试 .115.6 接口测试 115.7 文档测试 125.8 失效恢复测试 .131 目的和范围本文档阐述了常用的非功能性测试类型及其测试方法，供相关测试人员安排测试计划、设计测试和执行测试时参考。功能测试、回归测试和性能测试不在本文档讨论范围，另有专门文档讨论。本文档适用于上海银行信息技术部所有测试服务的非功能性测试工作。2 术语和缩写术语和缩写 解释 备注安全性测试 测试应用或系统的安全机制安装测试 测试被测软件在各种需要的软硬件配置下能正确安装配置/兼容性测试 测试被测软件在各种需
3、要的软硬件配置下能正确运行易用性测试 考虑软件使用时人的因素和感受数据和数据库完整性测试测试数据存取方法和过程等能正确运行，在整个数据操作过程中和结束后没有数据被破坏接口测试 测试内部单元组合到一起后能够按照设计的意图协作运行，接口的调用正确文档测试 验证发布的软件产品中的文档的正确性，尤其对与用户相关的文档失效恢复测试 测试被测软件能成功地从硬件、软件或网络故障中失效恢复而不会有数据的丢失3 参考资料参考文件 备注TMMi Framework v2.0 Produced by the TMMi Foundation上海银行信息技术部 ISO9001 2009.09 版（发布版）4 角色对应关
4、系角色 对应关系业务人员 来自产品开发部/业务部门的业务需求发起者测试需求分析人员 通常由信息技术部指派测试组长 通常由信息技术部指派测试设计人员 通常由信息技术部指派测试执行人员 通常由信息技术部指派开发组长 通常由信息技术部指派5 非功能性测试类型及其测试方法5.1 安全性测试软件安全性轻则造成操作的不方便，重则造成数据的破坏或丢失甚至系统的崩溃和人身的安全，因此，软件安全性是一个不容忽视的重要问题，我们可以简单地把软件的安全性作为一个或多个特定的功能来考虑，从而在软件生命周期的早期就加以考虑。为了帮助设计一个安全的信息系统，在产品设计的最开始就必须注意安全的问题，比如需求中应有安全性的相
5、关项目、设计和代码评审应有专门针对安全性的内容等等，然后才是测试。测试员仅仅能测试验证软件的安全性。当然，对于没有在软件需求书上标明的可能影响系统运行安全的隐性需求测试人员也要努力的发现，这也是一个有经验的安全性测试人员的可贵之处。当然，理论上没有任何一个信息系统是安全的，因为只要进行攻击，任何系统都能被攻破，只不过付出的代价的大小。而我们一般说某个信息系统是安全的就是基于如果要攻破该系统所必须付出的代价要高于或远远高于攻破系统后获得的利益。测试目标 测试应用或系统的安全机制，保证系统运行和使用的安全性测试策略 采取静态分析技术和功能测试两种方式拦截系统开发时存在的漏洞软件生命周期早期的代码、
6、设计评审（由开发人员完成）对软件安全性的提高非常有效和重要，可以人工评审和自动化工具结合的方法进行更详细的测试策略描述请参看下文软件安全性测试详细策略参考测试重点考虑 相关信息安全法律法规的要求 测试环境 网络安全 日志评审 文件完整性检查 系统软件安全 客户端应用安全 客户端到服务端应用通讯安全 服务端应用安全测试通过准则应用满足和符合采用的安全机制，在应用规定的程度上能保证系统正常运行和安全使用软件安全性测试详细策略参考：软件安全性测试包括应用软件、网络系统、数据库和系统软件安全性测试。根据系统安全指标不同测试策略也不同。1. 用户认证安全的测试要考虑问题： 系统中是否有不同的用户使用权限
7、 系统会不会因用户的权限的改变造成混乱 系统中会不会出现用户冲突 用户登陆密码是否可见、可复制 是否可以通过绝对路径登陆系统（拷贝用户登陆后的链接直接进入系统） 用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统2. 应用方面安全的测试要考虑问题： 缓冲区溢出 无效的数据类型 关键信息是否采用加密技术 是否可以通过绝对路径进入系统 使用的端口号 远程进入服务（如有） 文件完整性检查 日志评审 模拟黑客攻击3. 系统网络安全的测试要考虑问题 物理连接上的安全，包括无线部分（如有） 防火墙、防病毒软件的安全 测试采取的防护措施是否正确装配好，有关系统的补丁是否打上 模
8、拟非授权攻击，看防护系统是否坚固 采用成熟的网络漏洞检查工具检查系统相关漏洞 入侵网络监察系统和防护系统 采用各种木马检查工具检查系统木马情况 采用各种防外挂工具检查系统各组程序的外挂漏洞4. 数据库安全考虑问题： 系统数据是否机密 系统数据的完整性 系统数据可管理性 系统数据的独立性 系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）5. 系统级别软件安全考虑问题： 系统级别软件（如操作系统、数据库系统和中间件系统等）是否最新的，尤其如果使用开源软件或免费软件 系统软件是否有相应的补丁，尤其是安全性方面的补丁包 从安全性考虑，系统级别软件是否是最可靠的（如使用 Tomc
9、at 还是 Weblogic） 从安全性考虑，系统级别软件是否匹配应用设计技术5.2 安装测试安装测试有两个目的。第一个目的是确保软件能够在不同的条件下进行安装，例如，首次安装、升级安装、完整或自定义安装；在正常和异常条件下的安装。异常条件例如磁盘空间不足、安装用户缺少目录创建权限等。第二个目的是验证软件在安装后能正确操作。这通常意味着要运行大量为功能测试开发的测试用例。建议对于安装测试，其重点应该放在第一个目的上，对于第二个目的可以根据需要和实际情况穿插在后续的测试，如冒烟测试、功能测试中体现。测试目标 验证被测软件在各种需要的软硬件配置下正确安装，包括下列情况： 新安装。一新的机器，先前从
10、未安装过该软件 更新。该机器先前安装过该软件同样的版本 更新。该机器先前安装过该软件的老版本测试策略 手工或自动化不管是手工安装还是自动化脚本安装，都要严格按照用户安装手册规定的操作步骤进行测试重点考虑有没有安装手册对于第二个目的的安装测试，怎样选取预先规定的功能测试的子集测试通过准则对于第一个目的：确保软件能够在不同的条件下进行安装。成功的安装应该是在整个安装过程中和安装完成后没有任何异常错误出现，能成功登录该应用对于第二个目的：验证软件在安装后能正确操作。这个需要运行预先规定的一功能测试的子集5.3 配置和兼容性测试配置和兼容性测试验证被测软件在不同的软硬件配置下的操作和表现。在大多数生产
11、环境中，特定的硬件规格，如客户端工作站、网络情况、服务器配置甚至型号都会不同。另外，不同客户端工作站上也许有不同的软件负载，如不同的应用软件、不同的浏览器、浏览器的不同版本的插件、驱动程序等等；甚者不同的操作系统，如 Windows XP, Windows Vista 等等；服务器软件也会不一致，如数据库软件，如 Oracle, Microsoft SQLServer、中间件软件等等。该类测试对产品显得尤其重要。对于项目来说也有巨大的指导作用，如项目经理为了最优化配置（从成本和实用的角度等），就需要进行不同软硬件情况下的配置和兼容性测试。该类测试也往往和性能测试相结合以决定在不同软硬件情况下的
12、最优化配置（如从成本和实用的角度等）。测试目标 验证被测软件在各种需要的软硬件配置下能正确运行测试策略 使用功能测试脚本首先，针对一特定硬件配置下： 打开和关闭许多和被测软件无关的、但和被测软件共同在同一机器上的其它许多软件，如同机上的 Microsoft 应用软件，Excel 或 Word 等等（如果有），可以在测试过程中和测试前就打开 在此基础上执行相应的功能测试测试重点考虑硬件配置情况复杂多样，使用哪些硬件配置呢？建议最好做些调研，如考虑目标用户或最终用户的使用习惯和经济承受能力？打开哪些和被测软件无关的、但和被测软件共同在同一机器上的其它许多软件？建议最好做些调研，如考虑目标用户或最终
13、用户会使用哪些其它的常用软件？尤其在使用目标软件时往往同时会打开或使用的软件？测试通过准则在某一特定的硬件配置下，在许多和被测软件无关的、但和被测软件共同在同一机器上的其它许多软件运行或使用情况下，相应的功能测试没有失败5.4 易用性测试易用性是人类工程学的目标。软件的易用性是一个比较有特点的问题，会随着具体产品或项目的特征和要求而有巨大差异，比如手机软件和一般 Windows 平台下的软件易用性相差很大，又如一核反应堆的关闭序列和一语音信箱的菜单系统的易用性有着天壤之别。即使对于同一个软件，不同的用户也会有不同的感受。当然，我们也不是说对软件的易用性就毫无测试办法和标准，对于同一类软件还是有
14、它的通用性可言的。因此下面尝试从一些比较通用的方面讨论之。易用性主要考虑软件使用时人的因素和感受，因此我们先介绍两个概念。用户与程序相互交互的介质称为用户接口（User Interface - UI），用户接口对不同软件种类也会有巨大的差异，对于 PC 来说，我们现在有了精致的完善的图形用户接口（Graphical User Interface - GUI）。很快我们可以对着我们的 PC 听和说，那时又会有新的 UI。另外， Accessibility testing 也属于易用性测试范畴。这种测试一般针对对软件有特殊要求的群体，比如部分残疾人。测试目标 考虑软件使用时人的因素和感受测试策略
15、使用功能测试脚本对于一些比较通用的规则可以制成检查表的形式测试重点考虑 遵守通用的标准和指导方针。如 Windows 平台下的软件应和 Windows 平台的风格一致、而 Mac 平台下的软件显然应该和 Mac 平台的风格一致 直觉的。如用户界面是干净的、不多余的？用户界面是经过良好组织和布局的？ 一致性。如快捷键和菜单选项间；术语和命名；确认和取消按钮的位置布局等 灵活性。如用户希望能手工键入、粘贴、插入文件内容等方式作为输入方法 舒服的。如较长时间的等待应有进度条提示、一般情况下程序应有较快的反应，但也不是绝对的，举个例子，高性能就一定好吗？未必如此，例如当快速的连提示信息或出错信息都不能
16、看清时用户反而会觉得很不舒服 正确的。例如拼写；图标是否有同样的大小和背景；还有是否所见即所得 - WYSIWYG (what you see is what you get) 有用的。没有大量的过量功能，这个特征尤其在产品上表现突出，用户往往要面对大量的无用的或者不需要的功能测试通过准则该类测试对于不同产品和项目有较大的差异性，因此尤其要加强对该类测试用例的评审，在业务人员、设计人员等一致同意的基础上进行测试，测试人员也要关注软件需求中应有该方面的相关描述5.5 数据和数据库完整性测试在整个系统测试过程中，数据库和数据库过程应作为系统的子系统进行测试。这些测试不使用用户界面作为数据进入界面进
17、行测试。对不同的数据库管理系统，可能存在不同的工具和技术，如 Oracle 和 Microsoft SQLServer。测试目标 保证数据存取方法和过程正确运行，在整个数据操作过程中和结束后没有数据破坏测试策略 使用有效的和无效的数据或数据的请求调用各个数据库存取方法和过程检查数据库保证数据正如预期地进入，所有的数据库事件正确地发生，或者检查数据保证对于正确的请求取得正确的数据测试重点考虑测试也许需要一个 DBMS 开发环境或驱动程序以便在数据库中直接进入或更改数据确定哪些数据存取方法和数据过程重点测试测试的先后顺序测试通过准则所有的数据库存取方法和过程正如设计要求一样运行，没有任何的数据破坏
18、5.6 接口测试在集成测试过程中，接口测试显得特别重要，首先要确认被测软件是否集成了规定的单元或子系统、外部系统（如有）；其次，对相应的接口要进行详细的测试；最后也应该对集成后的所有功能进行相应的测试以确保集成后整个系统功能的正确性，当然这一步属于功能测试的范畴，本文不予讨论。测试目标 确保“测试需求”中对应的所有工作版本的内部单元组合到一起后能够按照设计的意图协作运行，接口的调用正确。测试策略 使用功能测试脚本。按照设计规范，对所有接口设计相应的测试用例进行手工或自动化测试，包括系统内部接口和外部接口，尤其注意和第三方的软硬件接口（如有）。测试重点考 测试的顺序性虑 数据是否能正确传递接口之
19、间的调用状态的变化是否正确（如有）接口之间的异常处理功能测试通过准则所有与接口有关的测试用例功能没有失败5.7 文档测试文档也是发布的软件产品的重要组成部分，因此也应该对文档进行相应的测试，尤其对安装手册（前面已有所述）、用户使用手册和在线帮助手册要进行重点测试。正确的文档能减少维护费用和提高软件的可维护性、改善软件易用性、减少责任等。测试目标 保证发布的软件产品中的文档的正确性测试策略 按照手册描述，逐章节阅读、检查和验证相应的内容，比如严格地按照用户使用手册上的描述去操作和使用程序测试重点考虑与用户相关的文档的测试（如安装手册、用户使用手册和在线帮助手册）术语的正确性和一致性是否覆盖了产品
20、的所有方面功能描述的准确性图形和屏幕截屏是否正确举例是否正确拼写和语法超文本链接测试通过准则文档所有内容描述准确和正确5.8 失效恢复测试失效恢复测试保证被测软件能成功地从硬件、软件或网络故障中失效恢复而不会有数据或事务的丢失。对于必须时刻保持运行的系统，失效备援测试保证当一个失效备援条件发生时，替代或备份系统正确地接管失败的系统而不会有数据或事务的丢失。恢复测试是一种对立的测试过程，让应用或系统遭受极端或仿真条件来引起一个故障，例如设备的输入、输出错误或无效的数据库指针和键。调用恢复过程、监控和检查应用或系统来验证已完成正确的应用、系统和数据恢复。测试目标 验证恢复过程（手工或自动化）正确恢
21、复数据库、应用和系统到期望的、已知的状态。测试策略 手工或自动化测试。如电源中断、通讯中断、网络中断、操作中断等可以手工直接执行；操作中断，尤其是有关数据库的操作、网络操作等也可以使用一些自动化工具执行。测试重点考虑测试设计或执行中应考虑： 客户端电源中断 服务端电源中断 客户端和服务器之间通讯中断 网络异常问题，如瞬间的断开 关键功能执行过程中操作异常中断 备份系统有效性（如有） 数据过滤过程中断、数据同步过程中断等 无效的数据库指针或键 数据库中无效的或被破坏的数据元素测试通过准则在上面所有的测试中，当恢复程序完成时，应用、数据库和系统应该成功返回到期望的、已知的状态。欢迎您的光临，Word 文档下载后可修改编辑 .双击可删除页眉页脚.谢谢！你的意见是我进步的动力，希望您提出您宝贵的意见！让我们共同学习共同进步！学无止境.更上一层楼。
