在衡量web用程序的性能时，哪些性能指标是比较重要的？

性能测试指标：  
1、SQL数据库：  
 User  0    Connections  (用户连接数，也就是数据库的连接数量)；  
 Number  of  deadlocks/Sec/－Total  （数据库死锁）  
 Memory\  Availalle  Mbyte  内存监控  (可用内存)  
 Physicsdisk  \disk  time  \－Total（磁盘读写总时间）（出现瓶颈时检查读磁盘的时间长还是写磁盘的时间长）  
 Butter  Caile  hit(数据库缓存的选取命中率)  
 数据库的命中率不能低于92％  
2、Web  Server：  
 Processor  \  Processon  time  \  Tatol    cpu时间  
 Memory  \  Availalle  MbyteAvai  应用服务器的内存  
 Requst  Quened  进入HTTP队列的时间；队列/每秒  
 Total  request  总请求数时间  
 Avg  Rps  平均每秒钟响应次数＝  总请求时间  /  秒数  
 Avg  time  to  last  byte  per  terstion  （mstes）平均每秒迭代次数  ；  上一个页面到下一个页面的时间是你录入角本的一个过程的执行  
 Http  Error  无效请求次数  
 Send  发送请求次数字节数  
3、Webload的压力参数：  
 Load  Size(压力规模大小)  
 Round  Time(请求时间)  
 Rounds  (请求数)  
 Successful  Rounds（成功的请求）  
 Failed    Rounds  （失败的请求）  
 Rounds  Per  Second  （每秒请求次数）(是指你录入角本的任务在一秒中执行的次数，类似Avg  time  to  last  byte  per  terstion  （mstes）)  
 Successful  Rounds  Per  Second(每秒成功的请求次数)  
 Failed    Rounds  Per  Second（每秒失败的请求次数）  
 Page  Time  页面响应时间  
 Pages  （页面数）  
 Pages    Per  Second  （每秒页面响应数）  
 Hit      Time（点击时间）  
 Hits（点击次数,也可以是请求次数，不过有一些不一样）  
 Successful    Hits  （成功的点击次数）  
 Failed    Hits  （失败的点击次数）  
 Hits  Per  Second  (每秒点击数)  
 Successful    Hits  Per  Second  （每秒成功的点击次数）  
 Failed    Hits  Per  Second  （每秒失败的点击次数）  
 Attempted    Connections  （尝试链接数）  
 Successful    Connections（成功的连接数）  
 Failed      Connections（失败的连接数）  
 Connect    Time（连接时间）  
 Process    Time（系统执行时间,一般用来显示CPU的运算量，服务器端与客户端都要记录）  
 Receive    Time（接受时间）  
 Send      Time（请求时间）  
 Time      To      First    Byte  （）  
 Throughput      （Bytes    Per    Second）（）  
 Response    Time（回应时间）  
 Response    Data      Size（）  
 Responses（）  

软件测试的14种类型

软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

1 数据和数据库完整性测试

数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
数据库完整性原即：
主码完整性：主码不能为空；
外码完整性：外码必须等于对应的主码或者为空。
数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支1持测试的工具和技术。

比如，有两张表：部门和员工。部门中有部门编号，部门名称，部门经理等字段，主码为部门编号；员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。
员工类型如下定义：0：职工，1：职员，2：实习生。但数据类型为Int，我们都知道Int占有4个字节，如果定义成char(1).就比原来节约空间。

2 白盒测试

白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
2.1 静态白盒测试
利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下：
Function NameGet(){
….
}
这是属于不符合开发规范的错误。
有这样一段代码:
if (i<0) & (i>=0)
…
这段代码交集为整个数轴，IF语句没有必要
I=0;
while(I>100){
J=J+100;
T=J*PI;
}
在循环体内没有I的增加,bug产生。

2.2 动态白盒测试
利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
看一段代码
if(I<0){
P1
}else{
P2
}
在调试中输入I=-1,P1程序段通过， P2程序段未通过，属于动态黑盒测试的缺陷

3.功能测试

功能测试指测试软件各个功能模块是否正确，逻辑是否正确。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。

4.UI测试

UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关
比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。

5.性能测试

性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试
5.1负载测试
负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？
5.2强度测试
强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。
5.3数据库容量测试
数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。
数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。
比如，在电子商务系统中，通过insert customer 往user表中插入10 000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100 000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；如果在规定的时间内显示出来，可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
5.4基准测试
基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。
5.5竞争测试
软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？

6. 安全性和访问控制测试

安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。
6.1应用程序级别的安全性
可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？
6.2系统级别的安全性
可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？

7.故障转移和恢复测试

故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。
故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。 
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？

8.配置测试

又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等）
下面列出主要配置测试
8.1浏览器兼容性
测试软件在不同产商的浏览器下是否能够正确显示与运行；
比如测试IE，Natscape浏览器下是否可以运行这套软件？
8.2操作系统兼容性
测试软件在不同操作系统下是否能够正确显示与运行；
比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？
8.3硬件兼容性
测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用.
比如在INTER,舒龙CPU芯片下系统是否能够正常运行？
这样的测试必须建立测试实验室，在各种环境下进行测试。

9.安装测试

安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。

10.多语种测试

又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。
本地化测试还要考虑：
l 当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
l 要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。
l 要考虑各个国家的民族习惯，比如龙个美国中被理解邪恶的象征，但翻译到中国，中国人认为为吉祥的象征。

11.文字测试

文字测试测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。
比如：“比如，请输入正确的证件号码！”何谓正确的证件号码，证件可以为身份证，驾驶证，也可为军官证，如果改为“请输入正确的身份证号码！”用户就比较容易理解了。

12.分辨率测试

测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。

13发布测试

主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试

13.1说明书测试
主要为语言检查，功能检查，图片检查
语言检查：检查说明书语言是否正确，用词是否易于理解；
功能检查：功能是否描述完全，或者描述了并没有的功能等；
图片检查:：检查图片是否正确
13.2宣传材料测试
主要测试产品中的附带的宣传材料中的语言，描述功能，图片
13.3帮助文件测试
帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能。
13.4广告用语
产品出公司前的广告材料文字，功能，图片，人性化的检查

14 文档审核测试

文档审核测试目前越来越引起人们的重视，软件质量不是检查出来的，而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料：

文档审核测试主要包括需求文档测试，设计文档测试，为前置软件测试测试中的一部分。

14.1需求文档测试

主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；

14.2设计文档测试

