测试计划检查表

合集下载

测试过程检查表

3. 测试计划文档检查表作者填写
评审者填写
检查点
检查点符合项位置
作者备注
是否达标
评审者意见
1 文档格式是否符合 XX 银行信息技术部测试体系模版
2 待测软件系统的名称是否明确
3 测试计划文档目的描述是否明了
Y N NA
作者填写
评审者填写
检查点
检查点符合项位置
作者备注
是否达标
14 测试计划是否包含定量管理部分
Y N NA
作者填写
评审者填写
检查点
检查点符合项位置
作者备注
是否达标
评审者意见
15 是否列出了不同测试阶段的工作产品，这些工作产品是否定义清晰
16 测试计划中是否有测试风险管理相关内容，内容是否合理
Y N NA
作者填写
评审者填写
检查点
检查点符合项位置
20 测试计划中是否包含了测试活动中的沟通计划和问题管理，这两项是否合理
Y N NA
作者填写
评审者填写
检查点
检查点符合项位置
作者备注
是否达标
评审者意见
21 测试计划中是否定义了跟踪与监控的相关内容，此章节内容是否合理
Y N NA
4. 测试风险管理流程检查表
评审者填写
检查点
评审者填写
检查点
8 测试计划是否标识出测试需求要点
Y N NA
作者填写
评审者填写
检查点
检查点符合项位置
作者备注
是否达标
评审者意见
9 所编写的测试计划中是否评估了依赖关系

测试过程检查表

检查点
评审者填写
是否达标
评审者意见
Y
N
NA
4
测试组长是否定义了
测试的进入/退出/中
断/继续标准
5
测试组长是否列出了
测试产品列表
6
测试组长是否定义了
测试活动的WBS（工作
分解）
7
测试组长是否定义了
测试活动不同阶段的
里程碑
8
测试组长是否列出了
测试阶段和测试活动
生命周期
9
测试组长是否确立了
估算的假设条件，并对
是否有各类
资源的使用
情况与统计
数据
4
测试报告中是否有测试覆盖率分析和统计如测试对需求的覆盖率。
检查点
作者填写
评审者填写
检查点
符合项
位置
作者备注
是否达标
评审者意见
Y
N
NA
5
测试报告中
是否有缺陷
统计与分析
6
测试报告中是否有按缺陷严重性分类、缺陷状态分类的的统计和分析
检查点
作者填写
评审者填写
11
测试方法策略中是否定义出不同测试阶段用到的测试类
型，内容是否完整合理
12
测试计划是
否包括测试
执行安排
检查点
作者填写
评审者填写
检查点
符合项
位置
作者备注
是否达标
评审者意见
Y
N
NA
13
是否在测试
计划中列出
所需使用的测试工具
14
测试计划是
否包含定量
管理部分
检查点
作者填写

软件设计评审检查表

是否所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰的描述？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
详细设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
正确性
是否处理所有条件（大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
该测试计划是否和更高级别的测试计划文档一致？
正确性
该测试计划的进入和退出条件是否实现？
是否所有必须的驱动程序和桩（stubs）都已被定义且可利用来测试指定的功能？
详细级别/程度
是否定义了总体设计目标？
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？

人行道检测计划表

人行道检测计划表(中英文版)**Walkway Inspection Schedule**In order to ensure the safety and functionality of our city"s sidewalks, we have developed a comprehensive inspection plan.This plan is designed to regularly assess the condition of our sidewalks and address any necessary repairs or maintenance.为了确保我们城市人行道的安全和功能，我们制定了一个全面检测计划。

此计划旨在定期评估人行道状况，并解决必要的修复或维护问题。

The first step in our inspection process is to conduct a visual assessment of each sidewalk.This assessment will be done by our trained inspectors who will be looking for any signs of damage or wear.我们检测过程的第一步是对每条人行道进行视觉评估。

这项评估将由我们的训练有素的检查员完成，他们将寻找任何损害或磨损的迹象。

