软件系统测试用例评审检查表模板

软件项目测试用例评审检查表-模板

是
7 步骤/输入数据部分是否清晰，是否具备可操作性？是
测试用例是否包含边界值、等价类分析、因果图、错误 8 推测、等测试用例设计方法？是否针对需求不同部分阐述预期结果是否合理？
是
10 用例覆盖率是否符合《系统测试指南》要求？
是
检查人：C
检查日期:20200829
查表
说明
检查日期:20200829
系统测试用例评审检查表
序号检查项
1 是否按照测试计划时间完成用例编写？ 2 测试用例是否覆盖了《需求规格说明书》？
是/否/不适用是是
3 用例是否按照公司定义的模板进行编写？
否
4 用例编号是否和需求进行对应？
是
5
非功能测试需求或不可测试需求是否在用例中列出并说明？
是
6 用例设计是否包含了正面、反面的用例？

软件测试-测试用例表格模版

登录正常登录
Login_001输入正确用户名与密码，验证登录 1.系统运行正常2.用户已正确注册登录异常登录
Login_002输入正确用户名，输入错误密码，验证登录 1.系统运行正常2.用户已正确注册
登录异常登录Login_002用户名密码都输入
空 1.系统运行正常
原始需求
ID
1.浏览器地址栏输入网址
2.输入用户名admin与密码123456，点击登录1.输入地址栏后，界
面显示正常（公司
logo、控件）
2.登录成功，界面显
示正确
高张三
1.浏览器地址栏输入网址
2.输入用户名admin与错误密码，点击登录1.输入地址栏后，界
面显示正常（公司
logo、控件）
2.登录失败，提示“
用户名密码错误”
中张三
1.浏览器地址栏输入网址
2.用户名密码都不输入，点击登录1.输入地址栏后，界
面显示正常（公司
logo、控件）
2.界面提示“用户名
与密码不能为空”
低张三。

软件设计与开发评审检查表

是否在内存访问的时候执行了边界检查（例如: 数组、数据结构、指针等）来保证只是改变了目的存储位置？
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出故意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否可以对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到本来拟定的权衡因素?
所继承设计的已知风险是否已拟定和分析？
具体设计检查表
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
检查项
Y/TBD/N/NA
清楚性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
对的性
是否解决所有条件（大于、等于、小于零、switch/case）？是否存在解决“case not found”的条件？
是否对的地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
备注
检查项
Y/TBD/N/NA
清楚性
系统的目的是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清楚, 不模糊？
是否有对整套系统进行功能概述？
是否已具体说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？

软件评审检查表-计分

15
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
15
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
100分
评审结论：
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性，使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）

软件测试检查表

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.是否涵盖了需求文档上的每个功能点
2.是否涵盖了需求文档上的每条业务规则说明
3.是否覆盖了输入条件的各种有意义组合
4.是否覆盖了业务操作的基本路径和异常路径
5.是否考虑了重要表单字段的数据合法性检查
6.是否考虑了其他的测试类型（对某个功能很重要，但未在需求文
档中提及的，如安全测试、周期性测试和故障恢复等方面）
7.是否考虑了对其他模块/功能的影响
8.是否使用了项目组的标准用例模板
9.用例是否覆盖了测试设计中定义的所有场景
10.用例编号是否统一、规范
11.用例名称是否简洁、明了
12.目的字段是否准确地描述了对应场景的测试输入的特征（不同数
据，操作，配置等）
13.前提条件字段的条目是否充分、准确，操作上是否不依赖于同组
之外的其他用例
14.对应的需求编号字段是否填写正确
15.用例粒度、预估出的执行时间是否适当
16.同组用例中，仅数据不同的，是否实现了测试步骤的重用
17.某个功能点的第一个用例是否是基本流的
18.操作步骤的描述，是否清晰、易懂
19.操作步骤是否充分和必要，并具有可操作性
20.测试用例的检查点是否明确、充分和可操作
21.单个用例步骤或检查点中是否不再存在分支
22.测试数据的特征描述是否准确，有条件的情况下，是否给出了一
个当前环境下的可用参考值
23.文字、语法是否准确；布局、格式是否统一。