测试设计是否符合全部需求以及设计是否合理。

总结

据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计，得出这样一个结论：软件缺陷在开发前期发现比在开发后期发现资金，人力上节约90%；软件缺陷在推向市场前发现比在推出后发现资金，人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的，可以根据产品的具体情况进行组装测试不同的类型。

软件测试的组织与管理

作为软件开发的重要环节，软件测试越来越受到人们的重视。随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。然而，为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。
从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。软件的生命周期可用图1的流程表示。
为了确保软件的质量，对图1的过程应进行严格的管理。虽然测试是在实现且经验证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。

1．测试的过程及组织

当设计工作完成以后，就应该着手测试的准备工作了，一般来讲，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。
在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般可按下列方式组织：
(1)首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。
(2)为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试和验收测试。
(3)代码会审：
代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长，2～3名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。例如，对某个局部性小问题修改方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功说明、模块间接口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。
(4)单元测试：
单元测试集中在检查软件设计的最小单位—模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。
(5)集成测试：
集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。
(6)验收测试：
验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。

2．测试方法的应用

集成测试及其后的测试阶段，一般采用黑盒方法。其策略包括：

(1)用边值分析法和（或）等价分类法提出基本的测试用例；
(2)用猜测法补充新的测试用例；
(3)如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上（1）、（2）两步进行。
单元测试的设计策略稍有不同。因为在为模块设计程序用例时，可以直接参考模块的源程序。所以单元测试的策略，总是把白盒法和黑盒法结合运用。具体做法有两种：
a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足它们。覆盖的标准应该根据模块的具体情况确定。对可靠性要求较高的模块，通常要满足条件组合覆盖或路径覆盖标准。
b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒法进行补充。

3．测试的人员组织 

为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此，对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进行软件测试。基于此，测试人员的组织也应是分阶段的。

(1)软件的设计和实现都是基于需求分析规格说明进行的。

需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量，应对其进行严格的审查。审查小组由下列人员组成：
组长：1人
成员：包括系统分析员，软件开发管理者，软件设计、开发和测试人员和用户

(2)设计评审：

软件设计是将软件需求转换成软件表示的过程。主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成：
组长：1人
成员：包括系统分析员、软件设计人员、测试负责人员各一人。

(3)程序的测试：

软件测试。是整个软件开发过程中交付用户使用前的最后阶段，是软件质量保证的关键。软件测试在软件生存周期中横跨两个阶段：通常在编写出每一个模块之后，就对它进行必要的测试（称为单元测试）。编码与单元测试属于软件生存周期中的同一阶段。该阶段的测试工作，由编程组内部人员进行交叉测试（避免编程人员测试自己的程序）。这一阶段结束后，进入软件生存周期的测试阶段，对软件系统进行各种综合测试。测试工作由专门的测试组完成，测试组设组长一名，负责整个测试的计划、组织工作。测试组的其他成员由具有一定的分析、设计和编程经验的专业人员组成，人数根据具体情况可多可少，一般3～5人为宜。

4．软件测试文件

软件测试文件描述要执行的软件测试及测试的结果。由于软件测试是一个很复杂的过程，同时也是设计软件开发其它一些阶段的工作，对于保证软件的质量和它的运行有着重要意义，必须把对它们的要求、过程及测试结果以正式的文件形式写出。测试文件的编写是测试工作规范化的一个组成部分。
测试文件不只在测试阶段才考虑，它在软件开发的需求分析阶段就开始着手，因为测试文件与用户有着密切的关系。在设计阶段的一些设计方案也应在测试文件中得到反映，以利于设计的检验。测试文件对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍须用到测试文件。

(1)测试文件的类型：

根据测试文件所起的作用不同，通常把测试文件分成两类，即测试计划和测试分析报告。测试计划详细规定测试的要求，包括测试的目的和内容、方法和步骤，以及测试的准则等。由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。不应在着手测试时，才开始考虑测试计划。通常，测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。测试报告用来对测试结果的分析说明，经过测试后，证实了软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见，这些意见即是对软件质量的评价，又是决定该软件能否交付用户使用的依据。由于要反映测试工作的情况，自然要在测试阶段内编写。

(2)测试文件的使用：

测试文件的重要性表现在以下几个方面：
a、验证需求的正确性：测试文件中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求的意图是十分有益的，
b、检验测试资源：测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。如果某个测试计划已经编写出来，但所需资源仍未落实，那就必须及早解决。
c、明确任务的风险：有了测试计划，就可以弄清楚测试可以做什么，不能做什么。了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备。
d、生成测试用例：测试用例的好坏决定着测试工作的效率，选择合适的测试用例是作好测试工作的关键。在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。
e、评价测试结果：测试文件包括测试用例，即若干测试数据及对应的预期测试结果。完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。
f、再测试：测试文件规定的和说明的内容对维护阶段由于各种原因的需求进行再测试时，是非常有用的。
g、决定测试的有效性：完成测试后，把测试结果写入文件，这对分析测试的有效性，甚至整个软件的可用性提供了依据。同时还可以证实有关方面的结论。

(3)测试文件的编制

在软件的需求分析阶段，就开始测试文件的编制工作，各种测试文件的编写应按一定的格式进行。

5．结束语
由于软件开发的规模越来越大，因此软件测试的重要性更加突出。本文主要对软件测试各阶段采用的方法和人员的组织进行了简要介绍。 

软件测试及其支持工具

引言

软件测试作为保证软件质量和可靠性的关键技术手段正日益受到广泛的重视。但如何进行测试,如何提高测试的质量和效率,从而确保软件产品的质量和可靠性,仍是令许多人深感困绕的问题。本文仅根据笔者多年从事软件测试研究与实践的体会,简要介绍软件测试的基本过程,以及一些常用的技术手段、测试策略和准则,并介绍两个很有特色并具有代表性的软件测试支持工具,以期愈来愈多的人在认识到软件测试的重要性的同时,能够进一步了解应如何正确地选择和有效地运用各种各样的测试方法、技术和工具,来提高软件的质量和可靠性。

　

一、软件测试的基本过程

软件测试是一个极为复杂的过程。如图一所示,一个规范化的软件测试过程通常须包括以下基本的测试活动。

·拟定软件测试计划

·编制软件测试大纲

·设计和生成测试用例

·实施测试

·生成软件问题报告