After the visual assessment, our inspectors will use specialized tools to test the structural integrity of the sidewalks.This will include checking for any cracks or uneven surfaces that could pose a risk to pedestrians.视觉评估后，检查员将使用专业工具测试人行道的结构完整性。

ASD_文件命名规范(打印版)

注意：
1.这里只统一开发过程文档的命名（源代码部分遵循公司的“编码规范”），开发类文档命名规范：<项目名称>_[Future ID]_<文件种类>_<V版本号/撰写日期>_[R]（中文注释）
其中[Future ID]命名规则：<开发阶段>_<主功能ID>_<子功能ID>
备注：下划连线“_”用来分开各名称域
R全称Relating,表示关联文档，若某一文档存在关联文档，则关联文档命名需用R标识，以作区别，
如：
91Note_A01_01_PDD_V1.0_R(A01阶段01概要设计关联文档)
示例：91Note_A01_PDP_V1.0(A01阶段开发计划)
91Note_A01_01_PDP_V1.0(A01阶段01***开发计划)
91Note_PDP_V1.0(开发计划)
91Note_FP_V1.0(feature计划明细表)
91Note_A01_01_PDD_V1.0(A01阶段01概要设计文档)
91Note_A01_01_PDD_V1.0_R(A01阶段01概要设计关联文档)
2.以上文档的格式请参考部门制定的模板或范例,详情参见日常管理目录下的模版目录和SOP目录
3.其中，待办单，风险跟踪表，版本发布计划，产品创新需求统计，各项目均已统一整合到FID明细表，统一按FID明细表文件命名（FID明细表简称FP）
备注：文档命名规范【】里头的相应字段，若无，则可省略。

测试计划评审检查表

5 是否明确测试环境（软件、硬件环境）？
6 是否对选定的测试工具的相关信息进行了详细描述并且经过确认？
7 测试各阶段的人员和进度安排是否合理？是否确定了测试阶段存在的主要风险，制定了详细的控制措施，并已经取得部
8 门或公司领导层的支持？
9 是否明确了配置库的层次结构？
10 《配置库结构层次ຫໍສະໝຸດ 》中确定的层次结构是否完整、实用？
11 是否明确了测试过程中基准配置项变更与完善控制的界定准则？
说明：（责任人对确定为“否”的检查项给出必要说明）
第 1 页/共 1 页
测试计划评审检查表
表格编号：项目编号-阶段/文档类别代号-两位顺序号
项目名称：
序号
检查项
结果
1 是否明确测试目的、预期达到的目标以及本次测试的范围？
2 是否完整、清晰地列出本计划中的专用词汇，并沿用了先前过程中定义词汇？
3 是否根据确定的测试类型与测试范围明确测试所需的手段、方法？
4
是否根据软件产品或项目的实际特点，对"A"、"B"、"C"、"D"四类问题的分级原则进行了明确、详细地描述？

软件测试检查表

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. 大数据量的处理，如导入、导出、系统备份、文件传输等；。

消防维护管理月检,季检,年检表格汇总

3
按安装量的30%试验选层（或选区）广播，检查广播声级是否正常
移动灭火器
1
检查灭火器的种类、数量、设置位置、标志等是否符合要求
2
按照总数的30%检查灭火器的压力、重量、有效期等是否合格，必要时做喷射试验
其它消防设施
1
配合使用单位试验自备发电设施能否正常切换和发电，测试投入时间
2
配合使用单位试验消防电梯的迫降功能是否正常
类别
序号
检查项目及内容
检查情况
整改措施
整改结果
结果验证
备注
消防
通讯
1
检查电话插孔、对讲电话、播音设备、扬声器等设备是否正常完好
气体灭火系统
1
检查贮瓶间及防护区的工作环境
2
检查系统贮气瓶、驱动瓶、瓶头阀、选择阀、管网（含高压软管）、喷嘴、紧急按钮、声光等设施设备是否正常完好
3
检查储气瓶、驱动瓶内气体压力是否合格（不小于设计压力的90%）
其它
1
检查消防通道是否畅通
注：对照月检表逐项进行检查，检查正常的在所属栏内注明正常，检查发现有问题的及时记录，并做出整改；整改完毕后物业部工程师对结果进行验证。
C6
1.1周期检查表
1.1.2季度检表（表2-1）检查人签名/日期：
类别
序号
检查项目及内容
检查情况
整改措施
整改结果
结果验证
备注
火灾自动报警系统
2
试验电话插孔和对讲电话的通话质量
3
试验选层（或选区）广播，检查广播声级是否正常
移动灭火器
1
检查灭火器的种类、数量、设置位置、标志等是否符合要求
2
检查灭火器的压力、重量、有效期等是否合格，必要时做喷射试验

