
软件测试的经典定义是:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。
软件测试描述一种用来促进鉴定软件的 正确性、完整性、安全性、和品质的过程。据此,您可能会想,软件测试永远不可能完整的确立任意电脑软件的正确性。然而,在可计算理论──计算机科学的一个支派──一个简单的数学证明推断出下列结果:不可能完全解决所谓‘当机’(指任意电脑程式是否会进入 无限循环、或者罢工并产生输出) 问题。换句话说,软件测试是一种实际输出与预期输出间的稽核或者比较过程。
软件测试有许多方法,但对复杂的产品执行有效测试不仅仅是研究过程,更是创造并严格遵守某些呆板步骤的大事。测试的其中一个定义:“为了评估而质疑产品的过程”──这里的“质疑”是测试员试着对产品做的事,而产品以测试者脚本行为反应作为回答。虽然大部分测试的智力过程不外乎回顾、检查,然而“测试”这个辞意味着产品动态分析──让产品流畅运行。程式品质可能,而且通常会,随系统不同而有差异;不过某些公认特性是共通的:可靠性、稳定性、轻便性、易于维护、以及实用性。请参照至 ISO 标准 ISO 9126 有更详尽的说明。
| 软件开发过程 |
| 软件开发步骤 |
| 需求分析 | 软件架构 | 软件设计 | 软件编程 | 软件测试 | 软件部署 |
| 软件开发模式 |
| 敏捷开发 | Cleanroom | 迭代式开发 | RAD | 统一过程 | Spiral | 瀑布模型 | 极限编程 | Scrum |
| 软件开发辅助领域 |
| 配置管理 | 文档编写 | 质量管理 | 项目管理 | 使用者经验设计 |
目录 |
软件测试一度被认为是编程能力偏低的员工的工作,直到今天,仍然有许多公司把优秀的人才放在编码上,也有更多公司让优秀的人才进行设计,可是很少公司让优秀的人才进行测试工作。实际的软件工程实践证明,让对软件思想有深刻理解的工程师进行软件测试,可以大幅度的提高软件质量。
软件测试和其他工程中的测试有很大的不同。人们可以牙咬来测试黄金的硬度、“真金不怕火炼”测试它的熔点,用化学方法测试它的纯度,可是我们没有很完善的指标来描述软件产品:比如通过率等等。
在一千个软件拷贝中,如果一个发现了错误,实际上就是这些拷贝都有错误。更重要的是其他工业产品都有“通过检测”这个概念,可是软件产品的测试的目的现在仍然是:尽可能多的找到软件中的错误,而不是证明软件的正确。
软件测试一般分为白盒测试和黑盒测试。
包括功能测试、系统测试(极限值测试、数据驱动测试或基于规格说明的测试等)。测试者不了解程序的内部情况。由于这类测试是利用将测试数据输入软件,然后确认输出结果是否正确的方法来对软件进行测试的。这种测试不需要了解软件的内部构造,是从用户的角度对程序进行的测试,只知道程序的输入、输出和系统的功能就可以,因此被称为黑盒测试。
| 功能测试 | 按照测试软件的各个功能划分进行有条理的测试,在功能测试部分要保证测试项覆盖所有功能和
各种功能条件组合; |
| 系统测试 | 对一个完整的软件以用户的角度来进行测试,系统测试和功能测试的区别是,系统测试利用的所
有测试数据和测试的方法都要模拟成和用户的实际使用环境完全一样,测试的软件也是经过系统集成以后的完 整软件系统,而不是在功能测试阶段利用的每个功能模块单独编译后生成的可执行程序。 |
| 极限值测试 | 对软件在各种特殊条件,特殊环境下能否正常运行和软件的性能进行测试。 特殊条件一般指的 是软件规定的最大值,最小值,以及在超过最大,小值条件下的测试。 |
| 性能测试 | 性能测试是对软件性能的评价。简单的说,软件性能衡量的是软件具有的响应及时度能力。因此,
性能测试是采用测试手段对软件的响应及时性进行评价的一种方式。根据软件的不同类型,性能测试的侧重点也不同。 |
在Alpha测试的开始阶段,开发人员使用白盒测试技术对软件进行测试。随后,一个专门的测试团队使用黑盒测试和灰盒测试的技术对其进行测试。
当Alpha阶段完成后,开发过程进入到Beta阶段。在Beta阶段,用于Beta测试的产品被发放到一部分受控制的公司外部人员手中,通过这部分受控制的外部人员的测试和反馈,Beta阶段可以尽量发现产品中存在的缺陷和错误。在某些情况下,Beta版本可能被发放到范围更广的外部人员手中(例如,通过网站下载或是其他方式面向公众发放)。
Beta阶段的测试被称为Beta测试,Beta测试主要使用黑盒测试技术。当然,在Beta阶段,测试人员仍然可以使用白盒测试技术对产品继续进行测试,但我们一般不认为这些测试是Beta测试的一部分。简单来说,我们认为Beta测试就是由一部分受控制的客户进行的黑盒测试。
Gamma测试是一个很少被提及的非正式测试阶段,该测试阶段对应的是对“存在缺陷”产品的测试。考虑到任何产品都可以被称为“存在缺陷”的产品(测试只能发现产品中存在的问题,不能说明产品不存在问题),因此这个概念存在一定的不确定。
对Alpha和Beta测试常见的一个认识误区是“Beta测试=黑盒测试”。实际上,Alpha和Beta测试对应在软件产品发布之前的Alpha和Beta阶段,而白盒、黑盒和灰盒测试技术是从技术和方法层面对测试的描述,不应该将这两部分概念混淆。
回归测试指在软件维护阶段,为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作,有研究表明,回归测试带来的耗费占软件生命周期的1/3总费用以上。 与普通的测试不同,在回归测试过程开始的时候,测试者有一个完整的测试用例集可供使用,因此,如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向,此外,回归测试的研究方向还涉及自动化工具,面向对象回归测试,测试用例优先级,回归测试用例补充生成等。
代码覆盖率原本是种白箱测试活动。目标软件通过特殊选项或者函式馆编译并且/或者执行在特殊环境──程式里每个函式都被映射回源代码里函式起点──下。这个过程允许开发员与品管员检视系统中在正常情况下极少或从未被读写的部分 (例如:例外处理之类) 并且帮助测试员确认最重要的情况 (函式点) 都被测过了。
测试员可检视代码覆盖率测试结果来设计测试个案、相对应的输入或者设定组以增加重要函式的代码覆盖率。两种测试员常用的代码覆盖率形式:陈述式覆盖率(或称行覆盖率) 以及路径覆盖率 (或称边覆盖率)。行覆盖率回报到测试完成时,执行过哪些行,或者内存大小。边覆盖率回报到测试完成时,哪些分支、或者程式决定点被执行过。正如覆盖率的“率”字所言,这两个都以百分比为单位。
通常代码覆盖率的工具与函式馆要求的效能、内存、或者其他资源开销不为正常的软件营运接受。因此它们通常只存在实验室里。又,你可能会想到软件里的许多类无法一一通过这些代码覆盖率测试,虽然代码覆盖程度可通过分析但不是直接测试。
有些瑕疵也会受这些工具的影响。个别来说某些竟态条件 (race condition) 或者类似的对即时 (real time) 敏感度高的操作几乎不可能在代码覆盖率测试环境下侦知;相反的这类的瑕疵只会带来更多的测试码开销。
Why are we here?
All text is available under the terms of the GNU Free Documentation License
This page is cache of Wikipedia. History