测试提交文档 测试文档使用方法
在测试的过程中测试人员会用到三张表，第一张表是“测试任务表”，这张表中记录的是软件在每个版本的每个阶段中需要做的具体测试任务，如果测试中不确定需要做哪些测试，在这张表中可以查询各个阶段中所要进行的测试项。
还有两张表是需要在相应测试阶段来添写的测试文档，分别是“白盒缺陷测试报告”和“黑盒测试缺陷报告”两张表。单元测试和集成测试属于白盒测试范围，需要添写白盒缺陷测试报告；系统测试和验收测试属于黑盒测试范围，需要添写黑盒测试缺陷报告。
测试人员测试完成之后，需要把所添写的缺陷测试报告按时提交给项目经理，由项目经理来安排具体人员进行修改和审核。 测试文档下载 ? 测试任务表
? 白盒缺陷测试报告 ? 黑盒缺陷测试报告 注：
在每次的测试中测试人员需要按表中的要求进行添写测试报告，然后由项目经理来分配给开发人员处理，开发人员修改完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；两边之和大于第三边；有两边等长；三边等长。