功能测试涉及了软件在功能上正反两面的测试，而非功能测试就是所有其他方面的测试。非功能测试包括性能、负载、安全、可靠性和其他很多方面。非功能测试有时也被称作行为测试或质量测试。非功能测试的众多属性的一个普遍特征是一般不能直接测量。这些属性是被间接地测量，例如用失败率来衡量可靠性或圈复杂度，用设计审议指标来评估可测性。
国际标准化组织（ISO）在ISO 9216和ISO 25000:2005中定义了几个非功能属性。这些属性包括：
可靠性
软件使用者期望软件能够无误运行。可靠性是度量软件如何在主流情形和非预期情形下维持它的功能，有时也包括软件出错时的自恢复能力。例如，自动定时保存现行文件的功能就可以归类到可靠性。
可用性
如果用户不明白应该如何使用，那么，即使是零差错的软件也会变得毫无用处。可用性测量的是用户学习和控制软件以达到用户需求的容易程度。进行可用性研究、重视顾客反馈意见和对错误信息和交互内容的检查都能提高可用性。
可维护性
可维护性描述了修改软件而不引入新错误所需的工作量。产品代码和测试代码都必须具备高度的可维护性。团队成员对代码的熟悉程度、产品的可测性和复杂度都对可维护性有影响。
可移植性
可移植性指一种计算机上的软件转置到其它计算机上的能力。软件移植是实现功能的等价联系，而不是等同联系。从狭义上讲，是指可移植软件应独立于计算机的硬件环境；从广义上讲，可移植软件还应独立于计算机的软件，即高级的标准化的软件，它的功能与机器系统结构无关，可跨越很多机器界限。
性能测试
性能测试目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。性能测试类型包括压力测试、负载测试，强度测试，容量测试等。因为各属性之间在范围上有重叠，很多非功能属性的名字是可以通用的。
压力测试
一般来说，压力测试的目的是要通过模拟比预期要大的工作负载来让只在峰值条件下才出现的缺陷曝光。内存泄漏、竞态条件、数据库中的线程或数据行之间的死锁条件、和其他同步问题等等，都是压力测试能发掘出来的常见缺陷。 压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等。
负载测试
负载测试是要探讨在高峰或高于正常水平的负载下，系统或应用软件会发生什么情况。例如，一个网络服务的负载测试会试图模拟几千名用户同时连线使用该服务。测试的主要是软件系统的性能，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等。
平均无故障时间（MTBF）测试
MTBF测试是测量系统或应用软件在出错或当机前的平均运行时间。这一测试有几个变体，包括平均无错时间(MTTF)或平均无当机时间(MTTC)。技术含义略有不同，但实践上，这些词汇都是一个意思。
低资源测试
低资源测试是要确定当系统在重要资源（内存、硬盘空间或其他系统定义的资源）降低或完全没有的情况下会出现的状况。重要的是要预估将会发生什么，例如为文件存盘而无足够空间、或一个应用程序的内存分配失败时将会发生什么。
容量测试
与负载测试非常相似，容量测试一般是用来执行服务器或服务测试。目的是要确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。容量模型通常建立在容量测试数据基础上。有了这些数据，营运团队(Operations)就能定计划什么时候增加系统容量：要么增加单机资源，如RAM、CPU和磁盘空间等；要么干脆增加计算机数目。
重复性测试
重复性测试是为了确定重复某一程序或场景的效果而采取的一项简单而“粗暴”(brute force)的技术。这个技术的精髓是循环运行测试直到达到一个具体界限或临界值，或者是不妙的境况。举个例子，一个操作也许会泄漏20字节的内存。这并不足以在软件的其他地方产生任何问题，但如果测试连续运行2000次，泄漏就可以增长到4万字节。如果是提供核心功能的程序有泄漏，那么这个重复性测试就抓到了只有长时间连续运行该软件才能发现的内存泄漏。通常有更好的办法来发现内存泄漏，但有时候，这种简单“粗暴”的方法也可以很有效。
兼容性测试
兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等环境中是否能够很友好的运行的测试。主要测试软件是否能在不同的操作系统平台上兼容，或测试软件是否能在同一操作平台的不同版本上兼容；软件本身能否向前或向后兼容；测试软件能否与其他相关的软件兼容；数据兼容性测试，主要是指数据能否共享等。
安全性测试
安全性测试是检查系统对非法侵入的防范能力。主要包括用户认证、系统网络安全和数据库安全方面的测试。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如：想方设法截取或破译口令；专门开发软件来破坏系统的保护机制；故意导致系统失败，企图趁恢复之机非法进入；试图通过浏览非保密数据，推导所需信息等。理论上讲，只要有足够的时间和资源，没有无法进入的系统。因此系统安全设计的准则是使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利图。
辅助功能测试
辅助功能测试保证软件公司开发的软件能被伤残人使用。其中任何应用程序都必须测试的特性包括：操作系统的设置测试、“内置”辅助特性的测试（包括Tab 键顺序、热键和快捷键）、编程访问的测试、以及辅助的技术工具的测试。辅助功能测试的一个重要方面就是使用辅助功能工具去测试应用程序, 这些工具包括,屏幕阅读器、放大镜、语音识别或者其他输入程序。
本地化测试
本地化就是将软件版本语言进行更改，本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试，安装/卸载测试，当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量，包含软件、文档和联机帮助等部分。
配置测试
配置测试就是测试软件是否和系统的其他与之交互的元素之间兼容，如浏览器、操作系统、硬件等，验证被测软件在不同的软件和硬件配置中的运行情况。配置测试执行的环境是所支持软件运行的环境。测试环境适合与否严重影响测试结果的真实性和正确性。硬件环境指测试必须的服务器、客户端、网络连接设备、打印机等，软件环境指被测试软件运行时的操作系统、软件平台、数据库其他应用软件构成的环境。
可用性测试
可用性测试是在产品或产品原型阶段实施的通过观察或访谈或二者相结合的方法，发现产品或产品原型存在的可用性问题，为设计改进提供依据。可用性测试不是用来评估产品整体的用户体验，主要是发现潜在的误解或功能在使用时存在的错误。可用性测试适于解决的问题：确定测试产品的可用性水平；与预期目标、与竞争对手、与老版设计相比的可用性水平；比较不同方案，确定哪个方案更加可行。
一些在设计阶段能帮助发现潜在的性能问题的技巧：
提出疑问：
找出有潜在性能问题的地方。对网络交通的拥塞状况、内存管理的效率、数据库设计的合理性、或其他任何有关地方提出疑问。即使你并没有性能设计的解决方案，而只是通过让其他团队成员考虑性能问题，测试工程师也一样能够产生很大的影响力。
考虑全局：
不是片面地考虑局部的优化，而是考虑全面的用户场景。你将会在整个开发过程中有相对充足的时间深入性能场景的细节，但是在设计阶段的时间最好是花费在考虑从头到尾的场景上。
明确目标：
象“响应时间应该很快”这样的目标是不可度量的。应用SMART（Specific-具体的, Measurable-可度量的, Achievable-可实现的, Relevant-相关的, Time-bound – 有时限的）标准来设计目标。举个例子，“每个用户操作的执行时间必须不超过100毫秒，或上一版本的10%的时间之内将控制权返回应用程序”。
还有一个要考虑的技巧是预测哪里可能有性能问题，或者说分辨出哪些操作对用户来说是最重要的，从而是需要度量的。而往往最有效的办法就是在设计阶段就定义这些场景。
注：本文为《微软的软件测试之道》一书第12章内容以及网络收集后整理后的知识笔记，感谢本书作者Alan Page及网络内容相关作者。
最新内容请见作者的GitHub页：http://qaseven.github.io/