文章目录
- 1.web测试流程
- 1.1 需求分析
- 2.1 测试计划编写
- 2.2 web端测试用例设计
- 2.2.1 UI测试
- 2.2.2 搜索测试
- 2.2.3 表单测试
- 2.2.4 输入域测试 - 输入框的场景
- 2.2.5 分页测试
- 2.2.6 交互性数据测试 - 前后台交互系统
- 2.2.7 链接测试
- 2.3 用例执行
- 2.4 回归测试
- 2.5 web专项测试
- 2.8 测试总结报告
- 总结
✨✨✨学习的道路很枯燥，希望我们能并肩走下来！
编程真是一件很奇妙的东西。你只是浅尝辄止，那么只会觉得枯燥乏味，像对待任务似的应付它。但你如果深入探索，就会发现其中的奇妙，了解许多所不知道的原理。知识的力量让你沉醉，甘愿深陷其中并发现宝藏。
本文开始
1.web测试流程
1.1 需求分析
在测试开始前，需详细分析需求文档，明确功能点和用户场景。通过需求分析，行确定测试范围和重点，确保测试覆盖所有关键功能.
否合理就是需求分析：考虑是否完善需求，
做法：先搜集测试相关的资料，包括原型图、各种需求文档、业务相关等需求相关材料
其次考虑，测试人需要注意的有思考：根据需求相关资料，自行熟悉需求效果，同时列出不明白的点，多与开发或产品沟通
再明确要测的范围，测试功能点有哪些，测试的作用流程是如何的，输出的结果是否明确，异常流程，测试预估，测试时间排期，测试顺序，形成测试需求
2.1 测试计划编写
测试计划：几个人测？如何安排测试？
测试的策略有哪些？-测试
测试时长？测试环境的搭建？
2.2 web端测试用例设计
填写测试用例表，通过等价类划分、边界值分析、错误推测、场景分析、判断表等方法设计具体测试用例。
注意：另外账号是否涉及权限，要是有，多用几个账号登录试试，遇到有问题的地方要多重现bug，确认障碍是否存在的；
点击了解 =》黑盒方法测试用例设计了解
2.2.1 UI测试
总结：界面样式和文字内容显示是否正确
- 界面风格样式统一，与 UI设计原型图一致
- 界面文案正确-文字显示正确
- 提示、警告或错误说明描述准确
- 否按比例缩小或出现滚动条，就是切换窗口大小，将窗口缩小后，页面页面是否正确展示
- 所有的图片是否都被正确加载
- 在不同的浏览器、分辨率下图片是否能正确显示
如: 下图考虑界面是否正常-百度一下为例
2.2.2 搜索测试
若是承受模糊查询，搜索名称中任意一个字符是否能搜索到
比较长的名称是否能查到，看名称长度规定是否有范围
输入系统中不存在的与之匹配的条件
否出现页面错误就是不同查询条件之间来回选择，
查询条件的组合测试 - 多条件查询，随机组合
1.任单个条件查询：正常输入搜索、模糊搜索、超长搜索、不存在与之匹配的条件、为空；
2.任两个组合查询：确保任两个组合查询的正确性验证，验证两个组合的所有情况；
3.三个组合查询：不需要测试三个组合的全部级组合。因为前面针对所有单个条件的搜索、两个组合的所有组合进行测试了，这里选择2-3组三种组合进行测试即可；
4.全条件组合查询：确保最大组合的正确性；
5.默认条件查询：补充默认条件查询的用例；下拉框搜索测试 —默认值、数据完整性/正确性、第一个/最后一个/中间一个选取、手动输入值模糊匹配、联动选择；
时间输入框 - 考虑如下
1.开始时间=结束时间，验证一天范围的信息；
2.开始时间<结束时间，验证跨天、跨月、跨年的内容；
3.开始时间大于/小于当前时间，若是针对出生年月搜索，验证大于的情况；若是定时任务时间搜索验证小于的情况；
4.只输入开始时间或者只输入结束时间；开始时间和结束时间都不输入；
否给予合理提示；就是5.结束时间早于开始时间，验证系统
6.验证是否支持手动输入时间，并注意时间格式验证例如20180612格式。
搜索如下图：包括下列搜索
2.2.3 表单测试
- 表单按钮功能正常达成
如：提交按钮，是否支持回车/单击、快速多次点击是否重复提交表单、网络中断（弱网）提交、提交之后是否有提示、提交后内容是否加密、提交是否做权限校验控制、多人针对表单同时操作的场景测试。 - 否支持模糊匹配就是下拉列表材料完整、正确，可以正常选择，
否完整，支持搜索吗，承受模糊搜索就是数据显示 - 文件上传大小、尺寸、格式、数量、文件内容规则验证
如：图片、视频、excel、txt等文件上传测试 ——大小、尺寸、格式、数量、文件内容规则验证； - 表单提交，删除，修改后是否有提示信息
- 表单页面-》浏览器的前进、后退、刷新按钮，是否会造成数据重现或页面报错
- 提交表单是否支撑回车键和 Tab 键 - 易用性考虑
- 数据重复检验
- 否能正确保存到数据库中就是表单提交的数据
2.2.4 输入域测试 - 输入框的场景
输入类型检验 - 根据需求设计类型建议，设计不同设计用例
如：数字，中文，字符，特殊符合输入长度检验 - 根据需求考虑输入长度，考虑使用边界值+等价类
必填项检验
重复性检验 - 看需求中是否允许重复
如: 需求允许重复，设计不重复数据输入
需求不允许重复，设计重复数据输入验证空格检查
如: 数据 + 空格 ；空格+数据+空格；单独空格(一个或多个空格)；空格+数据；安全性检查
如：注入sql , xml，js
加密-密文显示，权限-未登录-登录
2.2.5 分页测试
- 没有数据时界面展示情况
- 翻页后数据展示情况
如：首页、上一页、下一页、尾页功能验证；注意下首页情况下，上一页是否承受点击；尾页情况下，下一页是否支持点击； - 分页的总页数及当前页数显示是否正确
- 是否能正确跳转到指定的页数
指定跳转页验证；例如输入8，点击跳转那么是否能正常跳转到第8页的数据，且还注意下跳转的有效范围是1-总页数 ；
【注】考虑1、最大页数的有效值验证，且也需要考虑0、总页数+1、负数、小数、非数字、空的异常值验证。
2.2.6 交互性数据测试 - 前后台交互系统
- 否对后台产生相应正确的影响就是前台的数据执行
如：前台操作是否对后台操控影响 - 否随着授权而变化就是用户的权限，
如：用户获取权限，看前台是否有权限查看
2.2.7 链接测试
- 是否能够直接链接查看
如：输入栏url - 是否有权限控制
如：用户登录后，才用权限访问
无权限控制，一般链接理论上都可以访问 - 是否直接执行，并返回相应结果页
如：携带参数的url，直接访问某个页面看是否可以
2.3 用例执行
执行测试用例，对比预期结果和实际结果，过程中发现bug, 进行bug管理
2.4 回归测试
bug回归测试
老效果回归测试 - 敏捷编写中需要常测
2.5 web专项测试
兼容性测试，安全测试，验收测试
2.8 测试总结报告
测试报告：测试哪些功能，写了多少测试用例，执行依据多少，未通过多少，bug多少，用例通过率多少
总结
✨✨✨各位读友，本篇分享到内容是否更好的让你理解了测试，如果对你有帮忙给个赞鼓励一下吧！！
世上没有绝望的处境，只有对处境绝望的人。
个失败者。而一向努力奋斗，坚韧不拔的人会走向成功。就是一遇挫折就灰心丧气的人，永远
感谢每一位一起走到这的伙伴，我们可以一起交流进步！！！一起加油吧！！！