对整个测试过程进行有效的管理实际上,软件测试过程与整个软件开发过程基本上是平行进行的。测试计划早在需求分析阶段即应开始制定,其它相关工作,包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等也应在测试阶段之前进行。充分的准备工作可以有效地克服测试的盲目性,缩短测试周期,提高测试效率,并且起到测试文档与开发文档互查的作用。

此外,软件测试的实施阶段是由一系列的测试周期(Test Cycle)组成的。在每个测试周期中,软件测试工程师将依据预先编制好的测试大纲和准备好的测试用例,对被测软件进行完整的测试。测试与纠错通常是反复交替进行的。当使用专业测试人员时,测试与纠错甚至是平行进行的,从而压缩总的开发时间。更重要的是,由于专业测试人员丰富的测试经验、所采用的系统化的测试方法、全时的投入,特别是独立于开发人员的思维,使得他们能够更有效地发现许多单靠开发人员很难发现的错误和问题。



软件测试大纲是软件测试的依据。它明确详尽地规定了在测试中针对系统的每一项功能或特性所必须完成的基本测试项目和测试完成的标准。无论是自动测试还是手动测试,都必须满足测试大纲的要求。

一般而言,测试用例是指为实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。测试用例控制着软件测试的执行过程,它是对测试大纲中每个测试项目的进一步实例化。已有许多著名的论著总结了设计测试用例的各种规则和策略。从工程实践的角度讲有几条基本准则:

1.测试用例的代表性:能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等;

2.测试结果的可判定性:即测试执行结果的正确性是可判定的或可评估的;

3.测试结果的可再现性:即对同样的测试用例,系统的执行结果应当是相同的。

　

二、测试方法

软件测试的方法和技术是多种多样的。从测试是否针对系统的内部结构和具体实现算法的角度看,通常可分为两类:白盒子方法(结构测试)和黑盒子方法(功能测试)。前者是针对系统内部实现的测试,而后者侧重于系统的外部功能和特性。

　

三、软件测试工具

一些受软件开发人员欢迎的软件测试工具为软件测试提供了强有力的支持。本文将介绍美国Rational公司的著名套装软件SQA和Pure Atria公司极具特色的Purify。

SQA SuiteSQA直接支持对客户/服务器应用软件的测试,它的一个重要特点是可以自动驱动被测程序的运行。SQA可以自动记录和重放程序执行过程,从而实现了对测试进行"复查"的自动化。

由于测试是一个需要反复进行的过程,常常要数十次甚至数百次地重复。因此,这一特性大大地提高了软件"再测试"(Re-Test)和"回归测试"(Regression)的自动化程度,把测试人员从繁杂的、重复性的手工测试中解脱出来,从而显著地提高软件测试效率。

除了这个最基本的自动录放功能外,它还提供了一系列的辅助支持功能,比如,

· 被录制的程序执行过程可以被自动转换成具有良好可读性的高级语言程序,从而使这个测试驱动程序可以由测试人员根据测试需要进行必要的修改,甚至完全用手工方式编制。

·自动记录和分析比较测试的执行结果。不论是简单的正文方式的输出结果,还是任意的图表、声音、动画、图形用户界面(GUI)中的任一构件,都可以根据测试人员的指定被自动记录在测试结果库中,并可对两次测试的结果自动地进行比较,指出其差异部分。此项功能无疑对"自动查找错误"很有帮助。

·调节和设定事件的发生时间和速度。

·基本的测试库管理功能。

此外,SQA还支持软件测试人员进行以下工作:

·制定测试计划和测试大纲,并将这些文档按照自然的树状结构分层地管理起来,并据此控制和驱动整个测试过程。

·不仅能够自动记录各类测试结果,而且对其进行修改,从而使得测试人员可以在程序运行结果尚有许多错误的情况下,通过对所记录下的结果做适当修正来获得理想的"期望结果" ,为测试结果的自动比较奠定基础。

·测试问题报告的记录与管理。

总之,SQA Suite提供了一个比较完整的测试平台,以支持软件测试的各种基本活动,包括测试计划与测试大纲的制定、回归测试的自动化、测试结果的分析比较、软件问题报告的生成与自动分发和控制等。对于许多应用软件的开发无疑是个有力的测试支持工具。

Purify是原PureAtria公司(现已经与美国Rational公司合并,改名为美国Rational公司)于90年代初率先推出的专门用于检测程序中种种内存使用错误的软件工具。几乎所有使用过C语言开发软件的程序员都会有这样的体会,C语言中使用极为灵活的指针给程序员带来了很大便利,但同时也制造了许多的麻烦。由于指针使用不当而引起的错误通常是最难发现的,同时也是最难定位的一类错误。而Purify对多种常见的内存使用错误的检错能力和准确的定位,受到广大软件开发人员的青睐。

Purify可以自动识别出二十多种内存使用错误,包括

·未初始化的局部变量

·未申请的内存

·使用已释放的内存

·数组越界

·内存丢失

·文件描述问题

·栈溢出问题

·栈结构边界错误等

在下面的例子中,暗藏着两个内存使用错误。第一行为指针数组pp申请的空间尺寸不对。这类错误往往不易发现,因为在C语言中,一些"轻微"的内存越界可能被系统所容忍。但这往往是导致更严重错误的根源。例如,可能破坏其它数据区等。最后一行的错误是在释放pp 之前没有释放赋予它的字符串空间,从而把它们"丢失"了。这类错误犹如慢性自杀,它会逐渐消耗掉内存,降低系统的运行效率,直到完全崩溃。而真正的问题在于,这些程序中的"恶性肿瘤"用常规的测试手段和调试工具是极难发现和加以定位的。Purify则在此充分显示了它的强大功效,所到之处,即对所测试过的情况,上述各种常见的内存错误都可以被一一揭露出来,并且准确地指出错误的类型和位置。从而大大地提高了测试和纠错的效率,提高了软件的可靠性。

…/"to get 10 words and print them out"/

if(!(pp=(char**)malloc(10))){

/*Size should be 10*sizeof(char*)*/

printf("Out of memory.\n");

exit(-1);

}

for(i=0;i<10;i++){

scanf("%s",buffer);

if(!(pp[i]=(char*)malloc(strlen(buffer)+1))){

print("Out of Memory.\ n");

exit(-1);

}

strcpy(pp[i],buffer);

printf(pp[i]);

}

free(pp);/*all the strings pointed by it are lost!*/

………

