是这样子的，这个测试有个毛病，真的太烦人了。你每次改完一个 BUG 让她去验证一下，她都要问你，这个 BUG 是怎么改的，逻辑是啥？是加了个判断吗？总之就是要知道后端改这个 BUG 的代码逻辑。
然后就是遇到有洗数据的 SQL 时，非要我们把 SQL 发给她看，还说她需要知道 SQL 是怎么写的，好进行测试。
这两种行为，公司所有的测试就她一个人有，跟她说，她还反驳说，其他人怎么样她不管。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 1468 days ago, the information mentioned may be changed or developed.
Supplement 1 · Oct 26, 2022
我说明一下，如果是整个测试组都有这个要求，那我是非常乐意给她说这些的。现在是测试组长都没有提过这个要求，就她一个刚转正的提了这个要求。我觉得如果真有这个需求，可以先反馈给她的组长。
 |
fournoasOct 26, 2022
101
把 Bugfix 的 git diff 发给他看就行了
|
 |
jkbspinOct 26, 2022
102
为什么不考虑少写点 bug 呢。。
|
 |
hitmanxOct 26, 2022
103
bug 系统里或者 code review （如果你们有 code review 的话）里写清楚。她要问的话可以把链接丢给她。
人家想学习，这个没毛病。有这样的测试，确实要珍惜。 |
 |
cpsonyOct 26, 2022
104
感觉是因为这个 QA 的测试理念稍微更"超前点", 已经到了测试左移阶段了, 而你们公司却还在那区分黑盒 /白盒测试, 所以显得格格不入, 建议你和她领导反馈, 让她另谋出路吧, 外面适合她的机会有很多
|
 |
xx19941215Oct 26, 2022
105
负责的测试，很不错啊。如果线上出了问题，她也肯定会第一时间检查的。
|
 |
wowawesomeOct 26, 2022
106
她还是这么负责
|
 |
OMGZuiOct 26, 2022
107
挺好的呀
|
 |
wupherOct 26, 2022
108
不怕你笑，我有个前同事，就是这么被测试妹子给拿下。
|
 |
christinOct 26, 2022
109
emmm ，本来我也觉得挺好的，但是 lz 说她听不懂。那不就扯淡么，听不懂还问个 p ，给测试讲半天还耽误开发时间。
|
 |
dolphintwoOct 26, 2022
110
"刚转正"、"测试" 影响你判断了
|
 |
lueluevOct 26, 2022
111
在 MR 里艾特她让她自己看啦，看不懂的再问你
|
 |
particlecOct 26, 2022
112
同样情况，她会问我背后的逻辑、有时候提优化界面意见，每天催我禅道 bug ，项目赶进度的时候确实很崩溃，我很烦，但是客观来说她确实负责，上线后 bug 确实少
|
 |
SaltyMouseOct 26, 2022
113
”这个我就可以理解，如果是测试组整体这么要求，我是可以理解并且乐意给她讲解的。“
|
 |
camecoOct 26, 2022 via iPhone
114
我之前很喜欢改了一个问题给别人分享我的逻辑和实践。后面我明白了没有人愿意多听你的闲话，也不关心你怎么做的，好了就行，没好再来找你。
|
|
SaltyMouseOct 26, 2022
115
没打完发出去了，老是忘记这里的换行不一样。如果有要求楼主是乐意的，说明楼主其实觉得她也没有错，只是想偷懒而已啦，不然就算是测试组要求，也不会乐意吧。
|
 |
BigglesworthOct 26, 2022
116
朋友耐心一点吧，有些事情刚开始会不喜欢，但是如果讲清楚了的话，也会释然，说不定你们还能成为好朋友。讲讲也能让他了解逻辑，时间长了，他也能知道个问题大概，测试效率也更高。
|
 |
zhaokunOct 26, 2022 via iPhone
117
我之前也遇到过一个这样的测试，刚开始以为挺好，挺负责的，就给他讲编码的思路，但是他不懂代码呀，git 给他没用，他只问你代码思路，哪有那么多时间精力给他讲的那么细，最后我俩协商只给他讲复杂业务的大概思路，没必要一个 if 一个 if 的讲，讲了他也不懂
|
 |
