文档介绍：第 2 页
什么是软件测试
为了保证软件的质量与可靠性，应力求在分析、设计等各个开发阶段完毕前，对软件进展严格技术评审。但由于人们能力的局限性，审查不能发现所有的错误。而且在编码阶段还会引进大量的错误。这些错误与缺陷如果遗留到
文档测试
文档测试涵盖面很大，在软件的各个版本中均有所使用。随着软件版本的变化，文档测试的测试内容也有所变化。在需求分析以及原型架构阶段，文档测试主要目标是： Sitemap、动作分解列表、数据库ER图、UML用例图、流程图、需求文档等文档。
文档测试主要检查文档的正确性、完整性与可理解性。正确性是指不要把软件的功能与操作写错，也不允许文档内容前后矛盾。完整性是指文档不可以漏掉关键性内容。可理解性是指在文档中描述的语言要简明易懂，不能让别的开发人员拿到文档时看不懂文档的内容。
命名标准测试
命名标准测试用于测试工程中的文件命名、代码以及版本号等书写是否符合标准。文件命名标准以及版本号命名标准可以参看第四局部里软件命名标准的详细信息；各种语言的命名标准可以参考语言自身的标准，如NoahWeb的可以参考 ://。
第 7 页
需求完整性测试
需求完整性测试主要存在于需求探索阶段，在需求尚未完全明确之前对已收集到的需求做出整理性的、检查遗漏性的测试，确认需求是否明确。另外，需求完整性测试也承当着一局部澄清需求的任务。
链接完整性测试
在原型架构阶段，链接完整性的测试是非常有必要的。该项测试任务主要是检查假页面中各种链接是否完整，是否指向目标位置，属于检查性的测试。
第 9 页
页面完整性测试
页面完整性测试主要存在于集成测试阶段以及其后续其它阶段中，测试页面是否完整，页面质量是否达标，属于检查性测试。
UI合理性测试
UI合理性测试也就是人机交互界面的合理性，UI合理性测试的内容很多，具体测试内容如下：
提示、菜单、帮助的格式是否一致；
提示、菜单、帮助中的术语是否一致；
各个控件之间的对齐方式是否一致；
输入界面与输出界面在外观、布局、交互方式上是否一致；
功能类似的相关界面在外观、布局、交互方式上是否一致；
同一层次的文字在同一种提示场合〔一般情况、特殊字体、警告等〕在文字大小、字体、颜色、对齐方式方面是否一致，字体大小 是否及界面的大小比例协调；
第 10 页
多个连续界面依次出现的情况下，界面的外观、操作方式是否一致；
系统是否拒绝客户的错误输入并做出提示；
系统是否在用户完成操作时给出操作成功的提示；
用户界面是否存在空白空间，没有空白空间的界面是杂乱无章的，易用性差；
各个控件的间隔是否一致，垂直与水平方向上是否对齐；
是否允许动作的可逆性，返回原有操做；
数据与数据库完整性测试
因为在开发阶段开发人员随时都有可能根据需要来修改数据库，所以对数据与数据库完整性测试在软件工程的任何阶段也是非常必要的。该项测试内容主要是以数据库表为单位，检查数据库表以及表中各字段命名是否符合命名标准，表中字段是否完整，数据库表中的字段描述是否正确包括字段的类型、长度、是否为空，数据库表中的关系、索引、主键、约束是否正确。
第 11 页
功能测试
功能测试在软件工程的任何阶段中都是重要的。实现功能，满足客户需求是软件本身最大的使命。功能测试在任何阶段下根本上都作为测试工作的第一项出现。该项测试任务主要为了测试已实现的功能是否满足需求，是否正确，是否有价值以及是否完整。在黑盒与白盒测试状态下，该测试均会被使用。
功能测试中测试人员往往会忽略掉一些细节问题，比方：一个功能的实现必须要经过6步操作才能完成，而且需要参加20条信息才能看得出测试结果，有的测试人员为了节省时间虽然做完了6步操作，但是没有参加足量的信息，,使得测试不全面,正是因为这样而导致一些隐藏的BUG没有被测试出来。所以说在功能测试中要按部就班的把所有要进展的测试功能每一步都执行一遍，应该添加的数据都添加完整，以防止遗漏掉BUG没有测试出来。
第 11 页
压力测试
压力测试是为了发现在什么条件下您的应用程序的性能会变得不可承受。这通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。这种操作也称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进展压力测试。
对应用程序进展压力测试最简单的方法是手工改变输入〔客户机数量、需求大小、请求的频率、请求的混合程度等等〕并描绘性