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

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 1307 days ago, the information mentioned may be changed or developed.

是这样子的，这个测试有个毛病，真的太烦人了。你每次改完一个 BUG 让她去验证一下，她都要问你，这个 BUG 是怎么改的，逻辑是啥？是加了个判断吗？总之就是要知道后端改这个 BUG 的代码逻辑。

然后就是遇到有洗数据的 SQL 时，非要我们把 SQL 发给她看，还说她需要知道 SQL 是怎么写的，好进行测试。

这两种行为，公司所有的测试就她一个人有，跟她说，她还反驳说，其他人怎么样她不管。

Supplement 1 · Oct 26, 2022

我说明一下，如果是整个测试组都有这个要求，那我是非常乐意给她说这些的。现在是测试组长都没有提过这个要求，就她一个刚转正的提了这个要求。我觉得如果真有这个需求，可以先反馈给她的组长。

SQL

bug

测试

支支

235 replies • 2022-10-28 13:54:52 +08:00

1 2 3

❮

❯

101

fournoas

Oct 26, 2022

把 Bugfix 的 git diff 发给他看就行了

102

jkbspin

Oct 26, 2022

为什么不考虑少写点 bug 呢。。

103

hitmanx

Oct 26, 2022

bug 系统里或者 code review （如果你们有 code review 的话）里写清楚。她要问的话可以把链接丢给她。

人家想学习，这个没毛病。有这样的测试，确实要珍惜。

104

cpsony

Oct 26, 2022

感觉是因为这个 QA 的测试理念稍微更"超前点", 已经到了测试左移阶段了, 而你们公司却还在那区分黑盒 /白盒测试, 所以显得格格不入, 建议你和她领导反馈, 让她另谋出路吧, 外面适合她的机会有很多

105

xx19941215

Oct 26, 2022

负责的测试，很不错啊。如果线上出了问题，她也肯定会第一时间检查的。

106

wowawesome

Oct 26, 2022

她还是这么负责

107

OMGZui

Oct 26, 2022

挺好的呀

108

wupher

Oct 26, 2022

不怕你笑，我有个前同事，就是这么被测试妹子给拿下。

109

christin

Oct 26, 2022

emmm ，本来我也觉得挺好的，但是 lz 说她听不懂。那不就扯淡么，听不懂还问个 p ，给测试讲半天还耽误开发时间。

110

dolphintwo

Oct 26, 2022

"刚转正"、"测试" 影响你判断了

111

lueluev

Oct 26, 2022

在 MR 里艾特她让她自己看啦，看不懂的再问你

112

particlec

Oct 26, 2022

同样情况，她会问我背后的逻辑、有时候提优化界面意见，每天催我禅道 bug ，项目赶进度的时候确实很崩溃，我很烦，但是客观来说她确实负责，上线后 bug 确实少

113

SaltyMouse

Oct 26, 2022

”这个我就可以理解，如果是测试组整体这么要求，我是可以理解并且乐意给她讲解的。“

114

guisheng

Oct 26, 2022 via iPhone

我之前很喜欢改了一个问题给别人分享我的逻辑和实践。后面我明白了没有人愿意多听你的闲话，也不关心你怎么做的，好了就行，没好再来找你。

115

SaltyMouse

Oct 26, 2022

没打完发出去了，老是忘记这里的换行不一样。如果有要求楼主是乐意的，说明楼主其实觉得她也没有错，只是想偷懒而已啦，不然就算是测试组要求，也不会乐意吧。

116

Bigglesworth

Oct 26, 2022

朋友耐心一点吧，有些事情刚开始会不喜欢，但是如果讲清楚了的话，也会释然，说不定你们还能成为好朋友。讲讲也能让他了解逻辑，时间长了，他也能知道个问题大概，测试效率也更高。

117

zhaokun

Oct 26, 2022 via iPhone

我之前也遇到过一个这样的测试，刚开始以为挺好，挺负责的，就给他讲编码的思路，但是他不懂代码呀，git 给他没用，他只问你代码思路，哪有那么多时间精力给他讲的那么细，最后我俩协商只给他讲复杂业务的大概思路，没必要一个 if 一个 if 的讲，讲了他也不懂

118

harmless

Oct 26, 2022 via iPhone

多好的测试，你居然嫌烦

119

gwbw

Oct 26, 2022

我猜 OP 烦的是给她解释花的时间对自己来说是额外成本，需要自己消化掉，影响了其他工作进度 /私人时间。从事情本身触发你也不排斥这个做法。

从这个角度，你可以把她精益求精这个事推进一下，让整个测试团队都参考她的工作模式，并提出这样对团队和个人发展都有好处，但是额外引入的成本会减慢开发速度，让领导来定夺是否需要使用精益求精的方式。

没成，领导自然会让她减小这方面的投入，你也可以名言正顺地提出意见；成了，这部分成本就从需要你自己消化变成团队成本，也达成了你的目的

