为了保证软件的质量和可靠性，应力求在分析、设计等各个开发阶段结束前，对软件进行严格技术评审。软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。如果给软件测试下定义，可以这样讲：软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即输入一些数据而得到其预期的结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

软件测试在软件生存期中横跨两个阶段（1.编码和单元测试阶段2.综合测试阶段）：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。编码与单元测试属于软件生存期中的同一个阶段。在结束这个阶段之后，对软件系统还要进行各种综合测试，这是软件生存期的另一个阶段，即测试阶段，通常由专门的测试人员承担这项工作。

三、软件测试的目的

基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，普遍希望通过软件测试暴露出软件中陷藏的错误和缺陷，以考虑是否可以接受该产品。而从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立用户对软件质量的信心。

下面这些规则也可以看作是测试的目的或定义：

测试是为了发现程序中的错误而执行程序的过程；

好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

成功的测试是发现了至今为止尚未发现的错误的测试。

正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。

四、术语及名词定义

黑盒测试

黑盒测试也称为功能测试,它着眼于程序的外部特征,而不考虑程序的内部逻辑结构。测试者把被测程序看成一个黑盒,不用关心程序的内部结构。黑盒测试是在程序接口处进行测试，它只检查程序功能是否能正常使用，程序是否能接收输入数据产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试是基于用户角度进行的测试。

白盒测试

软件测试的主要方法之一，也称结构测试、逻辑驱动测试或基于程序本身的测试。测试者需要了解待测试程序代码的内部结构、算法等信息，这是从程序设计者的角度对程序进行的测试。它的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

灰盒测试

可以理解为静态的白盒测试或动态的黑盒测试，灰盒就是界于黑白之间, 对软件内部有所了解, 但不见得到了如指掌的程度, 却可以结合这些了解做些比黑盒多点的测试。

文档测试

文档测试涵盖面很大，在软件的各个版本中均有所使用。随着软件版本的变化，文档测试的测试内容也有所变化。在需求分析以及原型架构阶段，文档测试主要目标是： Sitemap、动作分解列表、数据库ER图、UML用例图、流程图、需求文档等文档。

文档测试主要检查文档的正确性、完整性和可理解性。正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。完整性是指文档不可以漏掉关键性内容。可理解性是指在文档中描述的语言要简明易懂，不能让别的开发人员拿到文档时看不懂文档的内容。

命名规范测试

命名规范测试用于测试项目中的文件命名、代码以及版本号等书写是否符合规范。文件命名规范以及版本号命名规范可以参看第四部分里软件命名规范的详细信息；各种语言的命名规范可以参考语言自身的规范。

需求完整性测试

需求完整性测试主要存在于需求调研阶段，在需求尚未完全明确之前对已收集到的需求做出整理性的、检查遗漏性的测试，确认需求是否明确。另外，它也承担着一部分澄清需求的任务。

链接完整性测试

在原型架构阶段，链接完整性的测试是非常有必要的。该项测试任务主要是检查假页面中各种链接是否完整，是否指向目标位置，属于检查性的测试。

页面完整性测试

页面完整性测试主要存在于集成测试阶段以及其后续其它阶段中，测试页面是否完整，页面质量是否达标，属于检查性测试。

UI合理性测试

UI合理性测试也就是人机交互界面的合理性，UI合理性测试的内容很多，具体测试内容如下：

提示、菜单、帮助的格式是否一致；
提示、菜单、帮助中的术语是否一致；
各个控件之间的对齐方式是否一致；
输入界面和输出界面在外观、布局、交互方式上是否一致；
功能类似的相关界面在外观、布局、交互方式上是否一致；
同一层次的文字在同一种提示场合（一般情况、特殊字体、警告等）在文字大小、字体、颜色、对齐方式方面是否一致，字体大小是否与界面的大小比例协调；
多个连续界面依次出现的情况下，界面的外观、操作方式是否一致；
系统是否拒绝客户的错误输入并做出提示；
系统是否在用户完成操作时给出操作成功的提示；
用户界面是否存在空白空间，没有空白空间的界面是杂乱无章的，易用性差；
各个控件的间隔是否一致，垂直和水平方向上是否对齐；
是否允许动作的可逆性，返回原有操作。

数据和数据库完整性测试