今年以来,原PureAtria公司陆续推出了其系列产品?/FONT>Pure,包括支持内存检测的Purify ,支持路径覆盖的PureCoverage,支持多线程应用程序性能测试的Quantify,以及用以提高测试期间连接编译被测程序效率的PureLink等。Pure系列现已支持C、C++、FORTRAN语言,以及UNIX和Window NT等操作系统,如Sun OS、Solaris 2.3,HP-UX,Windows NT Server以及IBM A/ X等。

　

四、结束语

充分认识软件测试的重要性和复杂性,合理地选择测试方法,有效地组织测试人员和安排测试任务,并且尽量使用软件测试工具增强软件测试的自动化程度,无疑可以帮助软件开发和测试人员大大提高测试效率和软件的质量。

软件测试自动化的一些具体做法

       作者在上篇文章略微谈到了软件测试的自动化，但并没有把本文的内容也一起写进去。原因主要是希望读者先努力考虑在自己的企业或项目内，可以有一些怎么样的做法，而不会先入为主地受到我所写的具体例子的影响而局限了思路。

　　 因为软件测试的工作量很大（40% 到60% 的总开发时间），而又有很大部分适于自动化，因此，测试的改进会对整个开发工作的质量、成本和周期带来非常显著的效果。

　　 首先，谈谈在测试自动化的情况下，带有图形界面的产品的测试用例的设计问题。因为图形界面的输出显示不是很容易做到测试结果自动化比较，所以一般的做法是把图形界面输出的部分单独建立测试用例，以手工运行。而所有非图形输出则可进行自动测试。

　　 下面举出一些测试自动化的例子：

　　 1.测试个案（test case ，或称为测试用例）的生成：

　　 用编程语言或更方便的剧本语言（script language 例如Perl等）写出短小的程序来产生大量的测试输入（包括输入数据与操作指令）。或同时也按一定的逻辑规律产生标准输出。输入与输出的文件名字按规定进行配对，以便控制自动化测试及结果核对的程序易于操作。

　　 这里提到测试个案的命名问题，如果在项目的文档设计中作统一规划的话，软件产品的需求与功能的命名就应该成为后继开发过程的中间产品的命名分类依据。这样，就会为文档管理和配置管理带来很大的方便，使整个产品的开发过程变得更有条理，更符合逻辑。任何新手半途加入到开发工作中也会更容易进入状态。

　　 2.测试的执行写控制：

　　 单元测试或集成测试可能多用单机运行。但对于系统测试或回归测试，就极有可能需要多台机在网络上同时运行。记住一个这样的原则，在开发过程中的任何时候，如果你需要等候测试的运行结果的话，那就是一个缩短开发时间的机会。

　　 对于单个的测试运行，挖潜的机会在测试的设置及开始运行和结果的对比及显示。有时候，需要反复修改程序，重新汇编和重新测试。这样，每一个循环的各种手工键入的设置与指令所花费的时间，加起来就非常可观。如果能利用make或类似的软件工具来帮助，就能节省大量的时间。

　　 对于系统测试或回归测试这类涉及大量测试个案运行的情况，挖潜的的机会除了利用软件工具来实现自动化之外，就是怎样充分利用一切硬件资源。往往，就算是在白天的工作时间内，每台计算机的负荷都没有被充分利用。能够把大量测试个案分配到各台机器上去同时运行，就能节省大量的时间。另外，把大量的系统测试及回归测试安排到夜间及周末运行，更能提高效率。

　　 如果不购买商品化的工具的话，应当遵从正规的软件开发要求来开发出好的软件测试自动化工具。在实践中，许多企业自行开发的自动化工具都是利用一些现成的软件工具再加上自己写的程序而组成的。这些自己开发的工具完全是为本企业量身定做的，因此可用性非常强。同时，也能根据需要随时进行改进，而不必受制于人。当然，这就要求有一定的人力的投入。

　　 在设计软件自动测试工具的时候，路径（path）控制是一个非常重要的功能。理想的使用情况是：这个工具可以在任何一个路径位置上运行，可以到任何路径位置去取得测试用例，同时也可以把测试的结果输出放到任何的路径位置上去。这样的设计，可以使不同的测试运行能够使用同一组测试用例而不至于互相干扰，也可以灵活使用硬盘的空间，并且使备份保存工作易于控制。

　　 同时，软件自动测试工具必须能够有办法方便地选择测试用例库中的全部或部分来运行，也必须能够自由地选择被测试的产品或中间产品采作为测试对象。

　　 3.测试结果与标准输出的对比：

　　 在设计测试用例的时候，必须考虑到怎样才能够易于对此测试结果和标准输出。输出数据量的多少及数据格式对比较的速度有直接影响。而另一方面，也必须考虑到输出数据与测试用例的测试目标的逻辑对应性及易读性，这将会大大有利于分析测试所发现的不吻合，也有利于测试用例的维护。

　　 许多时候，要写一些特殊的软件来执行测试结果与标准输出的对比工作，因为可能有部分的输出内容是不能直接对比的（比如，对运行的日期时间的记录，对运行的路径的记录，以及测试对象的版本数据等），就要用程序进行处理。

　　 4.不吻合的测试结果的分析、分类、记录和通报：

　　 上一点所谈到的，用于对测试结果与标准输出进行对比的特殊软件，往往也同时担任对不吻合的测试结果进行分析、分类、记录和通报的任务。

　　 “分析”是找出不吻合的地方并指出错误的可能起因。“分类”包括各种统计上的分项，例如，对应的源程序的位置，错误的严重级别（提示、警告、非失效性错误、失效性错误；或别的分类方法），新发现的还是已有记录的错误，等等。“记录”，是按分类存档。“通报”，是主动地对测试的运行者及测试用例的“负责人”通报出错的信息。

　　 这里提到测试用例的“负责人”的概念。是用以指定一个测试用例运行时发现的缺陷，由哪一个开发人员负责分析（有时是另外的开发人员引进的缺陷而导致的错误）及修复。在设立测试用例库时，各用例均应有指定的负责人。

　　 最直接的通报方法是由自动测试软件发出电子邮件给测试运行者及测试用例负责人。邮件内容的详细程度可根据需要灵活决定。

　　 5.总测试状况的统计，报表的产生：

　　 这些都是自动测试工具所应有的功能。目的是提高过程管理的质量，同时节省用于产生统计数据的时间。

　　 产生出来的统计报表，最好是存放到一个约定的路径位置，以便任何有关人员都知道怎样查阅。同时，可按需要用电子邮件向适当的对象（如项目经理，测试经理和质量保证经理）寄出统计报表。

　　 6.自动测试与开发中产品每日构建（build ）的配合：

