黑盒测试：不基于内部设计和代码的任何知识，而是基于需求和功能性。

　　白盒测试：基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。

　　单元测试：最微小规模的测试；以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。

　　累积综合测试：当一个新功能增加后，对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作，或当需要时那些测试驱动器已被开发出来; 这种测试可由程序员或测试员来做。

　　集成测试：一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。

　　功能测试：用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。

　　系统测试：基于系统整体需求说明书的黑盒类测试；应覆盖系统所有联合的部件。

　　端到端测试：类似于系统测试；测试级的“宏大”的端点；涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用网络通讯，或与外部硬件、应用系统或适当的系统对话。

　　健全测试：典型地是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。

　　衰竭测试：软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

　　接受测试：基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。

　　负载测试：测试一个应用在重负荷下的表现，例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。

　　强迫测试：在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。

　　性能测试：在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。

　　可用性测试：对“用户友好性”的测试。显然这是主观的，且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

　　安装/卸载测试：对软件的全部、部分或升级安装/卸载处理过程的测试。

　　恢复测试：测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。

　　安全测试：测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。

　　兼容测试：测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。

　　比较测试：与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。

　　Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

　　Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

＜2＞进一步扩展

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

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下试图运行中文版的程序），出现现象是否正常 。I'm not very sure about this. ( commented by Sherry)
本地化测试还要考虑：
当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度。
要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。
要考虑各个国家的民族习惯，比如龙在美国中被理解邪恶的象征，但翻译到中国，中国人认为是吉祥的象征。

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设计文档测试

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

软件测试的方法和技术是多种多样的。 　　对于软件测试技术，可以从不同的角度加以分类： 　　从是否需要执行被测软测试和动态测试。 　　从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试； 1、黑盒测试 　　黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 2、白盒测试 　　白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。 　　“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。 软件人员使用白盒测试方法，主要想对程序模块进行如下的检查： – 对程序模块的所有独立的执行路径至少测试一次； – 对所有的逻辑判定，取 “ 真 ” 与取 “ 假 ” 的两种情况都至少测试一次； – 在循环的边界和运行界限内执行循环体； – 测试内部数据结构的有效性，等。 具体包含的逻辑覆盖有： – 语句覆盖 – 判定覆盖 – 条件覆盖 – 判定－条件覆盖 – 条件组合覆盖 – 路径覆盖。 =====引用　天网====== “我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？” 答案在于软件自身的缺陷： 1、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。 2、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。 3、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。 正如Beizer所说的：“错误潜伏在角落里，聚集在边界上”，而白盒测试更可能发现它。 3. 灰盒测试 灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。 灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。 灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。 灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。 4．ALAC(Act-like-a-customer)测试

ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。

1、程序测试的过程具有破坏性

　　人类的活动具有高度的目的性，建立适当的目标具有重要的心理作用。如果我们的目的是要证明程序中没有错误，那我们就会不自觉地朝这个方向去做；也就是说，我们会倾向于挑选那些使程序出错的可能性较小的测试数据。另一方面，如果我们的目标是要证明程序中有错，那就会选择一些易于发现程序所含错误的测试数据。而后一种态度会比前者给程序增添更多的价值。

　　测试的定义意味着程序测试的过程是具有破坏性的，其程度甚至达到了不可容忍的地步。社会上大多数人的人生观是建设性的，而不是破坏性的。人们倾向于创造一个物品，而不是轻易毁坏—个物品。因此，程序坏—个物品。因此，程序测试的破坏性的定义使人们对程序测试工作望而生畏。程序测试定义还隐含着如何设计测试情况（测过数据），以及应该由谁和不应由谁来测试一个给定程序等等观点。 心理学研究还告诉我们，当人在干一件已经知道是不合适的或不可能做到的事时，往往做得不好。例如：如果让一个人在15分钟解出一个刊登在星期曰《纽约时报》上的交叉填字字谜，10分钟后我们会看到这人几乎没一点进展，因为他会感到实际上不可能做到而放弃自已的努力。然而，如果我们要求花4小时解出这题，那也许就会看到他在开头的10分钟内有较大的进展了。把程序测试定义为在程序中找出错误的过程，就使测试成了可以做到的任务，从而克服了心理上存在的问题。

