今天主要讲讲web测试的基本流程，同时也算是为大家慢慢普及这方面的知识和内容。

1、web测试流程：

1）参与一个web新项目的测试前，先搜集测试相关的资料，包括原型图、各种需求文档、业务相关等需求相关材料

2）结合第一步搜集到的需求相关资料，自行熟悉系统，同时列出不明白的点，对产品有个初步了解，对易错点、重点测试点列个问题列表；

3）找PM或产品经理熟悉系统，要求系统性地介绍一遍产品，包括相关的隐含需求点，同时过一遍上一步列出的问题列表和核对需求与开发进度，明确要测的范围、测试顺序，形成测试需求；

4）根据原型图和需求文档、测试需求，编写测试方案、计划，跟PM确认。确认后，开始根据系统概要列测试用例，填写测试用例表，通过等价类划分、边界值分析、错误推测、场景分析、判断表等方法设计具体测试用例。注意：浏览器兼容性，不同的操作系统（Mac,Windows）；另外账号是否涉及权限，如果有，多用几个账号登录试试，遇到有问题的地方要多重现bug，确认问题是否存在的；

5）配置测试环境、准备数据（线上导出整理或自行设计数据）。测试环境包括浏览器兼容，主流浏览器等，产品主要使用环境；

6）正式执行测试，根据测试用例执行测试，记录提交bug。对于发现的bug，在word上通过文字描述、截图等方式，列出问题及对应的复现条件，标记好优先级，修改时间，命名为xx系统缺陷记录汇总表；

7）邀请PM对bug文档进行备注，哪些是bug，哪些是测试理解有误，哪些是暂不开发或者需求有变化的，及时知晓，同时对于bug，及时分配给对应开发修复；

8）撰写简要的测试结果、缺陷数量、状态、分布等情况；

9）经过第一轮测试，已经对系统有了更深入的了解；开始根据开发迭代周期进行持续测试，对第一份测试结果进行修改，已fixed的标记删除，然后新增或更新bug;

10）后续的版本迭代测试，注意做好回归测试；每次发布前要求PM列好发布要点；

2、关于项目迭代过程中的回归测试——注意点：

​ 1）确保每次发布是受控的，即每次发布的要点自己必须清楚，避免未经测试的要点随便发布上线，做法：要求PM或产品经理提测时列发布要点，过一遍需求；

​ 2）对发布要点做冒烟测试前，要充分了解业务，对修改点熟悉，测试前有基本的测试方法，且针对新修改点可能涉及的模块，发散思维，确保完整测到所涉及到的相关模块；

​ 3）新增模块除了做基本的冒烟测试，一定要做关联模块和功能的check，尤其涉及交互的部分，做充分测试，也包括插件调用等；

​ 4）冒烟测试完成后，一定要做对应的回归测试，所有功能点要测试到位，前期在迭代发布测试过程中，总结精简有效测试集，对于后续优化过程中基本不会改变的功能，比如：注册、登录、修改密码等可以通过firefox的插件selenium编写一些自动化测试脚本，也可以提升回归测试效率；

​ 5）测试过程中，与产品经理或PM的交流需要时常进行，了解产品才能测试好好产品，且中间需求有变动或者系统相关的中间产出物也能及时获取；
（坑：登录-退出时，需要检查拦截问题，比如没登录，直接填充url来进行跳转，后台有无做验证；）

3、测试方案大概内容如下

​ 1）测试方案：写明将要如何进行测试的文档，包括测试计划、测试环境、测试数据、测试工具、测试方法、风险依赖等方面。

​ 2）测试方案参考目录（可根据项目或产品需要适当删减）

​ （1）功能测试、模块1、模块2、模块3、接口测试、测试内容

​ （2）包含系统的哪些模块哪些方面（功能、性能、数据）、测试范围、测试环境 、测试工具 、测试数据、测试方法 、测试人力资源安排、测试进度安排、测试输出 、风险分析 、硬件环境、软件环境、借助到的一些测试浏览器兼容性工具、自动化测试工具、性能测试工具

​ （3）黑盒测试、白盒测试、冒烟测试、验收测试、包含哪些文档、报告等、一般有：测试计划、测试方案、系统评测报告、缺陷报告等、系统上线后可能会出现的问题，一些现在尚未解决的bug，各种使用环境可能出现的问题等；

​ （4）编写目的、读者对象、项目背景、测试目标、参考资料、概述 、测试计划 、集成测试用例 、系统测试用例 、性能测试