　　 自动测试应该是整个开发过程中的一个有机部分。自动测试要依靠配置管理来提供良好的运行的环境，同时它必须要与开发中的软件的构建紧密配合。

　　 在开发中的产品达到一定程度的时候，就应该开始进行每日构建和测试。这种做法能使软件的开发状态得到频繁的更新，以及及早发现设计和集成的缺陷。

　　 为了充分利用时间与设备资源，下班之后进行自动的软件构建，紧接着进行自动测试（这里多数指的是系统测试或回归测试），是一个非常行之有效的方法。如果安排得好，到第二天上班时，测试结果就已经在各人的电子邮箱里面面了，等待着新的一天的开发工作。

　　 总结：以上只是根据经验和体会举了一些软件测试自动化的做法。

　　 由于企业开发环境的不同、产品的不同，测试自动化的实施方法会有很大的差异。希望大家从这些具体例子中掌握到这项工作的基本精神及思路，然后结合自己的情况，大胆创新。同时千万不要忘记向大家介绍好经验。祝大家测试愉快

测试、测试、测试

--软件测试的理论和实践

　

　

题记：测试是交付成功的优质的产品的保证

　

我们每个人，不会都是软件测试人员，但都是某些软件的用户。缺省或默认情况下，用户都会觉得买到的软件是没有问题的，一般不会去想这样的软件可能会有问题，用户只要使用这些软件来解决他们需要解决的问题就可以了。当他们发现问题的时候，甚至会感到震惊。存在的问题很多都和测试的成效有关系，一般的软件产品存在的问题确实比较少，但我觉得即使是以前买的正版的金山快译2000都有着一些显而易见的bug。如果测试不充分，那么这些问题会潜伏在软件中，等到用户发现以后，再有开发人员进行维护，改正错误的费用一般是开发阶段的40倍到60倍。

人们对测试存在着一些误区，例如：
1 测试是想象到可能出现的问题，然后试图验证这些问题。
实际上能想象到的只是一部分的情况，随意性太大，还要取决于开发人员的经验，对业务的熟悉程度和他想象到的程度。
2 让时间有富裕的员工去做一些测试
表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。
3 测试是相对简单的工作。
实际上并非如此，要真正做好一件事都不容易。测试也有很多相关技术和工具。而对测试的轻视问题，也许要通过痛苦的经历和结果才可能确切体会到。很多专家都在对测试的理论进行深入的探讨和研究。

测试的基本知识

让我们一起快速过一遍：

什么是软件测试：在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
测试的目标：以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量。
从测试的类型来看，测试分为2种：黑盒测试和白盒测试。
黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。
白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。
测试用例由测试输入数据以及与之对应的输出结果组成。测试用例设计的好坏直接决定了测试的效果和结果。
从测试实际的前后过程来看，软件测试上是由一系列的不同测试所组成，这些软件测试的步骤分为：单元测试、组装测试（集成测试）、确认测试和系统测试。软件开发的过程是自顶向下的，测试则正好相反，以上这些过程就是自底向上，逐步集成的。

单元测试（模块测试）：针对每个模块进行的测试，可从程序的内部结构出发设计测试用例，多个模块可以平行地对立地测试。通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。
集成测试：在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。
确认测试：验证软件的功能和性能及其它特性是否与用户的要求一致。
系统测试：将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试。

测试工作的文档主要有：测试计划、测试模型和用例设计或规格说明、测试分析报告等。从软件工程上说，这是属于软件配置的一部分。（我不知道，如果什么报告都没有，只是不断地摆弄执行程序，看到错误和问题就记下来，算不算真正的测试？）

测试需要一定的技术和工具

在用例设计过程中，可以考虑到很多方面，并且也有很多的指导方法和技术。

黑盒测试用例设计包括：

等价类划分：划分等价类--确立测试用例--设计用例
边界值分析：通过分析，考虑如何确立边界情况
错误推测法：靠经验和直觉来推测程序中可能存在的各种错误，从而有针对性地编写用例。可以列举出可能的错误和可能发生错误的地方，然后选择用例。
因果图：通过画因果图，在图上标明约束和限制，转换成判定表，然后设计测试用例。这适合于检查程序输入条件的各种组合情况。

功能图FD：通过形式化地表示程序的功能说明，并机械地生成功能图的测试用例。

白盒测试用例设计包括：

1 逻辑覆盖，以程序内在逻辑结构为基础的测试，包括以下5种类型：

1.1 语句覆盖：每一条可执行语句至少覆盖一次；
1.2 判定覆盖（分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；
1.3 条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次；
1.4 判定-条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次；
1.5 条件组合测试：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值至少执行一次；
1.6 路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。

2 基本路径测试

在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下5个方面：
2.1 程序的控制流图：描述程序控制流的一种图示方法。
2.2 程序环境复杂性：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界。
2.3 导出测试用例
2.4 准备测试用例，确保基本路径集中的每一条路径的执行
2.5 图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。

程序的静态分析方法：

1 生成各种引用表、静态错误分析

2 人工测试：桌前检查、代码评审等

3 软件测试工具：包括静态分析工具、动态测试工具、测试数据自动化生成工具、模块测试台、测试合成环境

3.1 静态分析工具：语言程序的预处理器、数据库工具、错误分析器和报告生成器。直接扫描所测试的正文，对程序的数据流和控制流进行分析，然后送出测试报告。

3.2 动态测试工具：通过选择适当的测试用例，实际运行所测程序，比较实际运行结果和预期结果，发现错误。

3.3 测试数据自动化生成工具：包括路径测试数据生成程序、随机测试数据生成程序以及根据数据规格说明生成测试数据

3.4 模块测试台是一种专门的测试用例描述语言，负责将输入数据传送到所测试模块中，然后将实际输出结果与在描述测试用例的语言中所表述的期望结果进行比较，发现错误。另外，也包括其它的功能：语句跟踪、动态断句、覆盖度量、用户自定义符号表、内容表和输出格式。

3.5 测试合成环境：包括环境模拟程序，代码检查程序，测试文档生成程序，测试执行严整程序，输出比较程序，程序正确性证明程序等，以及各种调试工具。而且还有集成系统，集成了多种工具，如SADAT、Microsoft Test for Windows和PureArtria等。

　

***********************************************************

　

测试的管理

作为项目或产品开发的一个必要的组成部分，需要良好的组织和管理。使用软件质量规范，编写和实现测试用例和模型，可以有效地组织测试。

