软件测试 维基百科转载

软件测试（英文：Software Test），描述一种用来促进鉴定软件的正确性、完整性、安全性、和品质的过程。据此，您可能会想，软件测试永远不可能完整的确立任意电脑软件的正确性。然而，在可计算理论──计算机科学的一个支派── 一个简单的数学证明推断出下列结果：不可能完全解决所谓“当机”(指任意电脑程序是否会进入无限循环、或者罢工并产生输出) 问题。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件品质，并对其是否能满足设计要求进行评估的过程。

软件测试有许多方法，但对复杂的产品运行有效测试不仅仅是研究过程，更是创造并严格遵守某些呆板步骤的大事。测试的其中一个定义：“为了评估而质疑产品的过程”──这里的“质疑”是测试员试着对产品做的事，而产品以测试者脚本行为反应作为回答。虽然大部分测试的智力过程不外乎回顾、检查，然而“测试”这个辞意味着产品动态分析──让产品流畅运行。程序品质可能，而且通常会，随系统不同而有差异；不过某些公认特性是共通的：可靠性、稳定性、轻便性、易于维护、以及实用性。请引用至ISO 标准 ISO 9126 有更详尽的说明。

软件测试介绍

软件测试一度被认为是编程能力偏低的员工的工作，直到今天，仍然有许多公司把优秀的人才放在编码上，也有更多公司让优秀的人才进行设计，可是很少公司让优秀的人才进行测试工作。实际的软件工程实践证明，让对软件思想有深刻理解的工程师进行软件测试，可以大幅度的提高软件质量。

软件测试和其他工程中的测试有很大的不同。人们可以牙咬来测试黄金的硬度、“真金不怕火炼”测试它的熔点，用化学方法测试它的纯度，可是我们没有很完善的指标来描述软件产品：比如通过率等等。

在一千个软件拷贝中，如果一个发现了错误，实际上就是这些拷贝都有错误。更重要的是其他工业产品都有“通过检测”这个概念，可是软件产品的测试的目的现在仍然是：尽可能多的找到软件中的错误，而不是证明软件的正确。

测试的进程
Alpha测试
Alpha测试通常是阶段性的开发完成后所开始进行，一直持续到进入Beta测试阶段前的阶段。

在这个阶段中，通常是在软件由潜在用户/客户或一个独立的测试团队，采用现成软件，以模拟或实际操作性的黑盒测试和灰盒测试进内联部验收测试。

Beta测试
当Alpha阶段完成后，开发过程进入到Beta阶段。在Beta阶段，用于Beta测试的产品被发布(release)到一部分受控制的公司外部人员手中，通过这部分受控制的外部人员的测试和反馈，Beta阶段可以尽量发现产品中存在的缺陷和错误。在某些情况下，Beta版本可能被发放到范围更广的外部人员手中（例如，通过网站下载或是其他方式面向公众发放）。

Beta阶段的测试主要使用黑盒测试技术。当然，在Beta阶段，测试人员仍然可以使用白盒测试技术对产品继续进行测试，但我们一般不认为这些测试是Beta测试的一部分。简单来说，我们认为Beta测试就是由一部分受控制的客户进行的黑盒测试。

Gamma测试
Gamma测试是一个很少被提及的非正式测试阶段，该测试阶段对应的是对“存在缺陷”产品的测试。考虑到任何产品都可以被称为“存在缺陷”的产品（测试只能发现产品中存在的问题，不能说明产品不存在问题），因此这个概念存在一定的不确定。

对Alpha和Beta测试常见的一个认识误区是“Beta测试＝黑盒测试”。实际上，Alpha和Beta测试对应在软件产品发布之前的Alpha和Beta阶段，而白盒、黑盒和灰盒测试技术是从技术和方法层面对测试的描述，不应该将这两部分概念混淆。

测试的方法
软件测试一般分为白盒测试和黑盒测试。

黑盒测试
这种测试不需要了解软件的内部构造，是从用户的角度对程序进行的测试，只知道程序的输入（将测试数据输入到软件）、输出（确认输出结果是否正确）和系统的功能就可以，因此被称为黑盒测试。

黑盒测试包括：功能测试、系统测试（极限值测试、数据驱动测试或基于规格说明的测试等）。