harmlessOct 26, 2022 via iPhone
118
多好的测试，你居然嫌烦
|
 |
119
我猜 OP 烦的是给她解释花的时间对自己来说是额外成本，需要自己消化掉，影响了其他工作进度 /私人时间。从事情本身触发你也不排斥这个做法。
从这个角度，你可以把她精益求精这个事推进一下，让整个测试团队都参考她的工作模式，并提出这样对团队和个人发展都有好处，但是额外引入的成本会减慢开发速度，让领导来定夺是否需要使用精益求精的方式。 没成，领导自然会让她减小这方面的投入，你也可以名言正顺地提出意见；成了，这部分成本就从需要你自己消化变成团队成本，也达成了你的目的 |
10 |
qzhaiOct 26, 2022
120
还是很不错的，可能这样的工作方式你会觉得烦躁，但是你习惯下把。
你要是经历过比较恐怖的线上事故之后， 你就会觉得这样的测试是多么的重要 |
 |
4arkOct 26, 2022
121
100 多楼都在说这位测试小姐姐负责任，还不能说明问题吗，还是说 OP 只是上来找认同感而已。
|
 |
doommmOct 26, 2022
122
个人建议把问题原因及修改的内容直接写在 bug 工单里，其它人也能看到，后面也可以帮助自己回忆 bug 解决过程
|
 |
chenshun00Oct 26, 2022
123
修复了 bug ，把原因跟人描述一下不是应该做的么，还需要人催，离大谱
|
 |
KMpAn8Obw1QhPoEPOct 26, 2022 via Android
124
@gwbw 高 实在是高
|
 |
PokoOct 26, 2022
126
我要是去做测试我也这样
|
 |
WishMasterOct 26, 2022
127
她真的，我哭死
|
 |
rickliOct 26, 2022
128
为啥改完 bug 自己不验证 要测试去验证？我公司都是要自己先验证的
|
 |
iScoutOct 26, 2022 via Android
129
刚转正，业务不熟悉，肯定会多问几句；
bug 改完提测，有关 bug 的简单说明，影响范围总得给测试说明一下吧； |
 |
neptunoOct 26, 2022
130
之前公司也是这样的，代码质量一下子上去很多，“不敢轻易写 bug 了”
|
 |
fogcellOct 26, 2022
131
我觉得测试软件应该有自己的分工和边界。
测试去了解代码的逻辑这部分是属于增值的部分，而不是强制要求。 所以如果这个测试问这些问题而且还能直接消化软件的回复的话，我觉得那就没问题，是个好测试。 如果是单纯做这些事情，能力不够那为什么不直接去做开发呢？ |
 |
grewerOct 26, 2022
132
建议发下联系方式给我, 我内推到我司
|
 |
133
你说她问你“这个 BUG 是怎么改的，逻辑是啥？是加了个判断吗？”，这个我认为本来就是修复 bug 的工单里要说清楚的吧。包括 SQL 变更，不说变了啥，她测什么呢。
作为一个刚转正的新人，这个工作态度至少是没毛病的。如果她能力再强一些，值得去大公司工作。 |
 |
cueOct 26, 2022
134
我想说…… 这个标题也是个 bug……
|
 |
SpringBlossomOct 26, 2022
135
把她的简历地址给一下吧，谢谢
|
 |
dunnOct 26, 2022
136
不要写 bug ，让他失业吧
|
 |
xiaowang9996Oct 26, 2022
137
这种测试是真正能够推动交付、保证上线质量的测试，说明在思考，如果这位小姐姐测试能够通过你说的逻辑，进而成长，得益是你们整个业务线。
|
 |
zhufeilongOct 26, 2022
138
@gwbw 高 实在是高
|
 |