一般的测试工作过程也可以是：计划-->配置（必要的软硬件资源下）-->开发（构造或配置测试工具、创建测试套件和测试方案库、准备适当的报告工具并记录测试系统如何运转）-->测试执行（进行测试、记录测试条件和问题，报告结果）。

测试管理也可以从测试经理和测试小组2个方面去看：

测试经理要管理好团队，很多人认为测试是枯燥乏味的事情，而且似乎低级的事情，所以测试经理应该不断地激励小组成员，为他们争取利益。在时间进度上保证稳步前进。就象赛跑，一开始就加班加点，只会导致极限的过早到来。
作为测试经理，应该有足够的质量意识。评价质量风险的方法是“失败模式和效果分析”(Failure Mode  and Effect Analysis, FMEA)。这种方法可以允许您在特定的质量风险和结果上映射需求、规范，以及项目小组假设。然后，按照风险级别进行分类，并按序排列。
实际上如果能得到充分的资源已是很困难的了，能用好临时的测试人员也已经不错了。一般企业的主管和技术经理都并不怎么真正重视测试工作的意义和价值。也许他们认为临时的投入一次性的强力测试足以发现绝大部分问题，而实际上这对产品的长远发展，以及质量改进都没有太大好处。

测试过程中软件功能可能进行调整和变化，测试发现问题也会导致变化，需要重新的测试。对这些变更也需要进行管理。
另外，由于上层管理部门的不重视，必须想办法与之进行清楚而有效的沟通；同开发部门的沟通也非常重要，因为开发和测试在性质上是有些对立的，很容易在相互之间产生一些不必要的矛盾。和开发部门不同的是，一般质量或测试部门和市场或销售部门的立场倒是比较一致的，如果双方都认为高质量的产品是市场战略中重要的品牌战略，彻底的测试对于达到这样的目标来说意义重大。因此，有必要和市场部门保持协作和交流。

测试经理可以经常问自己一些问题：

计划做哪些测试？实际完成了哪些测试？使用了多少用例？其中多少没有通过？管理部门是否有足够的支持？他们是否向你要过测试报告？开发部门的联络是否及时？等等。如果你是测试管理人员，应该可以想到更多的问题。

测试小组：

测试小组有多大的规模，一般取决于项目规模、测试人员与开发人员的比例、项目经理对质量保证的认识和期望等，也取决于你的准确的测试计划。
对一些项目来说，最好是在开始阶段就有测试人员有所介入。

如本文一开始所提到的，在测试小组中测试人员必须具备的素质包括：有效的坦率真诚的交流的能力、清晰简明的表达能力、一定的好奇心（但不至于太强，以至于花太多精力去探究一个微小的问题），不应害怕提出尖锐问题引起麻烦，一定的责任心，
注意力能够高度集中，是职业悲观主义者（但不是抱怨和憎恶）。

以下是一些测试的方法和基本工具：

测试方案、测试模型和测试用例
测试就象是做实验一样，实验对于象我这样的理工科毕业生来说真是太熟悉不过了。做实验之前必然有实验的方案、内容和步骤，测试似乎也是同样的。另外，基于测试用例的测试和常见的随机性的测来测去也是完全不同的，尽管习惯于随机性测试的人，如果注意力集中的话，他的头脑里也是有一些测试用例的。

关于测试实验室，进行测试工作首先要争取到尽可能好的环境。如果可能，应该建立测试实验室，实验室包括必要的装备、工具软件（包括测试工具）和各种操作系统平台，保持实验室的实用、整洁，避免他人干扰甚至破坏测试环境。

关于测试跟踪软件，制作一个简单的测试问题跟踪软件，记录测试的结果，将测试发现的问题分类，并对测试发现的问题和模块、开发人员进行关联，有助于分析问题，并可有效记录测试的结果，形成测试报告，并从中找出一些规律性的东西来。因此测试问题跟踪软件还是有一定的价值的。

关于测试自动化，有一定的风险。对一个稳定的系统，甚至可以自己开发自动化软件，而对于正处于快速变形中的软件开发过程，接口、主要功能和支持环境在发展变化中。为测试配置环境也要付出很多的时间。

以下是关于测试的一些技巧和经验：

在制定测试计划的时候，就要考虑到测试的风险，并抉择要执行哪些测试，并放弃哪些测试；测试计划的评审应该让开发人员参与；
测试模型的制作应该尽可能贴近用户，或者站在用户的使用立场上来观测软件，此时应该能发现更多的问题。

由于测试发现问题，在解决问题后还要重新测试，因此测试的时间可能会比实际更长一些

识别和注意少数重要的方面，而忽略多数次要的方面，有时候少数的问题足以致命，这些问题将是软件测试结果中重要性最高的错误。

错误的定位有时是很难的，要找出必然发生的前因后果，而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。

对错误的描述，应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解，其后果是可以想见的。

有时有经验的测试人员凭借直觉就可以发现一些问题，这可称为“错误猜测”。

测试人员容易犯2种错误：一是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种象“狼来了”一样的效果；二是测试人员将错误的严重性或优先级定得过低，从而产生“测试逃逸”，这样会造成产品质量的风险。以上两种错误应该尽量避免。

　

最后，我忽然想，测试实际上可以覆盖到硬件，甚至非计算机产品的测试，也许可以相互借鉴。

还有一种很奇特的感想，这种感想使我反而有些困惑不清了。我发现对测试来说，理论和实践的距离好象非常遥远，我先看了一本软件工程的书，然后写下了前面的一半内容，然后我又匆匆翻看了一本美国人的书，叫做《测试流程管理》，然后整理出了本文后一半的内容，该书中有着比本文多得多的各方面的实践经验。歌德说过，理论是苍白的，生命之树常青。我稍稍改变一下，就变成了：理论是苍白的，实践之树常青。也许测试是一种实践性很强的工作，大学教授们一般也不可能热衷于参加测试工作吧。

测试是一件有趣的事情？真的吗？

测试。讨厌！我一直讨厌做测试。测试（单元测试和功能测试）是防碍“真正”工作的事情。每个人都确信自己的代码是完美的，不是吗？在确实需要更改代码的极少数事件中，注释编写得如此之好，以致每个人都能领会其中的含义。我需要提高（或许还需要作一些咨询）。

在过去的几年里，单元测试已成为我编写软件的核心环节，多亏了一种称为极限编程 (XP) 的简便编程方法（请参阅参考资源）。这种方法要求我为添加的每个函数编写单元测试，并且要维护这些测试。如果单元测试失败，我就无法整合任何代码。随着代码库的不断增大，这些测试将使开发人员能够很有把握地完成更改。

