2004年底在大连出差的时候,帮一个项目做测试,顺便写下这个检查表,这个检查表对测试的初学者积累经验比较有用,实际对于有经验的测试人员尤其对于测试业务管理信息系统,基本上大量的测试不需要再编写测试用例,当然对业务流程、复杂逻辑还是要设计详细的测试用例的。如果你测试的系统是有大量人机交互的业务管理信息系统,而且你又比较懒惰,那就可以使用这个检查表检查了。
因此我总结了这类系统中常用的测试的检查项,供当时项目组的测试人员使用,现在再次整理出来发于博客。
1 针对测试组长或测试经理
1.1 测试管理工作检查表:
1. 检查每轮测试开始时测试环境是否准备好(包括软件硬件、测试基本数据等);
2. 确保测试环境(数据和程序)与开发分离,除了测试组之外其他人不能更新测试环境的数据和程序;
3. 每轮测试根据上一轮的情况和总体测试计划做分工调整;
4. 检查case库的填报情况,抽查执行过的case;
5. 检查BUG提交情况,抽查提交的BUG是否规范;
6. 每天晚上统计BUG情况,填写每天的BUG报告;
7. 根据每天的测试情况,决定是否开发组要发布新的BUILD;
8. 每轮测试结束后填写测试总结。
2 下面是针对测试执行人员的:
2.1 输入、编辑功能的验证检查点:
1. 必输项是否有红星标记,如果不输入提示是否跟相应的Label对应,提示的顺序是否跟Form输入域的排列次序一致;
2. 输入的特殊字符是否能正确处理:`~!@#$%^&*()_+-={}[]|\:;”’<>,./?;
3. Form下拉菜单的值是否正确,下拉菜单的值通过维护后是否正确显示并可用;下拉菜单比如是机构编码,要到机构编码的维护界面查询一下是否Form列出的与其一致;
4. 涉及到下拉菜单的编辑修改Form,要检查在编辑和修改From中,下拉菜单是否能正确显示当前值;
5. Form提交后,要逐项检查输入的内容跟通过查询的结果一致;
6. 有多层下拉菜单选择的情况要校验两层菜单的选择是否正确,比如:
a) 部门 财务
软件开发部人员 张三
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. 大数据量的处理,如导入、导出、系统备份、文件传输等;
li_hualing@163.com MSN:lihualing2004@hotmail.com 2004-12-12
分享到:
相关推荐
测试用例知识---测试用例检查表,方便理解
1. **整体测试流程的完整性**:评审的第一步是检查测试用例是否全面地描述了测试的开始和结束阶段。这包括了测试前的准备工作,如环境配置、数据准备、工具安装等,以及测试后的收尾工作,如测试报告编写、问题跟踪...
* 输出:整理成测试需求,将每一个需求细节列出,作为检查点 步骤二:业务流程分析 * 输入:业务背景和知识,被测系统/模块的业务流程 * 处理:整理主流程、备选流程、数据流向、关键判断条件以及完成该操作的(非...
判定表作为一种有效的测试用例设计方法,尤其适用于处理复杂的逻辑决策问题。在本文中,我们将深入探讨判定表的概念、应用以及如何在实际的C#.NET项目中进行实践。 首先,判定表是一种清晰表示多种条件组合及其对应...
ATM取款机测试用例的设计是软件质量保证的重要环节,尤其在金融系统中,确保ATM的安全性和稳定性至关重要。以下是对ATM取款机测试用例的详细说明: 1. **登陆流程**: - 银行卡插入:测试银行卡是否能正确识别并被...
测试用例编写是软件测试过程中的关键环节,旨在确保软件的质量和稳定性。本文将深入探讨测试用例编写规范,帮助初学者和测试用例编写者理解如何高效地编写测试用例。 1. **目的**: 测试用例编写规范的目的是统一...
“用例设计参考样例.doc”提供了设计用例的实例和指导,而“2.docx”和“实验2.txt”可能是额外的测试用例或补充资料,可作为设计和执行测试用例的参考。 综上所述,学生信息管理系统测试用例设计不仅关注功能实现...
通过这些详尽的测试用例,可以全面检查酒店管理系统的各个部分,确保在实际运营中能够提供准确、流畅的服务,减少错误和遗漏,提升客户满意度。同时,测试用例的编写和执行也是软件质量保证的重要环节,能有效预防...
### 测试用例设计白皮书知识点详述 #### 一、测试用例的基本概念 **1.1 测试用例定义** 测试用例是指为了验证软件系统在特定条件下是否能够按照预期工作而设计的一组特定输入、执行条件及其预期结果。简而言之,...
提高测试覆盖率是测试用例设计的主要目标之一,但如何设计测试用例来提高测试覆盖率却是一个需要认真思考的问题。 首先,测试人员需要对测试项进行详细的设计划分,然后针对每个测试项,考虑具体的测试用例。根据...
这些种类包括常规的测试用例、初始化的测试用例、边界的测试用例、空值的测试用例、格式错误的测试用例、溢出的测试用例、关联的测试用例、唯一值的测试用例、权限不足的测试用例、角色权限的测试用例等。...
公司项目后台管理测试用例 本测试用例涵盖了公司项目后台管理的多个方面,包括登录模块、角色管理、用户权限管理、用户管理和修改密码功能。下面是每个模块的详细信息: 登录模块 测试用例编号 TestCase -1- * ...
### 如何编写Robot Framework测试用例1---(基本格式篇) #### Robot Framework 测试用例基本格式概览 在深入探讨Robot Framework (RF) 的测试用例编写之前,有必要了解RF的基本概念及其如何通过一种独特的表格...
自己写的测试用例。本系统分为三大模块:终端,数据分析处理中心,Web管理端。 终端监控负责数据的采集,初加工以及封堵。 数据分析处理中心负责审计、日志存储、趋势分析和处理控制终端命令。 Web管理端负责审计、...
软件测试用例的设计-白盒测试---佣金数据流测试分析.ppt
测试用例设计是软件质量保证的关键环节,尤其对于中高级测试人员来说,深入理解并熟练应用测试用例设计原理和技巧至关重要。本文将详细解析测试用例设计的一些核心概念和步骤,以帮助测试人员提高测试效率和效果。 ...
边界值分析是软件测试中一种重要的黑盒测试技术,它主要针对输入或输出的边界条件进行测试用例设计,以期发现更多的程序错误。这种方法基于经验观察,即很多软件问题往往发生在输入或输出值的边界附近。通过选取边界...
例如,“授权记录生成”作为一个独立的测试项,可以在多个功能点中被复用,避免重复编写类似的测试用例,提高效率。 **3、隐含切面** 隐含切面指的是那些不易察觉但又极其重要的测试点。这类测试点通常涉及后台...
3. **开发人员**:虽然这不是测试用例设计的常规字段,但在此处可能表示该功能的开发者,他们对功能的理解有助于编写有效的测试用例。 4. **模块名称**:指的是软件中的具体模块,这有助于细化测试范围,确保每个...
1. 等价类划分:将输入域分成有效等价类(合理输入)和无效等价类(不合理输入),选取每个类的代表数据作为测试用例,以实现全面测试。 2. 边界值分析:关注输入或输出边界附近的值,因为这些区域往往容易出现错误...