139
我认识的一位测试人员也曾这样，在影子库里甚至精确到每个查询的 sql 以及纯 Excel 的数据对比。直到我们相继跳槽后，又入职了一家公司，他便再也没有问过我一条 sql 了，因为新公司用了 k8s ，在服务网格中，所有的查询都是单一且多次服务调用的，以前的 left join 对他而言显然已经 "看不到了"，没有了 sql 的概念，以他目前的知识储备，除了动手点点以外也无法做其他的测试，目前团队也走向自动化测试与一部分 devops 的工作，也准备对测试岗有一些培训（自学），对他而言都是新的挑战和机遇。
对于 OP 而言，我觉得一个巴掌拍不响。当我的同事对我的工作有过多的额外时间消耗时，我通常会善意提醒下，如果对方还是喋喋不休，我会告诉 ta 把想法在群里说出来，咨询下领导的意见，通常那些说话声最大的人反而哑口无言，最后甩给我一句那就这样吧，然后这事儿就翻篇了。 |
 |
jiejissOct 26, 2022
140
这个测试放在你们公司屈才了
|
 |
K1W1Oct 26, 2022 via iPhone
141
挺好的
|
 |
142
@cue 標題確實是個 bug ，OP 還是要謙虛謹慎，多學習爲好。
不厌其烦，解释是不嫌烦琐与麻烦，形容耐心。出自 清·夏敬渠《野叟曝言》第一百三十八回评：“每阅数年，必综叙素臣生子生孙，娶妇嫁女，中科发甲。而读者不厌其烦，甚至一回之中，先后数见，绝无沓冗繁复之病。” |
 |
sch1111878Oct 26, 2022
143
@optional 看 op 嫌弃的样子应该不是什么大公司, 所以没有 title
|
 |
JLXOct 26, 2022 via Android
144
这样的测试哪里找
|
 |
IvanLi127Oct 26, 2022 via Android
145
测试知道得太多了，那不就和开发自测差别不大了么。。。
|
 |
idblifeOct 26, 2022 via iPhone
146
负责任的测试
很快就会跳槽去更好的公司 |
 |
acehinnnqruOct 26, 2022
147
@IvanLi127 要测试的意义不就是开发自己测不了测不全吗。。。
|
 |
MilkShakeOct 26, 2022
148
方便把她联系方式提供么。
|
 |
149
挺好的，我反而觉得这个测试很负责任。如果测试能看懂代码，直接甩 commit 给他好了。看不懂就简单写一下改动点。
|
 |
anxnOct 26, 2022
150
测试没毛病
|
|
IvanLi127Oct 26, 2022 via iPad
151
@acehinnnqru 你在说啥？测试想知道怎么改的不就是为了片面地测么？那不就和开发一样测不全么。。。。有啥问题？
|
 |
leeson666Oct 26, 2022
152
不厌其烦的意思是：不嫌烦琐与麻烦,形容耐心
|
 |
thomaspaineOct 26, 2022
153
测试态度挺好的，但是大家似乎忽略了一个问题，这个测试按照 op 的说法似乎不懂 coding ，那换个角度看，其实是测试在通过 bug 的借口，找开发学习如何 coding 。
|
 |
kkbblzqOct 26, 2022
154
你们 bug 单不用写原因和解决方案吗。。。就你描述的内容在一些公司里是 bug 单是关单前的必填项吧。
BTW ，你可以以此督促自己更加严谨，没有 bug 也就没有这事了不是吗哈哈哈 |
 |
romisanicOct 26, 2022
155
这不是一个常见的白盒测试的常规操作吗？
你觉得她不正常，是因为你们团队以前不正常。 |
 |
offswitchOct 26, 2022
156
@thomaspaine 学习也挺好的，可以考虑转测开，开发太卷了。
|
 |
youismeOct 26, 2022
157
求简历，求联系方式
|
 |
