测试用例评审Checklist
- 格式:xls
- 大小:50.50 KB
- 文档页数:2
测试 Check List1. 引言测试 Check List 是测试过程中的一项重要工具,用于确保测试的全面性和准确性。
本文档将介绍如何编写和使用测试Check List。
2. 撰写测试 Check List 步骤2.1 确定测试范围在撰写测试 Check List 之前,首先需要明确测试的范围。
测试范围应该包括待测系统的功能、性能、安全性等方面。
2.2 列出待测功能点根据测试范围,列出待测的功能点。
每个功能点应该明确描述功能的预期行为。
示例:功能点预期行为用户登录登录成功后跳转到主页发布新文章成功发布后在文章列表中显示修改用户信息保存修改后,信息应更新到数据库删除评论删除后评论应从数据库中删除2.3 列出待测边界条件边界条件是指系统中的特殊情况,如极限值、异常值等。
列出待测边界条件可以帮助测试人员更全面地覆盖系统的各种情况。
示例:功能点边界条件发布新文章文章标题为空发布新文章文章内容超过最大长度修改用户信息用户名包含特殊字符删除评论评论ID不存在2.4 列出待测的关键功能点关键功能点是指对系统核心功能进行测试的功能。
列出待测的关键功能点,可以帮助测试人员重点关注系统的重要部分。
示例:•用户注册•支付功能•数据加密2.5 根据测试需求添加测试用例根据待测功能点和边界条件,为每个功能点编写相应的测试用例。
测试用例应包括输入、预期输出和实际输出。
示例:测试用例 1:功能点:用户登录输入:用户名、密码预期输出:登录成功实际输出:登录成功测试用例 2:功能点:发布新文章输入:文章标题、文章内容预期输出:文章成功发布实际输出:文章成功发布2.6 检查测试用例的覆盖范围在添加测试用例后,需要检查测试用例的覆盖范围。
确保所有待测功能点和边界条件都有相应的测试用例。
2.7 根据测试需求添加测试数据根据测试用例的输入要求,准备测试所需的测试数据。
确保测试数据覆盖了各种情况,包括正常情况和异常情况。
2.8 评审和修正测试 Check List在完成测试 Check List 的编写之后,需要进行评审。
增1能否执行插入功能2默认值是否正确3必输项是否有红星标记,如果不输入提示是否跟相应的Label对应,提示的顺序是否跟Form输入域的排列次序一致4输入的特殊字符是否能正确处理:`~!@#$%^&*()_+-={}[]|\:;”’<>,./?5Form下拉菜单的值是否正确,下拉菜单的值通过维护后是否正确显示并可用;下拉菜单比如是机构编码,要到机构编码的维护界面查询一下是否Form列出的与其一致6要求唯一的数据(主键)是否可以重复添加7备注字段的超长检查8输入域的编辑状态是否正确(editable/uneditable)9输入结果是否被正确保存10插入页面为当前主页面的情况下,提交保存后能否转到合适的页面11插入页面为弹出新页面的情况下,提交保存后原来的列表页面是否会自动刷新12插入的数据在结果列表中是否正确排序13有唯一性要求的,连续提交,不能产生重复数据,或造成数据混乱、丢失改1能否执行修改功能2编辑页面中各输入域是否被正确的置成可编辑、不可编辑状态;可编辑数据项的检查,比如:数据在正式提交之前所有的属性都可以编辑,在提交之后,编号、状态等不能编辑,要根据业务来检查是否符合需求3编辑页面中可编辑的项目是否显示正确的默认值,包括form下拉菜单与文本框4涉及到下拉菜单的编辑修改Form,要检查在编辑和修改Form中,下拉菜单是否能正确显示当前值5Form提交后,要逐项检查输入的内容跟通过查询的结果一致6编辑权限的检查,比如:user1的数据user2不能编辑等7输入的数据是否被保存,Form提交后,要逐项检查输入的内容跟通过查询的结果一致8输入的数据是否保存为其它的值9如果输入的数据(主键)已经存在,是否可以保存10修改操作是否被当作插入处理,即在保存原有数据的基础上,插入了修改值11提交保存后能否转到合适的页面12修改的结果在结果列表中是否正确排序13有唯一性要求的,连续提交,不能产生重复数据,或造成数据混乱、丢失删1必须有“确认删除”的提示2能否执行删除功能3选定的数据是否被删除4是否错误的删除没有选择的数据5是否可以删除部分或全部数据6当设置自动编号时,能否处理删除后的空白7根据项目需求检查是软删除还是硬删除,来检查数据库中是否还存在该条记录8如果是软删除,用查询、统计界面检查该条记录能否被查询出来,数据是否被统计进去9是否有相关的数据删除,如果有要确认该相关的数据也已经删除,并且在同一事务中完成10是否有删除约束,如果有删除约束,要检查该记录是否被约束,如果被约束该记录不能被删除11检查因为业务约束不能删除的数据能否被保护不能手工删除,比如:流程中已经审批的文件不能被删除12跟删除相关的权限问题,比如:需求要求只有管理员和该记录的创建人能够删除该记录,那就以不同的用户和角色登录进去,执行删除操作,检查是否与需求匹配查1能否执行查询功能2对于查询输入项的值是固定的要用下拉菜单,比如状态、类型等3是否可以设置查询条件4在不同部分查询统一信息,查询结果是否一致5查询结果是否包括符合条件的全部数据6是否存在重复出现相同数据的情况7查询结果中是否包括检索条件、可以判断正确与否8查询结果是否有明确的排列顺序9在插入/修改操作时,查询输入的值,结果是否正确10不设置查询条件时是否可以查到全部数据11根据项目需求是否支持模糊查询12根据项目需求查询关键字是否区分大小写13设置部分查询条件时查询结果是否正确14设置精确查询条件时查询结果是否正确15查询结果页面中是否保存查询条件16查询结果分页时,在点击下一页/上一页时查询条件是否能带过去,不能点击翻页时又重新查询17查询结果是否出现内容和合计数值不一致的情况18查询权限的检查,比如:user1不能查询到user2的数据等19当查询的数据量较大时系统性能如何20设置条件进行查询后清空查询条件,再次查询时是否仍然按照之前设置的条件进行查询21如输入%*?等通配符是否会导致查询错误22分页的统计数字是否正确,共X页,第N页,共X条记录等23对于查询有统计的栏目,比如:总计、合计等要计算数据是否正确24查询结果有超链接的情况要检查超链接是否正确分页1总页数是否正确2当前页数是否正确3设置跳转的页数后能否直接跳转4首页/末页、上一页/下一页按钮的状态是否正确5点击首页/末页、上一页/下一页是否跳转到正确的页面上传/下载1是否能正确上传附件文件2检查上传的文件是否能正确下载并打开3上传文件时是否符合大小限制,若没有指定大小的限制,至少检查下列大小的文件能正确上传,0k,100k,1M,2M,4M,10M,20M等4上传文件时是否符合指定的类型限制,如果没有指定类型的限制,至少上传以下几种类型的文件能否正确上传并正确打开,类型有:.doc,.xls,.txt,.ppt,.htm,.gif,.jpg,.bmp,.tif,.avi等5同一个位置是否可以上传同名文件6在不同位置上传的同名文件,打开时是否出错7根据项目需求,中文名称的文件是否可以正确上传/下载。
第 3 部分: 颜色和字体颜色和字体测试包含的范畴用户通过使用网页产品获取大量的数据信息,这些信息的显示方式包括图形和文字两大部分。
而在向用户呈现图形和文字的过程中,颜色和字体扮演了非常重要的角色。
合理恰当的颜色和字体设置可以保证用户以最高效、清晰的方式获取到需要的信息,而如果颜色和字体设置的不恰当,用户将花费更多的时间获取相同的信息量,从而导致用户获取信息的效率下降。
本文中,将列举一些Web 产品开发中需要注意的事项,通过避免这些事项,可以从一定程度上杜绝此类的问题给用户带来的不良体验,从而提高产品的用户满意度。
本文也会举例说明一些具体的Web 产品缺陷实例。
颜色测试Checklist表 1. 颜色测试Checklist 总结序号Checklist1.1 检查超链接的颜色1.2 确保所有页面的背景颜色都被测试1.3 检查警告消息的颜色是否符合规范1.4 确保相似页面的颜色一致1.5 确保前景色和背景色是易读的1.6 确保不要用红色高亮显示活跃组件1.1 检查超链接的颜色超链接的颜色显示通常呈现三种形式:缺省颜色、有光标时的颜色、访问后颜色,如图1 所示。
图 1. 超链接的三种颜色显示按照以上一致性的要求,可以保证用户在不同的产品之间切换时,能有一致的用户感受和体验,对用户流畅的应用新的产品很有帮助。
1.2 确保所有页面的背景颜色都被测试对于一款用户用好的网页产品,所有页面的背景颜色需要具有一致性,以保证提供给用户一致的用户体验。
图 2. 页面背景颜色不一致实例图2 中所示,该实例中,当水平滚动条出现后,拖动水平滚动条查看右侧内容,可以发现左右两侧的页面背景颜色是不一致的,这会让用户体验下降,是产品的一个缺陷。
1.3 检查警告消息的颜色是否符合规范警告消息需要对用户进行醒目的提醒和警告,需要很容易即可被用户发现。
因此,通常警告消息的颜色设置为粉红色,如图3 所示。
图 3. 警告消息实例在网页产品开发和测试过程中,开发测试人员需要检查警告消息的颜色是否保持一致,是否符合以上的颜色规范。
Web 软件测试Checklist 应用系列第 1 部分: 数据输入本文为系列文章"Web 软件测试Checklist 应用系列"中的第一篇。
该系列文章旨在阐述Checklist(检查清单)在Web 软件产品测试中的应用,以帮助您了解如何利用Checklist 这种重要的测试手段,更高效的寻找Web 产品中的defect(缺陷)。
Checklist 汇集了有经验的测试人员总结出来的最有效的测试想法,可以直接有效的指导测试工作,开阔测试人员的思路,能够快速的发现产品的缺陷并实现较好的测试覆盖,更重要的是该Checklist 在不同的项目中具有很强的通用性。
查看本系列更多内容|评论:苏京刚, 软件工程师, IBM2013 年3 月21 日1内容该系列文章分为以下几个部分:1第1 部分:数据输入主要介绍Checklist 在表格输入、数据验证、数据一致性、日期输入、数字输入、文字字符输入区检查等多个方面的应用。
2第2 部分:导航和链接主要介绍在Web 产品的导航和链接中应用Checklist,以确保Web 产品中的所有链接和页面可以正常到达。
3第3 部分:颜色和字体Checklist 在Web 测试中的重要性Checklist(检查清单)从名字字面意思即可理解,是用于检查的一系列条目。
之所以需要Checklist,是因为人们的记忆会有疏忽,可能遗漏一些需要注意的事项,还因为人们的经验和水平有限,能够思考到的程度有差异,借助Checklist 可以帮助我们做必要的检查。
举例,体检的时候,在体检中心登记之后会给每个人打印一个清单,就是当天需要检查的项目,逐项检查并打勾,就可以避免遗漏;再比如,当我们计划一次旅游时,我们会列举我们旅途中需要用到所有物品的清单,以及旅行前需要完成的各项准备工作。
通常,出行前,我们会按照清单逐项检查,比如办签证、订机票、订酒店等,出行前,我们会按照清单逐项打包需要带的东西,比如药品、工具、文件资料、护照签证、机票等等。
检查表(checklist)的使⽤--测试检查表checklist很常见,各⾏各业都有,但是作为电信运营⽀撑系统这样⼤的软件系统的实施和开发,却。
检查项⽬并不是⼀成不变的,也不是随便想⼏个就可以的,否则会成为摆设。
⼀定得要有过程管理思想并深刻体会到其中的关键点进⾏监控。
每个团队、每个时期都是动态变化的,checklist是⼀种动态的⼯具。
除了过程,可以使⽤在其他⽅⾯,例如:各种评审。
checklist可以让⼯作标准化,但是快速发展的团队和⾼效⼯作似乎不需要标准化?错,这要看checklist的内容是什么。
总会有需要checklist的地⽅并且能起到真正的作⽤。
测试⽤例检查表是否每个⽤例测试⼀种单独的情况⽤例是否有测试数据⽤例是否有预期结果是否明确描述了测试数据的异常值、正常值、边界值预期结果是否可以再现测试⽤例是否分级展现是否有数据恢复脚本是否有优先级是否是可⽤状态(ready)每个⽤例是否覆盖了测试需求是否有设计时间(⽤例完成设计的时间)是否被评审过测试场景检查表场景是否由⽤例组成的场景是否有优先级是否每个场景中的⽤例已经run是否被评审过测试需求检查表涉及到数据库连接是否明确了连接个数和⽅式是否每个测试需求相对独⽴测试需求之间不应该存在因果关系测试需求中不应该存在模糊描述(⼤量、很多、长时间等等)测试需求的来源是否可靠(不会被随意改动)测试需求描述是否清晰⽆歧义是否被评审过是否设定了优先级测试需求是否包含了业务需求是否把复杂的业务需求分解了是否每个测试需求都有明确的输⼊输出,便于测试defect检查表是否描述清晰:出现问题的环境简要描述是否描述清晰:出现问题的操作过程描述是否描述清晰:问题现象描述清楚是否提出了⾃⼰的分析是否指定了解决⼈是否跟踪了每⼀个⾃⼰的bug是否有未关闭的bug是否提出bug之前检查了没有⼈已经提出来过(不重复)是否每个defect描述⼀个独⽴的问题是否及时修改了defect状态是否填写了应该填写的字段不能带有主观的对程序的评价bug描述中不能带有疑问句是否填写了优先级是否填写了严重程度测试计划检查表是否符合项⽬⾥程碑时间要求是否安排好了执⾏时间计划是否安排好了执⾏⼈计划计划安排是否粒度到天(周)是否有测试⼈员培训计划第⼀、描述了项⽬的⽬的第⼆、描述了项⽬的开发周期第四、描述了测试案例的设计周期第五、描述测试案例的执⾏周期第六、描述了测试过程中⽤到的⼯具或者技术第七、描述了测试过程中⽤到的资源情况每⼀部分测试计划时间安排是否有冲突是否有测试过程检查机制测试过程检查是否涉及到其他组是否取得了相关组的认可是否经过了有项⽬经理参加的评审是否有测试执⾏⽇报告机制是否有风险分析以及规避⽅法是否有测试环境描述是否有测试⼈员协作机制是否有测试⼈员考核点描述并且可⾏是否有其他组协作机制描述测试环境更新检查表是否是在确认了版本⽆误的情况下更新的是否有配置⽂件更新是否可执⾏程序权限正确是否记录了编译错误并报告更新后是否做了冒烟测试更新后是否记录了更新过程如果更新步骤或内容有变化是否同步更新了作业指导⽂档更新问题是否提交到CVS更新问题是否通知到相关⼈员是否记录了本次更新经验(版本更新⽇志)测试⽅案检查表是否描述了测试⽅法是否描述了测试参与⼈员是否描述了测试环境是否描述了⼈员协作办法是否相关⼈员已经通知到是否描述了测试内容测试内容时候细化到模块是否描述了测试时间安排是否描述了测试⼈员培训安排是否描写了测试说明章节是否进⾏了换位思考(别⼈能读得懂吗)是否有备份⽅案是否经过评审准备测试评审检查表是否提前给开发组和项⽬经理以及相关⼈员发送了评审材料是否预定了会议室和预约了合理的时间是否准备了与会材料和⼯具(投影机等)是否主讲者已经演练了⼀下是否最好了被推翻重来的准备是否做好了听取改进意见的准备是否做好了改变原有思路的准备是否做好了⼤家都没有意见的准备是否做好了需要⼆次评审的准备是否做好了由于各种原因评审会失败的准备是否检查过了被评审材料压⼒测试检查表是否已经清楚了实际业务的压⼒情况是否已经预估了业务发展趋势和量化了增长速度是否预估了产品的⽣命周期是否预估了产品⽣命周期内业务量可能的峰值是否统计了业务峰值时间段以及峰值业务量是否已经明确了⽣产系统的主机分布。
项目测试管理CheckList Prepared by Date 2009-10-26
编制日期
Reviewed by Date
审核日期
Authorized by Date
批准日期
All rights reserved
版权所有违版必究
1、内容填写说明
A、项目基本信息由测试用例设计者填写。
B、自检,根据检查结果在自检结果“是、否、免”相应栏中作“V”标记;是:满足要求,否:不满足要求,免:内容不涉及此项目;在“否、免”栏作“V”标记,必须在自检说明中填写原因。
C、审查,确认自检结果是否正确,如与审查项目一致:在互检结果“是”栏作“V”标记,否则:在审核结果“否”栏作“V”标记,并在审核说明中填写原因。
D、“自检结论及问题说明”由测试用例设计者填写,在此栏说明该项目检视的要点,方便审核者检查。
“审核结论及问题说明”由审核者填写,在此栏列出审核结果中为“否”的所有问题。
E、最终QA将此文档提交给运作支持部,进行数据备份,整个过程由运作支持部跟踪。