软件测试术语解析

发布: 2007-4-22 18:05 | 作者: 未知 | 来源: 网络 | 查看: 64次 | 进入软件测试论坛讨论

一.从测试设计的方法来看，我们知道有两类方法：

Black box (黑箱)

White box (白箱)

二.功能测试

在下表所列的测试中，测试的范围有小到大，测试者也由内到外，从程序开发人员（单元测试）到 测试人员，到一般用户（Alpha/Beta 测试）。

测试名称

测试内容

Unit Test

单元测试 – 在最低的功能/参数上验证程序的正确性

Functional Test

功能测试 – 验证模块的功能

Integration Test

集成测试 – 验证几个互相有依赖关系的模块的功能

Scenario Test

场景测试 – 验证几个模块是否能够完成一个用户场景

System Test

系统测试 – 对于整个系统功能的测试

Alpha/Beta Test

外部软件测试人员（Alpha/Beta 测试员）在实际用户环境中对软件进行全面的测试。

三.非功能测试

测试名称

测试内容

Stress/load test

测试软件在负载情况下能否正常工作

Performance test

测试软件的效能

Accessibility test

测试软件辅助功能测试 – 测试软件是否向残疾用户提供足够的辅助功能

Localization/Globalization Test

本地化/全球化测试

Compatibility Test

兼容性测试

Configuration Test

配置测试 – 测试软件在各种配置下能否正常工作

Usability Test

可用性测试 – 测试软件是否好用

Security Test

软件安全性测试

四.Ad hoc Test, Exploratory Test “探索式”的测试

“ad hoc”测试的测试流程是不可重复的，因为它的测试都是“特定”测试，没法重复。由于这一原因，“ad hoc”测试不能自动化，就这一点而言，还达不到CMM的第二级 – 可重复级。

五.Regression Test回归测试

Regress的英语定义是：return to a worse or less developed state. 是倒退，退化，退步的意思。

在软件工程中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”- regression, 从正常工作的稳定状态退化到不正常工作的不稳定状态。

在一个模块的功能逐步完成的同时，和此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到此模块的功能基准（baseline）.

在某某版本，某某模块的某某测试用例是通过的！

如果测试人员发现了在新的构建版本某个测试用例失败了，这就是一个“倒退”，在新版本上运行所有已通过的测试用例以验证没有“退化”情况发生，这个过程就是一个“regression test”. 如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因），那么测试用例的基准就要修改，以和新的功能保持一致。

针对一个bug fixed，我们也要作Regression Test，

a) 验证新的代码的确把缺陷改正了，

b) 同时要验证新的代码没有把模块的现有功能破坏，没有regression。

所以我不也知道“回归测试”是如何的“回归”，我们可以理解为“回归到以前不正常的状态”。

回归测试最好要自动化，因为对于每一个构建都要运行所有回归测试，以保证尽早发现问题。

就是“退化测试吗”?

六.Scenario/integration/System Test 场景/集成/系统测试

在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，在各方面都能满足用户的要求。

七.Performance Test 效能测试

用户使用软件，不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平，软件的效能，是这些“非功能需求”，或者说“服务质量需求”的一部分。

八.Stress Test压力测试

压力测试严格地说不属于效能测试。压力测试要验证的问题是：

软件在超过设计负载的情况在仍能够返回正常结果，而没有产生严重的副作用或崩溃。

九.Alpha Test, Beta Test

在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会在开发过程中让特定的用户（alpha/beta用户）使用正处于开发过程中的版本，用户会用特定的反馈渠道（email, BBS）与开发者讨论使用中发现的问题。

......

补充一些测试类型名词:

测试种类	解释
黑盒测试	不基于内部设计和代码的任何知识，而是基于需求和功能性。
白盒测试	基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。
单元测试	最微小规模的测试，以测试某个功能或代码块。典型的由程序而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。
累积综合测试	当一个新功能增加后，对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以便在全部系统完成前能分别工作，这种测试可由程序员或测试员来做。
集成测试	一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试主要与客户服务器和分布式系统有关。
功能测试	用于测试应用系统的功能需求的黑盒测试方法。
系统测试	基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。
端到端测试	类似于系统测试，测试级的“宏大”的端点，涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用网络通讯，或与外部硬件、应用系统或适当的系统对话。
健全测试	典型的是指一个初始化的测试工作，以决定一个新软件版本测试是否足以执行下一步的测试。
衰竭测试	软件或环境的修复或更正后的“再测试”，可能很难确定需要多少遍再次测试，尤其在接近开发周期结束时，自动测试工具对这类测试尤其有用。
接受测试	基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。
负载测试	测试一个应用在重负荷下的表现，例如测试一个web站点在大量的负荷下，何时系统的响应会退化或失败。
强迫测试	在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复、大量数据的输入，对一个数据库系统大量的复杂的查询。
性能测试	在交替进行负荷和强迫测试时常用的术语，应在需求文档或质量保证、测试计划中定义。
可用性测试	对“用户友好性”测试，显然这是主观的，且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其它一些技术都可使用。程序员和测试员通常都不宜作可用性测试。
安装/卸载测试	对软件的全部、部分或升级安装或卸载处理过程的测试。
恢复测试	测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其它灾难性问题。
安全测试	测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。
兼容测试	测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。
比较测试	与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。
Alpha测试	在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。
Beta测试	当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。

*测试名称*	*测试内容*
Unit Test	单元测试 – 在最低的功能/参数上验证程序的正确性
*Functional Test*	功能测试 – 验证模块的功能
*Integration Test*	集成测试 – 验证几个互相有依赖关系的模块的功能
*Scenario Test*	场景测试 – 验证几个模块是否能够完成一个用户场景
*System Test*	系统测试 – 对于整个系统功能的测试
*Alpha/Beta Test*	外部软件测试人员（Alpha/Beta 测试员）在实际用户环境中对软件进行全面的测试。

*测试名称*	*测试内容*
*Stress/load test*	测试软件在负载情况下能否正常工作
*Performance test*	测试软件的效能
*Accessibility test*	测试软件辅助功能测试 – 测试软件是否向残疾用户提供足够的辅助功能
*Localization/Globalization Test*	本地化/全球化测试
*Compatibility Test*	兼容性测试
*Configuration Test*	配置测试 – 测试软件在各种配置下能否正常工作
*Usability Test*	可用性测试 – 测试软件是否好用
Security Test	软件安全性测试