测试基础3.21

环境：

QA（测试环境）

预发布环境   （自己人可以看的   客户是看不到的）

生产环境（线上环境开发人员专用的环境）

测试人员和开发人员是在不同的环境下操作的

测试用例评审步骤：

1、发起会议申请（在这个之前 首先看下规定时间下是否有可用会议室）

2、到约定的时间在会议室评审测试用例

3、评审结束后，完善测试用例（会议阶段同事补充的测试点   需要记一下 方便下来的完善）

4、完善之后，再次发出来（发到大家可以沟通的群）

参与者：

1、产品  开发  以及其他测试

谁主持：

1、谁发起  谁主持

注意：针对别人说的意见，需要当场有可能修改用例

bug的三种叫法：

bug     缺陷     ISSUE

缺陷的类型：

建议：建议不能说是问题，建议表达的是更加完善。

优化：指的是产品不是那么很好，优化下更加的好，比如提升信息。

BUG：指的是程序存在的缺陷。

需求：客户有了新的想法，增加到产品里面。

缺陷级别：

致命：系统崩溃、数据丢失、数据损坏、安全性被破坏

严重：操作性错误、结果错误、功能遗漏

一般：小问题，拼写错误、UI布局、罕见错误‘

建议：针对产品的改进建议。

缺陷优先级：

优先级表示修复 缺陷的重要程度和紧迫程度。

紧急：影响进一步测试，需要立即修复。

高：必须在版本类发布前修复。

中：不需要修复，不一定立即修复，可以讨论确定在某个时间节点修复好。

底：对产品影响比较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复

缺陷状态：

主要描述缺陷当前的状态。状态如下：

新建：测试人员提交新BUG、优化或者建议的状态。

进行中：开发人员确认是bug，在修复bug过程中的状态。

已解决：开发人员已修复bug的状态。

已关闭：测试人员验证修复的bug，确定已解决问题的状态。

不解决：开发人员认为不是bug，拒绝解决问题的状态或者无法解决问题的状态。

重开：测试人员验证修复的bug，发现没有完全修复好bug,重新打回开发人员的状态

暂缓：开发人员认为该BUG不急于修复，可以放置一段时间再修复的状态

bug提交流程

第一种情况

首先测试人员发现了一个bug 然后把缺陷发送给 对应的开发 然后开发进行验证 修复了这个问题 再发给测试 测试再进行回归测试 没有问题了 这个bug关闭

第二种情况

测试把缺陷任务发送了给了开发 开发那边认为这个不是问题 给拒绝了

第三种情况

测试把这个缺点任务发送给了开发 整个团队认为这个问题不是很严重的问题 就让开发给延迟了 等有时间了 再进行验证修复这个问题 再给测试 测试再进行回归测试 没有问题了 这个bug 关闭

 ISSUE注意事项：

1、bug标题一定要表达出问题的核心，看了标题就知道是什么问题；

2、bug步骤要清晰明了，通俗易懂，步骤要非常详细

3、提交bug最好要有问题截图

4、提交bug最好有详细的日志信息（主要针对的是后台服务）

测试计划的编写：

测试计划及目的：

一个叙述了预定的测试活动范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、测试人员安排以及任何偶发时间的风险。软件测试计划是指导测试过程的纲领性文档。计划可以统一认识，可以规划过程。

测试计划包含了产品概述、测试区域/测试范围（测试项）、测试目标（被测特征）、测试优先级、测试配置、测试

资源<赢硬件、软件、人力、技术等>、测试周期、进度安排（测试任务、人员安排）测试策略、测试方法、途径、测试交流、风险分析、测试标准、需交付文档等内容。

测试范围 明确测的是什么？

测试策略  明确怎么测

资源安排  包括测试人员的安排和资源环境安排

进度安排 在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。

发布标准：

发布标准是测试完成和上线需要满足的条件，以便项目内所有角色都有一致认可的目标。

风险预防 最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时应对措施提前进行一些考虑和准备，并在测试计划中体现出来。

下边是测试计划案例：

拉钩网添加测试职位（目前拉勾网只针对开发职位）

 

下边是BOSS直聘测试计划的案例

一、背景描述

 产品一直主打于BOSS直聘市场，无非满足测试类和开发类的职位搜索，本次迭代的核心是对测试类和开发类的职位是否正常搜索，让产品更加完善，更好的赋能于toC用户，打造顶级的bTOc的服务平台

二、前置安排

序号	资源	负责人	开始时间	结束时间	备注
1	缺少服务器	运维人：XX	3.21	3.22

三、项目任务安排

序号	任务描述	测试负责人	开始时间	结束时间	是否完成	备注
1	测试用例的编写	ABC	3.22	3.23	√
2	职位前端测试	AC	3.24	3.28	√
3	职位后台测试	B	3.24	3.28	√
4	测试类和开发类职位的搜索	AC	3.29	4.1	√
5	系统其他职位搜索	B	3.29	4.1	√
6	系统测试	ABC	4.1	4.4		开发问题没有修复完成

 

四、测试风险

序号	风险项	风险描述	负责人	是否已解决	备注
1	采购服务器	购买服务器需要财务审核，财务请假	运维人：XX	√

五、测试策略

本次测试针对新功能使用功能测试的方法，针对之前系统已经有的使用自动化测试方法，本次经过和相关的人沟通 ， 不考虑性能测试

---测试计划的编写一般用word进行编写