因为在开发阶段开发人员随时都有可能根据需要来修改数据库，所以对数据和数据库完整性测试在软件项目的任何阶段也是非常必要的。该项测试内容主要是以数据库表为单位，检查数据库表以及表中各字段命名是否符合命名规范，表中字段是否完整，数据库表中的字段描述是否正确包括字段的类型、长度、是否为空，数据库表中的关系、索引、主键、约束是否正确。

功能测试

功能测试在软件项目的任何阶段中都是重要的。实现功能，满足客户需求是软件本身最大的使命。功能测试在任何阶段下基本上都作为测试工作的第一项出现。该项测试任务主要为了测试已实现的功能是否满足需求，是否正确，是否有价值以及是否完整。在黑盒和白盒测试状态下，该测试均会被使用。

在功能测试中要按部就班的把所有要进行的测试功能每一步都执行一遍，应该添加的数据都添加完整，以避免遗漏掉BUG没有测试出来。

在测试前，首先要根据《软件需求规格说明书》全面了解用户需求并透彻理解。测试时要注意以下几点：

测试时要分清优先级，即先测试优先级高功能，后测试优先级低的功能。要选找出系统的功能主干，让数据依次流经功能主干，测试功能实现的是否正确。只要功能主干有问题，这个系统就是失败的。
功能主干用正常正确后，我们还要考虑测试其异常处理功能。
功能主干测试正确后，再进行分支功能的测试。
要对程序的功能进行方便性测试，将不够满意的地方，都应当成系统缺陷向项目负责人或系统开发者指出。
检查系统需求、设计说明书中要求的功能是否在系统中被实现，是否达到指定要求。
数据之间的逻辑关系是否正确。

压力测试

压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。这通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。这种操作也称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。

对应用程序进行压力测试最简单的方法是手工改变输入（客户机数量、需求大小、请求的频率、请求的混合程度等等）并描绘性能的变化。但是如果有许多输入，或者需要在大的范围内改变输入，那么你可以借助一个自动化的压力测试工具来完成此测试。

安全性测试

安全性测试主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据和页面的安全。测试人员可以学习一些黑客技术，来对系统进行攻击。另外，对操作权限的测试也包含在安全性测试中。具体测试内容如下：

执行添加、删除、修改等动作中是否做过登录检测。
退出系统之后的操作是否可以完成。
所有插入表单操作中输入特殊字符是否可以正常输正常存储，特殊字符为：！?#￥%……—*（）~——-+=[]、|；：‘”？/《》<>，。
在带有参数的回显数据的动作中更改参数，把参数改为特殊字符并加入操作语句看是否出错。
测试表单中有没有做标签检测，标签检测是否完整。
在插入表单中加入特殊的html代码，例如：<marquee>表单中的字本是否移动？</marquee>。

页面脚本测试

页面中时常使用到javascript脚本，为了降低页面的出错率，则必须对页面脚本进行测试。其主要内容包括：相关页面中的脚本是否正常运行，JavaScript脚本是否有错误页面。

提示文本测试

提示文本测试从严格意义上来讲应该属于UI合理性测试的一部分，该项测试主要针对各个页面中使用到的大量提示文档进行测试，主要包括：表达不明确的位置是否有提示文本、提示文本的弹出是否正常、提示信息含义是否明确易懂。

兼容测试

浏览器兼容：对于B/S结构项目需要对浏览器进行必要的测试。该测试任务主要是软件对各种浏览器（IE6.0、IE7.0、 IE8.0、360浏览器、FireFox浏览器等）的支持是否正常，在这些浏览器中可以正常显示的页面在其它浏览器中是否可以正常显示。
分辨率兼容：验证不同分辨率下，界面是否能够自适应，界面显示是否正常，功能使用能够正常使用。
操作系统兼容：

正式环境的操作系统如果和测试环境不一致，需要重新搭建环境，保证测试环境和正式环境一致，避免因为操作系统的差异，导致程序不能够正常使用。
如果正式环境需要保证在多个不同的操作系统正常运行，则需要搭建对应的测试环境。分别验证不同操作系统下环境信息是否正常。

安装测试

在软件项目的后期阶段，会对做好的软件进行打包把软件做成安装程序，以便用户可以正确的安装使用，所以需要对做好的安装文件进行安装功能方面的测试。该测试的主要任务是：检查软件是否能够正常安装使用、是否可以完全卸载此软件的所有功能和页面。

自定义测试

在常规测试时可能表中的测试项不能满足测试要求，如果有特殊测试项请测试人员自己定义修改测试的类型。

