本篇博客
项目测试流程（重点）
1 需求分析与评审（掌握）
- 1.1 需求评审实战
2 编写测试计划与测试方案（了解）
- 2.1 测试计划
- 2.2 测试方案
3 设计测试用例与评审（重点）
- 3.1 基本测试策略
- 3.2 测试用例核心要素
4 执行测试用例与bug跟踪（重点）
5 编写测试报告（了解）
项目测试流程（重点）
项目测试流程：
面试的时候，喜欢问项目的测试流程。
它不是一成不变的，也不是每一个公司都是一样的。下面的是按照时间，把关键的点给归纳总结出来的。切记不是背给别人听，而是要给别人讲清除。
1. 需求分析与评审（理解）
2. 编写测试计划与测试方案（计划）
3. 测试用例设计与评审（写用例和评审）
4. 测试执行与BUG跟踪（执行用例和bug跟踪）
5. 编写测试报告（结果）
（我们在测试的时候工作中心，落在第3步和第4步。）
1 需求分析与评审（掌握）
1 什么是软件需求？
软件需求是指为用户解决某一问题或达到某一目标所需的软件功能
1）解决问题
2）达到目标
解决问题，举个例子：支付宝解决了快捷支付的问题。微信解决了沟通社交问题。
达到目标，举个例子：王者荣耀，在端午节血包会成为粽子的形状。
2 什么是需求评审
项目相关人员就软件需求进行确认和评估的相关活动
3 为什么要做需求评审？
确认需求完整与准确
理解一致
降低因为需求不明确带来的项目失败的风险
4 需求评审的目的
保证需求说明书的完整，准确
保证项目团队对需求的理解达成一致
5 怎么做需求评审？
需求评审会议（在线，离线的形式都可以）
参与人：
- 产品经理/项目经理（一般是由他们来召集这个会议）
- 开发/UI
- 测试（测试可以站在产品最终检验的角度，包括用户使用的经验和用户使用习惯的建议一些点，来让产品更完善）
- DBA（数据库管理人员）
- 。。。甚至架构
注意：测试可能在会议里像打酱油的，但是也要认真听，对写测试用例有帮助。
6 测试人员在需求评审的职责：（测试关注这个就可以了）
1）确认自己对需求要有清晰的理解，没有疑惑（有疑惑当场就要问出来）
2）确认需求无明显错误，能够支撑后续的用例设计等
3）提出一些改进建议
1.1 需求评审实战
需求评审案例：身份认证，第一轮。
大概理解一下上面的图片每一个步骤是干嘛的？
图1：拍两张身份证照片上传到平台
图2：平台会自动识别身份证信息
图3：录入活人头像
图4：将活人头像与身份证照片作比较，如果一致。验证通过
图5：将活人头像与身份证照片作比较，如果不一致，验证失败。
第一轮需求评审
图1：
科普：身份证的真面是有国徽的那一面。
1 上传的身份证需要打上水印，仅供当前产品使用
2 包含身份证有效期的反面照不需要上传吗？（应该3张照片：身份证正面，反面和手持身份证）
图2：
1 姓名与身份证号显示不对齐
2 提示语位置超出界面范围
3 识别后的姓名信息可以修改，但是证件号不可以进行修改
图3：
图片没有问题，但开发会思考到的问题：
技术上存在疑惑，系统能实时给出实名认证判定结果？
大公司：一般需要人工智能，人脸识别技术来支持人脸对比功能。
小公司：审核需要等待，需要1-3个工作日。需要后台人眼进行对比。
现在假设是小公司，所以需要添加一个页面：等待多久以后告诉结果。
图4：
1 返回上一步没有必要，因为已经通过。
2 下一步是去哪？认证通过以后应该就是结束。
图5：
1 简化业务流程，认证失败后不需要返回上一步
2 认证不通过以后建议重新发起认证流程
注意：上面都是通过明面上的错误，基于常识，对比同类型产品发现的问题。基于自我感觉，还有正常人的逻辑。从方方面面找到这些错误。
需求评审案例：身份认证，第二轮。
第二轮需求评审：
图1
身份证的正反面的示例图片的修改
图2
冒号：一个中文，一个英文
图4
1 节点状态应该是审核中，而不是验证完成
2 大概告诉一个人期限（1-3个工作日，注意结果）
图6
提示语错误，不应该是“支付失败”与实名认证完全无关
图1~图6
流程节点（审核中）缺失，所有的图片都应该增加该节点状态
2 编写测试计划与测试方案（了解）
计划和方案越来越统一，计划可能包含方案，有可能就写一个。
测试计划或方案：需要有一个负责人，编写一个文档，来指导接下来测试。比如这个测试任务比较大，会拆成不同的测试工程师去负责不同的模块，然后在哪天做哪些事情。有没有可能会遇到哪些问题，都可以提前琢
磨一下。具体测试的时候用哪一套环境，用什么样的工具，这个都需要在这一步去了解一下。
编写测试计划的负责人：
1 测试组长、经理（第一负责人、管理经验）
2 测试工程师
测试计划一般是由有经验和有管理经验的人写。比如：测试组长和经理
但新时代测试工程师，至少能够写一个测试计划，安排一下自己的测试任务。
2.1 测试计划
概念：是指描述了要进行的测试活动的范围、方法、资源和进度的文档。
核心内容：
1 范围与目标（范围就是要测试哪些功能模块）
2 角色与职责
3 进度与资源（资源比如测试服务器有哪些，测试工程师有几个，有多长测试时间）
4 风险与应对
5 准入准出标准
理解第5点准入和准出的标准：
准入标准：测试接受，开发提交版本的一个标准
准出标准：测试完成测试，提交给后面运维发布的一个准出标准。
下面来看一下TPshop的测试计划和测试方案：G:\2021新测试\学习视屏\03、功能测试\day4\1-课堂资料
TPshop的测试计划一般就是按照左边的5点写的：
2.2 测试方案
概念：是从测试的技术角度去分析需求，在方向上明确要怎么测，分析结果重点在于测试策略与技术实现。
核心内容：
1 方法：黑盒，白盒，自动化还是其他的
2 环境：在哪一套环境里面测
3 工具：如果是自动化用哪一个测试工具，比如：UI/Selenium
测试方案更像一个技术文档，落地方法，环境和工具。它需要像高级测试工程师才能写的出来，不是小白就可以写的文档。
（一般很少写测试方案，除非是一个很大的项目。一般都把测试方案包含在测试计划里。）
TPshop测试方案：G:\2021新测试\学习视屏\03、功能测试\day4\1-课堂资料
注意：当你独立的，完整的负责一个项目以后，自己要开始写测试计划。这样才可以有条不紊的高效的推进测试。避免没有必要的加班。
面试题：测试计划与测试方案的区别?
测试计划是【管理型】文档，测试方案是【技术性】文档
测试计划主要解决【做什么？】【谁来做？】，测试方案主要解决【怎么做？】
主要内容存在差异：
1）测试计划主要内容如下：
1 目标与范围
2 角色与职责
3 资源与进度
4 风险与应对
5 准入与准出
2）测试方案主要内容如下：
1 策略与方法
2 环境
3 工具的选择
3 设计测试用例与评审（重点）
3.1 基本测试策略
基本测试策略：
1 冒烟测试：
基本功能检查
核心业务流程测试
2 单功能测试：
轮播图
购物车
后台会员管理
抢购
......
3 集成测试与回归
4 系统测试与回归
5 验收测试与回归
面试的时候：会问你测试的时候都测几轮啊？
怎么也的3-4轮，先做一个单功能测试，然后做业务流程的集成测试，再做整体的系统和验收测试。
（这就是基本的一个测试套路，拿到一个产品以后，你去开展的你的测试，它的一个套路要知道。这就是基本的测试策略）
3.2 测试用例核心要素
测试用例核心要素：
1 ID
2 模块
3 优先级
4 标题
5 测试数据
6 前置条件
7 测试步骤
8 预期结果
这一小节讲的是设计测试用例与评审，上面讲的是设计测试用例。那么评审是什么？可以大概有个印象：
评审：就是你写完用例，召集一帮人来点评，来确认一下你的用例写全了没有，需不需要再加点东西。
4 执行测试用例与bug跟踪（重点）
缺陷模板核心要素：
1 ID
2 标题
3 优先级
4 严重程度
5 预置条件
6 测试数据
7 复现步骤
8 预期结果
9 实际结果
10 缺陷类型
11 缺陷状态
5 编写测试报告（了解）
1 测试概要
2 缺陷统计与分析（重点）
3 测试结论
测试通过标准：
比如当没有发现致命性错误和严重性错误，一般性错误数量小于测试用例总数的5%（95%的测试用例执行通过并通过系统测试），则认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准。
注意：禅道-报表里的图可以放在测试报告里作缺陷统计和分析的。这样就可以在下一次测试的时候，更加具有针对性。
Tpshop系统测试报告
Tpshop系统测试报告的位置：G:\2021新测试\学习视屏\03、功能测试\day4\1-课堂资料
可以看一下，Tpshop系统测试报告。这里应该重点关注：4 缺陷汇总
假如：这是在测试报告里有两个模块：注册和购物里发现的bug数量统计。
那下次优先，重点的就应该是购物车模块了。（bug的群集现象，越容易放错的地方，越容易放错。有可能是这个地方的逻辑比较复杂。）