软件测试-公共用例-小结

在各个项目测试周期中，经常有像类似的测试点，总结如下（不涉及业务公共用例）：

类型	测试点	测试内容/步骤
类型	测试点	测试内容/步骤
新页面、页面重构、页面修改	TDK	检查页面的title，description，keywords是否齐全
	统计代码	检查是否包含了百度统计代码，不包含其它不必要的统计代码
	资源大小	图片是否过大，是否经过压缩
	资源缓存	刷新检查css，js，图片是否做了缓存
	加载速度	检查加载速度是否超过2S
	懒加载	同时包含图片和文字内容时，是否使用了懒加载
	https兼容	https页面内是否包含了http资源和链接并且是否可以正常跳转访问
	JS加载	检查是否有js加载错误
	TAB键顺序	具有填写表格或者选项的页面，tab键顺序是否正确
	元素点击区域	元素可点击区域，鼠标悬浮变色提示等是否符合要求
	后退，返回	页面后退是否符合业务要求
	信息泄密	检查页面源代码是否有不适合的注释，比如泄漏公司服务器目录结构等；
	域名指向	是否有链接地址写死指向测试域名(此种情况功能正常，上线后会有问题)
	浏览器兼容	各个主流浏览器上的展示以及功能是否正常
	分辨率兼容	主流分辨率手机（或者PC显示器）展示以及功能是否正常
列表，列表页 【注： 列表中的每一条数据称为数据项 每条数据项包含若干元素，如： FM节目可以包含标题，主播，封面 等元素】	空数据	空数据页面及提示是否符合需求定义
	数据项不足一页	数据少于一页要求的条数时
	数据项多于分页	数据多于一页，检查翻页和每页条数是否正确
		数据多于一页，检查数据项是否重复显示
	数据项排序	检查数据项排序是否符合预期
		多个数据项排序条件都相同时，检查先后顺序
	翻页操作	点击或者滑动翻页时，向前或向后翻页是否符合预期
		有页码或者前一页后一页的，点击页码进行跳转，或者最后一页，第一页时进行前后跳页
		滑动翻页到数据项加载完全，检查提示和交互是否符合需求预期
		在非首页进行刷新操作，检查是否保持当前页（滑动刷新除外）
		url有页码时，直接修改页码存在和不存在的页码进行跳转
	数据项点击跳转和回退	检查列表数据项整体是否整体可点击，点击区域是否符合预期
		点击首页列表头部元素，中部位置元素查看后返回，检查返回的显示位置是否符合预期
		翻页后再次点击元素查看后回退，检查返回的显示位置是否符合预期
	数据项增删	增加若干条数据项，刷新页面，检查数据项条数
		删除列表第一条数据项，刷新页面，检查数据项条数和位置（是否可删除或者不显示，根据业务情况而定）
		删除列表当前页中间的某一条数据项，刷新，检查数据项条数和位置
		删除当前页未尾一条数据项，刷新，检查数据项条数和位置
		增加数据项后，不刷新，进行翻页，检查数据项条数和位置（是否会影响原有排序和分页，取决于开发实现比如是否缓存，是否每次请求等）
		删除数据项后，不刷新，进行翻页，检查数据项条数和位置
		删除数据项后，不刷新，点击查看，检查是否符合需求定义
	数据项状态变更	数据项由显示变为不显示（比如后台标记为隐藏，或者删除），刷新检查数据项和显示
		数据项的其它状态为更，如待审核，审核通过，审核不通过等状态变更时的显示（根据业务情况而定）
	数据项各元素显示	检查各元素显示位置
		检查各元素的可点击性和点击区域是否符合预期
		一个元素有不同字段时，取值是否符合预期（比如问答显示的是编辑后的标题还是原标题，需要多了解各字段数据来源）
		各元素值修改或者变更后，刷新检查值变化是否符合预期
		各元素显示的长度验证，超长或者包含特殊字符时的显示
		列表中图片的尺寸是否符合剪裁要求，是否做了压缩
聚合页面或模块 【聚合页面，定义为只是读取数据展示的页面或者 模块，比如App首页的FM模块，测试评模块，广告 模块。PC首页的各个模块都是类似的，都是由不同 的数据显示模块构成。列表页也是一种聚合页面， 只是比较特殊，有代表性，单独划分】	数据显示条件验证	验证需要出现的数据是否符需求定义的条件
	数据为空	检查空数据时是否出现异常或者满足需求定义
	数据条数不足	检查当符合条件的数据条数大于0少于需求要求的常规个数时的显示
	数据项增删	增加满足展示条件的数据，检查刷新后的显示
		删除或者减少满足展示条件的数据，检查刷新后的显示
		删除数据项后，不刷新，点击查看，检查是否符合需求定义
	数据项状态变更	数据项由显示变为不显示（比如后台标记为隐藏，或者删除），刷新检查数据项和显示
		数据项的其它状态为更，如待审核，审核通过，审核不通过等状态变更时的显示（根据业务情况而定）
	数据项各元素显示	检查各元素显示位置
		检查各元素的可点击性和点击区域是否符合预期
		一个元素有不同字段时，取值是否符合预期（比如问答显示的是编辑后的标题还是原标题，需要多了解各字段数据来源）
		各元素值修改或者变更后，刷新检查值变化是否符合预期
		各元素显示的长度验证，超长或者包含特殊字符时的显示
		图片的尺寸是否符合剪裁要求，是否做了压缩
	数据有缓存	后台编辑数据（或者通过其它业务操作改变数据项的内容），刷新后检查数据项是否有更新（采用主动刷新的情况下会更新，补动刷新的情况下，不会更新）
		删除缓存或者等缓存过期后，重新刷新
		增加或者删除一些数据项，刷新后检查数据是否有更新（采用主动刷新的情况下会更新，补动刷新的情况下，不会更新）
		新旧版本采用相同缓存key的时候，验证由旧版本生成的缓存数据由新版本读取时，新版本生成的缓存数据由旧版本读取时，是否都能正确解析和显示，操作是否正常
内容需要接审核系统	数据处于审核中	检查数据可能出现的地方是否符合需求定义（可见或者不可见，可操作或者不可操作等）
	数据审核不通过	检查数据可能出现的地方是否符合需求定义（可见或者不可见，可操作或者不可操作等）
	数据审核通过	检查数据可能出现的地方是否符合需求定义（可见或者不可见，可操作或者不可操作等）
	数据审核状态变更	数据由审核通过变为不通过，由不通过变为通过，检查数据可能出现的地方是否符合需求定义（可见或者不可见，可操作或者不可操作等）
	重复审核	重复多次审核，检查可能出现的通知等消息是否会重复
	异步或者同步回调	需要与开发沟通，审核的回调是同步的还是异步的，异步的需要考虑可能导致业务阻塞的情况，是否影响用户体验；异步的情况，需要考虑在审核未回调时，是否符合需求要求
消息、任务队列	触发场景	根据需求定义，验证触发消息，或者任务的条件
		同一个场景或者动作反复触发，是产生一个消息、任务还是多个（根据需求定义，需考虑是否存在被恶意刷的可能）
	并发性能	考虑业务上是否存在同时触发大量消息或者任务的情况，如存在，需要考虑队列处理是否存在性能问题
	容错处理	人为制造一些脏数据，使消息发送失败或者任务执行失败，检查队列是否阻塞

转载于:https://www.cnblogs.com/fengyupo/p/10813728.html