软件测试自学笔记整理

黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

5、是否有初始化或终止性错误？

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

1. 单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。

2. 集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。

3. 系统测试主要针对概要设计，检查了系统作为一个整体是否有效地得到运行，例如在产品设置中是否达到了预期的高性能

4. 验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要(需求) 。

单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

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

系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。

验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。

什么是软件测试

为了保证软件的质量和可靠性，应力求在分析、设计等各个开发阶段结束前，对软件进行严格技术评审。但由于人们能力的局限性，审查不能发现所有的错误。而且在编码阶段还会引进大量的错误。这些错误和缺陷如果遗留到软件交付投入运行之时，终将会暴露出来。但到那时，不仅改正这些错误的代价更高，而且往往造成很恶劣的后果。

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

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

大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终目的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。

软件测试的目的

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

因为在程序中往往存在着许多预料不到的问题，可能会被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。如果不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。如果站在用户的角度替他们设想，就应当把测试活动的目标对准揭露程序中存在的错误。在选取测试用例时，考虑那些易于发现程序错误的数据。

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

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

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

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

从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。

由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外，应该认识到测试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。

返回导航

术语、名词定义

1. 黑盒测试

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

的测试。

2. 白盒测试

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

3. 灰盒测试

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

4. 文档测试

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

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

5. 命名规范测试

命名规范测试用于测试项目中的文件命名、代码以及版本号等书写是否符合规范。文件命名规范以及版本号命名规范可以参看第四部分里软件命名规范的详细信息；各种语言的命名规范可以参考语言自身的规范，如NoahWeb 的可以参考 http://docs.noahweb.net附录中的《NoahWeb 各类资源命名规范》。

6. 需求完整性测试

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

7. 链接完整性测试

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

8. 页面完整性测试

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

9. UI 合理性测试

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

o 提示、菜单、帮助的格式是否一致；

o 提示、菜单、帮助中的术语是否一致；

o 各个控件之间的对齐方式是否一致；

o 输入界面和输出界面在外观、布局、交互方式上是否一致；

o 功能类似的相关界面在外观、布局、交互方式上是否一致；

o 同一层次的文字在同一种提示场合（一般情况、特殊字体、警告等）在文字大小、字体、颜色、对齐方式方面是否一致，字体大小 是否与界面的大小比例协调；

o 多个连续界面依次出现的情况下，界面的外观、操作方式是否一致；

o 系统是否拒绝客户的错误输入并做出提示；

o 系统是否在用户完成操作时给出操作成功的提示；

o 用户界面是否存在空白空间，没有空白空间的界面是杂乱无章的，易用性差；

o 各个控件的间隔是否一致，垂直和水平方向上是否对齐；

o 是否允许动作的可逆性，返回原有操做；

10. 数据和数据库完整性测试

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

11. 功能测试

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

功能测试中测试人员往往会忽略掉一些细节问题，比如：一个功能的实现必须要经过6步操作才能完成，而且需要加入20条信息才能看得出测试结果，有的测试人员为了节省时间虽然做完了6步操作，但是没有加入足量的信息，, 使得测试不全面, 正是因为这样而导致一些隐藏的BUG 没有被测试出来。所以说在功能测试中要按部就班的把所有要进行的测试功能每一步都执行一遍，应该添加的数据都添加完整，以避免遗漏掉BUG 没有测试出来。

12. 压力测试

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

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

13. 安全性测试

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

o 执行添加、删除、修改等动作中是否做过登录检测。

o 退出系统之后的操作是否可以完成。

o 所有插入表单操作中输入特殊字符是否可以正常输正常存储，特殊字符为：！?#￥%„„—*（）~——-+=[]{}、|；：‘”？/《》，。

o 在带有参数的回显数据的动作中更改参数，把参数改为特殊字符并加入操作语句看是否出错。

o 测试表单中有没有做标签检测，标签检测是否完整。

o 在插入表单中加入特殊的HTML 代码，例如：表单中的字本是否移动？。

14. 页面脚本测试

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

15. 提示文本测试

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

16. 浏览器测试

由于B/S结构项目是基于浏览器运行的，所以需要对浏览器进行必要的测试。该测试任务主要是软件对各种浏览器（IE5.5、IE6.0、 FireFox 浏览器 ）的支持是否正常，在IE 浏览器中可以正常显示的页面在其它浏览器中是否可以正常显示。

