软件测试分类及介绍：软件测试是一项复杂的系统工程，从不同的角度考虑可以有不同的划分方法，对测试进行分类是为了更好的明确测试的过程，了解测试究竟要完成哪些工作，尽量做到全面测试。

1,按是否需要执行被测软件的角度按是否需要执行被测软件的角度，可分为静态测试和动态测试，前者不利用计算机运行待测程序而应用其他手段实现测试目的，如代码审核。

（我认为主要是让测试人员对编译器发现不了的潜在错误进行分析，如无效的死循环，多余的变量等），而动态测试则通过运行被测试软件来达到目的。

2、按阶段划分：1 单元测试单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。

它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。

因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。

因此应用系统有一个设计很好的体系结构就显得尤为重要。

一个软件单元的正确性是相对于该单元的规约而言的。

因此，单元测试以被测试单位的规约为基准。

单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

2 集成测试集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。

它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。

集成测试的策略主要有自顶向下和自底向上两种。

3 系统测试系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。

因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。

软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。

4 验收测试验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。

它的测试数据通常是系统测试的测试数据的子集。

所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。

这是软件在投入使用之前的最后测试。

5 回归测试回归测试是在软件维护阶段，对软件进行修改之后进行的测试。

其目的是检验对软件进行的修改是否正确。

这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。

6 Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。

这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

7 Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。

这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

3、按测试方法划分：1 白盒测试白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

“白盒”法是穷举路径测试。

在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

贯穿程序的独立路径数是天文数字。

但即使每条路径都测试了仍然可能有错误。

第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。

第二，穷举路径测试不可能查出程序中因遗漏路径而出错。

第三，穷举路径测试可能发现不了一些与数据相关的错误。

白盒测试可以借助一些工具来完成如Junit Framework，Jtest等。

2 黑盒测试黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。

“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。

实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

黑盒测试也可以借助一些工具，如WinRunner，QuickTestPro，Rational Robot 等。

3 ALAC(Act-like-a-customer)测试ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。

ALAC测试是基于复杂的软件产品有许多错误的原则。

最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。

软件测试举例：ATM机操作用例：一台ATM 机器的主角和用例。

下表包含了上图中提款用例的基本流和某些备用流：本用例的开端是ATM 处于准备就绪状态。

准备提款- 客户将银行卡插入ATM 机的读卡机。

验证银行卡- ATM 机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。

输入PIN - ATM 要求客户输入PIN 码（4 位）验证帐户代码和PIN - 验证帐户代码和PIN 以确定该帐户是否有效以及所输入的PIN 对该帐户来说是否正确。

对于此事件流，帐户是有效的而且PIN 对此帐户来说正确无误。

可以从这个用例生成下列场景注：为方便起见，备选流3 和6（场景3 和7）内的循环以及循环组合未纳入上表。

对于这7 个场景中的每一个场景都需要确定测试用例。

可以采用矩阵或决策表来确定和管理测试用例。

下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。

本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。

然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。

例如，在下面的矩阵中，V（有效）用于表明这个条件必须是VALID（有效的）才可执行基本流，而I（无效）用于表明这种条件下将激活所需备选流。

下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

在上面的矩阵中，六个测试用例执行了四个场景。

对于基本流，上述测试用例CW1 称为正面测试用例。

它一直沿着用例的基本流路径执行，未发生任何偏差。

基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。

这些负面测试用例由CW2 至6 表示（阴影单元格表明这种条件下需要执行备选流）。

虽然CW2 至6 对于基本流而言都是负面测试用例，但它们相对于备选流2 至4 而言是正面测试用例。

而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 - 基本流）。

每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景4 正是这样的一个示例。

要全面地测试场景4 - PIN 有误，至少需要三个正面测试用例（以激活场景4）：* 输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3 - 输入PIN。

* 输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

* 最后一次输入时输入了“正确”的PIN。

备选流在步骤5 - 输入金额处重新加入基本流。

注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。

以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。

由于只需要查看V 和I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。

从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景6 - 不存在的帐户/帐户类型有误和场景7 - 帐户余额不足就缺少测试用例。

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据：以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。

需要的其他测试用例包括：* 场景6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用* 场景6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款* 场景7 - 帐户余额不足：请求的金额超出帐面金额在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：* 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）* 无法读卡（读卡机堵塞、脱机或出现故障）* 帐户已消户、冻结或由于其他方面原因而无法使用* ATM 内的现金不足或不能提供所请求的金额（与CW3 不同，在CW3 中只是一种币值不足，而不是所有币值都不足）* 无法联系银行系统以获得认可* 银行网络离线或交易过程中断电在确定功能性测试用例时，确保满足下列条件：* 已经为每个用例场景确定了充足的正面和负面测试用例。

* 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边界条件/值上都存在测试用例。

* 测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还应能处理用户界面对象状态或条件。

* 测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。

对于负载测试：对于强度测试：为安全性/访问控制测试生成测试用例，在ATM 用例中，如果主角“银行客户”的卡和帐户有的属于拥有这个ATM 机的银行，有的是竞争银行的银行卡（和帐户），或是企图使用该ATM不支持的银行卡，则将对该主角“银行客户”执行不同的用例事件流。

对于功能性测试用例，请同样遵循上面列举的指南。

关于安全性和访问控制测试用例的示例：手机软件测试举例：一、等价类分析法等价类划分方法针对手机状态大致可以归几个大类：1.按键类（等价法）：有效输入和无效输入（有效输入指UM和菜单指示；无效输入指测试菜单功能此时没有定义的按键和用户动作）；2. 外部中断类（等价法）：常用、不常用及无效2.1. 常用：来电和来消息（短信、彩信、push消息）；掀合盖；侧键；耳机＆FM；情景模式；电量不足2.2. 不常用：充电；闹钟＆记事本＆关机时间＆整点报时提示；Icon＆动画显示；Icon＆动画刷新；编辑界面＆pop显示框输入为空或满；编辑界面＆pop显示框状态输入法默认＆字符编码默认；失效SIM卡；大容量等SIM卡兼容；排序；号码识别；2.3. 无效：“资料读取中…”；“复制中…”；“请稍后再试”3. 存储器类3.1. 等价法分类：读或写；不读或不写。