测试用例评审检查单

序号
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
主要检查项
《需求规格说明书》是否评审？
是否按照测试计划时间完成用例编写？
需求新增和变更是否进行了对应的调整？
用例是否按照公司定义的模板进行编写？
测试用例是否覆盖了《需求规格说明书》？
用例编号是否和需求进行对应？
非功能测试需求或不可测试需求是否在用例中列出并说明？用例设计是否包含了正面、反面的用例？
每个测试用例是否清楚的填写了测试目的、步骤、预期结果？步骤/输入数据部分是否清晰，是否具备可操作性？
测试用例是否包含测试数据、测试数据的生成办法或者
输入的相关描述？
测试用例是否包含边界值、等价类分析、因果图、错误
推测、等测试用例设计方法？是否针对需求不同部分设
计使用不同设计方法？
重点需求用例设计至少要有三种设计方法？
每个测试用例是否都阐述预期结果和评估该结果的方法？
需要进行打印、表格、导入、导出、接口是否存在打印
位置、表格名称、指定数据库表名或文件位置；表格和
数据格式是否有说明或附件？
用例覆盖率是否达到相应质量指标?
用例预期缺陷率是否达到相应质量指标?
是否通过
出并说明？
、预期结果？
的方法？。

软件需求规格说明书评审检查表

软件需求规格说明书评审
编制人员：项目名称：检查依据：《软件需求规格说明书模板》、《需求开发过程》序号 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 21 22 23 24 25 结果统计
是：否：不适用：未检查：说明

测试用例评审表

4. 5. 评审结论
评审组签字
日期
审核人签字 1.评审结果在对应项中画“√” 。 2.如果该项为不通过应在评审说明中详细描述问题。 3.通过的判定准则是没有“不通过”的评审结果。
日期
备注
项目状态初次评审修改将选中打产应与测试方案和测试计划的内容相一致测试用例应覆盖测试方案和测试计划中的全部测试内容测试用例应模拟典型的具有代表性的用户应用通过不通过评审组签字日期审核人签字日期备注1
测试用例评审表
项目状态产品名称用例数量评审表序号 1. 2. 3. 评审内容测试用例应按规定格式编写测试用例应与测试方案和测试计划的内容相一致测试用例应覆盖测试方案和测试计划中的全部测试内容测试用例应模拟典型的、具有代表性的用户应用测试用例应包括异常处理流程通过不通过评审结果通过不通过评审说明初次评审修改（将选中□打√）版本号

软件设计评审检查表

是否所有的界面都提供了所要求的信息
~
是否已说明内部各界面之间的关系
界面的数量和复杂程度是否已减少到最小
可维护性
该设计是否是模块化的
}
这些模块具有高内聚度和低耦合度
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明
性能
主要性能参数是否已被详细说明（例如：实时、速度要求、磁盘输入/输出接口等）
）
；
Y: 是 TBD: 不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义
、
是否对关键术语和缩略语进行定义和描述
所使用的术语是否和用户/客户使用的一致
需求的描述是否清晰，不含糊
是否有对整套系统进行功能概述
：
是否已详细说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)
完成软件确认测试说明、执行软件确认测试、进行测试分析、编写确认测试报告
完成系统测试说明、执行系统测试、进行测试分析、编写系统测试报告
正确性
是否处理所有条件（大于、等于、小于零、switch/case）是否存在处理“case not found”的条件
￥
是否正确地规定了分支（逻辑没有颠倒）
数据使用
是否所有声明的数据都被实际使用到
是否所有该单元的数据结构都被详细说明
￥
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限
该测试计划是否充分地描述了测试基线
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用
该测试计划是否定义了足够和正确的衰退测试
^
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档

软件设计评审检查表

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

软件设计评审检查表