JohnBullOct 27, 2022
158
如果她负责近 RD 的白盒测试这没毛病，如果是近 PM 的集成黑盒测试，这么搞确实太烦人，感兴趣自己去看代码，没义务给无关人员做免费培训。
建议建立相关流程，避免无谓低效的口舌交流，降低项目对特定测试人员的依赖。 比如说她怀疑你是针对某个 case 加了个判断，那么就要求她写出针对特定边界判断无法通过的 case 集，与代码同源维护，最终一律在 Jenkins 上 make test 见分晓。 天长日久积累起来的带文档的 case 库，才是项目的财富 |
 |
dayeye2006199Oct 27, 2022
159
这个是 code reviewer ，建议分享代码库权限，并且 Bug 修复附上 PR 号
|
 |
AloentoOct 27, 2022
160
直接让她来写后端就好了，很专业负责的测试
不像我自己写测试各种水... |
 |
whajcfOct 27, 2022
161
这不是正常流程吗? 要么更改详设提交给她,要么就讲清楚逻辑, 要不人家咋知道你改动影响,要回归多少测试用例或者增加用例
|
 |
Y29tL2gwd2FyOct 27, 2022 via Android
162
求联系方式
|
 |
JessunOct 27, 2022
163
这种测试虽然要求多，但是都不过分啊。我遇到这种反而很放心 —— TA 那么心细一定不会出 bug 的。
一般在做变更前，都会写明下面几条： 1. 需求背景 /问题背景 2. 解决方案 /问题原因 如果是需求，就写方案，写大概怎么做。如，xxx 服务增加 xxx 功能。或者 xxx 接口新增 xxx 判断。 如果是 bug ，就写 xxx 在 xxxx 情况下没有判断空指针引发的错误等等 （有时，写得越详细越好） 3. 该方案实施后，会有哪些变化？比如会有哪些操作？或者观察哪些特征的日志？ 比如新增 xx 操作，可以通过关键字 xxx 过滤日志来观察 xxx 是否已经生效。 以上是基本的方面吧？这样，无论是自己、产品、测试或者是后来的人，一看就知道这个需求 /问题是做了什么。减少了沟通成本。 我的建议是这样的：在完成开发后，提交测试前，你就把上面的内容写好。这时候有人问你怎么做的，你就把上面的文档发给 TA ，这样别人一看就懂，就不会再提其他问题了。 好的文档的标准 —— “一个刚入职的研发 /测试 /产品”一看就明白整个过程，不会再有问题。 |
 |
asssfsdfwOct 27, 2022
164
测试是跟需求相关的。告诉它实现反而可能会造成测试上的一些局限性。（黑白盒测试）
重要的是测试用例。 |
 |
acerphoenixOct 27, 2022
165
我要遇到这种主动学习的，会鼓励，但顶多简单介绍，然后给他代码让自己看 diff 去，
|
 |
fox0001Oct 27, 2022 via Android
166
有无可能，她想转开发？
|
 |
zw1oneOct 27, 2022
167
找她组长
|
 |
zarvinOct 27, 2022
168
肯定是妹子不好看
|
 |
gumuxiOct 27, 2022
169
这样的测试，才是一个合格的测试工程师，很快他飞速成长就不会烦你了，成长起来就去更好的公司了
|
 |
justRuaOct 27, 2022
170
说明人家负责，我们这测试都会看你代码，测试环境有问题人家自己先看日志，然后跟你说代码 xxx 这一行是不是有问题。。。
|
 |
varzyOct 27, 2022
171
为什么我见过的测试都是面向点点点测试。。。
|
 |
tw93Oct 27, 2022 via iPhone
172
这么好的测试 你就偷着乐吧
|
 |
botao1Oct 27, 2022
173
@itechnology 对啊，你为啥不愿说解决的逻辑？
|
 |
pkwendaOct 27, 2022
174
我的日常是求着测试回归。
|
 |
softtwilightOct 27, 2022
175
而且，你把逻辑讲给别人听真的会拖慢工作进度吗...
|
 |
patrickchooOct 27, 2022
176
这是认真尽责在测试呀，随便点两下的都是摸鱼 😂
|
 |
redvoilinOct 27, 2022
177
@itechnology 你明显不懂测试，什么叫不要黑盒测试，也不要白盒测试，只要普通测试，啥叫普通测试？ 大部分点点点的测试就是黑盒测试
|
 |
