《微软的软件测试之道》读书笔记 之 非功能测试
《微软的软件测试之道》读书笔记 之 非功能测试
2014-07-22
非功能属性分类
可靠性
软件使用者期望软件能够无误运行。可靠性是度量软件如何在主流情形和非预期情形下维持它的功能，有时也包括软件出错时的自恢复能力。例如，自动定时保存现行文件的功能就可以归类到可靠性。
可用性
可用性测量的是用户学习和控制软件以达到用户需求的容易程度。
可维护性
可维护性描述了修改软件而不引入新错误所需的工作量。
可移植性
现在， Windows 的代码则必须能在32 位和64 位处理器上运行。许多微软产品运行在Windows 和Macintosh 两种平台上。
性能测试
因为各属性之间在范围上有重叠，很多非功能属性的名字是可以通用的。例如，性能测试经常会跟下面将要提及的压力、负载和可扩展性测试的概念联系起来。这些领域的测试手段和目标有很多不同点，但也有几个相似点。例如，在有几千个用户联线的状况下测试一个服务器系统的表现是一种性能测试（很多其他人会认为这是负载测试或可扩展性测试）。类似地，软件经过好几周或几个月的连续运转而无需重启的测试也被很多人看作是性能测试的一部分（大多数人会说这是可靠性测试或马拉松测试）。
这类性能测试的要旨只是测量某些重要操作(action)的执行时间。大多数的性能测试实际上是通过执行测试用例并记录所用时间的自动化测试来实现的。
性能测试的目标是发现重大的系统瓶颈。你可以想象一个系统由一系列的瓶颈组成；发现并改善一个瓶颈往往会在其他地方产生一个新的瓶颈。关键在于要尽早订立性能目标，否则你可能不知道什么时候该停止性能测试。
怎样测量性能
在设计过程的早期就积极地介入代码评审和分析性能目标是绝对必要的。
下面是一些在设计阶段能帮助发现潜在的性能问题的技巧：
- 提出疑问：找出有潜在性能问题的地方。对网络交通的拥塞状况、内存管理的效率、数据库设计的合理性、或其他任何有关地方提出疑问。即使你并没有性能设计的解决方案，而只是通过让其他团队成员考虑性能问题，测试工程师也一样能够产生很大的影响力。
- 考虑全局：不是片面地考虑局部的优化，而是考虑全面的用户场景。你将会在整个开发过程中有相对充足的时间深入性能场景的细节，但是在设计阶段的时间最好是花费在考虑从头到尾的（end to end）场景上。
- 明确目标： 象“响应时间应该很快”这样的目标是不可度量的。应用SMART（Specific-具体的, Measurable-可度量的, Achievable-可实现的, Relevant-相关的, Time-bound – 有时限的）标准来设计目标。举个例子，“每个用户操作的执行时间必须不超过100毫秒，或上一版本的10%的时间之内将控制权返回应用程序”。
性能计数器（performance counters) 经常被用来检测系统的性能瓶颈。性能计数器是揭示应用软件或系统的某些性能指标的细节测量工具，它使得监测和分析这些指标成为可能。所有Windows操作系统的版本都包含了一个监测这些计数器的工具(Perfmon.exe)，Windows在很多瓶颈存在的地方设置了性能计数器，例如CPU，磁盘I/O，网络I/O，内存统计，和资源占用率。
压力测试
应用软件在预期的和重负载条件下的表现和处理容量增大的能力，通常被归类在性能测试下面。广义上，压力测试经常包括了负载测试、平均无故障时间(MTBF - mean time between failure)测试、低资源测试、容量测试、或重复性测试。这些不同测试的方法和目的之间的主要区别是：
压力测试 一般来说，压力测试的目的是要通过模拟比预期要大的工作负载来让只在峰值条件下才出现的缺陷曝光。压力测试是要发现软件的弱点所在。内存泄漏、竞态条件、数据库中的线程或数据行之间的死锁条件、和其他同步问题等等，都是压力测试能发掘出来的常见缺陷。
负载测试 负载测试是要探讨在高峰或高于正常水平的负载下，系统或应用软件会发生什么情况。例如，一个网络服务的负载测试会试图模拟几千名用户同时连线使用该服务。性能测试一般都包括测量峰值负荷下的响应时间。
平均无故障时间（MTBF）测试 MTBF（Mean Time Between Failure）测试是测量系统或应用软件在出错或当机前的平均运行时间。这一测试有几个变体，包括平均无错时间(MTTF)或平均无当机时间(MTTC)。技术含义略有不同，但实践上，这些词汇都是一个意思。
低资源测试 低资源测试是要确定当系统在重要资源（内存、硬盘空间或其他系统定义的资源）降低或完全没有的情况下的状况。重要的是要预估将会发生什么，例如为文件存盘而无足够空间、或一个应用程序的内存分配失败时将会发生什么。
容量测试 与负载测试非常相似，容量测试一般是用来执行服务器或服务测试。目的是要确定一台或多台计算机能支持的最多用户数目。容量模型通常建立在容量测试数据基础上。有了这些数据，营运团队(Operations)就能定计划什么时候增加系统容量：要么增加单机资源，如RAM、CPU和磁盘空间等；要么干脆增加计算机数目。
重复性测试 重复性测试是为了确定重复某一程序或场景的效果而采取的一项简单而“粗暴”(brute force)的技术。这个技术的精髓是循环运行测试直到达到一个具体界限或临界值，或者是不妙的境况。举个例子，一个操作也许会泄漏20字节的内存。这并不足以在软件的其他地方产生任何问题，但如果测试连续运行2000次，泄漏就可以增长到4万字节。如果是提供核心功能的程序有泄漏，那么这个重复性测试就抓到了只有长时间连续运行该软件才能发现的内存泄漏。通常有更好的办法来发现内存泄漏，但有时候，这种简单“粗暴”的方法也可以很有效。