完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置？
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清晰，不含糊？
是否有对整套系统进行功能概述？
是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置）？
如果有会影响实施的假设情况，是否已经声明？
完成软件确认测试说明、执行软件确认测试、进行测试分析、编写确认测试报告
完成系统测试说明、执行系统测试、进行测试分析、编写系统测试报告
是否将需求分别陈述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
Y:是TBD:不确定N:不是NA:不适用

软件测试用例表格.docx

XX项目 XX测试用例产品名称：产品版本：拟制:日期评审人:日期批准:日期测试人：日期软件负责人：（仅供内部使用）修改记录修日期版本修改描述修改人yyyy-mm-dd1初稿完成修改 XXX1.Xxx2.Xxx3. ...yyyy-mm-dd 1.01修改 XXX1.Xxx2.Xxx3. ...修改 XXXyyyy-mm-dd 1.021.Xxx2.Xxx3. ...⋯⋯⋯⋯⋯⋯⋯⋯修改 XXX1.Xxxyyyy-mm-dd22.Xxx3. ...精品文档测试记录V（汇程总序版本）项目名称：软件版本：配置版本：测试人：测试时间：软件负责人：序号问题及步骤描述正确结果反馈意见修正结果检验结果反馈意见修正结果检验结果备注注意：1、测试人员开始新版本测试时需更新测试记录汇总版本，例如：测试记录汇总+V（程序版本2、测试人员将问题出现的详细步骤填写清楚、将预期正确的现象填写在“正确结果”3、软件工程师将对问题意见填写在“反馈意见”、填写最终修正结果4、测试人员将检验修正后的结果填写在“检验结果”5、软件工程师如有特殊说明请填写“备注”功能测试用例号用例目的前提条件子用例号描述本用例的目的如果某些前提条件不足，本用例无法正常行，在此描述入操作步期望果果注示例：典型⋯示例：界⋯示例：异常⋯示例：典型⋯示例：界⋯示例：异常⋯示例：典型⋯示例：典型⋯示例：界⋯性能测试用例编号性能A描述用例目的前提条件子用例编号输入数据期望的性能（平均值）实际性能（平均值）状态界面测试用例编号用例目的前提条件指标子用例编号检查项评价备注合适性用界面是否与件的功能相融洽？和正确性是否所有界面元素的文字和状都正确无？于常用的功能，用能否不必手册就能使用？是否所有界面元素（例如）都不会人解？容易理解是否所有界面元素提供了充分而必要的提示？界面构能清晰地反映工作流程？用是否容易知道自己在界面中的位置，不会迷失方向？有机帮助？同的界面元素是否有相同的感和相同的操作方式？格一致字体是否一致？是否符合广大用使用同件的？及反是否提供度条、画等反映正在行的比耗的程？信息是否重要的操作返回必要的果信息？是否重要的入数据行校？行有的操作，有“确”、“放弃”等提示？出理是否根据用的限自屏蔽某些功能？适各种所有界面元素都具充分必要的操作和鼠操作？水平的用初学者和家都有合适的方式操作个界面？色盲或者色弱的用能正常使用界面？是否使用国通行的和言？国化度量位、日期格式、人的名字等是否符合国例？是否具有与众不同的、用深刻的界面？个性化是否在具必要的“一致性”的前提下突出“个性化”？界面的布局符合件的功能？界面元素是否在水平或者垂直方向？界面元素的尺寸是否合理？行、列的距是否保持一致？合理布局窗口切、移、改大小，界面正常？界面的色是否人感到和、意？重要的象是否用醒目的色彩表示？色彩使用是否符合行的？压力测试用例编号用例目的极限名称A如“最大并发用户数量”前提条件子用例编号输入 / 动作输出/响应是否能正常运行备注如10个用户并发操作如20个用户并发操作如10个用户并发操作如20个用户并发操作如10个用户并发操作如20个用户并发操作其他测试类型ID测试目的预制条件功能描述操作步骤预期结果自测结果测试结果备注模块名称：。