接口测试

涉及第三方接口的，可以直接进行接口测试，根据接口规范文档，验证入参、出参是否按照接口定义返回正确的结果。

接口测试可以使用工具单独对接口进行测试。

五、软件命名规范

1.软件版本阶段说明（基础架构版2.软件功能实现版3.系统界面修改版4.发行初版5.最终实现版）

Base版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。

版本命名规范（版本的命名可以根据项目的名称来进行）

软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。

版本号定修改规则：

主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。

子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。

阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。

日期版本号(051021):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

2.文件命名规范

文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：项目外包平台测试报告1.1.1.051021_beta_b.xls，此文件为项目外包平台的测试报告文档，版本号为：1.1.1.051021_beta。

如果是同一版本同一阶段的文件修改过两次以上，则在阶段标识后面加以数字标识，每次修改数字加1，项目外包平台测试报告1.1.1.051021_beta_b1.xls

当有多人同时提交同一份文件时，可以在阶段标识的后面加入人名或缩写来区别，例如：项目外包平台测试报告1.1.1.051021_beta_b_XX2.xls

3.版本号的阶段标识

软件的每个版本中包括11个阶段，详细阶段描述如下：

阶段名称	阶段标识
需求控制	a
设计阶段	b
编码阶段	c
单元测试	d
单元测试修改	e
集成测试	f
集成测试修改	g
系统测试	h
系统测试修改	i
验收测试	j
验收测试修改	k

六、测试任务描述

在软件的开发过程中每个版本都会经历四次测试任务，分别为：单元测试、集成测试、系统测试、验收测试，在这四次测试任务中，每次测试都有不同的测试方向和重点。

单元测试（检查软件编码的正确性）

单元测试是软件开发过程中要进行的最基本的测试，属于白盒测试范围，一般情况下是在开发人员完成了某个单独模块的编码之后做的测试。它的目的是检查软件编码的正确性以及一些规范性测试，来查找软件所存在的BUG并记录下产生BUG的原因，以便开发人员进行修改。这样可以在很大程度上减少集成以后而出现的BUG。

单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试应该是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行，也就是说每个版本的开发都需要经过单元测试，这样可以在以后的开发阶段减少很多不必要的麻烦。

单元测试的重点测试内容包括：源代码测试、命名规范测试、需求完整性测试、页面完整性测试、提示文本测试、页面脚本测试等。

单元测试基本流程如下：

确认单元测试计划
根据单元测试计划设计单元测试用例
评审该单元测试计划，若评审通过，则进行下一步，反之，则重新设计该用例
执行测试用例
在执行过程中发现问题，提交缺陷报告，若有缺陷，则要修正这些缺陷，然后重新执行测试用例，反之，则可纳入配置库中。

集成测试（测试功能的完整性和正确性，是有目的性和针对性的）

集成测试也属于白盒测试范围，是在单元测试的基础上将软件的多个模块或者系统前后台合并之后进行的测试，也可以算是对单元测试修改进行的复审测试。在集成测试中可以弥补单元测试中没有测试到的BUG，也可以检查出单元测试没法测试的功能，比如前后台的集成之后的关联功能，对于这些有关联性功能的测试，单元测试中是无能为力的，必须依靠集成测试来保证功能的完整性和正确性。和系统测试相比较集成测试从程序结构出发，目的性、针对性更强，发现问题的效率高，较容易测试特殊的处理流程中存在的BUG。

集成测试的重点测试内容包括：链接完整性测试、页面完整性测试、数据和数据库完整性测试、功能测试、压力测试、安全性测试、页面脚本测试、提示文本测试等。

集成测试基本流程如下：

编写集成测试计划
系统集成（在这一步要形成集成说明书和集成记录文档）
编写集成测试用例
执行集成测试
测试缺陷跟踪与结构分析（形成集成测试报告）

系统测试

系统测试属于黑盒测试范围，是在系统集成测试修改完BUG之后进行的测试。从软件工程和测试的分类来看：集成测试在系统测试之前就必须要进行完毕，只有集成测试完成了，才能保证相应的系统测试进行。也就是说，集成测试是系统测试的基础。

系统测试是针对整个产品的全面测试，既包含各模块的验证性测试和功能合理性测试，又包括对整个产品的可靠性、健壮性、安全性、UI合理性及各种性能参数的测试。