17. 安装测试

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

18. 自定义测试

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

软件命名规范

1. 软件版本阶段说明

o Base 版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。

o Alpha 版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug 较多，需要继续修改。

o Beta 版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI 。

o RC 版: 该版本已经相当成熟了，基本上不存在导致错误的BUG ，与即将发行的正式版相差无几。

o Release 版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release 不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ) 。

2. 版本命名规范

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

1.1.1.051021_beta。

版本号定修改规则：

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

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

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

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

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

3. 文件命名规范

文件名称由四部分组成：第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：项目外包平台测试报告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_LiuQi.xls。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别，例如：项目外包平台测试报告1.1.1.051021_beta_b_LiuQi2.xls

4. 版本号的阶段标识

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

阶段名称 阶段标识

需求控制 a 设计阶段 b

编码阶段 c 单元测试 d

单元测试修改e 集成测试 f

集成测试修改 g 系统测试 h

系统测试修改 I 验收测试 j

验收测试修改 k

5. 测试任务描述

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

1. 单元测试

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

一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。 这在外表上看来是一项明显的进步，而象单元测试会推迟对整个系统进行合并这种真正有意思的工作启动的时间。

这种开发步骤中，真实意义上的进步被软件合并后的外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug 。现实的开发中，没有单元测试的软件常常会导致这样的结果，软件甚至无法运行。更进一步的结果是大量的时间将被花费在本应该在单元测试里就完成的简单Bug 上面，在个别情况下，这些Bug 也许是琐碎和微不足道的，但是总的来说，他们会延长软件集成为一个系统的时间， 而且当这个系统投入使用时也无法确保它能够可靠运行。

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

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

2. 集成测试

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

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

3. 系统测试

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

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

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

4. 验收测试

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

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

测试工作流程图

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

1. Base 版各个测试阶段流程图

测试提交文档

测试文档使用方法

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

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

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

测试文档下载

• 测试任务表

• 白盒缺陷测试报告

• 黑盒缺陷测试报告

注：

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

测试方法和方式

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

测试方法 测试覆盖率 执行人员 描述

黑盒测试 100% 测试人员 功能测试或数据驱动测试

灰盒测试 10~20% 测试或开发人员 静态的白盒测试或动态的黑盒测试

白盒测试 5% 开发人员 结构测试或逻辑驱动测试

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

黑盒测试覆盖范围:

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

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

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

通过测试的标准

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

准则如下：

1. 功能性测试用例通过率达到100％；

2. 非功能性测试用例通过率达到95％；

备选通过办法：

根据实际情况由项目经理和测试负责人以及用户等共同讨论确定本阶段是否结束。

实施建议

对于系统的一些实施建议：

o 对系统测试人员进行必要的培训，提高他们的测试效率。

o 项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”的测试。

附录一：缺陷分类

类 别 描 述

需求缺陷

1） 需求有误 2） 需求逻辑错误 3） 需求不完备

4） 需求文档描述问题 5） 需求更改

设计缺陷 功能的使用对用户带来不便及不符合行业标准的：

1） 设计不合理 2） 设计文档描述问题 3） 设计变更带来的问题

功能和性能缺陷 功能没有达到需求的要求，或功能存在严重缺陷，系统在运行过程中存在性能瓶颈，或对系统性能有影响的功能：

1） 功能或性能有误 2） 性能不完全 3） 功能不完全

4） 适应范围有问题 5） 用户信息和诊断信息有误 6） 异常情况处理有误

7） 其他功能错误

界面缺陷 系统上图片、文字、按钮等出现明显错误

数据错误 访问数据库时出错，得出的数据错误：

1） 数据定义数据结构错误 2） 数据存取及数据操作错误 3） 其它数据问题

结构缺陷

1） 控制流和控制顺序错 2） 处理错

实现与编码缺陷

1） 编码错误 2） 违背编码风格或标准

3） 文档有误 4） 其它实现的问题

系统结构缺陷

1） 操作系统引用或使用错误 2） 软件结构错误 3） 恢复错误

4） 执行错误 5） 诊断错误 6） 分割覆盖错误 7） 引用环境错误

测试设计与测试执行错误

1） 测试设计错误 2） 测试执行错误 3） 测试文档有误 4） 测试用例不充分

5） 其他测试错误

