下载文档原格式
登录正常登录
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.界面提示“用户名
与密码不能为空”
低张三。
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
主要检查项
《需求规格说明书》是否评审？
是否按照测试计划时间完成用例编写？
需求新增和变更是否进行了对应的调整？
用例是否按照公司定义的模板进行编写？
测试用例是否覆盖了《需求规格说明书》？
用例编号是否和需求进行对应？
非功能测试需求或不可测试需求是否在用例中列出并说明？用例设计是否包含了正面、反面的用例？
每个测试用例是否清楚的填写了测试目的、步骤、预期结果？步骤/输入数据部分是否清晰，是否具备可操作性？
测试用例是否包含测试数据、测试数据的生成办法或者
输入的相关描述？
测试用例是否包含边界值、等价类分析、因果图、错误
推测、等测试用例设计方法？是否针对需求不同部分设
计使用不同设计方法？
重点需求用例设计至少要有三种设计方法？
每个测试用例是否都阐述预期结果和评估该结果的方法？
需要进行打印、表格、导入、导出、接口是否存在打印
位置、表格名称、指定数据库表名或文件位置；表格和
数据格式是否有说明或附件？
用例覆盖率是否达到相应质量指标?
用例预期缺陷率是否达到相应质量指标?
是否通过
出并说明？
、预期结果？
的方法？。