120

qzhai

Oct 26, 2022

还是很不错的，可能这样的工作方式你会觉得烦躁，但是你习惯下把。
你要是经历过比较恐怖的线上事故之后，
你就会觉得这样的测试是多么的重要

121

4ark

Oct 26, 2022

100 多楼都在说这位测试小姐姐负责任，还不能说明问题吗，还是说 OP 只是上来找认同感而已。

122

doommm

Oct 26, 2022

个人建议把问题原因及修改的内容直接写在 bug 工单里，其它人也能看到，后面也可以帮助自己回忆 bug 解决过程

123

chenshun00

Oct 26, 2022

修复了 bug ，把原因跟人描述一下不是应该做的么，还需要人催，离大谱

124

KMpAn8Obw1QhPoEP

Oct 26, 2022 via Android

@gwbw 高实在是高

125

HENQIGUAI

Oct 26, 2022

@Dlin #45 这楼已经讲得很明白了，可以结贴了。

126

Poko

Oct 26, 2022

我要是去做测试我也这样

127

WishMaster

Oct 26, 2022

她真的，我哭死

128

rickli

Oct 26, 2022

为啥改完 bug 自己不验证要测试去验证？我公司都是要自己先验证的

129

iScout

Oct 26, 2022 via Android

刚转正，业务不熟悉，肯定会多问几句；
bug 改完提测，有关 bug 的简单说明，影响范围总得给测试说明一下吧；

130

neptuno

Oct 26, 2022

之前公司也是这样的，代码质量一下子上去很多，“不敢轻易写 bug 了”

131

fogcell

Oct 26, 2022

我觉得测试软件应该有自己的分工和边界。
测试去了解代码的逻辑这部分是属于增值的部分，而不是强制要求。
所以如果这个测试问这些问题而且还能直接消化软件的回复的话，我觉得那就没问题，是个好测试。
如果是单纯做这些事情，能力不够那为什么不直接去做开发呢？

132

grewer

Oct 26, 2022

建议发下联系方式给我, 我内推到我司

133

imycc

Oct 26, 2022

你说她问你“这个 BUG 是怎么改的，逻辑是啥？是加了个判断吗？”，这个我认为本来就是修复 bug 的工单里要说清楚的吧。包括 SQL 变更，不说变了啥，她测什么呢。
作为一个刚转正的新人，这个工作态度至少是没毛病的。如果她能力再强一些，值得去大公司工作。

134

cue

Oct 26, 2022

我想说…… 这个标题也是个 bug……

135

SpringBlossom

Oct 26, 2022

把她的简历地址给一下吧，谢谢

136

dunn

Oct 26, 2022

不要写 bug ，让他失业吧

137

xiaowang9996

Oct 26, 2022

这种测试是真正能够推动交付、保证上线质量的测试，说明在思考，如果这位小姐姐测试能够通过你说的逻辑，进而成长，得益是你们整个业务线。

138

zhufeilong

Oct 26, 2022

@gwbw 高实在是高

139

Stendan

Oct 26, 2022

我认识的一位测试人员也曾这样，在影子库里甚至精确到每个查询的 sql 以及纯 Excel 的数据对比。直到我们相继跳槽后，又入职了一家公司，他便再也没有问过我一条 sql 了，因为新公司用了 k8s ，在服务网格中，所有的查询都是单一且多次服务调用的，以前的 left join 对他而言显然已经 "看不到了"，没有了 sql 的概念，以他目前的知识储备，除了动手点点以外也无法做其他的测试，目前团队也走向自动化测试与一部分 devops 的工作，也准备对测试岗有一些培训（自学），对他而言都是新的挑战和机遇。

对于 OP 而言，我觉得一个巴掌拍不响。当我的同事对我的工作有过多的额外时间消耗时，我通常会善意提醒下，如果对方还是喋喋不休，我会告诉 ta 把想法在群里说出来，咨询下领导的意见，通常那些说话声最大的人反而哑口无言，最后甩给我一句那就这样吧，然后这事儿就翻篇了。

140

jiejiss

Oct 26, 2022

这个测试放在你们公司屈才了

141

K1W1

Oct 26, 2022 via iPhone

挺好的

142

lsry

Oct 26, 2022

@cue 標題確實是個 bug ，OP 還是要謙虛謹慎，多學習爲好。
不厌其烦，解释是不嫌烦琐与麻烦，形容耐心。出自清·夏敬渠《野叟曝言》第一百三十八回评：“每阅数年，必综叙素臣生子生孙，娶妇嫁女，中科发甲。而读者不厌其烦，甚至一回之中，先后数见，绝无沓冗繁复之病。”

143

sch1111878

Oct 26, 2022

@optional 看 op 嫌弃的样子应该不是什么大公司, 所以没有 title

144

JLX

Oct 26, 2022 via Android

这样的测试哪里找

145

IvanLi127

Oct 26, 2022 via Android