白盒测试

白盒测试又称为结构测试和逻辑驱动测试。 白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

测试的类型
功能测试 按照测试软件的各个功能划分进行有条理的测试，在功能测试部分要保证测试项覆盖所有功能和各种功能条件组合。
系统测试 对一个完整的软件以用户的角度来进行测试，系统测试和功能测试的区别是，系统测试利用的所有测试数据和测试的方法都要模拟成和用户的实际使用环境完全一样，测试的软件也是经过系统集成以后的完整软件系统，而不是在功能测试阶段利用的每个功能模块单独编译后生成的可执行程序。
极限值测试 对软件在各种特殊条件，特殊环境下能否正常运行和软件的性能进行测试。
特殊条件一般指的是软件规定的最大值，最小值，以及在超过最大，小值条件下的测试。
特殊环境一般指的是软件运行的机器处于CPU高负荷，或是网络高负荷状态下的测试，根据软件的不同，特殊环境也有过不同。
性能测试 性能测试是对软件性能的评价。简单的说，软件性能衡量的是软件具有的响应及时度能力。因此，性能测试是采用测试手段对软件的响应及时性进行评价的一种方式。根据软件的不同类型，性能测试的侧重点也不同。

压力测试与性能测试
压力测试常常和性能测试相混淆。它们主要不同点是，压力测试要求进行超过规定性能指标的测试。例如一个网站设计容量是100个人同时点击，压力测试就要是采用120个同时点击的条件测试。

压力测试的通常判断准则：

系统能够恢复。
压力过程中不要有明显性能下降。
测试的阶段
单元测试

单元测试（又称为模块测试）是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书(en:Specification)要求的工作目标，没有程序错误；虽然单元测试不是什么必须的，但也不坏，这牵涉到专案管理的政策决定。

每个理想的测试案例独立于其它案例；为测试时隔离模块，经常使用stubs、mock[1] 或fake等测试马甲程序。单元测试通常由软件开发人员编写，用于确保他们所写的代码符合软件需求和遵循开发目标。它的实施方式可以是非常手动的（通过纸笔），或者是做成构建自动化（build automation）的一部分。

 集成测试

集成测试又称组装测试，即对程序模块采用一次性或增殖方式组装起来，对系统的接口进行正确性检验的测试工作。集成测试一般在单元测试之后、系统测试之前进行。

系统测试
系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。

回归测试
回归测试指在软件维护阶段，为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。

与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用，因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。

测试用例、测试脚本和测试场景
主条目：测试用例
测试过程示例
软件测试活动
验收测试
系统测试
集成测试
单元测试
回归测试
性能测试
压力测试
安全测试
安装测试
可用性测试
稳定性测试
易用性测试
移植测试
代码覆盖率
代码覆盖率原本是种白箱测试活动。目标软件通过特殊选项或者函数馆编译并且/或者运行在特殊环境──程序里每个函数都被映射回源代码里函数起点──下。这个过程允许开发员与品管员查看系统中在正常情况下极少或从未被读写的部分 (例如：例外处理之类) 并且帮助测试员确认最重要的情况 (函数点) 都被测过了。

测试员可查看代码覆盖率测试结果来设计测试个案、相对应的输入或者设置组以增加重要函数的代码覆盖率。两种测试员常用的代码覆盖率形式：陈述式覆盖率(或称行覆盖率) 以及路径覆盖率 (或称边覆盖率)。行覆盖率回报到测试完成时，运行过哪些行，或者存储器大小。边覆盖率回报到测试完成时，哪些分支、或者程序决定点被运行过。正如覆盖率的“率”字所言，这两个都以百分比为单位。

通常代码覆盖率的工具与函数馆要求的性能、存储器、或者其他资源开销不为正常的软件营运接受。因此它们通常只存在实验室里。又，你可能会想到软件里的许多类无法一一通过这些代码覆盖率测试，虽然代码覆盖程度可通过分析但不是直接测试。

有些瑕疵也会受这些工具的影响。个别来说某些竞态条件 (race condition) 或者类似的对实时 (real time) 敏感度高的操作几乎不可能在代码覆盖率测试环境下侦知；相反的这类的瑕疵只会带来更多的测试码开销。