被刚转正的测试弄的不厌其烦，求各位支支招

这不是正常流程吗? 要么更改详设提交给她,要么就讲清楚逻辑, 要不人家咋知道你改动影响,要回归多少测试用例或者增加用例

求联系方式

这种测试虽然要求多，但是都不过分啊。我遇到这种反而很放心 —— TA 那么心细一定不会出 bug 的。

一般在做变更前，都会写明下面几条：

1. 需求背景 /问题背景
2. 解决方案 /问题原因

如果是需求，就写方案，写大概怎么做。如，xxx 服务增加 xxx 功能。或者 xxx 接口新增 xxx 判断。
如果是 bug ，就写 xxx 在 xxxx 情况下没有判断空指针引发的错误等等
（有时，写得越详细越好）

3. 该方案实施后，会有哪些变化？比如会有哪些操作？或者观察哪些特征的日志？

比如新增 xx 操作，可以通过关键字 xxx 过滤日志来观察 xxx 是否已经生效。

以上是基本的方面吧？这样，无论是自己、产品、测试或者是后来的人，一看就知道这个需求 /问题是做了什么。减少了沟通成本。

我的建议是这样的：在完成开发后，提交测试前，你就把上面的内容写好。这时候有人问你怎么做的，你就把上面的文档发给 TA ，这样别人一看就懂，就不会再提其他问题了。


好的文档的标准 —— “一个刚入职的研发 /测试 /产品”一看就明白整个过程，不会再有问题。

测试是跟需求相关的。告诉它实现反而可能会造成测试上的一些局限性。（黑白盒测试）
重要的是测试用例。

我要遇到这种主动学习的，会鼓励，但顶多简单介绍，然后给他代码让自己看 diff 去，

有无可能，她想转开发？

找她组长

肯定是妹子不好看

这样的测试，才是一个合格的测试工程师，很快他飞速成长就不会烦你了，成长起来就去更好的公司了

说明人家负责，我们这测试都会看你代码，测试环境有问题人家自己先看日志，然后跟你说代码 xxx 这一行是不是有问题。。。

为什么我见过的测试都是面向点点点测试。。。

这么好的测试 你就偷着乐吧

@itechnology 对啊，你为啥不愿说解决的逻辑？

我的日常是求着测试回归。

而且，你把逻辑讲给别人听真的会拖慢工作进度吗...

这是认真尽责在测试呀，随便点两下的都是摸鱼 😂

@itechnology 你明显不懂测试，什么叫不要黑盒测试，也不要白盒测试，只要普通测试，啥叫普通测试？ 大部分点点点的测试就是黑盒测试

我觉得测试就应该面对黑盒，不然会被先入为主的思维带偏，测试要的就是符合需求，且周全，不在乎具体实现，开发没有义务给测试讲解具体实现。

看到评论区前面几条看得发抖，真如楼主所说的场景的话，这个测试简直就是离谱。

他知道业务逻辑复现场景测试用例就能处理完了，何必给双方增加麻烦。

真想知道代码逻辑就自己去找架构开 code reviewer 权限。

目前现状就是想通过你剥削你进行学习。

@whajcf 想象自己是个质检员，你根本不应该知道具体调整细节，而是按标准把所有质检项目重新进行一遍，合格就放行