测试知道得太多了，那不就和开发自测差别不大了么。。。

146

idblife

Oct 26, 2022 via iPhone

负责任的测试
很快就会跳槽去更好的公司

147

acehinnnqru

Oct 26, 2022

@IvanLi127 要测试的意义不就是开发自己测不了测不全吗。。。

148

MilkShake

Oct 26, 2022

方便把她联系方式提供么。

149

honamx

Oct 26, 2022

挺好的，我反而觉得这个测试很负责任。如果测试能看懂代码，直接甩 commit 给他好了。看不懂就简单写一下改动点。

150

anxn

Oct 26, 2022

测试没毛病

151

IvanLi127

Oct 26, 2022 via iPad

@acehinnnqru 你在说啥？测试想知道怎么改的不就是为了片面地测么？那不就和开发一样测不全么。。。。有啥问题？

152

leeson666

Oct 26, 2022

不厌其烦的意思是：不嫌烦琐与麻烦,形容耐心

153

thomaspaine

Oct 26, 2022

测试态度挺好的，但是大家似乎忽略了一个问题，这个测试按照 op 的说法似乎不懂 coding ，那换个角度看，其实是测试在通过 bug 的借口，找开发学习如何 coding 。

154

kkbblzq

Oct 26, 2022

你们 bug 单不用写原因和解决方案吗。。。就你描述的内容在一些公司里是 bug 单是关单前的必填项吧。
BTW ，你可以以此督促自己更加严谨，没有 bug 也就没有这事了不是吗哈哈哈

155

romisanic

Oct 26, 2022

这不是一个常见的白盒测试的常规操作吗？
你觉得她不正常，是因为你们团队以前不正常。

156

offswitch

Oct 26, 2022

@thomaspaine 学习也挺好的，可以考虑转测开，开发太卷了。

157

youisme

Oct 26, 2022

求简历，求联系方式

158

JohnBull

Oct 27, 2022

如果她负责近 RD 的白盒测试这没毛病，如果是近 PM 的集成黑盒测试，这么搞确实太烦人，感兴趣自己去看代码，没义务给无关人员做免费培训。

建议建立相关流程，避免无谓低效的口舌交流，降低项目对特定测试人员的依赖。

比如说她怀疑你是针对某个 case 加了个判断，那么就要求她写出针对特定边界判断无法通过的 case 集，与代码同源维护，最终一律在 Jenkins 上 make test 见分晓。

天长日久积累起来的带文档的 case 库，才是项目的财富

159

dayeye2006199

Oct 27, 2022

这个是 code reviewer ，建议分享代码库权限，并且 Bug 修复附上 PR 号

160

Aloento

Oct 27, 2022

直接让她来写后端就好了，很专业负责的测试
不像我自己写测试各种水...

161

whajcf

Oct 27, 2022

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

162

Y29tL2gwd2Fy

Oct 27, 2022 via Android

求联系方式

163

Jessun

Oct 27, 2022

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

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

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

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

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

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

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

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

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

164

asssfsdfw

Oct 27, 2022

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

165

acerphoenix

Oct 27, 2022

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

166

fox0001

Oct 27, 2022 via Android

有无可能，她想转开发？

167

zw1one

Oct 27, 2022

找她组长

168

zarvin

Oct 27, 2022

肯定是妹子不好看

169

gumuxi

Oct 27, 2022

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

170

justRua

Oct 27, 2022

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

171

varzy

Oct 27, 2022

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

172

tw93

Oct 27, 2022 via iPhone

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

173

botao1

Oct 27, 2022

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

174

pkwenda

Oct 27, 2022

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

175

softtwilight

Oct 27, 2022

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

176

patrickchoo

Oct 27, 2022

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

177

redvoilin

Oct 27, 2022

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

178

manasheep

Oct 27, 2022

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

179

ufan0

Oct 27, 2022

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

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

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

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

180

manasheep

Oct 27, 2022

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

181

Guesser

Oct 27, 2022

你的提测范围是否明确？

你是否能保证无 bug ？

能否提供修复 bug 的影响范围？

如果无，那这是珍稀种测试

182

yuhuan66666

Oct 27, 2022

求求了我希望我 qa 也这样

183

ainon

Oct 27, 2022

评论里都是明白人啊

184

Musong

Oct 27, 2022

我遇到过两种，这两种人都有问逻辑的情况，区别是
第一种最终提的 Bug ，测试的方法等，和问的问题没有任何关系，Bug 质量不高，基本都是哪儿歪了，哪儿不好看，但是就是问题特别多，最后发现他只是做给不懂技术的领导看的
第二种就属于目的不是完成工作，而是提高项目质量，有次提了个内存泄露的 Bug ，因为影响不大被开发搪塞了，他最终提的 Bug 直接指出哪段代码，哪个资源重复创建对象。他的 Bug 哪怕是出现概率特别低，也描述的明确详细，开发很容易就能定位