测试过程检查表

检查点
作者填写
评审者填写
检查点符
合项位置
作者备注
是否达标
评审者意见
Y
N
NA
1
文档格式是否符合XX银行信息技术部测试体系模版？
2
待测软件系统的名称是否明确？
3
测试计划文档目的描述是否明了？
检查点
作者填写
评审者填写
检查点符
合项位置
作者备注
是否达标
评审者意见
Y
N
NA
4
是否使用了标准术语和统一形式？
1.
检查点
评审者填写
是否达标
评审者意见
Y
N
NA
1
是否在请求测试服务时提交了《测试服务申请单》？
2
对于项目类测试服务，是否在需求评审阶段就提交了《测试服务申请单》？
3
对于项目类任务的测试请求，是否同时提交了
《开发计划书》？
4
《测试服务申请单》是否经过审核并填写了审核意见？
5
对于项目类任务的测试请求，是否使用《测试工作量估算表》进行了测试工作量估算？
检查点
评审者填写
是否达标
评审者意见
Y
N
NA
4
测试组长是否定义了测试的进入/退岀/中断/继续标准？
5
测试组长是否列岀了测试产品列表？
6
测试组长是否定义了测试活动的WBS(工作分解)？
7
测试组长是否定义了测试活动不同阶段的里程碑？
8
测试组长是否列岀了测试阶段和测试活动生命周期？
9
测试组长是否确立了估算的假设条件，并对估算结果进行记录？

单元测试检查表

单元测试检查表单元测试是软件开发中的重要环节，它可以确保代码的正确性和稳定性。

为了帮助开发人员进行有效的单元测试，本文将介绍一些实用的单元测试检查表。

首先，让我们了解一下什么是单元测试。

单元测试是针对程序中的每个独立单元或模块进行测试的过程。

这些测试通常由开发人员编写，用于验证他们的代码是否按预期工作。

单元测试的主要目标是发现代码中的错误和缺陷，从而提高软件的质量和可靠性。

在编写单元测试时，以下是一些实用的检查点：1、明确测试的目的和范围：在开始编写测试用例之前，确保清楚地了解测试的目的和范围。

这有助于确定需要测试哪些功能以及如何设计测试用例。

2、编写可重复的测试用例：确保测试用例可以重复执行，以验证相同的输入是否产生相同的结果。

这有助于确保代码的稳定性和一致性。

3、确保测试覆盖率：尽量确保测试覆盖了所有可能的代码路径和边界条件。

这有助于提高测试的可靠性和全面性。

4、验证输出：除了确保代码按预期执行外，还要验证输出是否符合预期结果。

这有助于确保代码的正确性和符合预期的业务需求。

5、处理异常情况：编写测试用例时，确保考虑了各种异常情况和边界条件。

这有助于发现潜在的错误和缺陷，提高软件的鲁棒性和稳定性。

6、监控性能：在编写测试用例时，注意监控代码的性能。

这有助于发现潜在的性能问题，确保代码在高负载情况下仍能保持稳定。

7、代码重构：在编写测试用例时，不要害怕重构代码。