　　另一个令人烦躁的问题是即使程序完成了预期要求，仍可能含有错误。也就是说，如果程序不按要求工作，它显然有错，但是如果程序做了不要它做的事，它也有错。

2、程序员应避免测试自己的程序

　　开发者被指定测试自己的代码是一件很糟糕的事。开发和测试生来就是不同的活动。开发是创造或者建立什么东西的行为，一个模块或者整个系统。而测试的唯一目的是证明一个模块或者系统工作不正常。这两个活动之间有着本质的矛盾。一个人不太可能把两个截然对立的角色都扮演的很好。基于这个想法，应该限制开发者在测试中的参与。给他们比较合适的任务是进行有可能的最低层的测试--单元测试。不同当一个程序员在完成了设计，编写程序的建设性工作后，要一夜之间突然改变他的观点，设法对程序形成一个完全否定的态度，那是非常困难的。许多户主都知道，揭掉糊墙纸（破坏性过程〉是不容易的，若糊墙纸原先是由他而不是别人贴上的，他几平会感到难以忍受的沮丧。所以，大部分程序员都由于不能使自己进入必要的精神状态（不是抱着要揭露出自己程序中错误的态度），因而不能有效地测试自己的程序。 除了这个心理学问题之外，还有一个重要的问题：程序中可能包含由于程序员对问题的叙述或说明的误解而产生的错误。如果是这种情况，当程序员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。

　　再者，可以把测试看做是对一篇论文或—本书作校对，或与写评论相类似的工作。正如许多作者所知，校对或批评自己的著作是非常困难的。也就是说，在自已的工作中找出缺陷往往是人的心理状态所不容的。

　　以上看法并不意味着程序员不可能测试自已的程序。不过相比之下如果由另外—些人来进行程序测试，就会更有效、更成功。注意：这个论断并不适用于纠错（改正已知错误），由原来程序的作者纠错肯定效率更高。 3、程库设计机构不应测试自己的程序

　　在许多意义上来说，一项工程或一程序设计机构是个有生命的有机体，它同样有心理学问题。再者，在大多数情况下，人们都是以在给定日期内，以一定代价编制程序的能力来衡量程序设计机构和项目管理人员的。这祥做的一个理由是时间和成本指标便于衡量，而程序的可靠性却很难度量。要程序设计机构在测试自己的程序时持客观态度是困难的，因为如果用正确的定义看待测试，就不大可能按预定计划完成测试也不大可能把耗费的代价限制在要求的范围以内。

　　软件生产的三个最重要的因素是：质量、进度和费用。

　　计算技术的进步，意味着在经济领域中信息系统更新的速度更快。新的硬件技术的发展，均会使软件过时，系统交付使用的时间变得日益重要，新产品在其性能和费用上被其他产品取代之前的推销时间，即市场窗口就已经缩小了。

　　由于费用和进度的限制，要开发一种高质量、快速交付和低成本的软件产品变得越来越困难，也就是说要同时达到三个目标是困难的。因此在软件产品的开发中就要权衡它们之间的关系，使软件的特性能满足用户的要求，这意味着软件产品特性的度量和预计是必要的。

　　软件测试由独立测试机构承担有许多好处。独立测试是指软件测试工作由在经济上和管理上独立于开发机构的组织进行。独立测试可以避免软件开发者测试自己开发的软件，由于心理学上的问题，软件开发者难以客观、有效地测试自己的软件，而找出那些因为对问题的误解而产生的错误就更加困难。独立测试还可以避免软件开发机构测试自己的软件，软件产品的开发过程受到时间、成本和质量三者的制约，时间和成本指标便于衡量，而质量却很难度量，因此在软件开发过程中，当时间、成本和质量三者发生矛盾时，质量最容易被忽视，如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试过程受到干扰。

　　采用独立测试方式，无论在技术上还是管理上，对提高软件测试的有效性都具有重要意义。

①、客观性

　　对软件测试和软件中的错误抱着客观的态度，这种客观的态度可以解决测试中的心理学问题，既能够以揭露软件中错误的态度工作，也能不受发现的错误的影响。经济上的独立性使其工作有更充分的条件按测试要求去完成。