manasheepOct 27, 2022
178
我觉得测试就应该面对黑盒，不然会被先入为主的思维带偏，测试要的就是符合需求，且周全，不在乎具体实现，开发没有义务给测试讲解具体实现。
|
 |
179
看到评论区前面几条看得发抖，真如楼主所说的场景的话，这个测试简直就是离谱。
他知道业务逻辑复现场景测试用例就能处理完了，何必给双方增加麻烦。 真想知道代码逻辑就自己去找架构开 code reviewer 权限。 目前现状就是想通过你剥削你进行学习。 |
 |
GuesserOct 27, 2022
181
你的提测范围是否明确？
你是否能保证无 bug ？ 能否提供修复 bug 的影响范围？ 如果无，那这是珍稀种测试 |
 |
yuhuan66666Oct 27, 2022
182
求求了 我希望我 qa 也这样
|
 |
ainonOct 27, 2022
183
评论里都是明白人啊
|
 |
MusongOct 27, 2022
184
我遇到过两种，这两种人都有问逻辑的情况，区别是
第一种最终提的 Bug ，测试的方法等，和问的问题没有任何关系，Bug 质量不高，基本都是哪儿歪了，哪儿不好看，但是就是问题特别多，最后发现他只是做给不懂技术的领导看的 第二种就属于目的不是完成工作，而是提高项目质量，有次提了个内存泄露的 Bug ，因为影响不大被开发搪塞了，他最终提的 Bug 直接指出哪段代码，哪个资源重复创建对象。他的 Bug 哪怕是出现概率特别低，也描述的明确详细，开发很容易就能定位 |
 |
1018jiOct 27, 2022
185
你不要给我们吧，巴不得
|
 |
zwdsixOct 27, 2022
186
祝一楼以及点赞的各位在职业生涯中被负责到底
|
 |
feelingluckyOct 27, 2022
187
|
 |
liuchao719Oct 27, 2022
188
这贴我得收藏起来 随时鞭策自己……
|
 |
RainCatsOct 27, 2022
189
建议配合。。。我都是主动跟测试说这个问题是什么原因导致的，怎么解决的
|
 |
adoalOct 27, 2022
190
很多时候开发想要的只是字面意义上的“测试”队友，就如 OP 所想。
其实正规团队里的测试角色，有个装 B 的名称叫 QA （ quality assurance ），这才是测试角色存在的本意。 |
 |
miraclesOct 27, 2022
191
从专业角度来讲，这是人家的工作经验啊，学习能力强的，下次测试遇到相同或者相似的问题，反馈给技术时可以帮助定位到一定范围
|
 |
192
上个公司，组里只有一个测试，他的职责就是写 pipeline 上面的各种测试代码。每次 pr 通过合并了之后，把 jira 任务移到 ready for test 之前，会有一个 desk check 。这个会上唯一事情就是给我们这个测试讲清楚我们是怎么实现的，他好写集成测试。
|
 |
horizonOct 27, 2022
193
有可能是你太菜了，配不上她。
|
 |
5oiR5piv5YK76YC8Oct 27, 2022
194
你把她的简历和联系方式发出来，我帮你解决问题
|
 |
uvwlabOct 27, 2022 via Android
195
这样的测试，我喜欢
|
|
acehinnnqruOct 27, 2022
196
@IvanLi127 你的观点很好，你可以保持，我不和你争吵。从测试的角度，测试知道逻辑才是最合理的。开发能做全测试，那就别提测。片面测这个真刷新了我对开发的思维的认知。
|
 |
197
主要还是颜值问题
|
 |
TateLiaoOct 27, 2022
198
这种测试请给我来一个
|
 |
darkbreadOct 27, 2022
199
对 change 的说明本来就应该写在 PR 里的
|
 |
madeworldbetterOct 27, 2022
200
额外的流程就应该额外协商，当然这种事没发生在自己身上都可以拿大棒随便敲。
|
Select Language