起初，我认为有了单元测试，就没必要再进行功能测试。噢，又错了。功能测试与单元测试相差甚远。我花了很长一段时间理解二者的区别，以及如何结合使用两者来改进开发过程。

本文探究单元测试与功能测试之间的区别。并概述了在日常开发中使用这两种测试的方法。

测试与开发过程
测试对于开发人员极为重要，您必须在开发过程中不断进行测试。测试不应该只属于开发周期的某个特定阶段。它绝不应该是您将系统交给客户前要完成的最后一项任务。如何才能知道您何时就完成了所有任务呢？如何才能知道对一个小错误的修正是否破坏了系统的主要功能呢？目前想像中的系统如何才能演化为实实在在的系统呢？单元测试和功能测试都应该是开发过程中不可分割的一部分。

单元测试应成为您编写代码的核心环节，当您所做的项目时限很紧并且您希望控制开发进度时尤其如此。由于单元测试是如此重要，所以您应该先编写测试，再编写代码。

一套适当的单元测试具有以下功能：

• 说明可能的最实用设计
• 提供类文档的最佳格式
• 确定一个类何时完成
• 增强开发人员对代码的信心
• 作为快速重构的基础

　

单元测试创建随系统自然发展的设计文档。再读一遍上一句话。文档随系统自然发展，这是软件开发的“圣杯”。有什么方法比通过提供一个用例编码集来记录一个类效果更好呢？那就是单元测试：一系列记录类所做工作的用例代码，提供输出控制。这样，由于单元测试必须通过，所以设计文档总是最新的。

您应该首先编写测试，然后再编写代码。这样就为要测试的类提供了一种设计，这种设计使您每一时刻都只需集中考虑一小块代码。这种做法也使设计变得不再复杂。您没有试图为以后着想而实现一些不必要的功能。先编写测试还使您知道该类何时完成。一旦通过所有测试，任务也就完成了。

最后，单元测试可使您高度自信，这又会转化为开发人员的满意度。如果只要更改代码即运行单元测试，您立即就能发现您所做的更改是否对系统造成了破坏。

功能测试比单元测试更重要，因为功能测试将验证系统是否可以发行了。功能测试以一种有用的方式对您的工作系统进行说明。一套适当的功能测试具有以下功能：

• 以有效方式捕获用户需求
• 增强小组（用户和开发人员）在系统满足用户需求方面的信心

　

功能测试以有效方式捕获用户需求。传统开发通过用例来捕获需求。通常，人们讨论用例并花很长时间对它们进行细化。他们最后所得到的只是一纸空文。功能测试就像自验证式用例。极限编程方法可解释这一概念。XP Stories 将成为未来用户与开发人员进行沟通的协议。功能测试便是这种沟通的结果。未经功能测试的 Stories 不可能很完善。

功能测试填补单元测试留下的空白，并可增强小组对代码的信心。单元测试漏掉许多错误。尽管它可以提供您所需的全部代码，但它可能无法提供您所需的全部系统功能。功能测试将暴露单元测试遗漏的问题。一套适当的自动化功能测试也不可能捕捉到每个错误，但是它能比最好的单一单元测试捕捉更多的错误。

单元测试与功能测试
单元测试向开发人员表明代码正确执行操作；而功能测试向开发人员表明代码执行正确的操作。

单元测试
单元测试是从程序员的角度编写的。它确保类的某个特定方法成功执行一系列特定的任务。每个测试都确保只要给定输入，方法将输出预期的结果。

如果没有测试框架，编写一套可维护的自动化单元测试几乎是不可能的。在开始编写测试之前，请选择一个小组公认的框架。您将经常性地使用这个框架，因此您最好对它有点好感。极限编程网站提供了几个单元测试框架（请参阅参考资源）。我最熟悉的框架是 JUnit，它专门用来测试 Java 代码。

功能测试
功能测试是从用户的角度编写的。这种测试确保系统执行用户期望它执行的工作。

很多时候，系统开发好比建筑房屋。尽管这种类比不很恰当，但为了理解单元测试与功能测试的区别，我们可以扩充这种类比。单元测试好比房屋建筑现场的建筑监理员。他关心房屋的各个内部系统，如地基、构架、供电系统和管道设备等。他确保（测试）房屋每一部分的工作都安全、正常，即符合建筑说明。这种情况下，功能测试类似于视察同一建筑现场的房主。他假定内部系统将正常运作，并假定建筑监理员在执行其任务。房主关心的是住在这所房子里将会怎样。他关心房子的外观如何，各个房间的大小是否合适，房子能否满足家庭的需要，以及窗户的位置是否有利于采光。房主对房子执行功能测试。他从用户的角度考虑问题。建筑监理员对房子执行单元测试。他从建筑工人的角度考虑问题。

就像单元测试一样，如果没有测试框架，编写一套可维护的自动化功能测试实际上是不可能的。JUnit 非常适合编写单元测试；但是，当试图编写功能测试时，它就显得力不从心了。就功能测试而言，没有与 JUnit 相当的框架。也有几种用于功能测试的产品，但我从来没见过它们应用于生产环境。如果找不到满足您的需要的框架，您就必须创建一个。

无论我们多么擅长于构建手头的项目，也不管我们正在创建的系统多么灵活，如果我们的产品不合用，那我们就是白费时间。因此，功能测试是开发最重要的部分。

由于两种测试都必不可少，您就需要了解编写它们应遵循的原则。

如何编写单元测试
刚开始编写单元测试时很容易恢心。最佳的入手方式就是为新代码创建单元测试。（尽管为现有代码创建单元测试比较困难，但并非无法实现）。首先从新代码着手，待您习惯了整个过程以后，再针对现有代码创建测试程序。

如上文所述，应该首先编写单元测试，然后再编写这些单元测试要测试的代码。如何为尚不存在的代码编写测试呢？问得非常好。掌握这一方法需要 90% 的思维加 10% 的技术。我的意思是，您只需假定您正在为其编写测试的类已经存在。接下来的任务就是编写测试。起初会犯很多语法错误，但您先别管它。这一步您要做的就是定义该类要实现的接口。下一步就是运行您的单元测试，修正语法错误（即，编写一个类，使它实现您的测试刚定义的接口），并再次运行测试。重复这一过程，每次仅编写修正故障的代码。运行测试，直到测试全部通过为止。一旦通过全部单元测试，代码也就完成了。