计算错误 数学结算错误

不同硬件设备所产生的错误 所产生的问题与硬件设备直接有关

其他错误 测试者检查出来的且不包括在以上所有类型中的错误

附录二：缺陷严重程度

类 别 描 述

1-致命

1）可能有灾难性的后果，如造成系统崩溃，造成事故等

2） 程序无法运行

2-严重 产生错误的结果，导致系统不稳定的问题，运行时好时坏：

1）造成数据库不稳定的错误

3）列在说明中的需求未在最终系统中实现

4）业务流程不正确

3-一般 不正确的，但不会影响系统稳定性的：

1） 过程调用或其它脚本错误

2） 系统刷新错误

3） 产生错误结果，如计算结果错误等

4） 功能的实现有问题。如在系统实现的界面上，一些可接受输入的控件点击后无作用，对数据库的操作不能正确实现

5） 编码时数据类型、长度定义错误的

6） 对用户的使用有操作顺序上的限制

7） 虽然正确性不受影响，但系统性能和响应时间受到影响

4-轻微 不正确的，但有使系统使用起来不太方便的错误：

1）系统的提示语不明确，不简明

2）滚动条无效

3）可编辑区和不可编辑区不明显

4）光标跳转设置不好，鼠标（光标）定位错误

5）上下翻页，首尾页定位错误

6）界面不一致，或界面不正确

7）日期或时间初始值错误（起止日期、时间没有限定）

8）按钮或标签上有拼写错误的单词、不正确的大小写

5-建议 1） 容易给用户误解和岐议的提示

2） 界面需要改进的

3） 对有疑虑的文档，提出修改建议

附录三：优先级

类 别 描 述

1-立即修改完成（最高） 影响测试进度的BUG ， 重大的功能缺陷BUG ，需要及时处理的

2-下一个阶段结束前必须修改完成 功能没有达到需求的的BUG ，设计上存在轻微缺陷的

3-产品推出前必须修改完成 系统上图片、文字、按钮、翻页上有的BUG 或建议

4-时间允许再进行修改 有缺陷，但不影响系统功能，只是系统使用起来不太方便

5-下个版本再修改（最低） 在此版本中不做修改，进入下一版本时再做修改

6-无法修改，不做处理 因为所要求的内容不合理，所以不做处理

金山的软件测试方向的笔试，考的都是很专业的测试方面的问题。

第一题是如何测试一个安装程序，选用什么工具，什么方法；

用虚拟机测试安装程序，在虚拟机上运行安装程序。

主要测试安装时的安装目录、环境变量、硬件环境以及卸载过程等。

第二题是软件测试前需要做哪些准备工作；

①明确测试对象，了解测试内容；

②根据相关文档（需求文档和设计文档）编写软件测试计划，如测试策略、测试方法；

③设计测试用例；

④搭建测试环境；

最后是执行测试。

(提交测试报告)

第三题是软件开发的阶段，软件测试的阶段，以及每个阶段的任务；

{RAD(rap application development), 就是软件开发过程中的一个重要模型，称为快速应用开发模型。其模型构图形似字母V ，所以又称V 模型。他通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。

V 模型大体可以划分为下面几个不同的阶段步骤，既需求分析、概要设计、祥细设计、编码、单元测试、集成测试、系统测试、验收测试。}

⑴需求分析：明确客户需要，按需求写出规格文档说明书；

⑵概要设计：构建框架，描述模块功能及接口；

⑶祥细设计：设计模块的具体实现方式及模块的组合方式（把程序的具体实现的功能，现象等描述出来）； ⑷编码：按照祥细设计好的模块功能表，编写出实际的代码；

①单元测试（模块测试）：按照设定好的最小测试单元进行按单元测试，主要是测试程序代码；

②集成测试（也叫组装测试，联合测试）：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确；

③系统测试：是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其指定的要求； ④验收测试：验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。 第四题应该是个智力题，每3个空啤酒瓶可以换1瓶啤酒，10个空瓶最多可以换多少瓶啤酒！4瓶

后面是关于测试用例的题：

第五题是一个正交表法设计测试用例；

第六题是设计对于一个键盘的测试；

第七题是对于一三个整数组，判定其是不等边三角形、等腰三角形，还是等边三角形。

三边长大于0；两边之和大于第三边；有两边等长；三边等长。