日常项目测试用例检查点(来自一线测试人员的吐血总结)

原文链接:https://blog.csdn.net/u012941152/article/details/90055797

转载自同事的总结,从测试用例中,也可以总结出我们开发的时候需要注意和校验的事项。下面是正文


是这几年的测试工作中,渐渐觉得自己工作久了,可以自行发散测试思维去做一个测试用例,甚至有时候连用例都不写了,久而久之工作根本没有效率,还经常忽略很多测试的点

    现在我整理下网上和自己工作中得到的经验,检察自己每次做测试任务的时候都对照着自己有没有遗漏的地方

一. 输入框

1.1  字符型输入框

1. 根据需求是否必填

2. 字符型输入框:英文全角、英文半角、数字、空或者空格、特殊字符“~!@#¥%……&*?[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时,使用“粘贴、拷贝”功能尝试输入。

3. 长度检查:最小长度、最大长度、最小长度-1、最大长度+1、输入超工字符比如把整个文章拷贝过去。

4. 输入的文字限制,需要在输入框内加上placeholder提示语

5. 空格检查:输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格、字符全部为空格(不允许)

6. 多行文本框输入:允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行,检查能否正确保存(若能,检查保存结果,若不能,查看是否有正常提示)

7. 表情:系统表情、键盘表情、表情包输入

8. 安全性检查:输入特殊字符串

(null,NULL,,javascript,<script>,</script>,<title>,<html>,<td>)、输入脚本函数(<script>alert("abc")</script>)、doucment.write("abc")、<b>hello</b>)

 

1.2 数值型输入框:

1. 根据需求是否必填

2. 边界值:最大值、最小值、最大值+1、最小值-1

3. 位数:最小位数、最大位数、最小位数-1最大位数+1、输入超长值、输入整数

4.异常值、特殊字符:输入空白(NULL)、空格或"~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能导致系统错误的字符、禁止直接输入特殊字符时,尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能,通过剪贴板拷贝到输入框,分页符,分节符类似公式的上下标等、数值的特殊符号如∑,㏒,㏑,∏,+,-等、

5. 输入负整数、负小数、分数、输入字母或汉字、小数(小数前0点舍去的情况,多个小数点的情况)、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制,8进制数值、货币型输入(允许小数点后面几位)、

6. 安全性检查:不能直接输入就copy

 

1.3 日期型输入框:

1. 根据需求是否必填

2. 按钮防止重复点击

3 合法性检查:(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入[30][31]、输入非闰年,月输入[2],日期输入[28、29]、输入闰年,月输入[2]、日期输入[29、30]、月输入[0、1、12、13]

考虑开始日期与结束日历的比较,特别是在查询的时候.

4. 异常值、特殊字符:输入空白或NULL、输入~!@#¥%……&*(){}[]等可能导致系统错误的字符

5. 安全性检查:不能直接输入,就copy,是否数据检验出错?

 

二. 表单提交

1. 表单中哪些字段是必填项

2. 表单中字段内容的限制:非空、重复、长度、特殊字符,文字前后空格、全部空格、以及一些和业务相关的约束条件

测试点:

           1、提交按钮是否支持回车

            2、单击按钮

            3、快速双击, 校验按钮有无做防重复点击操作

            4、网络中断

            5、只输入必填项,单击提交

            6、分别缺少一个必填项、单击提交(无效等价类不能合并)

            7、所有字段的最大长度,单击提交

             8、所有必填项+非必填项 ,单击提交

             9、提交成功是否有提示,或有页面跳转

             10、如果有上传附件,附件超大、网络慢,是否有上传提示,提交后是否成功

              11、使用POST加密传输

              12、SQL注入     

              13、权限校验,也就是说只有有权限的人才可以提交

              14、对于修改、新增、审核等需要修改数据库中数据的操作,多人同时操作的场景需要测试,比如A编辑,B再编辑然后B提交,A提交

              15. 敏感词处理

              16. 图片上传:限制上传size、网络中断(前端提示)、上传服务器地址失败(服务端返回error msg )
 

功能测试:

业务流程,一般会涉及到多个模块的数据,所以在对业务流程测试时,首先要保证单个模块功能的正确性,其次就要对各个模块间传递的数据进行测试,这往往是容易出现问题的地方,测试时一定要设计不同的数据进行测试。

如某一功能模块具有最基本的增删改查功能,则需要进行以下测试:

1. 单项功能测试(增加、修改、查询、删除)

2. 增加——>增加——>增加 (连续增加测试)

3. 增加——>删除

4. 增加——>删除——>增加 (新增加的内容与删除内容一致)

5. 增加——>修改——>删除

6. 修改——>修改——>修改 (连续修改测试)

7. 修改——>增加(新增加的内容与修改前内容一致)

8. 修改——>删除

9. 修改——>删除——>增加 (新增加的内容与删除内容一致)

10. 删除——>删除——>删除 (连续删除测试)

 

容错测试:

1. 输入系统不允许的数据作为输入

2. 把某个相关模块或者子系统停掉,验证对当前系统的影响

3. 配置文件删除或者配置错误

4. 数据库注入错误数据

 

常规性能测试

1. 连接速度测试

用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。
另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

2. 负载测试
负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

3. 压力测试
负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等

 

兼容性测试

兼容性测试不只是指界面在不同操作系统或浏览器下的兼容,有些功能方面的测试,也要考虑到兼容性,包括操作系统兼容和应用软件兼容,可能还包括硬件兼容,比如涉及到ajax、jquery、javascript等技术的,都要考虑到不同浏览器下的兼容性问题。

除了上面所说的这些测试以外,还有算法测试、配置测试、安全性测试等等,在工作中不断总结和分析,形成自己的功能测试框架,当你把这份工作做起来以后,对于你自己对于测试团队而言都是一份很有价值的事情,你的测试思路也会变得更全面。
————————————————
版权声明:本文为CSDN博主「雪国的花儿」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/u012941152/article/details/90055797

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章