测试用例检查表范
- 格式:docx
- 大小:7.66 KB
- 文档页数:2
SugarCRM_ST_Dashboard_RELATION-CONTACTS-01 SugarCRM_ST_Dashboard_RELATION-CONTACTS-02 SugarCRM_ST_Dashboard_RELATION-ACCOUNTS_01 SugarCRM_ST_Dashboard_RELATION-ACCOUNTS_02 SugarCRM_ST_Dashboard_RELATION-LEADS_01 SugarCRM_ST_Dashboard_RELATION-LEADS-02 SugarCRM_ST_Dashboard_RELATION-OPPORTUNITY_01 SugarCRM_ST_Dashboard_RELATION-OPPORTUNITY_02 SugarCRM_ST_Dashboard_RELATION-CASES_01 SugarCRM_ST_Dashboard_RELATION-CASES_02 SugarCRM_ST_Dashboard_RELATION-BUG TRACKER_01 SugarCRM_ST_Dashboard_RELATION-BUG TRACKER_02 SugarCRM_ST_My Portal_ADD_01测试Dashboard模块的关联联系人功能关联联系人,跳转到联系人模块测试Dashboard模块的关联联系人功能关联联系人,跳转到联系人模块测试Dashboard模块的关联客户功能关联客户,跳转到客户模块测试Dashboard模块的关联客户功能关联客户,跳转到客户模块测试Dashboard模块的关联潜在客户功能关联潜在客户,跳转到潜在客户模块测试Dashboard模块的关联潜在客户功能关联潜在客户,跳转到潜在客户模块测试Dashboard模块的关联商业机会功能关联商业机会,跳转到商业机会模块测试Dashboard模块的关联商业机会功能关联商业机会,跳转到商业机会模块测试Dashboard模块的关联客户反馈功能关联客户反馈,跳转到客户反馈模块测试Dashboard模块的关联客户反馈功能关联客户反馈,跳转到客户反馈模块测试Dashboard模块的关联缺陷跟跟踪功能关联缺陷跟踪,跳转到缺陷跟踪模块测试Dashboard模块的关联缺陷跟跟踪功能关联缺陷跟踪,跳转到缺陷跟踪模块测试My Portal模块的新增站点功能新增网站信息高能正常运行无到Contacts模块,对联系人进行创建高Dashboard模块能正常运行无1、点击【Create Conta】,跳转到非Contacts模块,跳转错误高Dashboard模块能正常运行无1、点击【Create Account】,成功跳转到Accounts模块,对客户进行创建高Dashboard模块能正常运行无1、点击【Create Account】,跳转到非Accounts模块,跳转错误高Dashboard模块能正常运行无1、点击【Create Lead】,成功跳转到Leads模块,对潜在客户进行创建高Dashboard模块能正常运行无1、点击【Create Lead】,跳转到非Leads模块,跳转错误高Dashboard模块能正常运行无1、点击【Create Opportunity】,成功跳转到Opportunitys模块,对商业机会进行创建高Dashboard模块能正常运行无1、点击【Create Opportunity】,跳转到非Opportunitys模块,跳转错误高Dashboard模块能正常运行无1、点击【Create Case】,成功跳转到Cases模块,对客户反馈进行创建高Dashboard模块能正常运行无点击【Create Case】,跳转到非Cases模块,跳转错误高Dashboard模块能正常运行无1、点击【Report Bug】,成功跳转到Bug Tracker模块,对缺陷进行创建高Dashboard模块能正常运行无1、点击【Report Bug】,跳转到非BugTracker模块,跳转错误高成功跳转到Contacts模块成功跳转到Contacts模块成功跳转到Accounts模块成功跳转到Accounts模块成功跳转到Leads模块成功跳转到Leads模块成功跳转到Opportunitys模块成功跳转到Opportunitys模块成功跳转到Cases模块成功跳转到Cases模块成功跳转到Bug Tracker模块成功跳转到Bug Tracker模块。
模块接口测试
外部输入输出
检查局部数据结构路径测试和循环测试
判断与控制流
单元测试
1 输入的实际参数与形式参数的个数是否相同;
2 输入的实际参数与形式参数的属性是否匹配;
3 输入的实际参数与形式参数的量纲是否一致;
4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同;
5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配;6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致;
7 调用预定义函数时所用参数的个数、属性和次序是否正确;
8 是否存在与当前入口点无关的参数引用;
9 是否修改了只读型参数;
10 对全程变量的定义各模块是否一致;
11是否把某些约束作为参数传递。
1 文件属性是否正确;
2 OPEN/CLOSE语句是否正确;
3 格式说明与输入输出语句是否匹配;
4缓冲区大小与记录长度是否匹配;
5文件使用前是否已经打开;
6是否处理了文件尾;
7是否处理了输入/输出错误;
8输出信息中是否有文字性错误;
1 不合适或不相容的类型说明;
2变量无初值;
3变量初始化或省缺值有错;
4不正确的变量名(拼错或不正确地截断);
5出现上溢、下溢和地址异常。
1 误解或用错了算符优先级;
2混合类型运算;
3变量初值错;
4精度不够;
5表达式符号错。
1不同数据类型的对象之间进行比较;
2错误地使用逻辑运算符或优先级;
3因计算机表示的局限性,期望理论上相等而实际上不相等的两个量相等;4比较运算或变量出错;
5循环终止条件或不可能出现;
6迭代发散时不能退出;
7错误地修改了循环变量。
测试用例模板(Test Case Template)┏━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━┓┃用例编号│┃┠──────┼───────────────────────────┨┃测试优先级│┃┠──────┼───────────────────────────┨┃用例摘要│┃┠──────┼───────────────────────────┨┃测试类型│┃┠──────┼───────────────────────────┨┃用例类型│┃┠──────┼───────────────────────────┨┃用例设计者│┃┠──────┼───────────────────────────┨┃设计日期│┃┠──────┼───────────────────────────┨┃对应需求编号│┃┠──────┼───────────────────────────┨┃对应UI│┃┠──────┼───────────────────────────┨┃对应UC│┃┠──────┼───────────────────────────┨┃版本号│┃┠──────┼───────────────────────────┨┃对应开发人员│┃┠──────┼───────────────────────────┨┃前置条件│┃┠──────┼───────────────────────────┨┃测试方法│┃┠──────┼───────────────────────────┨┃输入数据│┃┠──────┼───────────────────────────┨┃执行步骤│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┃│┃┠──────┼───────────────────────────┨┃预期输出│┃┠──────┼───────────────────────────┨┃实际结果│┃┠──────┼───────────────────────────┨┃测试日期│┃┠──────┼───────────────────────────┨┃结论│┃┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛sample┏━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━┓┃用例编号│BOSS_ FS_ MARKETING_NEW_01P┃┠──────┼───────────────────────────┨┃测试优先级│高(还有“较高、中、较低、低”几个等级)┃┠──────┼───────────────────────────┨┃用例摘要│新增营销记录┃┠──────┼───────────────────────────┨┃测试类型│功能性测试(对应还有“安全性测试”等)┃┠──────┼───────────────────────────┨┃用例类型│基本事件(对应还有“备选事件”、“异常事件”)┃┠──────┼───────────────────────────┨┃用例设计者│songfun┃┠──────┼───────────────────────────┨┃设计日期│2005-04-25┃┠──────┼───────────────────────────┨┃对应需求编号│REQ_ MARKETING_NEW_01┃┠──────┼───────────────────────────┨┃对应UI│Marketing.htm┃┠──────┼───────────────────────────┨┃对应UC│UC_ MARKETING_NEW_01┃┠──────┼───────────────────────────┨┃版本号│Build v0.1┃┠──────┼───────────────────────────┨┃对应开发人员│Frank┃┠──────┼───────────────────────────┨┃前置条件│操作员登录营销管理系统┃┠──────┼───────────────────────────┨┃测试方法│等价类划分(对应还有“错误猜测法”、“边界值分析”等)┃┠──────┼───────────────────────────┨┃输入数据│用户名:testing 性别:男金额:10元描述:aaaaaaa┃┠──────┼───────────────────────────┨┃执行步骤│①.进入【营销下发】页面;┃┃│②.点击『增加』按钮;┃┃│③.输入相应数据;┃┃│④.点击『确定』按钮;┃┃│⑤.在后台数据库(test/test@testDB)输入查询语句验证:┃┃│select * from MarketingTab where ID='1001'┃┃│┃┠──────┼───────────────────────────┨┃预期输出│㈠.执行步骤④后,页面弹出添加成功提示信息框;┃┃│㈡.执行步骤⑤后查询数据库,记录确实添加成功且数据无误┃┃│┃┠──────┼───────────────────────────┨┃实际结果│符合预期┃┠──────┼───────────────────────────┨┃测试日期│2005-05-01┃┠──────┼───────────────────────────┨┃结论│┃┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛。
测试检查表checklist输入、编辑功能的验证检查点:1. 必输项是否有红星标记,如果不输入提示是否跟相应的Label对应,提示的顺序是否跟Form输入域的排列次序一致;2. 输入的特殊字符是否能正确处理:`~!@#$%^&*()_+-={}[]|\:;”’ <>,./?;3. Form下拉菜单的值是否正确,下拉菜单的值通过维护后是否正确显示并可用;下拉菜单比如是机构编码,要到机构编码的维护界面查询一下是否Form列出的与其一致;4. 涉及到下拉菜单的编辑修改Form,要检查在编辑和修改From中,下拉菜单是否能正确显示当前值;5. Form提交后,要逐项检查输入的内容跟通过查询的结果一致;6. 有多层下拉菜单选择的情况要校验两层菜单的选择是否正确;7. 备注字段的超长检查;8. 提交保存后能否转到合适的页面;9. 编辑Form显示的数据是否跟该记录的实际数据一致;10. 编辑权限的检查,比如:user1的数据user2不能编辑等;11. 可编辑数据项的检查,比如:数据在正式提交之前所有的属性都可以编辑,在提交之后,编号、状态等不能编辑,要根据业务来检查是否符合需求;12. 对于保存有事务Transaction提交,比如一次提交对多表插入操作,要检查事务Transaction的处理,保证数据的完整和一致;13. 其他的合法性校验。
查询功能检查点:1. 查询输入Form是否正常工作,不输入数据是否查询到全部记录;2. 当查询的数据非常多的时候,性能有无问题;3. 查询的下拉菜单列出的数据是否正确;4. 查询结果是否正确;对于复杂的查询要通过SQL来检查结果;5. 如输入%*?等通配符是否会导致查询错误;6. 查询结果列表分页是否正确,在点击下一页上一页时,查询条件是否能带过去,不能点击翻页时又重新查询;7. 对于数据量比较大的表查询时,不容许无条件查询,避免性能问题的出现;8. 对于查询输入项的值是固定的要用下拉菜单,比如状态、类型等;9. 分页的统计数字是否正确,共X页,第N页,共X条记录等;10. 对于查询有统计的栏目,比如:总计、合计等要计算数据是否正确;11. 查询结果有超链接的情况要检查超链接是否正确;12. 查询权限的检查,比如:user1不能查询到user2的数据等;删除功能检查点:1. 必须有“确认删除”的提示;2. 根据需求检查是软删除还是硬删除,来检查数据库中是否还存在该条记录;3. 是否有相关的数据删除,如果有要确认该相关的数据也已经删除,并且在同一事务中完成;4. 是否有删除约束,如果有删除约束,要检查该记录是否被约束,如果被约束该记录不能被删除;5. 如果是软删除,用查询、统计界面检查该条记录能否被查询出来,数据是否被统计进去;6. 检查因为业务约束不能删除的数据能否被保护不能手工删除,比如:流程中已经审批的文件不能被删除;7. 跟删除相关的权限问题,比如:需求要求只有管理员和该记录的创建人能够删除该记录,那就以不同的用户和角色登录进去,执行删除操作,检查是否与需求匹配;上传附件检查点:1. 检查是否能正确上传附件文件;2. 检查上传的文件是否能正确下载并打开;3. 至少检查下列大小的文件能正确上传,0k,100k,1M,2M,4M,10M,20M等;4. 如果没有指定类型的限制,至少上传以下几种类型的文件能否正确上传并正确打开,类型有:.doc,.xls,.txt,.ppt,.htm,.gif,.jpg,.bmp,.tif,.avi等;5. 如果有文件类型的限制还要检查能上传的文件的类型;6. 上传同名的文件,在打开的时候是否出错;7. 有中文文件名的文件能否正确上传;影响操作性能的检查点:(不能代替系统的性能测试和压力测试,主要看系统在正常操作情况下的响应和处理能力)1. 对数据记录条数比较多的表的查询操作,避免全表查询,比如对银行用户账号的查询就不能缺省全部查出,必须让用户输入查询条件;2. 菜单树,测试大量数据时菜单树的响应情况;3. 有日志的查询或者统计,要注意查询的效率;4. 大报表的处理或者批处理的操作,要关注效率,比如:银行对帐、财务年终结算、财务年报表、系统初始化等;5. 大报表的排序sort、组函数的使用等;6. 大数据量的处理,如导入、导出、系统备份、文件传输等。
目的:
规程简要说明:
2)在项目测试用例评审时,评审人员参考该检查表内容对测试用例进行评审,以发现测试用例的问题。
3)对《项目测试记录》文档的测试用例Review时,参考测试记录检查表。
对《项目测试用例》文档中的测试用例评审时测试用例检查表。
本文件的目的是提供测试用例评审使用该文件发现测试用例不足的地方,帮助评审人员
描1)确认并定制适用的检查项。
如果该检查表中通用检查项不足,测试人员可根据项目实际需要,在检查内容中定义补充
行评审,以发现测试用例的问题。
表。
对《项目测试用例》文档中的测试用例评审时,使用
审人员更有效的执行评审活动。
人员可根据项目实际需要,在检查内容中定义补充检查项。
由于格式的限制,这里给一个列表。
1. 是否涵盖了需求文档上的每个功能点2. 是否涵盖了需求文档上的每条业务规则说明3. 是否覆盖了输入条件的各种有意义组合4. 是否覆盖了业务操作的基本路径和异常路径5. 是否考虑了重要表单字段的数据合法性检查6. 是否考虑了其他的测试类型(对某个功能很重要,但未在需求文档中提及的,如安全测试、周期性测试和故障恢复等方面)7. 是否考虑了对其他模块/功能的影响8. 是否使用了项目组的标准用例模板9. 用例是否覆盖了测试设计中定义的所有场景10.用例编号是否统一、规范11.用例名称是否简洁、明了12.目的字段是否准确地描述了对应场景的测试输入的特征(不同数据,操作,配置等)13.前提条件字段的条目是否充分、准确,操作上是否不依赖于同组之外的其他用例14.对应的需求编号字段是否填写正确15.用例粒度、预估出的执行时间是否适当16.同组用例中,仅数据不同的,是否实现了测试步骤的重用17.某个功能点的第一个用例是否是基本流的18.操作步骤的描述,是否清晰、易懂19.操作步骤是否充分和必要,并具有可操作性20.测试用例的检查点是否明确、充分和可操作21.单个用例步骤或检查点中是否不再存在分支22.测试数据的特征描述是否准确,有条件的情况下,是否给出了一个当前环境下的可用参考值23.文字、语法是否准确;布局、格式是否统一测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
测试用例(Test Case)目前没有经典的定义。
比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。
内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。
领测国际认为不同类别的软件,测试用例是不同的。
不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不统一,变化更大、更快。
测试用例评审表序号评审项1用例是否按照本部门规定的模板编写,如命名、类型、优先级、内容描述。
2测试步骤应与描述相一致3测试步骤和期望结果应完整、一致、清晰4操作步骤应仅包含与被测项相关的内容5期望结果应是确定的、唯一的6每个软件测试用例的操作步骤<=157对于由系统自动生成的输出项应注明生成规则8对于查询和表格,应设计产生数据的用例9测试用例本身描述是否清晰,是否存在二义性,与需求目标一致10软件测试用例应包含对中间和后台数据的检查11场景测试用例应覆盖最复杂的业务流程12场景测试用例的执行顺序应符合实际的业务流程13可重用(对被测项的当前版本和后续版本)14可跟踪性(与软件测试需求相对应)15如果存在不可测需求,应列出并进行说明16软件测试用例应确保所有的软件测试需求被覆盖以上为必须通过的测试项17软件测试用例执行后是应将软件测试环境恢复到执行前的状态18应包含相关的配置信息:环境、数据、前置测试用例、用户授权等19用词规范、准确、一致20场景测试用例中应包含每个业务流程环节的中止和回退相关的设计和组合21用例设计是否包含了正面、反面的用例评审结果:序号评审项1 是否按照测试计划完成用例编写2《需求规格说明书》是否评审并建立了基线3需求新增和变更是否进行相应地调整4测试用例是否包含边界值、等价类分析、因果图、错误推测等测试用例设计方法5是否针对需求的不同部分设计使用不同设计方法6用例覆盖率是否达到相应质量指标评审结果:1 2每个模块的评审结果分为通过、基本通过、不通过,其中基本通过和不通过必须填写说明:评审结果分为通过、不通过。
当必须通过的评审项通过时其评审结果为通过。
初审模块1模块2模块3评审人:评审日期:二审模块1模块2模块3试用例设计方法评审人:评审日期:过必须说明原因,并附上哪些用例不通过的编号或说明。
过。
总模块总模块。
CK_测试环境检查表项目基本信息项目名称项目编号项目经理检查工作量技术负责人日期质量保证员检查项序号检查种类检查内容切合不切合不合用备注1 过程测试计划、测试方案能否编写完成并经过审查2 过程测试种类、测试方法、测试用例能否已确立3 过程测试工具、测试文档能否已准备达成4 技术测试服务器能否按测试计划中的环境商定安装达成5 技术测试环境网络线路能否物理上能否已经连通6 过程测试数据能否准备就绪7 过程软硬件环境能否都有专人负责安装、调试、保护8 技术上线环境的测试能否达成9 过程应用服务器和数据服务器搭建后,能否经过检查10 技术网络环境能否到位11 技术上线的硬件参数配置能否设置正确12 技术上线的软件参数配置能否设置正确13 过程系统软件的打包版本能否正确14 技术系统软件能否正确的安装到上线环境中15 技术其余外面设备能否调试达成16 技术上线用数据能否准备达成17 过程上线的培训的能否达到标准18 过程接口单位能否已经明确协作方案确认信息CK_测试用例检查表项目基本信息项目名称项目经理技术负责人项目编号检查工作量日期质量保证员检查项序号检查种类检查内容切合不切合不合用备注1 过程测试用例能否依照企业定义的模板进行编写2 技术测试用例描绘能否和《软件需求规格说明书》一致3 过程每个测试用例能否描绘了操作步骤4 过程每个测试用例能否包括了预期结果5 过程每个测试用例能否认义输入数据确认信息CK_产品公布检查表项目基本信息项目名称项目经理技术负责人项目编号检查工作量日期质量保证员检查项序号检查种类检查内容切合不切合不合用备注1 过程产品能否经过了相应的测试,拥有《测试报告》2 过程软件产品组件和项目成就清单能否已经入产品库3 过程项目经理能否提出产品公布申请,填写《公布申请审查单》4 过程配置管理员能否依照《公布申请审查单》,从产品库中提取产品组件5 过程打包次序能否在《公布申请审查单》中描绘6 过程技术负责人能否依照打包次序达成产品打包7 过程打包达成的产品能否经过项目经理审查8 过程产品公布能否经过项目主管同意9 过程产品公布能否经过客户确认确认信息CK_产品集成检查表项目基本信息项目名称项目编号项目经理检查工作量技术负责人日期质量保证员检查项序号检查种类检查内容切合不切合不合用备注1 过程能否列出了打包文件清单2 过程能否认义了打包次序3 技术能否成立测试环境4 过程技术负责人能否对测试环境进行检查5 技术能否编译代码生成可履行文件6 技术能否 build 并生成可公布的 war包7 技术Build 过程能否有异样8 过程打包达成后能否对产品包进行表记9 过程有关规程和文档的版本能否与可履行程序般配确认信息CK_代码检查表项目基本信息项目名称项目经理技术负责人项目编号检查工作量日期质量保证员检查项( Java代码)序号检查种类检查内容切合不切合不合用备注1 技术程序的命名能否与规范一致?2 技术程序内变量的定义能否与规范一致?3 技术程序内语句的编写能否切合规范中对于语句格式的要求?4 技术每一个方法、类、文件能否有正确的头说明?5 技术代码中应该说明的地方能否都有合理说明?6 技术程序内的说明能否与规范一致?7 技术说明和代码能否保持一致?8 技术代码中说明的数目能否合理?9 技术调试信息能否被说明掉?10 技术局部变量和全局变量的定义能否没有矛盾?11 技术能否有冗余或无用的变量?12 技术变量和属性能否都正确的初始化?13 技术变量使用结束后能否都赋了空值?14 技术被赋值的变量,其变量种类能否一致或被正确变换?15 技术代码可否经过当地的编译和调试?16 技术较复杂的程序模块能否被拆分红多个程序块?17 技术代码能否防止了对浮点型数值的相等比较操作?18 技术能否存在不一样种类数据之间的混淆计算?19 技术全部的循环、分支、逻辑结构能否完好、正确?20技术在IF-ELSEIF结构中,最一般的状况能否先被考虑?21技术每一个布尔测试,能否都检查过正确的条件?22技术循环结束的条件能否显然,并总可以达到?23技术被除数能否做了零值测试?24技术全部的界限值能否都作了考虑,并正确的进行了办理?25技术假如一个循环有多个出口,能否每个出口都正确办理?26 技术Switch 申明能否都有 default 条件?27 技术循环和分支的嵌套能否过深?能否不合理?28 技术数组能否被合理定义范围?29 技术标志的不确立或错误的代码能否被更正?30 技术每个程序段能否只有一个进口和一个结束点?31 技术调用文件前能否被翻开?32 技术文件使用后能否被封闭?33技术全部的I/O异样能否被正确的办理?34技术能否全部的代码都能有效被调用或履行?35技术代码能否正确的实现了需求要求?36技术代码能否正确的实现了设计要求?检查项( C代码)序号检查种类检查内容切合不切合不合用备注1 技术程序的命名能否与规范一致?2 技术程序内变量的定义能否与规范一致?3 技术程序内语句的编写能否切合规范中对于语句格式的要求?4 技术每一个方法、类、文件能否有正确的头说明?5 技术代码中应该说明的地方能否都有合理说明?6 技术程序内的说明能否与规范一致?7 技术说明和代码能否保持一致?8 技术代码中说明的数目能否合理?9 技术调试信息能否被说明掉?10 技术局部变量和全局变量的定义能否没有矛盾?11 技术能否有冗余或无用的变量?12 技术变量和属性能否都正确的初始化?13 技术变量使用结束后能否都赋了空值?14 技术被赋值的变量,其变量种类能否一致或被正确变换?15 技术代码可否经过当地的编译和调试?16 技术较复杂的程序模块能否被拆分红多个程序块?17 技术代码能否防止了对浮点型数值的相等比较操作?18 技术能否存在不一样种类数据之间的混淆计算?19 技术全部的循环、分支、逻辑结构能否完好、正确?20技术在IF-ELSEIF结构中,最一般的状况能否先被考虑?21技术每一个布尔测试,能否都检查过正确的条件?22 技术循环结束的条件能否显然,并总可以达到?23 技术被除数能否做了零值测试?24 技术全部的界限值能否都作了考虑,并正确的进行了办理?25 技术假如一个循环有多个出口,能否每个出口都正确办理?26技术Switch 申明能否都有 default 条件?27技术循环和分支的嵌套能否过深?能否不合理?28技术数组能否被合理定义范围?29技术标志的不确立或错误的代码能否被更正?30技术每个程序段能否只有一个进口和一个结束点?31技术调用文件前能否被翻开?32技术文件使用后能否被封闭?33 技术全部的 I/O 异样能否被正确的办理?34 技术能否全部的代码都能有效被调用或履行?35 技术代码能否正确的实现了需求要求?36 技术代码能否正确的实现了设计要求?确认信息CK_评审检查表项目基本信息项目名称项目经理技术负责人项目编号检查工作量日期质量保证员检查项序号检查种类检查内容切合不切合不合用备注1 过程能否编写评审实行计划2 过程能否依照《评审指导书》,确立评审方式3 过程评审时间和人员的安排能否与客户达成一致建议(假如客户参加评审)4 过程能否提早散发评审资料给参加评审的人员5 过程能否提早将《评审实行计划》通知参加评审的人员6 过程能否依照评审实行计划进行评审7 过程能否依照评审检查单的检查项进行评审8 过程能否进行评审会议记录9 过程能否形成《评审报告》10 过程评审能否得出评审结论11 过程评审结论能否经过评审组确认12 过程能否对评审发现的问题进行追踪并经过审查13 过程未经过的评审能否安排再次评审时间14 过程能否记录评审数据确认信息CK_上线环境检查表项目基本信息项目名称项目经理技术负责人项目编号检查工作量日期质量保证员检查项序号检查种类检查内容切合不切合不合用备注1 过程软硬件环境能否都有专人负责安装、调试、保护2 技术上线环境的联调测试能否达成3 技术应用服务器和数据服务器搭建后,能否经过检查4 技术网络环境能否到位5 技术数据库软件能否在数据库服务器上经过测试6 技术中间件软件能否安装到位,能否经过测试7 技术上线的硬件参数配置能否设置正确8 技术上线的软件参数配置能否设置正确9 过程系统软件的打包版本能否正确10 过程系统软件能否正确的安装到上线环境中11 技术其余外面设备能否调试达成12技术机房设备能否达到上线标准?如UPS、机房散热等。