1.测试流程:
(仅供参考,个人工作流程:)
- web测试
- 参与一个新项目的测试前,先搜集测试相关的资料,包括原型图、各种需求文档、业务相关的说明,比如要开发的:品牌表、约定的指标计算方式等码表,业务说明等需求相关材料;
- 结合第一步搜集到的需求相关资料,自行熟悉系统,同时列出不明白的点,对产品有个初步了解,对易错点、重点测试点列个问题列表;
- 找PM或产品经理熟悉系统,要求系统性地介绍一遍产品,包括相关的隐含需求点,同时过一遍上一步列出的问题列表,同时核对需求和开发进度,明确要测的范围、测试顺序,形成测试需求;
- 根据原型图和需求文档、测试需求,编写测试方案、计划,跟PM确认。确认后,开始根据系统概要列测试用例,填写用例表,通过等价类划分、边界值分析、错误推测、场景、判断表等方法设计具体用例。【注意浏览器兼容性,不同的系统(Mac,Windows);另外账号是否涉及权限,如果有,多用几个账号登录试试,遇到有问题的地方多重现bugs,确认问题是存在的;】
- 配置测试环境、准备数据(线上导出整理或自行设计数据)。测试环境包括浏览器兼容,主流浏览器,产品主要使用环境;
- 正式执行测试,根据测试用例执行测试,记录bugs文档。对于bugs点,在word上通过文字描述、截图等方式:列出问题及对应的重现条件,标记好优先级,修改时间,命名为xx系统缺陷记录mmdd;
- 邀请PM对bugs文档进行备注,哪些是bugs点,哪些是测试理解有误,哪些是暂不开发或者需求有变化的,及时知晓,同时对于bugs点,及时分配修复;
- 撰写简要的测试结果、缺陷数量、状态、分布等情况;
- 经过第一轮测试,已经对系统有了更深入的了解;开始根据开发迭代周期进行持续测试,对第一份测试结果进行修改,已fixed的标记删除,然后新增或更新bugs;
- 后续的版本迭代测试,注意做好回归测试;每次发布前要求PM列好发布要点;
2.关于项目迭代过程中的回归测试——注意点:
1、确保每次发布是受控的,即每次发布的要点自己必须清楚,避免未经测试的要点随发布上线,做法:要求PM或产品经理提测时列发布要点,过一遍需求;
2、对发布要点做冒烟测试前,要充分了解业务,对修改点熟悉,测试前有基本的测试方法,且针对新修改点可能涉及的模块,发散思维,确保完整测到所涉及到的相关模块;
3、新增模块除了做基本的冒烟测试,一定要做关联模块和功能的check,尤其涉及交互的部分,做充分测试,也包括插件调用等;
4、冒烟测试完成后,一定要做对应的回归测试,所有功能点要测试到位,前期在迭代发布测试过程中,总结精简有效测试集,对于后续优化过程中基本不会改变的功能,比如:登录、修改密码…可以通过firefox的插件selenium编写一些自动化测试脚本,也可以提升回归测试效率;
5、测试过程中,与产品经理或PM的交流需要时常keep,了解产品才能测好,且中间需求有变动或者系统相关的中间产出物也能及时获取;
(坑:登录-退出的,需要检查拦截问题,比如没登录,直接填充url来进行跳转,后台有无做验证;)
3.测试方案大概内容
测试方案:写明将要如何进行测试的文档,包括测试计划、测试环境、测试数据、工具、测试方法、风险依赖等方面。
-
测试方案参考目录(可根据项目或产品需要适当删减)
- 概述
- 编写目的
- 读者对象
- 项目背景
- 测试目标
- 参考资料
- 测试计划
- 测试内容
- 包含系统的哪些模块哪些方面(功能、性能、数据)
- 测试范围
- 测试环境
- 硬件环境
- 软件环境
- 测试工具
- 借助到的一些测试浏览器兼容性工具、自动化测试工具…
- 性能测试工具
- 测试数据
- 测试方法
- 黑盒(将用到的相关方法)
- 白盒(讲用到的方法)
- 冒烟测试
- 验收测试
- 测试人力资源安排
- 测试进度安排
- 测试输出
- 包含哪些文档、报告等
- 一般有:测试计划、测试方案、系统评测报告、缺陷报告等
- 风险分析
- 系统上线后可能会出现的问题,一些现在尚未解决的bugs,各使用环境可能出现的问题等;
- 集成测试用例
- 接口测试
- 系统测试用例
- 功能测试
- 模块1
- 模块2
- 模块3
- …
- 性能测试
- 性能测试用例
- 概述