下载文档原格式
产品测试质量检查表(范本模板)产品测试质量检查表1. 产品信息- 产品名称：- 版本号：- 发布日期：- 开发人员：- 测试人员：- 测试日期：2. 测试目标- 确保产品功能的完整性和正确性。
- 发现并修复产品中存在的缺陷和问题。
- 保证产品的稳定性和可靠性。
- 提供有效的测试报告和评估意见。
3. 测试范围- 测试的功能模块/页面/组件：1.2.3.- 测试的环境/设备：- 操作系统版本：- 浏览器版本：- 设备型号：4. 测试方法及标准4.1 功能性测试- 测试用例覆盖：- 确认所有功能模块是否都有对应的测试用例。
- 功能性测试内容：- 确认产品的主要功能是否可正常运行。
- 检查产品的输入、输出和操作是否符合预期。
- 功能性测试标准：- 产品的主要功能模块被确认为稳定可用。
4.2 兼容性测试- 测试环境覆盖：- 确认产品在不同操作系统、浏览器和设备上的兼容性。
- 兼容性测试内容：- 确认产品在不同操作系统、浏览器和设备上的显示正常。
- 确认产品在不同分辨率下的界面布局合理。
- 兼容性测试标准：- 产品在常见的操作系统、浏览器和设备上能够正常显示和操作。
4.3 性能测试- 测试负载和压力：- 测试产品在正常和峰值负载下的性能表现。
- 性能测试内容：- 测试产品的响应时间、并发用户数和吞吐量。
- 检查产品的资源消耗、内存泄漏和性能稳定性。
- 性能测试标准：- 产品在常规使用条件下的响应时间和吞吐量符合预期。
5. 测试结果- 缺陷和问题记录：- 记录产品中的缺陷和问题。
- 包括缺陷的描述、严重程度和修复建议。
- 测试评估意见：- 提供测试评估意见和建议。
6. 测试结论- 产品测试结果的总结和结论。
7. 附件- 测试用例文档。
- 测试环境配置说明。
以上是产品测试质量检查表的范本模板，根据实际情况进行详细填写，以确保测试过程的全面性和有效性。
测试完成后，需将测试结果和评估意见及时反馈给开发人员，以便及时进行问题修复和改进。
1. 检查每轮测试开始时测试环境是否准备好（包括软件硬件、测试基本数据等）；3. 每轮测试根据上一轮的情况和总体测试计划做分工调整；4. 检查case库的填报情况，抽查执行过的case；5. 检查BUG提交情况，抽查提交的BUG是否规范；6. 每天晚上统计BUG情况，填写每天的BUG报告；7. 根据每天的测试情况，决定是否开发组要发布新的BUILD；8. 每轮测试结束后填写测试总结。
2 下面是针对测试执行人员的：2.1 输入、编辑功能的验证检查点：1. 必输项是否有红星标记，如果不输入提示是否跟相应的Label对应，提示的顺序是否跟Form输入域的排列次序一致；3. Form下拉菜单的值是否正确，下拉菜单的值通过维护后是否正确显示并可用；下拉菜单比如是机构编码，要到机构编码的维护界面查询一下是否Form列出的与其一致；4. 涉及到下拉菜单的编辑修改Form，要检查在编辑和修改From中，下拉菜单是否能正确显示当前值；5. Form提交后，要逐项检查输入的内容跟通过查询的结果一致；6. 有多层下拉菜单选择的情况要校验两层菜单的选择是否正确，比如：部门财务软件开发部人员张三7. 备注字段的超常检查；8. 提交保存后能否转到合适的页面；9. 编辑Form显示的数据是否跟该记录的实际数据一致；10. 编辑权限的检查，比如：user1的数据user2不能编辑等；11. 可编辑数据项的检查，比如：数据在正式提交之前所有的属性都可以编辑，在提交之后，编号、状态等不能编辑，要根据业务来检查是否符合需求；12. 对于保存有事务Trasaction提交，比如一次提交对多表插入操作，要检查事务Trasaction的处理，保证数据的完整和一致；13. 其他的合法性校验。
2.2 查询功能检查点：1. 查询输入Form是否正常工作，不输入数据是否查询到全部记录；2. 当查询的数据非常多的时候，性能有无问题；3. 查询的下拉菜单列出的数据是否正确；4. 查询结果是否正确；对于复杂的查询要通过SQL来检查结果；5. 如输入%*?等统配符是否会导致查询错误；6. 查询结果列表分页是否正确，在点击下一页上一页时，查询条件是否能带过去，不能点击翻页时又重新查询；7. 对于数据量比较大的表查询时，不容许无条件查询，避免性能问题的出现；8. 对于查询输入项的值是固定的要用下拉菜单，比如状态、类型等；9. 分页的统计数字是否正确，共X页，第N页，共X条记录等；10. 对于查询有统计的栏目，比如：总计、合计等要计算数据是否正确；11. 查询结果有超链接的情况要检查超链接是否正确；12. 查询权限的检查，比如：user1不能查询到user2的数据等；2.3 删除功能检查点：1. 必须有“确认删除”的提示；2. 根据需求检查是软删除还是硬删除，来检查数据库中是否还存在该条记录；3. 是否有相关的数据删除，如果有要确认该相关的数据也已经删除，并且在同一事务中完成；4. 是否有删除约束，如果有删除约束，要检查该记录是否被约束，如果被约束该记录不能被删除；5. 如果是软删除，用查询、统计界面检查该条记录能否被查询出来，数据是否被统计进去；6. 检查因为业务约束不能删除的数据能否被保护不能手工删除，比如：流程中已经审批的文件不能被删除；7. 跟删除相关的权限问题，比如：需求要求只有管理员和该记录的创建人能够删除该记录，那就以不同的用户和角色登录进去，执行删除操作，检查是否与需求匹配；2.4 上传附件检查点：1. 检查是否能正确上传附件文件；2. 检查上传的文件是否能正确下载并打开；3. 至少检查下列大小的文件能正确上传，100k,1M,2M,4M,10M,20M等；4. 如果没有指定类型的限制，至少上传以下几种类型的文件能否正确上传并正确打开，类型有：.doc, .xls, .txt, .ppt, .htm, .gif, .jpg, .bmp, .tif, .avi等；5. 如果有文件类型的限制还要检查能上传的文件的类型；6. 上传同名的文件，在打开的时候是否出错；7. 有中文文件名的文件能否正确上传；2.5 影响操作性能的检查点：（不能代替系统的性能测试和压力测试，主要看系统在正常操作情况下的响应和处理能力）1. 对数据记录条数比较多的表的查询操作，避免全表查询，比如对银行用户账号的查询就不能缺省全部查出，必须让用户输入查询条件；2. 菜单树，测试大量数据时菜单树的响应情况；3. 有日志的查询或者统计，要注意查询的效率；4. 大报表的处理或者批处理的操作，要关注效率，比如：银行对帐、财务年终结算、财务年报表、系统初始化等；5. 大报表的排序sort、组函数的使用等；6. 大数据量的处理，如导入、导出、系统备份、文件传输等；。
1. 测试恳求管理过程检查表检查点能否达标评审者填写评审者建议Y N NA1能否在恳求测试服务时提交了《测试服务申请单》？2对于项目类测试服务，能否在需求评审阶段就提交了《测试服务申请单》？3对于项目类任务的测试恳求，能否同时提交了《开发计划书》？4《测试服务申请单》能否经过审查并填写了审查建议？5对于项目类任务的测试恳求，能否使用《测试工作量估量表》进行了测试工作量估量？2.测试计划流程检查表检查点能否达标评审者填写评审者建议Y N NA1测试组长有没有获取有关的测试依照，如开发计划书、技术方案，项目计划等文档？2测试组长有没有依据测试依照确定系统中可测试的范围和不做测试的范围？检查点能否达标评审者建议Y N NA3测试组长有没有定义针对可测内容的测试方法，测试技术、用到的测试工具，发现与组织级测试策略不一致的地方，并采纳了相应的应付策略？4测试组长能否认义了测试的进入 /退出 /中止 / 持续标准？5测试组长能否列出了测试产品列表？6测试组长能否认义了测试活动的 WBS（工作分解） ?7测试组长能否认义了测试活动不一样阶段的里程碑？8测试组长能否列出了测试阶段和测试活动生命周期？9测试组长能否确定了估量的假定条件，并对估量结果进行记录？10测试组长在编写测试计划从前，能否有测试进度表，能否已经辨别了与测试有关的项目风险 ?11测试计划中能否认义出了测试活动中有关的关连人？12测试计划中能否包含了测试风险、交流、追踪与监控等内容？13在测试计划达成后，同行（ peer）能否从充足性和切合测试标准的角度对此计划进行评审和检查？14测试组长能否和测试活动关连人一同按期对测试计划进行复审，找出偏离内容？检查点能否达标评审者建议Y N NA15测试活动关连人、能否针对测试计划给出版面承诺并按期关注测试活动进展？16能否追踪测试活动过程中与计划不切合的地方（称为“偏离” ），主假如对影响测试计划的因素，测试资源的使用状况，测试承诺的实现状况，项目风险（测试有关），关连人的参加状况进行追踪，并按期对测试进度和里程碑进行回首和评审？17能否追踪产质量量与计划和预期的偏离，主假如对进入标准、退出标准、中止与持续标准的履行状况，缺点，产品风险等进行追踪与监控，并按期组织对产质量量和产质量量里程碑的回首与评审？18能否追踪已发现的偏离，直至封闭，在此过程中需要剖析问题，成立对不切合项的纠正举措并追踪纠正状况？3.测试计划文档检查表检查点1文档格式能否切合 XX银行信息技术部测试系统模版？作者填写评审者填写检查点符合项地点作者备注能否达标评审者建议Y N NA检查点2待测软件系统的名称能否明确？3测试计划文档目的描绘能否了然？4能否使用了标准术语和一致形式？5使用的术语是不是独一的？6同义词、缩略语等的使用在全文中能否一致并预先已予以说明？7计划文档中的大部分内容是不是由测试组长编写的？能否与其余组议论过？8测试计划能否表记出测试需求重点？9所编写的测试计划中能否评估了依靠关系？10所编写测试计划中能否描绘了测试进入标准、退出标准、中止 / 持续标准？标准能否能够胸怀？检查点符合项地点作者备注能否达标评审者建议Y N NA检查点11测试方法策略中能否认义出不一样测试阶段用到的测试种类，内容能否完好合理？12测试计划能否包含测试履行安排？13能否在测试计划中列出所需使用的测试工具？14测试计划能否包含定量管理部分？15能否列出了不一样测试阶段的工作产品，这些工作产品能否认义清楚？16测试计划中能否有测试风险管理有关内容，内容能否合理？17测试计划中波及到的测试人员及测试活动关连人能否认义清楚，并明确了有关人员的职责？18测试计划中的人员安排及任务分派能否合理？检查点符合项地点作者备注能否达标评审者建议Y N NA检查点19测试计划中的测试活动进度安排能否合理？20测试计划中能否包含了测试活动中的交流计划和问题管理，这两项能否合理？21测试计划中能否认义了追踪与监控的有关内容，此章节内容能否合理？检查点符合项地点作者备注能否达标评审者建议Y N NA4.测试风险管理流程检查表评审者填写检查点能否达标评审者建议Y N NA1． 0 通用标准与列表1.1测试负责人能否组织有关人员定义了测试风险评估标准？1.2测试负责人能否拟订了通用的测试风险列表？1.3通用测试风险列表中能否划分了风险类型（项目风险（测试有关）、产品风险），并设置了初始信息（如可能性、影响度、风险等级、对应举措等）1.4测试负责人能否认期保护通用测试风险列表？2． 0 辨别测试风险评审者填写检查点能否达标评审者建议Y N NA2.1测试组长在辨别测试风险时，能否邀请了有关人员参与并从中获取了必需的信息？2.2测试组长在辨别并记录测试风险时，能否使用组织统一的模板？3． 0 测试风险剖析3.1测试组长能否在有关人员的辅助下，对所辨别出的测试风险进行评级？3.2测试组长能否认期保护（修改）测试风险？3.3测试组长能否起码为高等级项目风险（测试有关）制定了风险管理计划？4． 0 测试风险监控3.1测试组长能否认期或在事件驱动状况下，监控辨别出的测试风险？5.测试需求管理流程检查表检查点能否达标评审者填写评审者建议Y N NA 1． 0 发送测试依照1.1在项目类/保护类任务的需求阶段，项目经理能否实时向测试组长供给了流程中规定的测试依照？1.2在项目类/保护类任务的设计阶段，项目经理能否实时向测试组长供给了流程中规定的测试依照？1.3在需求改正发生时，项目经理能否实时向测试组长提供了有关资料？评审者填写检查点能否达标评审者建议Y N NA1.4测试组长能否实时将接收到的测试依照连同主测试计划 /阶段测试计划(草案 )发送给测试需求剖析人员？2． 0 考证测试依照2.1测试需求剖析人员能否对测试依照进行了考证并向测试组长和项目经理书面提交了考证建议？3． 0 定义测试需求3.1测试需求剖析人员在定义测试需求时，使用了 HP QC10.0 或一致的测试需求模板？3.2测试需求剖析人员在编写完测试需求后，能否填写了需求追踪矩阵？3.3测试组长能否组织了有关人员对测试需求进行评审？3.4测试组长能否组织了有关人员对测试需求进行风险评估定级？3.5在发生需求改正，测试组长及测试需求剖析人员能否在判断了改正需求种类后，依照并履行了流程中规定的相应步骤。