这有助于提高代码质量和可维护性，同时使测试更加可靠和稳定。

8、持续集成和自动化测试：将单元测试纳入持续集成流程，并实现自动化测试。

这有助于确保代码的及时验证和持续改进，提高开发效率和软件质量。

总之，单元测试是软件开发过程中不可或缺的一环。

通过遵循以上实用的检查点，开发人员可以编写可靠、全面的单元测试，从而提高软件的质量和稳定性。

《成长的节拍》单元测试成长的节拍成长是一个人生旅程的重要阶段，它充满了挑战、机遇和收获。

在这个过程中，我们不断学习、改变和适应，以便更好地适应生活的各种要求。

ck_检查表_软件工程.xls

8
技术代码中注释的数量是否合理？
9
技术调试信息是否被注释掉？
10
技术局部变量和全局变量的定义是否没有冲突？
11
技术是否有冗余或无用的变量？
12
技术变量和属性是否都正确的初始化？
13
技术变量使用结束后是否都赋了空值？
14
技术被赋值的变量，其变量类型是否一致或被正确转换？
15
技术代码能否通过本地的编译和调试？
21
技术每一个布尔测试，是否都检查过正确的条件？
符合
不符合不适用
备注
22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
确认信息
技术技术技术技术技术技术技术技术技术技术技术技术技术技术技术
循环结束的条件是否明显，并总能够达到？被除数是否做了零值测试？所有的边界值是否都作了考虑，并正确的进行了处理？如果一个循环有多个出口，是否每个出口都正确处理？ Switch声明是否都有default条件？循环和分支的嵌套是否过深？是否不合理？数组是否被合理定义范围？标记的不确定或错误的代码是否被改正？每个程序段是否只有一个入口和一个结束点？调用文件前是否被打开？文件使用后是否被关闭？所有的I/O异常是否被正确的处理？是否所有的代码都能有效被调用或执行？代码是否准确的实现了需求要求？代码是否准确的实现了设计要求？
过程
》配置管理员是否依据《发布申请审核单》，从产品库中提取产品组件
过程打包顺序是否在《发布申请审核单》中描述
符合
不符合不适用
备注
6 7 8 9
确认信息
过程过程过程过程

软件设计评审检查表

测试计划检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？

消防维保月检、季检、年检表格2017-7-26

一、工作进度计划表及周期检查表消防系统维保工作按每月、每季、每年度进行,每半年进行一次全联动测试。

1. 年度检查计划安排：江苏盛华系统集成工程技术有限公司0C4 1。

1周期检查表1.1.1月检表（表1—1) 检查人签名/日期：江苏盛华系统集成工程技术有限公司0C5 1.1。

1月检表（表1-2) 检查人签名/日期：江苏盛华系统集成工程技术有限公司0注：对照月检表逐项进行检查,检查正常的在所属栏内注明正常，检查发现有问题的及时记录,并做出整改；整改完毕后物业部工程师对结果进行验证。

C61.1周期检查表江苏盛华系统集成工程技术有限公司01。

1.2季度检表(表2-1) 检查人签名/日期:江苏盛华系统集成工程技术有限公司0C71。

1周期检查表1。

1。

2季度检表(表2-2) 检查人签名/日期：江苏盛华系统集成工程技术有限公司0C8 1.1周期检查表江苏盛华系统集成工程技术有限公司01.1.2季度检表（表2-3）检查人签名/日期：江苏盛华系统集成工程技术有限公司01.1周期检查表1.1.3年检表（表3—1）检查人签名/日期：江苏盛华系统集成工程技术有限公司0江苏盛华系统集成工程技术有限公司0C10 1。

1周期检查表1.1。

3年检表（表3—2）检查人签名/日期：江苏盛华系统集成工程技术有限公司0C11 1。

1周期检查表检查人签名/日期:1.1.3年检表（表3-3)江苏盛华系统集成工程技术有限公司0江苏盛华系统集成工程技术有限公司0江苏盛华系统集成工程技术有限公司。

