测试用例检查表范

合集下载

测试过程检查表

评审者填写
是否达标 Y N NA
评审者意见
. 技术资料 . 专业整理.
.WORD 完美格式.
检查点
作者填写
检查点符合项位置
作者备注
测试报告中是 9 否有测试评
价？如果测试计划有性能测试的 10 安排，是否有单独的性能测试报告？性能测试报告中是否记录了 11 被测系统的版本？性能测试报告中是否有对实 12 际测试环境的描述？性能测试报告中是否有测试 13 计划中规定的所有的测试种类？性能测试报告中是否有关于 14 测试场景的说明？性能测试报告中各种测试类 15 型的结果记录是否清晰合理？性能测试报告中是否对各种 16 测试类型的结果进行分析？性能测试报告中是否有各类 17 资源的使用情况与统计数据？
. 技术资料 . 专业整理.
评审者填写
是否达标 Y N NA
评审者意见
.WORD 完美格式.
检查点
作者填写
检查点符合项位置
作者备注
测试报告中有失败的、其它 28 的测试用例列表吗？测试报告中有各类资源的使 29 用情况与统计数据吗？测试报告中有测试覆盖率分 30 析和统计吗？如测试对需求的覆盖率。测试报告中有 31 缺陷统计与分析吗？测试报告中有按缺陷严重性 32 分类的缺陷统计和分析吗？测试报告中有按缺陷状态分 33 类的缺陷统计和分析吗？测试报告中有 34 遗留缺陷的统计和分析吗？测试报告中有与测试计划的 35 偏离比较分析吗？测试报告中有 36 明确的测试结论吗？如果测试计划有性能测试的 37 安排，有单独的性能测试报告吗？
4．0 测试风险监控
3.1 测试组长是否定期或在事件驱动情况下，监控识别出的测试风险？

软件测试用例多用例表格模板

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┃┠──────┼───────────────────────────┨┃结论│┃┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛。

CMM文件-ST-C02 测试用例检查单