②、专业性

　　独立测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效用的必然途径。

③、权威性

　　由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，由专业化的独立测试机构的评价，更客观、公正和具有权威性。

④、资源有保证

　　独立测试机构的主要任务是进行独立测试工作，这使得测试工作在经费、人力和计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性，可以避免开发单位侧重软件开发而对测试工作产生不利的影响。

排错（即调试）与成功的测试形影相随。测试成功的标志是发现了错误。根据错误迹象确定错误的原因和准确位置，并加以改正的主要依靠排错技术。 １． 排错过程 　　如下图所示，排错过程开始于一个测试用例的执行，若测试结果与期望结果有出入，即出现了错误征兆，排错过程首先要找出错误原因，然后对错误进行修正。因此排错过程有两种可能，一是找到了错误原因并纠正了错误，另一种可能是错误原因不明，排错人员只得做某种推测，然后再设计测试用例证实这种推测，若一次推测失败，再做第二次推测，直到发现并纠正了错误。

排错是一个相当艰苦的过程，究其原因除了开发人员心理方面的障碍外，还因为隐藏在程序中的错误具有下列特殊的性质： 　　（1） 错误的外部征兆远离引起错误的内部原因，对于高度耦合的程序结构此类现象更为严重； 　　（2） 纠正一个错误造成了另一错误现象（暂时）的消失； 　　（3） 某些错误征兆只是假象； 　　（4） 因操作人员一时疏忽造成的某些错误征兆不易追踪； 　　（5） 错误是由于风时而不是程序引起的； 　　（6） 输入条件难以精确地再构造（例如，某些实时应用的输入次序不确定）； 　　（7） 错误征兆时有时无，此现象对嵌入式系统尤其普遍； 　　（8） 错误是由于把任务分布在若干台不同处理机上运行而造成的。 　　在软件排错过程中，可能遇到大大小小、形形色色的问题，随着问题的增多，排错人员的压力也随之增大，过分地紧张致使开发人员在排除一个问题的同时又引入更多的新问题。 　　尽管排错不是一门好学的技术（有时人们更愿意称之为艺术），但还是有若干行之有效的方法和策略，下面介绍几种排错方法。 ２． 排错方法 　　无论采用哪种排错方法，目标只有一个，即发现并排除引起错误的原因，这要求排错人员能把直观想象与系统评估很好的结合起来。 　　常用的排错策略分为三类： 　　① 原始类（brute force） 　　② 回溯类（backtracking） 　　③ 排除类（cause eliminations） 　　原始类排错方法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它，主要思想是"通过计算机找错"。例如输出存储器、寄存器的内容，在程序安排若干输出语句等，凭借大量的现场信息，从中找到出错的线索，虽然最终也能成功，但难免要耗费大量的时间和精力。 　　回溯法能成功地用于程序的排错。方法是从出现错误征兆处开始，人工地沿控制流程往回追踪，直至发现出错的根源，不幸的是程序变大后，可能的回溯路线显著增加，以致人工进行完全回溯到望而不可及。 　　排除法基于归纳和演绎原理，采用"分治"的概念，首先惧与错误出现有关有所有数据，假想一个错误原因，用这些数据证明或反驳它；或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端，则立即精化数据，乘胜追击。 　　上述每一类方法均可辅以排错工具。目前，调试编译器、动态调试器（"追踪器"）、测试用例自动生成器、存储器映象及交叉访问示图等到一系列工具已广为使用。然而，无论什么工具也替代不了一个开发人员在对完整的设计文档和清晰的源代码进行认真审阅和推敲之后所起的作用。此外，不应荒废排错过程中最有价值的一个资源，那就是开发小组中其他成员的评价和忠告，正所谓"当事者迷，旁观者清"。 　　前面多次提到，修改一处老问题可能引入几处新问题，有时程序越改越乱，但若能做到每次纠错前都扪心自问三个问题，情况将大为改观： 　　① 导致这个错误的原因在程序其他部分还可能存在吗？ 　　② 本次修改可能对程序中相关的逻辑和数据造成什么影响？引起什么问题？ 　　③ 上次遇到的类似问题是如何排除的？

    计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作：
