非功能测试

非功能的测试领域包括了性能、负载、安全、可靠性和其他很多方面。非功能测试有时也被称作行为测试或质量测试。非功能测试的众多属性的一个普遍特征是一般不能直接测量。这些属性是被间接地测量，例如用失败率来衡量可靠性或圈复杂度，用设计审议指标来评估可测性。

可靠性

软件使用者期望软件能够无误运行。可靠性是度量软件如何在主流情形和非预期情形下维持它的功能，有时也包括软件出错时的自恢复能力。

可用性

如果用户不明白应该如何使用，那么，即使是零差错的软件也会变得毫无用处。可用性测量的是用户学习和控制软件以达到用户需求的容易程度。进行可用性研究、重视顾客反馈意见和对错误信息和交互内容的检查都能

提高可用性。

可维护性

可维护性描述了修改软件而不引入新错误所需的工作量。

可移植性

代码的可移植性是代码能在不同配置平台上运行。许多微软产品运行在Windows 和Macintosh 两种平台上。

可扩展性

(程序能应付过载的能力)

安全性

系统应对非授权改动图谋的能力)

测试经理：产品测试，性能测试，安全测试

在设计过程的早期就积极地介入代码评审和分析性能目标是绝对必要的。事实上，若要满足大多数非功能测试需要，最好的办法是在程序设计阶段就加以考虑。

在设计阶段能帮助发现潜在的性能问题的技巧：

(1)提出疑问：找出有潜在性能问题的地方。对网络交通的拥塞状况、内存管理的效率、数据库设计的合理性、或其他任何有关地方提出疑问。即使你并没有性能设计的解决方案，而只是通过让其他团队成员考虑性能问题，

测试工程师也一样能够产生很大的影响力。

(2)考虑全局：不是片面地考虑局部的优化，而是考虑全面的用户场景。你将会在整个开发过程中有相对充足的时间深入性能场景的细节，但是在设计阶段的时间最好是花费在考虑从头到尾的(end

to end)场景上。

(3)明确目标：

象“响应时间应该很快”这样的目标是不可度量的。应用SMART(Specific-具体的,Measurable-可度量的,

Achievable-可实现的, Relevant-相关的, Time-bound – 有时限的)标准来设计目标。

建立基线 早定义、早测量的一个重要方面是建立基线。

经常运行测试 一旦你建立了基线，就尽量经常地测量。

测量响应效率

用户并不关心程序在后面用了多长时间来执行。他们关心的是应用软件响应是否够快。性能测试必须着重于测量用户响应时间，

测量的是性能

我们常常忍不住想在性能测试中加入功能或其他类别的测试。但是，既是性能测试，就要专注于测量性能。

预估瓶颈 针对延迟会发生的地方做性能测试

合理使用资源很重要

响应时间和延迟两者都是性能的关键标识，但不要在性能测试中忘记检查CPU的负荷，磁盘或网络I/O，还有内存。

避免改变 克制住给你的性能测试小修(或大修)的冲动。不管该操作的后台计算需要耗费多少时长。

压力测试

应用软件在预期的和重负载条件下的表现和处理容量增大的能力，通常被归类在性能测试下面。广义上，压力测试经常包括了负载测试、平均无故障时间(MTBF

- mean time between failure)测试、低资源测试、容量测试、或重复性测试。

压力测试的目的是要通过模拟比预期要大的工作负载来让只在峰值条件下才出现的缺陷曝光。压力测试是要发现软件的弱点所在。内存泄漏、竞态条件、数据库中的线程或数据行之间的死锁条件、和其他同步问题等等

负载测试是要探讨在高峰或高于正常水平的负载下，系统或应用软件会发生什么情况。

MTBF测试是测量系统或应用软件在出错或当机前的平均运行时间。

低资源测试是要确定当系统在重要资源(内存、硬盘空间或其他系统定义的资源)降低或完全没有的情况下的状况。

容量测试一般是用来执行服务器或服务测试。

重复性测试是为了确定重复某一程序或场景的效果而采取的一项简单而“粗暴”(brute

force)的技术。

兼容性测试

应用程序兼容性测试(Application compatibility

testing)一般注重于应用程序之间或所测试的目标系统与其他应用程序之间的交互。

吃我们自己的“狗食” ：“在微软，当我们谈到‘吃我们自己的狗食( Eating our Dogfood)’时，

我是指，‘在你让任何人吃你的狗食之前，你必须自己先尝尝。” - 史蒂夫·鲍尔默于 2003 年10 月21 日ffice

发行大会上

可达性测试 “可达性是指消除障碍, 让每个人都能享受技术的益处。”— 史蒂夫•鲍尔默

可达性是指为每个人提供接触信息和工具的相等机会, 这些信息和工具是他们完成每天工作所必需的。

这包括从复制文件到浏览网页到产生新的文档等所有事情。软件可达性的根本点是让用户有一种感觉,

他有能力创造和维护应用程序、网站或者文件，并且有能力与之互动。

可用性测试

可用性和可达性很相似，但我们所考虑的这两者有一个很大的区别。可达性是指任何一个人都能够使用用户界面，而可用性是指用户能不能很容易的理解和与用户界面互动。

安全测试

威胁建模审查应用程序结构以找到潜在的安全威胁和弱点，威胁模型的意图是找出一个应用程序能被攻击的所有可能的方法，然后根据概率和可能的危害来排优先级。好的威胁建模需要分析和调研技能—这两种技能使得测试在这过程中很适用。

模糊测试

模糊测试是一种用来决定程序对无效输入数据会怎样反应的技术。

功能测试极其重要，而用来有效的完成功能测试的许多技术和方法也同等重要。很多团队有时会忘记一点，那就是用户并不关心找到了多少个缺陷，或者有多少测试失败了，或是代码覆盖率。它们都是“测试食谱”中重要而有价值的成分，但最终来说，用户关心的是产品非功能性的方面。用户想要的软件必须既安全又可靠，能够轻而易举地完成他们想做的事；还要能方便地找到功能，而且响应速度足够快。

非功能测试与功能测试相得益彰，对于确定产品是否拥有高质量和能否发布起着决定性作用。非功能属性常面临的一个难题是很多方面在开发早期就需要充分地考虑，而真正测量这些属性要一直等到用户使用该软件才能开始。要解决这个难题，关键是要通过角色扮演或其他相似的机制，在各个测试的前沿倾听用户的声音。