一般而言，类的每个公共方法都应有一个单元测试。但是，功能简单的方法（例如，getter 方法和 setter 方法）不需要单元测试，除非它们以某种特别的方式进行获取和设置。应该遵循下面这条很好的原则：即只要您认为有必要对代码中的某个行为加注，就编写一个单元测试。如果您像其他许多程序员一样不喜欢为代码加注，则单元测试是记录代码行为的一种方法。

将单元测试与被测试的相关类放在同一个包内。这种组织方式使每个单元测试都能访问被测试类中带有 package 或 protected 访问修饰符的方法和引用变量。

在单元测试中避免使用域对象。域对象是特定于某个应用程序的对象。例如，一个电子表格应用程序可能包含一个注册对象；这个注册对象就是一个域对象。如果您有一个已知这些域对象的类，则在测试中完全可以使用这些对象。但是如果您有一个根本不使用这些域对象的类，在测试中就不要将这些对象联系到该类上。应该避免这种情形完全是因为代码重用。为某一项目创建的类经常要用于其他项目。重用这些类可能很简单。但是，如果对重用类的测试中用到了另一个项目的域对象，则使测试能够正常运行这一工作就会相当耗时。通常情况下，这个测试将被删除或重写。

这些机制为您提供很好的帮助，但是如果您不运行这些测试，一套综合的单元测试就变得一文不值。尽早运行测试通常使您在任何时候都对代码充满信心。您将随着项目进展不断添加功能。运行这些测试将会通知您刚刚实现的新功能是否对系统造成了破坏。

在您掌握了编写单元测试的技巧之后，我们再来看看现有代码。为现有代码编写测试可能是个挑战。不要为测试而测试。当您发现有必要对一个未经很好测试（或者根本就没有测试）的类进行修改时，请“随时”编写测试。现在是添加测试的时候了。像往常那样，该类的单元测试应该捕获其每个方法的功能。找出应该进行哪些测试的最容易的方法之一是：查看现有代码中的注释。任何注释都应在单元测试内捕获。将位于方法开头、说明该方法所起作用的注释块翻译为单元测试。

如何编写功能测试
尽管功能测试很重要，但它却没有受到足够的重视。多数项目都有单独的一个组来做功能测试。通常有一大群人不断地与系统交互，以确定系统是否正确工作。这种观念和设置专门的功能测试小组的做法很不明智。

对功能测试的处理与对单元测试的处理不应该有太大的区别。只要您编写的代码用来产生要求用户与之交互的组件（如对话框），就要编写测试，但实际上编写测试要在编写代码之前进行。请与用户一起编写获取用户需求的功能测试。无论何时开始一项新任务，都要在功能测试框架中描述此任务。您的开发工作将继续向前发展，当添加新代码时，请执行单元测试。当所有的单元测试都结束以后，运行最初的功能测试，看看它是否能够通过，或者是否需要修改。

从理论上讲，功能测试小组的概念该消失了。开发人员应与用户共同编写功能测试。在对系统所做的一系列功能测试结束之后，开发组中负责功能测试的成员就应该用初始测试的各种变化形式来轰击系统。

单元测试与功能测试的界限
通常单元测试与功能测试之间并没有明确的界限。老实说，有时我也不清楚这个界限在什么位置。在编写单元测试时，我根据以下原则来确定当前编写的单元测试实际上是否是功能测试：

• 如果单元测试跨越类边界，则它就可能是功能测试。
  
  
• 如果单元测试变得很复杂，则它可能是功能测试。
  
  
• 如果单元测试很脆弱（也就是说，虽然它是一个有效测试，但它必须不断改变以处理不同的用户组合），则它可能是功能测试。
  
  
• 如果编写单元测试比编写其所测试的代码更难，则它可能是功能测试。

　

请注意“它可能是功能测试”这一措辞。本文无法提供硬性而快速的规则。单元测试与功能测试中之间有一个界限，但界限的具体位置要由您来确定。您用单元测试用得越熟练，某个特定测试是单元测试还是功能测试的界限就越明显。

小结
单元测试是从开发人员的角度出发编写的，并且关注的是所测试的类的特定方法。当编写单元测试时，请使用以下这些原则：

• 首先编写单元测试，然后再编写要测试的类代码
  
  
• 在单元测试中捕获代码注释。
  
  
• 测试所有执行“令人感兴趣的”功能（即，不是 getter 和 setter，除非它们以某种独特的方式执行获取和设置操作）的公共方法。
  
  
• 将每个测试实例与它要测试的类放在同一个包内，以获得对包成员和保护成员的访问权。
  
  
• 避免在单元测试中使用特定于域的对象。

　

功能测试是从用户的角度出发编写的，并且关注用户感兴趣的系统行为。找一个优秀的功能测试框架，或者开发一个测试框架，并使用这些功能测试识别用户的真实需求。这样，功能测试人员即可获得一种自动化工具以及使用这一工具的着手点。

使单元测试和功能测试成为您开发过程中的中心环节。如果您这样做了，您将对系统的运行及扩展充满信心。如果您没有这样做，您对系统就没有十足的把握。测试可能不那么有趣，但是在开发过程中进行单元测试和功能测试使开发变得相当有趣。

参考资源

"Incremental development with Ant and JUnit"（developerWorks，2000 年 11 月）探究单元测试的好处，尤其是使用 Ant 和 JUnit 框架。逐渐熟悉 极限编程方法。从极限编程网站下载各种 单元测试框架。 "Incremental development with Ant and JUnit"（developerWorks，2000 年 11 月）探究单元测试的好处，尤其是使用 Ant 和 JUnit 框架。 逐渐熟悉 极限编程方法。从极限编程网站下载各种 单元测试框架。 "Incremental development with Ant and JUnit"（developerWorks，2000 年 11 月）探究单元测试的好处，尤其是使用 Ant 和 JUnit 框架。逐渐熟悉 极限编程方法。从极限编程网站下载各种 单元测试框架。

软件测试应遵循的八条原则 

    软件测试，从不同的角度出发会派生出两种不同的测试原则。从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷；从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求。

　　中国软件评测中心的测试原则，就是从用户和开发者的角度出发进行软件产品测试的。

　　为了达到上述的原则，需要注意以下几点：

　　1.应当把“尽早和不断地测试”作为开发者的座右铭。

　　2.程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

　　3.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

　　4.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

　　5.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

　　6.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

　　7.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

　　8.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。