系统测试的重点测试内容包括：链接完整性测试、UI合理性测试、命名规范测试、功能测试、压力测试、页面完整性测试、安装测试、提示文本测试、游览器测试等。

系统测试过程如下：

制定系统测试计划
设计系统测试用例
执行系统测试
根据测试结果评估系统测试（形成测试分析报告）

验收测试

验收测试属于黑盒测试范围，是对系统测试修改后的复审，这方面和集成测试有些类似，首先确认系统测试中的BUG已经按要求修改完成，然后检测一下功能是否符合用户的需求、文档是否完整、有没有前面测试中遗漏没有测试出来的BUG。要说明的一点是，此处的验收测试并非客户验收测试，这里没有客户参与测试，只有测试人员参与测试。验收测试是开发结束或进入下一版本的标志性测试。

验收测试的重点测试内容包括：链接完整性测试、UI合理性测试、功能测试、压力测试、页面完整性测试、提示文本测试、浏览器测试、安装测试。

验收测试过程如下：

编写验收测试计划
设计验收测试用例
验收测试计划的评审和批准
执行验收测试

七、测试工作流程图

软件在开发过程中共有五个版本，分别是Base版、Alpha版、Beta版、RC版、Release版，每个版本的开发中都需要经过上述四次测试，但是每个版本中各阶段的测试重点是不一样的，详细的测试流程和重点请看下面各版本流程图：

Base版(基础版)各个测试阶段流程图

2.Alpha版各个测试阶段流程图

3.Beta版各个测试阶段流程图

4.RC版（候选版本）各个测试阶段流程图

5.Release版（发行版）各个测试阶段流程图

八、测试提交文档

测试文档使用方法

在测试的过程中测试人员会用到三张表，第一张表是“测试任务表”，这张表中记录的是软件在每个版本的每个阶段中需要做的具体测试任务，如果测试中不确定需要做哪些测试，在这张表中可以查询各个阶段中所要进行的测试项。

还有两张表是需要在相应测试阶段来添写的测试文档，分别是“白盒缺陷测试报告”和“黑盒测试缺陷报告”两张表。单元测试和集成测试属于白盒测试范围，需要添写白盒缺陷测试报告；系统测试和验收测试属于黑盒测试范围，需要添写黑盒测试缺陷报告。

测试人员测试完成之后，需要把所添写的缺陷测试报告按时提交给项目经理，由项目经理来安排具体人员进行修改和审核。

测试文档下载

测试任务表
白盒缺陷测试报告
黑盒缺陷测试报告

注：在每次的测试中测试人员需要按表中的要求进行添写测试报告，然后由项目经理来分配给开发人员处理，开发人员修改完BUG之后再交由项目经理来分配给测试人进行修改后的复审，检查前面测试出来的BUG是否已经修改完成，在此要特别说明的一点是：为了让测试报告更方便查看，如果在复审过程中查出还有BUG没有修改完或是根本没有修改，则在复审描述中说明原因，然后把此处标注成新的BUG索引项指到新的BUG编号上，详细情况请看下面截图：

九、测试方法和方式

测试方式主要以手工测试为主，在条件允许的情况下使用自动化测试工具进行测试。

测试方法	测试覆盖率	执行人员	描述
黑盒测试	100%	测试人员	功能测试或数据驱动测试
灰盒测试	10~20%	测试或开发人员	静态的白盒测试或动态的黑盒测试
白盒测试	5%	开发人员	结构测试或逻辑驱动测试

说明：黑盒测试是依据用户能看到的规格说明，即针对命令、信息、报表等用户界面及体现他们的输入数据与输出数据之间的对应关系，特别是针对功能进行测试。主要由客户或系统使用者完成执行黑盒测试。

黑盒测试覆盖范围:

测试用例覆盖：测试的每一个用例都被测试过。

输入覆盖：测试过程中所输入的数据或资料必须一再的试验，如在程序安装过程中输入用户名时，测试者必须反复输入不同长度的中文、英文或数字等来做测试。

输出覆盖：测试过程中程序所产生的行为、反映及数据必须都一再的试验，如不同情况的对话窗口的内容、运算结果数据等都必须反复地测试审核。

十、通过测试的标准

一般有“基于测试用例”和“基于缺陷密度”两种评比准则，在这里我们采用前者。准则

以上是关于软件测试系列一《软件测试基础知识》的主要内容，如果未能解决你的问题，请参考以下文章