测试工程师日常工作流程

文章目录

前言

一、需求分析

二、制定测试计划，bug定义标准

三、编写测试用例

四、执行测试

五、回归测试

六、验收测试

七、发布上线

总结

---

前言

 

测试，特别是软件测试在目前软件研发流程里基本是最后一环。大部分测试都逃不过被产品一直改需求，开发一直拖时间的命运。所以在上线时间一直不会变的情况下，测试工程师何时介入，何时收尾，对我们测试工程师来说如何在这种场景下做到保质保量是非常重要的。本文将介绍测试工程师在日常的项目过程中基本的工作流程

一、需求分析

一个好的测试，不仅仅是关注产品提供的需求本身，更是要对产品给出的需求从测试的角度进行需求分析。而且该阶段应该在项目需求出来之后就开始介入。

比如：

1. 软件的版本需求合理性，是否可测试。这点非常重要，如果不具备可测试性，那产品需求本身的风险需要在该阶段就进行提出，才不会影响后续工作的开展。
2. 项目人员的配置。最简单的开发负责人是谁，前后端都有哪些人，遇到问题找谁，有多少人投入测试。甚至包括测试的软件，硬件环境等
3. 分析测试的软件主流程，异常流程，测试重点，也就是我们平时做的测试分析部分
4. 项目整体规划，比如开发何时提测，项目何时发布等等。

二、制定测试计划，bug定义标准

这部分可能不是每个测试都需要做的，基本是测试负责人完成。有的公司可能是项目PM做的。但是对于测试也是要知道这部分的。

1. 针对需求，在已有的和可协调到的资源上做出具体的，可执行的计划，目的是输出测试计划
2. 测试计划要明确测试范围
3. 测试计划要明确测试策略，比如功能测试，性能测试，自动化测试，可用性测试，云测，monkey等
4. bug定义标准，不同公司对bug类型，bug级别具体定义可能都不大一样，但是基本上都逃不过几个基本要素，比如bug严重程度，bug优先级别，bug类型等。所以这部分也是非常需要预先定义好。不过一家公司基本会有统一的标准。

三、编写测试用例

说到测试用例，现阶段其实大部分的测试还是以功能测试为主，也就是熟称的点点点。我个人认为，不管测试发展到何种阶段，点点点都是不会被淘汰的。至于原因，此处不赘述。

功能测试的用例编写方法非常多，但主要掌握几种方法就足够日常测试使用了

1. 等价类
2. 边界值
3. 错误猜测
4. 因果图
5. 正交分解法
6. 特殊场景

最后一种不能称之为测试用例编写的一种方法，但是其实大部分的bug发现可能都是在这部分的用例里。

那特殊场景又从何处着手呢？

通常我会考虑以下几种场景

1. 接口为空、数据为空
2. 加载超时
3. 网络异常
4. 重复提交
5. 异常中断
6. 缓存冲突
7. 系统兼容
8. 流程迂回
9. 流程中断

其他我还会考虑兼容性测试。

比如PC兼容性，考虑浏览器（IE，Chrome，火狐，苹果等），考虑操作系统（xp,win7,win8,win10,linux,mac）

比如手机兼容性，考虑操作系统，手机屏幕尺寸，手机网络

 

最后，测试用例编写完成后，有条件建议大家进行测试用例评审。虽然我知道很多公司不要说测试用例评审，可能连测试用例都没有。但是有条件的公司还是建议大家评审。毕竟这是最后一个质量守护者对产品的理解。能与产品，开发，三方的理解达到一个一致，才能保证我们最终做出来的是大家共同要做的一个东西。

四、执行测试

到了这一阶段，如果前期工作都能很好的完成的话，我想这阶段的工作也是能比较顺利的。

这部分的工作也就是我们大家都做得最多也是最日常的工作，执行用例，补充场景，记录bug，回归bug

五、回归测试

回归测试主要是在所有单模块在系统中进行测试完成之后，有余力再扩大一些范围进行回归测试。当然也可以选择只针对bug比较多的模块进行回归测试。可以依据项目进度而定。

六、验收测试

其实大部分的验收测试目前是由产品来完成，也就是产品看看开发和测试一起做的功能是不是跟他最初预想的一致的一个过程。测试在这个阶段可能需要协助产品进行测试，比如提供一些环境或者数据之类的

七、发布上线

总结

以上就是测试工程师日常工作流程，希望能给想进入测试行业或者刚进入测试行业的人一些帮助