测试过程检查表

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在发生需求改正，测试组长及测试需求剖析人员能否在判断了改正需求种类后，依照并履行了流程中规定的相应步骤。

品质检查表-月检计划测试表-月检评价报告-品质管理部门表格模板

备注
编号：WDSY/XA-FR-PZ0203序号：
月检评价报告
受检查部门：
受检日期：年月日
不合格事项描述：
管理质量评判
优秀口良好口
一般口不及格口
需口否口提交《纠正及预防措施报告》提交《纠正及预防措施报告》的问题描述：
检查组长签名：
受检部门负责人签名：
不合格事项验证：
验证人签名：日期：
注：周检、日常检查效果不好，部门（班队）负责人须填写《纠正预防措施报告》。
品质检查表
时间
检查问题描述
性质
整改期限
贡任人
整改意见
复验
检查人:
NO.025
注:
周检口日检口
1.“性质”栏中按《检查分析与评价指引》中的分类方法对问题进行评定;
2.此表在一个月内可连续使用，在规定的考核日之前汇总至相关考核人处作为考核依据。
一序号
测试点
测试方法
问题描述Βιβλιοθήκη （测试被通过打“J”）受检人

评审检查表

评审检查表
目录
1.项目计划检查表 (3)
2.需求规格阐明书检查表 (4)
3.概要设计阐明书检查表 (5)
4.具体设计阐明书检查表 (6)
5.编码检查表 (7)
6.测试用例检查表 (10)
7.产品验收和公布检查表 (11)
1.项目计划检查表
2.需求规格阐明书检查表
3.概要设计阐明书检查表
4.具体设计阐明书检查表
5.编码检查表
通过结合编码检查表和代码检查单，能够比较清晰地拟定代码问题的位置。

5.1.代码检查表
5.2.代码检查内容
备注：
1)激活：本列标注Y 的为激活的项目，表明这些项目必须被明确地自查（其它问题处在“顺
便被检查”的状态），在运行编码检查的时候，前期几乎全部项都要在激活状态；后期稳定后，保持8~10 个（或遵从目前规范）激活的检查项。

为了醒目，能够像此表这样将目前的激活项用亮黄色表达。

其中10~40 是编码错误，50~100 是设计错误。

3)检查项：全部检查项均为普通疑问句，当发现回答为“否”时，即存在一种缺点。

6.测试用例检查表
7.产品验收和公布检查表。

酒店建设施工试验检验计划表

屋面防水施工前
技术总工
18
屋面
耐根穿刺高聚物改性沥青防水卷材
技术部
屋面防水施工前
技术总工
28
导墙、构造柱
水泥
技术部
同一水泥厂、同期出厂、同一出厂编号及同 Nhomakorabea度水泥（散装W500吨/批、袋装W
200吨/批）。
材料进场前
技术总工
29
导墙、构造柱
黄砂
技术部
同一产地、同一规格、同一进场时间≤400m3∕批或W600吨/批。
材料进场前
技术总工
30
导墙、构造柱
石子
技术部
同一产地、同一规格、同一进场时间W400m3∕批或W600吨/批。
材料进场前
技术总工
31
地下室外墙、屋面
XPS挤塑板
技术部
单位面积2万平米以下时，抽取不少于3次，每
材料进场前
技术总工
次3块
耐碱网格布
8平米
技术总工
抹面胶浆
IOkg或5升
技术总工
胶黏剂
技术总工
每个单体
每施工一层
技术总工
42
单体
抽气（风）道检验
专业单位
每个单体
抽气（风）道施工完成后
技术总工
43
单体
外窗气密性水密性耐风压检测
专业单位
每个单体
门窗施工完成后
技术总工
44
单体
节能保温测试
专业单位
每个单体
装饰装修施工完成
技术总工
45
单体
室内环境检测
专业单位
每个单体
装饰装修施工完成
技术总工
单体
幕墙检测