Web项目测试流程
测试流程
标准测试流程
各阶段交付内容：
| 阶段 | 交付物 |
|---|---|
| 计划 | 测试计划、测试方案 |
| 控制 | 每个阶段的测试进度 |
| 分析 | 测试需求分析文档 |
| 设计 | 测试用例 |
| 实施 | 测试环境 |
| 执行 | 测试用例执行结果、缺陷报告 |
| 结束活动 | 测试总结报告 |
评审
可以理解为评价、审查，一种静态测试技术。测试的交付物，用户需求、UI设计、开发设计等文档都要经过评审才能正式使用。
评审是为了检查文档的完整性和准确性，找到其中的缺陷。
评审的形式：
交叉评审（非正式）、走查、技术评审
环境搭建
系统开发完成后，下一步就是熟悉系统并进行相关测试环境的搭建。
Windows平台部署
1.数据库服务器部署
安装并启动MySQL（安装版MySQL、集成环境MySQL），导入脚本
2.后端服务器部署
环境和密钥，部署并启动后端
3.前端服务器部署
安装并启动Nginx，部署前端
4.设置局域网访问
编写测试计划
编写测试计划的目的在于对资源、成本及进度进行越来越合理的估算。
测试计划是一项持续的活动，贯穿整个产品的生存周期。
测试计划一般由测试主管制定，测试组员参与测试计划的制定及评审活动。
测试计划模板内容：
- 确定测试的范围、目标和风险
- 定义整体测试方法
- 将测试活动集成并协调到软件生命周期活动中
- 确定要测试的内容，开展各种测试活动所需要的人员和其他资源，以及如何开展测试活动
- 安排测试分析、设计、实施、执行和评估活动的进度表，例如，在顺序开发过程中安排或在每次迭代开发中安排
- 选择测试监督和控制的度量
- 为测试活动编制预算
- 确定测试文档的详细程度和结构（提供模板或示例文档）
注意事项：
1.实际工作中，常常把需求分析放在测试计划之前做，这是因为不清楚需求规模无法确定用例数量、缺陷大概规模
2.注意各组员对于项目的结构、时间、进度等各项的一致性，不要计划内容相互冲突、矛盾
3.注意计划贴合实际，比如实际测试周期为7天。
任务要求
如果是一个测试小组，则组长分配给每个组员任务，完成后由组长检查、合并；如果是单人，最后提交一个测试计划文档。
测试需求分析
目的是确定测什么。
测试需求分析的测试点是编写测试用例的依据，测试需求分析有助于保证测试质量与进度。
测试需求分析是避免漏测的最有效手段之一。
分析测试需求大致有如下三个环节（分析过程）：
测试需求分析经过如下3个环节：
测试要点分析
测试要点是对每一条开发需求的细化和分解，形成可测试的分步骤描述。
通过分析开发需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容。
注意：
1.需求的完整性
1.经过分解获得的需求必须能够充分覆盖软件的各个特征
2.每个需求必须可以独立完成有意义的功能，可以进行单独测试
2.需求的规模
1.每个最低层次的需求的测试用例的颗粒度应保持均匀
功能交互分析
测试要点分析是细化和分解，功能交互分析是将细化和分解的测试点交换起来，主要使用流程分析法分析业务流程，对测试点进行补充。
做的比较熟悉之后，测试要点分析和功能交互分析可以合并为一步做。
质量特性分析
根据ISO25010质量模型，分析每一个测试点的质量特性。
软件产品质量
外部质量：功能性、性能效率、兼容性、易用性、可靠性、安全性
内部质量：可维护性、可移植性
注意：
一个测试点可能会有多个质量特性
测试类型分析
根据每一个测试点的质量特性，划分测试类型
常见测试类型有：
功能测试、性能测试（压力测试、负载测试、容量测试）、安全性测试、兼容性测试（配置测试、安装测试）、可靠性测试（稳定性测试）、易用性测试（UI测试）。
熟练之后，质量特性分析和测试类型分析可以合并为一步做。
注意
需求分析是一个动态的过程，随着需求的不断变更，以及测试执行之后的总结反馈，需求分析文档也需要不断的维护、变更。
需求评审
设计测试用例
将上一阶段测试需求分析的测试点编写成测试用例
测试需求分析回答了"测什么"的问题，测试设计回答了"如何测"的问题
设计测试用例包括以下主要活动：
1.设计测试用例和测试用例集，并确定其优先级
2.准备所需的测试数据以支持测试用例
3.设计测试环境
主要采用黑盒测试技术：
1.等价类划分法
2.边界值分析法
3.场景设计法
注意
1.用例不是越多越好，在尽量覆盖需求的前提下，用例的数目越少越好
2.一般一条测试用例包含多个步骤，如果大量用例都只有1-2个步骤，用例的质量一般不高
3.相似测试点的用例要合并，一些不能明确观察测试结果的用例要删除
4.不要一个UI元素写一个用例，例如，一页有多个输入框，编写一个测试用例即可。
实施与执行
实施与执行阶段主要是搭建测试环境、识别测试条件、准备测试数据，执行测试
这个阶段的主要输出是：测试用例执行结果、缺陷报告
测试实施主要包括：
1.确定测试规程，创建自动化测试脚本
2.根据测试规程和自动化测试脚本来创建测试套件
3.在测试执行进度表中，以有利于测试执行的方式安排测试套件
4.构建测试环境，包括测试工具、服务虚拟化等，并验证一切所需都已正确设置
5.准备测试数据并能够在测试环境中正确加载
6.确认并更新测试需求、测试条件、测试用例、测试规程和测试套件之间的双向可追溯性
测试执行主要包括：
1.记录测试项、测试工具及测试的ID和版本
2.手工或者使用测试执行工具进行测试
3.将实际结果与预期结果进行比较
4.分析异常现象来确定他们可能发生的原因
5.根据实际观察到的失效报告缺陷
6.记录测试执行的结果（通过、失败、阻塞）
7.对异常修复完的结果要进行确认测试、回归测试
8.确认并更新测试需求、测试条件、测试用例、测试规程和测试套件之间的双向可追溯性
用例执行结果：
1.通过
2.失败：测试结果与预期结果不符
3.阻塞：某功能欠缺或者测试环境的某个部分欠缺，导致当前测试不能进行
4.忽略
注意
1.一个测试用例由多个测试步骤组成，只要有一个步骤失败，用例失败，只要有1个步骤阻塞，用例失败
2.在执行过程中如果对用例有疑问，一定要联系用例作者
3.不要空跑用例，没有在软件上执行相应操作就直接打结果，这违反测试工程师的职位道德，一经发现直接开除。
4.自己的测试用例全部执行完毕，还可与其他组之间交叉执行
缺陷报告
从某种意义来说，缺陷报告是软件测试工作中最重要的输出。
缺陷报告的编写要注意
1.误报缺陷会耽误整个团队的大量时间，报bug一定要谨慎
2.发现缺陷的第一反应不是编写缺陷报告，而是反复重现，找到出现缺陷的规律、重现概率和步骤
3.留存缺陷的证据，截图、录像、日志文件等。
3.缺陷的严重程度一定要实事求是
4.每个组员的缺陷应该指派给组长评审
测试结束
测试结束活动出现在项目里程碑，例如测试项目完成时，系统发布时，维护版本完成时
测试结束主要包括：
1.检查是否所有缺陷已关闭
2.创建测试总结报告
3.归档测试环境、测试数据、测试基础设施及其他相关测试件
4.通过收集的信息来改进测试过程的成熟度
主要输出是：测试总结报告。
核心在于统计用例的执行情况和缺陷的状态分布数据
注意
1.好的测试报告在于多用图表表示数据
2.根据项目质量情况可以更进一步给出一些测试建议，例如，建议重点测试哪些模块，增加哪些测试类型