　　（1） 为测试软件系统的输入信息设计出错处理通路；
　　（2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；
　　（3） 参与系统测试的规划和设计，保证软件测试的合理性。

　　系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。下面简单讨论几类系统测试。

１、恢复测试

　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

２、安全测试

　　安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

３、强度测试

　　强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。

４、 性能测试

　　对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

人们常常以为，开发一个程序是困难的，测试一个程序则比较容易。这其实是误解。设计测试用例是一项细致并需要高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。

　　不论是黑盒测试方法还是白盒测试方法，由于测试情况数量巨大，都不可能进行彻底的测试。所谓彻底测试，就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。 “黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 “白盒”法是穷举路径测试，贯穿程序的独立路径数是天文数字，但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。E．W．Dijkstra的一句名言对测试的不彻底性作了很好的注解：“程序测试只能证明错误的存在，但不能证明错误不存在”。

　　在实际测试中，穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的。当然就不能够保证被测试程序中不存在遗留的错误。软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试。为了降低测试成本，选择测试用例时应注意遵守“经济性”的原则。第一，要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级；第二，要认真研究测试策略，以便能使用尽可能少的测试用例，发现尽可能多的程序错误。掌握好测试量是至关重要的，一位有经验的软件开发管理人员在谈到软件测试时曾这样说过：“不充分的测试是愚蠢的，而过度的测试是一种罪孽”。测试不足意味着让用户承担隐藏错误带来的危险，过度测试则会浪费许多宝贵的资源。

　　测试是软件生存期中费用消耗最大的环节。测试费用除了测试的直接消耗外，还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下：

①、系统的目的

　　系统的目的的差别在很大程度上影响所需要进行的测试的数量。那些可能产生严重后果的系统必须要进行更多的测试。一台在Boeing 757上的系统应该比一个用于公共图书馆中检索资料的系统需要更多的测试。一个用来控制密封燃气管道的系统应该比一个与有毒爆炸物品无关的系统有更高的可信度。一个安全关键软件的开发组比一个游戏软件开发组要有苛刻得多的查找错误方面的要求。

②、潜在的用户数量

　　一个系统的潜在用户数量也在很大程度上影响了测试必要性的程度。这主要是由于用户团体在经济方面的影响。一个在全世界范围内有几千个用户的系统肯定比一个只在办公室中运行的有两三个用户的系统需要更多的测试。如果不能使用的话，前一个系统的经济影响肯定比后一个系统大。除此而外，在分配处理错误的时候，所花的代价的差别也很大。如果在内部系统中发现了一个严重的错误，在处理错误的时候的费用就相对少一些，如果要处理一个遍布全世界的错误就需要花费相当大的财力和精力。

③、信息的价值

　　在考虑测试的必要性时，还需要将系统中所包含的信息的价值考虑在内，一个支持许多家大银行或众多证券交易所的客户机/服务器系统中含有经济价值非常高的内容。很显然这一系统需要比一个支持鞋店的系统要进行更多的测试。这两个系统的用户都希望得到高质量、无错误的系统，但是前一种系统的影响比后一种要大得多。因此我们应该从经济方面考虑，投入与经济价值相对应的时间和金钱去进行测试。

④、开发机构

　　一个没有标准和缺少经验的开发机构很可能开发出充满错误的系统。在一个建立了标准和有很多经验的开发机构中开发出来的系统中的错误不会很多，因此，对于不同的开发机构来说，所需要的测试的必要性也就截然的不同。 然而，那些需要进行大幅度改善的机构反而不大可能认识到自身的弱点。那些需要更加严格的测试过程的机构往往是最不可能进行这一活动的，在许多情况下，机构的管理部门并不能真正地理解开发一个高质量的系统的好处。

⑤、测试的时机

　　测试量会随时间的推移发生改变。在一个竟争很激烈的市场里，争取时间可能是制胜的关键，开始可能不会在测试上花多少时间，但几年后如果市场分配格局已经建立起来了，那么产品的质量就变得更重要了，测试量就要加大。测试量应该针对合适的目标进行调整。