软件测试的基本概念和方法 [转]

软件测试方法之所以没能完全标准化和统一化，主要原因是因为软件产业产品到软件测试有各式各样的软件。但是目前仍有很多各样软件测试方法都基本可用的常用概念和方法。我们这里介绍的思路和方法就是可用于多数应用软件的测试。有六个有关软件测试方法的基本概念是很重要的：白箱测试，黑箱测试，灰箱测试，有效用例和无效用例，边界条件以及等价类测试。

白箱测试或白盒测试（White-box testing 或glass-box testing）是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。

黑箱测试或黑盒测试（Black-box testing)是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。

灰箱测试或灰盒测试（Gray-box testing）：灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于：如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。

有效用例(Valid case)或者叫合法输入用例：是那些已知软件程序能正确地处理的测试用例。一般是指软件输入的测试用例。比如说，在 Microsoft Excel 中，用键盘输入“=1+1”, 看到的结果是“2”。 这里输入的有效用例是“=1+1”。无效用例（Invalid case有人叫不合法输入用例）或者出错用例(error case)：是那些事先就知道软件程序不支持处理的测试用例。比如说在 Microsoft Excel 中，用键盘输入“=a+1”, 看到的结果是“#NAME?”。这里输入的“=a+1”既是无效用例同时也是出错用例。

边界条件（Boundary Cases）：环绕边界值的测试。通常意味着最大值，最小值或者所设计软件能够处理的最长的字符串等等。比如说某软件字体的字号支持范围是：从8到72。那么边界测试用例应该包括：小于8, 等于8, 等于72 和大于72。

等价类（equivalent classes）：等价类测试用例指的是如果有很多测试用例执行再多也不会找到新的中的缺陷。因为虽然输入和输出结果有所不同，但是它们都通过同样的软件的源代码路径。通常只要一个源代码程序的路径是用于处理一定数值范围内的所有数值，那么除了边界值以外，在边界值范围以内的所有数值一般都属于等价类。因为如果软件程序能正确处理一个值，也就意味着该程序能正确处理在这个范围内的除了边界值以外的其他任何有效输入值。我们来用以上软件字体的字号来举例说明。软件支持的字号范围是：从8到72。那么8和72之间的所有支持的字号都可以被认为是等价类的测试用例。

软件测试的基本方法

软件测试方法在不同的书籍中可能有不同的分类，不同的叫法和不同的解释。比如，从测试人员角度看，煞治侄馐院妥远馐浴４釉创氲慕嵌瓤煞治ピ馐院凸δ懿馐浴４永砺鄱ㄒ謇捶郑煞治谙洳馐裕紫洳馐院突蚁洳馐浴Ｕ饫镆致鄣幕救砑馐苑椒ㄖ饕嘀赜谌砑δ艿暮谙洳馐苑椒ǎ汗δ懿馐裕‵unctionality Test），可接受性测试（Acceptance Test），用户界面(User interface或UI)测试，Ad hoc一般指‘探讨或开放’型测试，边界条件测试（Boundary Condition），性能测试（Performance Test），回归测试（Regression Test），强力测试（Stress Test），配置和安装测试（Configuration and Setup Test），兼容性测试（Comparability Test），国际化支持测试（International Sufficiency）以及本地化语言测试（Localization）。

功能测试：验证测试软件功能能否正常按照它的设计工作。看运行软件时的期望行为是否符合原设计。比如，测试Microsoft Excel插入->符号的功能包括测试能够在Microsoft Excel所选单元格中正确地插入符号并且显示正确符号？能否正确显示使用不同的字体的符号？

//注 下面的测试应该是 smoke test
可接受性测试：是在把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求。比如不会很容易程序就挂起或崩溃。如果一个新版本没通过可测试性的验证，就应该阻拦测试部门花时间在该测试版本上测试。同时还要找到造成该版本不稳定的主要缺陷并督促尽快加以修正。

用户界面测试：分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息（Menu 和Help content）等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。

‘探索或开放’型的测试：不是按部就班的按照一个又一个正式的测试用例来进行，也不局限于测试用例特定的步骤。这种测试是测试人员在理解该软件功能的基础上运用灵活多样的想象力和创造力去模拟用户的需求来使用该软件的多种功能。通常涉及很多的测试用例或者通过更复杂的步骤来使用该软件。
边界条件测试：是环绕边界值的测试。通常意味着测试软件各功能是否能正确处理最大值，最小值或者所设计软件能够处理的最长的字符串等等。

性能测试：通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会流失（memory leak）。比如，验证程序保存一个巨大的文件新版本不比旧版本慢。

回归测试：根据修复好了的缺陷再重新进行的测试。目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围时是比较困难的，特别当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码，因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。因此应当鼓励对所有回归测试用例进行自动化。

强力测试：它通常验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。或者说是验证软件的性能在各种极端环境和系统条件下的承受能力。比如，在最低的硬盘驱动器空间或系统记忆容量条件下，验证程序重复执行打开和保存一个巨大的文件1000次后也不会崩溃或死机。

集成与兼容性测试：验证该功能能够如预期的那样与其他程序或者构件协调工作。兼容性经常意味着新旧版本之间的协调，也包括测试的产品与其它产品的兼容使用。比如用同样产品的新版本时不影响与用旧版本用户之间保存文件，格式，和其他数据等操作。

装配/安装/配置测试：验证软件程序在不同厂家的硬件上，所支持的不同语言的新旧版本平台上，和不同方式安装的软件都能够如预期的那样正确运行。比如，把英文版的 Microsoft Office 2003安装在韩文版 的Windows Me 上，再验证所有功能都正常运行。

国际化支持测试：验证软件程序在不同国家或区域的平台上也能够如预期的那样运行，而且还可以按照原设计尊重和支持使用当地常用的日期，字体，文字表示，特殊格式等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串？用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串？又比如，日文版的Microsoft Excel对话框是否显示正确翻译的日语？一旦来说执行国际化支持测试的测试人员往往需要基本上了解这些国家或地区的语言要求和期望行为是什么。

本地化语言测试：要验证所有已计划要发布的不同语言版本软件如预期的那样被正确地翻译成当地语言。这类测试一般包括验证菜单，对话框，出错信息，帮助内容等所有用户界面上的文字都能够显示正确翻译好的当地文字。

软件测试的原则
应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭
测试用例应由测试输入数据和对应的预期输出结果这两部分组成
程序员应避免检查自己的程序
在设计测试用例时，应当包括合理的输入条件和不合理的输入条件

软件测试对象
软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间
需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象

软件测试分类
白盒测试：知道被测软件如何（HOW）完成功能和完 成什么样的功能（WHAT），白盒测试一般由开发人员完成
黑盒测试:只知道WHAT下进行的测试，黑盒测试一般由测试人员进行
单元测试是一种白盒测试，目的是验证所设计的类是否符合需求
Junit是单元测试工具

测试框架定义
框架定义了一些条条框框，编写的测试代码必须遵循这些条条框框：继承某个类，实现某个接口
框架通俗一点就是我们所说的规范