聊点不一样的，初级软件测试岗需要做些什么？

港控/mmm° 2023-10-02 14:24 27阅读 0赞

## **前言** ##

目前本人在一家 ‘发展中’公司，研发团队的成员也是在不断的健壮着，近期在测试团队，一下子人员变动比较大。 今天一大早，领导找我简单问了一下看法。可能也是想从开发组的角度了解一下日常协助上的感受。

ps： 本人重心还是在后端研发上， 不过也曾主导过公司的移动办公产品的整个测试、实施，也许这也是为什么领导想找我聊聊的点（当初闲聊的时候扯远？走漏了风声？ 我郑重地声明，我是一个正统的研发！）

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bCP55uu5qCH6Z2S5bm0_size_20_color_FFFFFF_t_70_g_se_x_16][]

##  ##

## **正文** ##

测试岗门槛低，说实话确实是的，但是上限高，这一点是必须承认的。

测试左移右移的进阶投入，能否上升一个层次，也是需要不断学习前进的。

本人现在也是后端研发岗，也无法说出一些高阶的测试开发的发展路线。 但是，对于带队或者说是要求初级的软件测试人员能做到什么，需要做到什么，我还是可以说一说的。

ps：看官们有想法的，也欢迎评论留言探讨

先看一副简图，下面的基本也是我个人对初级软件测试人员的一个工作技能要求看法：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bCP55uu5qCH6Z2S5bm0_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

> **需求评审、需求分析**

需求评审阶段，大多数都会有产品、研发相关人员一块参与，那么评审需求是否合理，怎么样才能确定下来一个合理的需求，对其业务的分析是必不可少的。

这一Part，我想表达的一点是， 需求的分析，其实并不是仅仅是产品、研发的的活，作为测试人员的我们，我们也是可以根据自己的项目经验、测试经验，对需求展开分析， 不求能完全剖析，但是我们要有这种活跃的思维、想法，去关注我们关注的一些点。

> **测试计划、测试排期**

计划、排期，很多测试人员只针对当前评审过的单一模块做一个简单的估量，做一些排期计划。

这一Part，我想表达的一点是，其实作为测试人员的我们，在做自己的排期计划时，是有必要了解到其他功能模块的测试排期，因为大多数的研发项目，功能需求之间都是有联系、甚至有先后、有前提的。 如果对需求业务了解不够，不考虑完全，出现乱套，重测的场景就会较为频繁，这样的排期计划，无疑多多少少也是失败的。

> **测试用例编写、评审**

测试用例的编写、评审， 这环节对于研发、甚至是产品，都算是一个 自检环节。 通过用例条的评审，再次审视自己的需求，这里的需求包括 产品的功能需求 以及 研发人员的开发需求。

用例的细致、严谨、逆向角度、覆盖场景等，能够促使大家 ‘ 多虑 ’。

这一Part，我想表达的一点是，很多测试人员不看重这个用例的编写，都是想从简，认为研发这边已经考虑够足了，不需要插手。 其实这种想法是很不对的， 我们测试人员要有一种 ‘认为研发的业务逻辑并不比我们强’ 的思维，就这些研发，能考虑周全么？ （PS：我是研发）

> **测试数据模拟、构建**

什么叫模拟构建？ 很多测试人员都是基于研发功能接口完毕了，才去使用接口做一些数据的增删改查。没错，这也是属于构建的环节。

但是这一Part，我想表达的一点是， 我们要对业务足够了解，对研发的设计足够了解 （通过HLD设计评审、通过接口API、数据库表等），我们最好能要求自己能够在设计稳固下来后，自己能够针对业务场景，自己模拟出相关的测试数据（包括第三方数据、自己系统数据，可能还会涉及到各种组件、中间件的使用）。

如果我们有条件，我们需要能够做到自己把自己的业务关联数据都能模拟出来，换角度去审视、检测相关业务接口。

> **测试环境服务部署**

这一Part，实话说，不一定能够下放到给我们测试去实现。虽说是测试环境，但是不同公司对于测试环境的权限掌控分配也不同。

但是对于公司项目的服务部署，我们作为测试人员，其实也是需要具备这种能力的。 我们可以看情况做版本（数据库数据）的归档，阶段性地分离测试等。  
这一Part，我个人了解不够，不多言。

> **执行测试**

执行测试，这一Part，也是要看个人测试能力的掌握程度去执行。因为测试门槛低，可能大多数刚入门的也能够做到基本的点点点，但是怎么去点点点这一部分是最能直接去提升能力的。

因为我了解到身边很多测试，还处于一旦离开了功能页面，就无法对功能执行测试的情况，说实话这是非常不应该的。 光是对接后端的接口，已经可以展开一系列的操作了，业务逻辑、稳定、性能、安全等等，这些都是能够前后端分离测再结合测的。

> **bug记录、提交、跟踪**

这一Part，大家应该都非常熟悉，一提到测试或者研发，大家最喜欢说的就是bug 这个词。

那么我想强调的一点是， 跟踪 。 跟踪，我想表达的是分为两部分，一部分，主动无配合跟踪，我们根据我们的测试用例、业务梳理，能够自己跟踪定位到问题，并且能够对该现象做进一步合理的分析。另一部分，是配合跟踪，配合相关研发人员做问题复现、定位。 还补充一点，就是进度的跟踪，这个不多说。

> **测试报告、文档输出**

这一Part是很多初级测试人员的懊恼点，不想、不会写文档。其实对于刚入门的测试不会写，很正常，没有人天生啥都会， 我们是可以基于前辈的指导去输出文档。 但是在输出文档的时候，往往需要很多测试项的数据说明，这时候，就是很直接地告诉你，你需要学些什么，掌握些什么。

最后，再啰唆一下，也是个人的看法，不要小看测试岗了，不要认为测试岗轻松、压力小。

想要提升上限，测试岗人员需要了解到的知识范围是非常非常广的，

包括不限于 https、加密算法、socket、Nginx、DNS、缓存、抓包、json解析、数据结构、resultful、分布式、内存、mock、安卓/ios、手机机型/系统、mysql、linux、线程、注入攻击、语言框架、中间件 等等 很多很多，一下子想不完。

那么今天这个瞎聊就到这，大家有什么想法，欢迎评论交流。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bCP55uu5qCH6Z2S5bm0_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/65811d37ecb3499892bec901d41fe9fe.jpg?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5bCP55uu5qCH6Z2S5bm0,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5bCP55uu5qCH6Z2S5bm0_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/25639a4f2fc141f5a014273519647e78.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5bCP55uu5qCH6Z2S5bm0,size_20,color_FFFFFF,t_70,g_se,x_16