检查条件是否通过
必须必须
必须必须必须必须必须必须
必须必须必须必须必须必须必须必须必须
必须必须必须
备注Biblioteka 设计规范： 1、详细测试需求点、测试步骤和预期结果必须体现测试目的和测试重点 2、测试用例中需要用到附件的，需附上文件和文件存放路径；(附件大于1M可指定路径） 34、、用测例试步用骤例和用期表望格结设果计要需量遵化循，用不例能规出范现(必如须：有大测概试、点可、能步、骤基、本预功期能结正果常、、执或行、结等果；)，很表大格、放少入数测等试形用容例词附件中5、测试用例设计时需考虑测试执行效率，功能用例执行10分钟原则 6、“测试步骤”和“预期结果”必须可实现和可执行 7、测试用例需验证客户业务，不能只检查配置和页面，除非为纯页面测试 8、体现强关联，去掉弱关联；强关联：案例中缺少此步骤就无法达到案例例目的；弱关联：案例中缺少此步骤可以达到案例目的；对于大家都知道或应该清楚的点不用体现在用例中 9、测试用例需要有正反对比验证：开和关的对比、匹配和不匹配对比、输出结果的对比等
可维护性规范： 1、测试用例中不能出现页面配置路径，如：登录UI-打开科室规则配置-新建识别规则 2、测试用例中不能出现操作过程，比如打开XX目录下文件，点击什么；直接写需做的操作即可 3、测试用例需用到的例行检查点、公共检查点、后台、调试、配置文件等查看方法统一写到模块description
D】据。
【YYYY-MM-DD】
测试用例设计检查单
说明：功能用例整体规范检查结果应全部通过，如有不通过者需说明理由，此表为用例抽查的重要依据。
检查项
框架规范： 1、功能模块框架按标准框架 2、需要在“模块”文件夹备注中说明功能框架设计的思路

软件测试用例表格

1.Xxx
2.Xxx
3....
yyyy-mm-dd
2
修改XXX
1.Xxx
2.Xxx
3....
测试记录汇总序版本）
项目名称：
软件版本：
配置版本：
测试人：
测试时间：
软件负责人:
序号
问题及步骤描述
正确结果
反馈意见
修正结果
检验结果
反馈意见
修正结果
检验结:
备注
、八，注意：
1、测试人员幵始新版本测试时需更新测试记录汇总版本，例如
度量单位、日期格式、人的名字等是否符合国际惯例？
个性化
是否具有与众不同的、让用户记忆深刻的界面设计？
是否在具备必要的“一致性"的前提下突岀“个性化"设计？
合理布局
界面的布局符合软件的功能逻辑吗？
界面元素是否在水平或者垂直方向对齐？
界面元素的尺寸是否合理？行、列的间距是否保持一致？
窗口切换、移动、改变大小时，界面正常吗？
前提条件
如果某些前提条件不满足，本用例无法正常执行，则在此描述
子用例编号
输入
操作步骤
期望结果
实测结果
备注
示例：典型值•
示例：边界值•
示例：异常值•
示例：典型值•
示例：边界值•
示例：异常值•
示例：典型值•
示例：典型值•
示例：边界值•
性能测试
用例编号
性能描述
用例目的
前提条件
子用例编号
卜输入数据
期望的性能（平均值
xx
产品名称:
产品版本:
拟制：
日期
评审人：
日期
批准：

模板_测试检查表checklist

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

测试用例检查表1

目的:
规程简要说明:
2）在项目测试用例评审时，评审人员参考该检查表内容对测试用例进行评审，以发现测试用例的问题。

3）对《项目测试记录》文档的测试用例Review时，参考测试记录检查表。

对《项目测试用例》文档中的测试用例评审时测试用例检查表。

本文件的目的是提供测试用例评审使用该文件发现测试用例不足的地方，帮助评审人员
描1）确认并定制适用的检查项。

如果该检查表中通用检查项不足，测试人员可根据项目实际需要，在检查内容中定义补充
行评审，以发现测试用例的问题。

表。

对《项目测试用例》文档中的测试用例评审时，使用
审人员更有效的执行评审活动。

人员可根据项目实际需要，在检查内容中定义补充检查项。

ST-测试用例检查单

测试用例检查单
文档编号：ST-测
项目名称
项目编号
项目经理
检查人员
检查日期
序号
检查项
是
否不适用
1
文档结构是否清晰、组织是否合理？
√
2
是否程序中的每个需求都有对应的测试用例？
3
在测试程序中执行目标状态是否明确？
4
是否程序中的每个设计元素都有对应的测试用例？
5
是否在测试用例中列举了一些过去常存在的错误？
6Байду номын сангаас
是否对简单的临界值进行了测试？如最大、最小值？即组合输入数据可能导致某计算变量过大或过小？
7
是否测试了典型的中间值？
8
是否包含了足够的不合理和有冲突的输入组合？即默认输入值的使用方法是否合理？
9
是否可演示程序中所有的错误路径？
10
是否能提供充分的可行度，包括已被测试的功能在确定环境运行正确？
11
测试用例是否检查了错误数据？
12
为了支持软件可靠性的估计而被收集和验证的测试数据是否充分？
13
测试用例是否使得手工检查很容易？
14
被批准的测试用例是否可以追溯到需求规格说明书、设计说明书等文档中？
文档编号：ST-测试用例检查单0 注释

易用性测试检查表

易用性测试检查表
序号一 1、 2、 3、 4、 5、二 6、 7、 8、三 9、 10、四 11、 12、 13、 14、五 15、 16、 17、 18、 19、六 20、 21、 22、 23、 24、七 25、 26、 27、 28、 29、 30、八 31、 32、 33、 34、九 35、 36、 37、 38、 39、 40、问题分类导航个人信息显示，在主页中有明显快捷键链接菜单按：常用-主要-次要-工具-帮助次序排列菜单按钮显示位置妥当列表不缺少常规、常用导航功能位置提示显示正确帮助/支持需要帮助有明确的帮助适当的时候提供帮助不适当的时候提供帮助工作支持流系统能够灵活应用、自定义执行了不必要的步骤错误处理提示、警告或错误说明清楚、明了恰当提出错误说明“发生了什么、为什么发生、如何解决” 能避免用户无意录入无效数据对可能发生严重后果操作补救措施一致性和Windows或常用界面风格类似常用操作相同符合标准和规定不同页面布局风格统一，按钮控件是否一致相同的信息、说法、排列等准确反馈信息明确系统在做什么使用了正确的光标、进度条显示进度消息提示在正确的地方消息提示及时明确未正确屏蔽系统反馈信息功能性系统做了用户想要做的事有些功能提供提供了大量的准确的缺省值复杂的任务提供了操作向导常用功能提供模板系统支持残疾障碍人员控制和使用系统控制能控制交互，能随时取消操作够能控制功能执行流程能决定哪些信息可以显示确实无法控制的信息，系统有正确的信息提示视觉清晰颜色使用正常，控制在三色以内使用了和主题相关的颜色使用了不恰当的颜色颜色主次清楚、背景和前文对应尽量大文字字型、字体、颜色是保持一致界面元素是否使用过多、没分类、排版混乱

功能测试用例通用模板

编写/修改人员测试人员执行结果用例版本
——
—— 通过
1.0
——
——
1.0
通过
——
——
1.0
通过
——
——.0
通过
——
——
1.0
通过
查看发票详情功能验证功能
高
查看发票验证计划
功能
高
发票验证计划弹窗字段验证
功能
高
预置条件登陆资产管理系统
登陆资产管理系统
操作步骤 1.查看页签显示 2.查看页面排版 1.查看搜索项 2.查看搜索项输入框 3.查看下拉框内容 4.未设置搜索条件进行搜索 5.设置单个搜索条件进行搜索 6.设置多个条件进行搜索
用例编号所属模块 ZCGL-V1.5.2-001
ZCGL-V1.5.2-002
用例标题页面检查
测试类型重要级别
功能
高
搜索功能验证
功能
高
ZCGL-V1.5.2-003 报表管理/贷后发票状列表字段验证态跟踪表
功能
高
ZCGL-V1.5.2-004 ZCGL-V1.5.2-005 ZCGL-V1.5.2-006
登陆资产管理系统
1.查看列表字段
登陆资产管理系统登陆资产管理系统登陆资产管理系统
1.点击发票号码 1.点击【发票验证计划】 1.查看弹窗列表字段
预期结果 1.页签显示正确 2.页面排版美观，无错位、错别字等 1.搜索项齐全 2.搜索框有暗纹提示 3.核心企业下拉选择鱼需求一致 4.搜索成功，展示所有信息 5.搜索成功，搜索结果与条件相符； 6.搜索成功，搜索结果与条件相符 1.核心企业、融资产品、融资批次号、申请时间（年月日时分秒）、融资状态（融资中、已放款、已还款）、供应商、发票号码、发票代码、发票类型、含税金额（两位小数）、验真结果（值：成功、失败、验真中）、发票状态（值：正常、异常）、更新时间（年月日时分秒） 1.可以点击 2.进入发票详情页 1.弹出状态更新记录弹窗 2.根据融资产品配置的验证规则，生成相应的计划；人工手动验证后，增加一条验证计划 1.显示查验时间、发票状态、验真结果、异常原因、自动查验状态、查验方式、操作用户

软件测试用例单用例表格模板

用例名称用例描述
软件环境：
测试环境
硬件环境：网络环境：
设计人前提步骤
设计时间预期结果
1：用户输入：admin
1
输入合法的用户名和密码
2：密码输入：admin 3：保存登录信息：默认勾选
系统成功登录，进入 agileone主页面
3：点击登录按钮
2
输入非法的用户名输入合法的密码
1：用户输入：abc 2：密码输入：admin 3：保存登录信息：默认勾选 3：点击登录按钮
系统登录失败，提示：“用户名或密码不正确，请重新输入
”
3
输入非法的用户名输入非法的密码
1：用户输入：abc 2：密码输入：123456 3：保存登录信息：默认勾选 3：点击登录按钮
系统登录失败，提示：“用户名或密码不正确，请重新输入
”
1：用户输入：abc
4
输入正确的用户名输入正确的密码连续点击登录按钮
2：密码输入：123456 系统能正常登录，进
3：保存登录信息：默入agileone主页面，
认勾选
无多次刷新页面的情
3：点击登录按钮（快况。
速双击）
优先级
高
备注
中中低

测试用例检查表范

计方法？
是［］否［］免［］
每个测试用例是否都阐述预期结果和评估该结果的方法？
是［］否［］免［］
需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置；表格和数据格式是否有说明或附件？
是［］否［］免［］
3
详细内容（可选）
业务流程中最长的流程用例是否覆
盖？
是［］否［］免［］
步骤/输入数据部分是否清晰，是否具备可操作性？
是［］否［］免［］
测试用例是否包含测试数据、测试数的生成办法或者输入的相关描述？
是［］否［］免［］
测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法？是否针对需求不同部分设计使用不同设计方法？
是［］否［］免［］
重点需求用例设计至少要有三种设
业务流程中每个环节的终止和回退是否存在条件和组合的设计？
是［］否［］免［］
角色和用户在用例中是否已经设定？跨流程的角色是否有设计？
是［］否［］免［］
菜单、必录项和相关控件是否有说明？
是［］否［］免［］
存在系统自动生成的输出项是否列出了生成规则？
是［］否［］免［］
对于查询和表格是否设计了可以产生数据的用例？
是［］否［］免［］
查询和自定义报表的结果是否根据条件组合设计至少三条用例保证覆盖？
是［］否［］免［］
无法在界面显示的字段是否编写
SQL语句进行后台表查询？
是［］否［］免［］
2
设计
测试用例是否覆盖了〈〈需求规格说明书》？
是［］否［］免［］
用例编号是否和需求进行对应？
是［］否［］免［］
非功能测试需求或不可测试需求是否在用例中列出并说明？

软件测试用例检查单

由于格式的限制，这里给一个列表。

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)目前没有经典的定义。

