术语、名词定义

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代码，例如：<marquee>表单中的字本是否移动？</marquee>。

14.   页面脚本测试

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

15.   提示文本测试

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

16.   浏览器测试

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

17.   安装测试

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

通过测试的标准

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

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

备选通过办法：

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