软件测试培训之我在测试工作中是怎么做的?

软件测试培训之我在测试工作中是怎么做的?

比如说我上个东家，虽说是个三线互联网公司，但是也是港股上市，业务稳定，大几千人。这样的公司通常很多流程已经比较规范了，比如从需求的提出，到最终的上线，可以较好的按照比较标准的流程走下来，具体流程大家都知道，就不赘述了。

那现在的情况就不一样了，我现在的是创业型公司，处于C轮。需求多、测试人力不够(一直在招，合适的难找)、流程不规范，这些缺点都有。这时候还用之前的那套显然啥都做不了了。

就拿最近负责的业务来说说，我在测试工作中通常会去做什么?

1. 需求急，短时间上线——关键词【沟通】

其实这种情况，在稳定和创业型公司都会遇到，只不过后者这种情况更多见。这时候，熟悉需求肯定还是首要的。不管你有没有直接参与需求的评审，都要找涉及需求的直接人员进行有效沟通，注意是有效沟通。

找到需求的推进人，确定上线周期，提测时间，好规划测试时间，以及对于需求的一个测试重点分布。另外，还要把发现的一些风险点或者测试覆盖不到的地方及时的抛出来，群策群力一起想办法。千万不要有阻塞点卡着 你不说出来，这样的话万一导致延期的话，锅可就是你的了。

2. 需求描述简单，不仔细——关键词【梳理】

这情况也是伴随着上述的情况而生，因为这种需求下很难有完整的需求文档描述以及原型图等等， 那么这个时候开发在设计的时候也可能考虑不全。那么，既然我又不能直接撂挑子不管不顾，那我也只能尽我自己一份力，去帮着查漏补缺。

比如，最近的需求测试当中，我就要测试一个job接口，这个接口用来按照策略生成任务的，数据很重要，自然这个部分就是测试的一大核心重点。

重点需求重点对待，不仅要看功能页面上的展示，还要去查询各种表，去确定数据的准确性。

这个需求因为测试数据不好准备，在前期与开发沟通的时候，了解了涉及到的各种表之间的关系，自己去写sql造测试数据。

在验证结果的时候，我还会去查日志，一些关键点没有日志的话 提醒开发童鞋补上，方便验证。然后在一次次的测试中，再次梳理接口的处理逻辑。

看似正确的处理逻辑，当设计了足够多的场景数据去测试的时候，果然，发现了2除逻辑上的疏忽。

开发童鞋连赞发现的好，立马找来产品确认下是否需要补齐这个逻辑。

另外，在我查询各种表的时候，开发童鞋还反问我：“你还查库呢?我看很多测试都不查数据库的，挺好的”

3. 发现问题，如何更好的提bug——关键词【谨慎】

提bug，那肯定是我们工作中的一大重点内容了。发现问题，我觉得可以不用立即去提bug单，首先我会在我的case脑图后加标记，出现的什么问题。

然后再结合我的时间安排，觉得定位bug的深度。 最最最不济，你也要确定这问题是能复现出来的。

其实定位bug还是常用的那些方式，看请求，确认参数返回，查数据，看日志，依次来大概确定下是谁的问题，这时候你再提单会好一些。

当然了，肯定有一些我不能确定的问题，那么我可能会提给这个功能的最直接的那个人。

此外!!!还要多加一句：“这个问题可能不是你导致的，如果你发现不是你的问题，你直接将bug流转给对应的人就好”。

对应没时间写测试用例，这个事情也很经常了。我觉得这种需求下，在你熟悉大概情况后，可以边测边写，再不济的话，测试过的点和考虑到的场景务必要记录，

还有重要的沟通内容，截图等等，这是你工作细节的证明，也是你日后甩锅的证据。

4. 无意之中，“秀”一下你的代码

其实很多开发会鄙视测试的最直接的因素，就是测试不写代码。 我在上一家测试一个专项的时候，跟组里的高T开发合作过，结项的时候，他表示觉得我

是一个不错的测试，他觉得不会写代码的测试不能算做一个合格的测试。

其实这位大佬的言论在我看来还是有些偏激的，但是这确实就是代表了一部分开发的想法。

就包括我现在，在开发debug的空闲期，我也会打开我的编辑器去继续写一些有用的代码，有些开发看到后，会好奇的问：你在写什么代码呀?这个时候你就可以扯一波了，千万不是吹嘘自己，表示你用代码在做一些有利于提效等等的事情，尽管你的开发水平不高，但是开发人员这时候还是会对你刮目相看，给你打上一个会写代码的标签。

但是，我们别忘了，测试学习写代码，最终目的就是要去提效，提高工作效率，做一些对大家有意义的事情，让代码发挥出价值。千万不要本末倒置，为了写而写。