比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

领测国际认为不同类别的软件，测试用例是不同的。

不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。

测试用例表格

Cancel 废弃用例数
Execute
Coverage 用例执行覆
盖率
#REF! #REF!
#REF!
#REF!
#REF! #REF!
#REF!
#REF!
Total Suggest 提示问题总数
File Name 文件名
0
0
#NAME?
0
Variance 变化率
File Name 文件名
0.00% 0.00%
#NAME? sum汇总
12 15
Working copy, if printed
#REF!
Test Case Details 测试用例说明
Total Test Cases Executed 已执行用例总数
Pass 通过用例数
1
sum汇总
1
#REF! #REF!
#REF! #REF!
Defect Details 缺陷说明
Sum 汇总
Total Critical 致命问题总数
Total Major 严重问题总数
Test Report
Project ID 项目编号
Test Type 测试类型
Test Start Date 测试开始日期
#REF!
Test Owner测试责任人
Total Test Case 测试用例总数
Project Name 项目名称
Test Owner 测试责任人
Test End Date 测试结束日期
Total Fixed 已修改问题
数（个）
Code Size 代码规模 (KLOC)
0
0
0
0
0
0

用例审核检查项列表(模板)

1
每个测试用例是否都说明/代表一个唯一的输入集或事件流？
2
测试用例是否可以追溯到产品需求？
3
测试用例是否100％覆盖产品需求要求的所有功能点？
4
用例是否覆盖了测试计划的测试类型？
5
所有的“前置条件”是否都是充分必要条件？
6
判断点中是否没有操作步骤？
7
测试步骤是否简练？
8
每个步骤是否描述了一个事件？
9
“测试步骤”中引用数据的格式是否统一？
10
“测试步骤”和“预期结果”中对界面文字的引用是否加引号？
11
预期结果是否描述完整？
12
文档使用的词语是否清晰明确、无歧义？
13
测试用例是否覆盖每个被测功能的所有可能的输入输出的组合？
14
测试用例是否覆盖正常的输入输出组合的所有可能的取值范围？
15
测试用例是否包括测试了被测试对象的初始化过程？
16
测试用例是否包含了被测对象中所有异常流的测试？

测试用例评审表

测试用例评审表序号评审项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_检查表_软件工程.xls

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、机房散热等。