2.2.4非功能性的系统测试需求
对于非功能性的系统测试，主要目的是验证软件系统的整体性能等是否满足其产品设计规格所指定的要求，涉及非功能性的质量需求有系统性能、安全性、兼容性、扩充性等的测试，可能还会涉及第三方产品的集成测试。对于每一个应用软件系统，非功能特性的质量需求都是存在的，这类测试需求会因不同的项目类型差异比较大，这些需求的程度、重要性不同，因此要求为非功能性测试需求设置优先级，下面就做一个简单的分析。
·纯客户端软件，如字处理软件、下载软件、媒体（音频/视频）播放软件等在系统测试要求上是最低的，对性能、容错性、稳定性等有一定的要求，如占用较少的系统资源（CPU和内存），而且能运行在不同的操作系统上，一般分为Windows、Linux和Mac等。在Windows上要支持Windows NT、Windows 2000、Windows XP和Windows Vista等。
·纯Web（B/S）应用系统，如门户网站、个人博客网站、网络信息服务等在系统测试上要求较高，特别强调性能和可用性，对安全性有一定的要求，主要是保证数据的备份和登录权限。性能要求好，可以允许大量并发用户的访问，而且用户在任何时刻都可以访问，即每周7天，每天24小时（7×24）运行。
·客户端/服务器（C/S）应用系统，如邮件系统、群件或工作流系统、即时消息系统等在系统测试需求上与Web应用系统接近，也可能出现大量并发访问的用户，但安全性相对好写，客户端是特定的开发软件，相对于浏览器来说，对端口、协议等的限制比较容易做到。
·大型复杂企业级系统涉及面广、集成性强，包括B/S、C/S、数据库、目录服务、服务器集群、XML接口等各个子系统。在系统测试需求上，这类系统要求最高，不论是在性能、可用性方面，还是在安全性、可靠性等方面，都有很高的要求。
系统非功能性测试的需求在不同应用领域也体现较大差异。如网上银行、信用卡服务等系统，其安全性、可用性和可靠性等多方面的测试至关重要，因为这方面的缺陷很可能会给用户造成较大的损失。这些系统需要得到充分的安全性测试、容错性测试和负载测试。多数情况下，还需要独立第三方的安全认证。
而对于局域网内的企业级应用来说，有关权限控制、口令设置等安全性测试依然重要，但兼容性测试就相对简单，因为可以指定某些特定的硬件和软件，如打印机只用HP LaserJet，操作系统和浏览器只用Windows XP和IE，无须对各种各样的硬件和软件进行兼容性测试。对于客户端软件，一般情况下，性能不是问题，而容错性、稳定性的测试则显得重要些。
对于企业级应用系统来说，存在着不同的应用模式，其系统的架构也不一样，可以分为“以功能为中心、以数据库为中心和以业务逻辑（工作流）为中心”等，在进行系统测试时，所设定的目标也有一定的区别。
·以功能为中心的系统，强调模块化的低耦合性和高内聚性，这类系统的可扩充性、维护性要求很高。
·以数据库为中心的系统，强调数据处理的性能、正确性和有效性，使数据具有良好的一致性和兼容性，同时，确保数据的安全性，包括数据的存储、访问控制、加密、备份和恢复等。
·以应用逻辑（工作流）为中心的系统，强调灵活、流畅和时间性，系统的可配置性强，接口规范，如采用XML统一各工作流构件的输入和输出。
除此之外，还有其他一些因素的影响，如项目的周期性和依赖性等。如果项目是一次性的，对可扩充性、可移植性等要求低，而长期性的项目（产品开发）对可扩充性、可移植性要求就很高。
Google日历实际上是一种软件服务，即属于软件即服务（Software as aService，SaaS）的应用模式，对软件运行的服务质量（QoS）也有很高的要求，需要支持7x24不间断的服务。对于这样的Web服务软件，非功能性测试的需求涉及性能、安全性、容错性、兼容性、可用性、可伸缩性等各个方面。
服务级别协议（SLA）指定了最低性能要求，以及未能满足此要求时必须提供的客户支持级别和程度。与 QoS 要求一样，服务级别要求源自业务要求，对要求的测试条件及不符合要求的构成条件均有明确规定，并代表着对部署系统必须达到的整体系统特性的担保。服务级别协议被视为合同，所以必须明确规定服务级别要求。如表2-3所示。下面侧重性能、可用性、安全性和兼容性的测试需求讨论，而对其他非功能性属性就不进行过多的讨论，这并不意味着这些属性就没有测试需求，例如可维护性（即系统维护的容易程度）的测试需求也是很多的，包括系统监视、日志文件、故障恢复、数据更新和备份等测试。
1．性能测试
性能测试分为服务器端性能测试和客户端性能测试，需要考虑“哪些负载（如并发用户数200、400、1000等）、哪些基本配置（最低配置、标准配置等）需要进行性能测试”等测试需求。服务器端的性能测试还可进一步分为基准性能测试、性能验证测试、压力测试、容量测试、可伸缩性测试等。
客户端性能测试，需要对页面显示、刷新的时间进行测试获得相关性能指标数据，如在Google日历中添加大批量的待办事项，然后查看页面浏览的响应时间。客户端软件性能测试，还要考察其运行时所占有资源（如CPU、内存）情况，占有资源越少越好。
·如Google Talk在好友数量以及对话窗口非常多的情况下，CPU、内存的使用仍然处在一个合理的范围内，如CPU使用率不超过20%（正常运行时间，不是软件启动的短暂时刻）。
·网络资源占用，如Google Talk的语音占带宽大约24～32K（24000～32000bit/s）。
·在较差的网络条件下，语音与文字聊天能保持流畅。
·移动应用app测试时，不仅要测试其网络流量，还要测其耗电量，耗电量和CPU的开销也有关系。
·在长时间运行（7×24小时）下，没有内存泄漏等问题。
这些既是性能要求，也是性能测试需求，性能测试要覆盖各项要求。
在服务器端，通过改变网络带宽或延迟、负载模式和大小，对一些关键业务（如Google日历中登录、提交新事项时、按月显示、查询等）进行测试，以获取或验证系统整体的性能指标。如系统要求在正常使用情况下其响应时间为3～5秒，即使在使用高峰期（如上下班时间）系统的响应时间也不应该超过15秒，这就意味至少要进行两种场景——平均负载和高峰负载的性能测试。在对实际系统进行性能测试时，往往会结合其关键业务考虑其关键性能测试需求。
·多人同时登录（并发用户活动）、设置活动时，页面的响应速度要求在3秒之内。
·通过页面进行搜索时，查询时间应控制在5秒以内。
·设置共享时、用户更新活动信息时，是否能快速同步，即在另一共享好友处即刻显示更新过的信息。
·当活动/事件达到一定数量（200～1000）时，页面响应速度要在5秒之内。
·当循环会议较多时，页面的处理速度正常（5秒之内）。
在哪些负载、测试周期（8个小时、24小时、7天等）的组合情况下进行压力测试。
压力测试往往和容量测试结合起来，以测试系统的限制和故障恢复能力，如测试应用系统在长期高负载下会不会崩溃、在什么情况下会崩溃，并确定系统能承受的最大负载（如最大连接数、并发用户数等）。
可伸缩性通常要求在对部署体系结构的设计不做修改的情况下增加资源以满足系统增加的容量，从而使系统容易支持来自现有用户或扩大的用户群体的额外负载。可伸缩性测试也可以归为性能测试，如在部署两台服务器时测试系统性能（容量，即最大负载），再部署四台、八台服务器时分别进行系统容量的测试，看其容量是否为上次（两台、四台）实验值的两倍或接近两倍。如果是，系统就具有良好的可伸缩性。
2．可用性测试
可用性是指系统正常运行的能力或程度，在一定程度上也是系统可靠性的表现，可用性测试就基本上等同于可靠性测试。可用性一般用正常向用户提供软件服务的时间占总时间的百分比来表示，即：
可用性 = 正常运行时间 /（正常运行时间 + 非正常运行时间）· 100%
系统非正常运行时间可能是由于硬件、软件、网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或连接中断不能被访问，或性能急剧降低不能使用软件现有的服务等。
可用性指标一般要求达到4个或5个“9”，即99.99% 或99.999%。
·如果可用性达到99.99%，对于一个全年不间断（7·24的方式）运行的系统，意味着全年（525600分钟）不能正常工作的时间只有52 分钟，不到一个小时。
·如果可用性达到99.999%，意味着全年不能正常工作的时间只有5 分钟。
所以一个系统的可用性达到99.999%，基本能满足用户的需求。当然，不同的应用系统，可用性要求是不一样的，非实时性的信息系统或一般网站要求都很低，可能在99%和99.5%之间，而对一些军事系统，则要求很高，如美国防空雷达系统全年失效时间不超过两秒，可用性高达7个“9”之上，达99.999994%。
可用性测试就比较困难，不可能有足够的时间来进行测试，就只能采用空间换时间的办法，例如在高负载情况下进行为期一周或一个月的测试，以判断其可靠性。其次，就是对提高可靠性的措施进行测试，如故障转移的测试。
容错处理系统能够处理异常、错误操作而不至于系统崩溃，从而能够提供系统的可用性。例如，业务处理过程中中断事务时，系统能保存当前状态，程序能自动或提示重连，或在某个时刻可以恢复操作。
3．安全性测试
安全性是一个复杂的主题，涉及部署系统的各个级别。安全性要求分析，包括确定可能的或潜在的各类安全威胁和找到处理这些威胁的策略，即：
·确定关键（有形的和无形的）资产，并找到对这些资产的威胁；
·确定使组织暴露于可能带来风险威胁的薄弱环节；
·开发减轻组织风险的安全规划。
分析安全要求应由软件组织的各方面风险承担者参与，包括管理员、业务分析师和信息技术人员等。通常，组织会指定一个安全结构设计师来领导安全措施的设计和实现。
安全性测试就是全面检验软件在需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应，对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案进行针对性测试，并对安全性关键的软件单元和软件部件，单独进行加强的测试，以确认其满足安全性需求。所以，安全性测试的需求点还是比较多的，任务还是比较重的，特别是对复杂的系统。这里举一些常见的需求点：
·各种登录模式的安全性验证、对口令各种要求的测试；
·用户权限的验证；
·所有入口的验证，即对数据输入的验证；
·Cookie和Session的有效期验证等特殊机制的验证；
·数据访问权限设置验证，如服务器上的目录设置；
·敏感数据加密、数据存储安全性的验证；
·验证系统的日志文件是否得到保护；
·在异常条件下操作、错误操作，测试软件以表明不会因可能的单个或多个输入错误而导致不安全状态；
·其他各种安全漏洞（如跨站点攻击、SQL注入等）的检查。
4．兼容性测试
兼容性测试需求是指明确要测试的兼容环境，考虑软、硬件的兼容，就软件兼容来说，不仅要测试系统自身的版本兼容、用户已有数据的兼容，还要测试与操作系统、应用平台或浏览器、和其他第三方系统以及第三方数据的兼容性。操作系统包括Windows、Mac、Solaris、Linux等，浏览器包括IE、FireFox、Chrome和Safari等，如表2-4所示，形成环境组合矩阵，更能明确兼容性测试需求。兼容性测试的组合不仅仅局限在操作系统、浏览器这两个因素，还有其他因素，如：
·32位、64位CPU；
·手机平台 Android、iOS、Windows Phone；
·支持不同的Internet连接速度；
·是否支持SSL。
兼容性测试需要根据被测试应用的具体情况决定。像Google日历应用，支持移动平台是必须的，而且日历有较多的个人信息，需要支持SSL，但32位、64位CPU对其没有什么影响，不需要考虑。而对于像Google Talk这样客户端应用程序，就不需要考虑浏览器支持，而且不同的操作系统（Windows、Mac OS、iOS、Android等）有不同的应用程序，需要单独处理，只是每类操作系统还有多个版本，如iOS有iOS 5、iOS 6和iOS 7等。
兼容性测试，不仅是软件系统之间兼容、和第三方系统之间的兼容，而且还需考虑系统版本之间的兼容，特别是用户数据的兼容，数据兼容测试也是重要的需求。例如：
·不同客户端软件（如Google Talk）版本和服务器系统的兼容，服务器上一般部署的都是最新版本，但客户端就不一定；
·新版本的软件能够兼容以前各种版本产生的历史数据，确保数据向上兼容，如Word2013 能够正常打开之前多个Word版本（如Word 2003，Word 2007等）产生的用户.doc文件。
相关文章：
