如何做程序员喜欢的测试妹子？

最新推荐文章于 2021-12-02 11:05:09 发布

diancha9110

最新推荐文章于 2021-12-02 11:05:09 发布

阅读量320

点赞数

文章标签：人工智能

原文链接：http://www.cnblogs.com/flyrock/p/11368247.html

版权

原文链接（作者一个人）：https://juejin.im/post/5d4e2ea76fb9a06b2f5fa018

昨天看了一篇文章叫《如何做测试妹子喜欢的程序员》，觉得作者点的很到位，首先我是一名程序员，那么站在一名合格程序员的角度，怎么看待这些观点呢，没看过上面文章的同学，可以抽两分钟时间阅读下，文章简单有趣，今天我想借此机会说说我的观点，并且也表达下站在测试的角度，如何做程序员喜欢的测试妹子？我们也聊聊有趣的故事。

先从测试妹子的文章观点说起

1.测试妹子说开发举一反三讨人喜欢：

说的什么意思呢？测试提了一个bug，开发却改了三个（三代表多个）bug，其他两个bug是隐藏暂未发现的。经验不足开发小哥哥在修改这个bug的时候，觉得影响范围不大，简单的修改了；而经验丰富的开发发现后赶紧跑去通知测试妹子说：“这个bug会影响好多业务功能，请你先暂停相关功能测试，容我修复后再测”。

妹子一听乐了，心想：“刚好我还有另一个测试任务需要测试，要不先忙别的，不然又在这里白忙活了，如果手上没别的项目，正好这会儿可以去喝杯下午茶休息下”。

我觉得上面有两个问题：

1）程序员举一反三的能力重要

2）良好的沟通能力更重要

如果开发小哥哥解决了好多相关的bug,偏偏没有及时告诉测试，测试妹子傻傻了在那里测出来同一个根源的多个bug, 合到最后，总结bug数量的时候，开发说这三个bug算一个，测试说不行，三个就是三个为什么你算一个，我白忙活了这么久找bug, 就算一个太不公平了，一场口舌大战即将爆发。

想想这个问题，确实很有意思，其实开发人员有时候很在乎bug数量的，记得之前有同事因为bug差点和测试发生争执，其实仔细想来没必要，我们也要站在对方的角度考虑，如非必要，做好自己最重要。

2.测试不喜欢“买”一送一的开发：

开发有时候改完一个bug，测试回归后发现确实解决了，然而悲剧的是，前院刚收拾干净，后院又着火了，接着另一个功能不可用了。工作中这个现象很常见，说白了是开发考虑不周，经验不足，或者业务不熟悉。所以提醒同行的老铁们，控制好自己的代码，问题想清楚后再去撸代码，不然测试会经常找你追债。

3.测试喜欢听故事：

测试说你给我讲讲，你的bug怎么产生的，不然bug不关闭，不懂情调的开发，楞头什么也没写，测试妹子一脸懵逼。我觉得这里不备注bug原因确实有失礼貌，甚至不利于团队协作

第一：测试辛辛苦苦测试出问题，想知道原因，最后得到的结果却是一个单词done，确实不太绅士。

第二：测试想统计整个项目中质量情况，bug严重级别和分类，环境引起的还是代码层面引起的，如果代码层面是粗心引起的，还是考虑不周引起的，甚至是压根没做引起的等等

第三：项目总结中，开发回过头看这些bug，如果时间久了，自己也不清楚什么原因引起的，如果后面想总结思考还一脸雾水，万一那天领导问话了，我听说前段时间的项目遇到一个bug,坑很深，让你费了很多力气，给我们分享下你的填坑事迹。如果你没记录根源，想必还要再去苦思冥想一会儿，想必领导对你的态度也是不一样的

上面是今天的话题引子，啰嗦了这么多，发现自己一下笔就忍不住写多了，下面才是今天的主题：

如何做程序员喜欢的测试妹子？

如果真是一名测试妹子看到我下面文字的时候，可能有点严肃,我的要求有点多，不要打我

业务的精通
好奇心
良好沟通能力
拥有BA技能
精确分析能力
一颗安静的心
永不妥协
强烈的责任感
卓识的远见
风险管理能力
颜值高

下面我们用一个项目的生命周期说明以上测试素质的分析：

业务的精通

开发最喜欢熟悉业务的测试，因为他们要忙着撸代码，没时间告诉你这个这个业务规则是怎么样（有人说了，业务规则不是应该找产品吗？产品也有不在或不熟悉的时候，这就是产品的问题了，写完这篇文章，我估计得罪不少人，我是忍着压力，哈哈，开玩笑，项目大了人员变动频繁，规则能完全理清的人凤毛麟角，都理解）；熟悉了业务才能站在更高角度去测试并分析找出系统问题。

好奇心

怀疑一切并积极求证，有洞察力；测试人员进行测试的主要目的就是发现软件存在缺陷，而不是证明它没有缺陷。如果不抱着怀疑一切的态度就不是一名合格的测试人员，我相信测试都必备着技能，只是强烈程度差别而已。

举个例子，一名开发修改了一个小需求提测给测试妹子，说：“我修改了功能A，需要测试下1，2，3相关的场景，你帮我测试下”。妹子反问一句：“改动大吗，有什么风险，你自测了没，会影响其他功能吗，需要测试其他功能点吗？” 开发小哥哥一听，心想怎么那么多问题，然后说：“我想想哈，你这么一问，我突然想起来会影响另一个功能，你也测试下吧，万一有影响就惨了”。

而此时测试千万别相信开发，他说改了什么，你就测试什么，好听话呀，你最好根据自己对业务的判断，分析需要测试什么点，总之怀疑的态度对待。之前工作中我曾几何时就遇到过类似的问题，导致上线几天用户反馈有个功能有bug,才发现原来上次的改动引起的。

良好沟通能力

测试人员常常需要与不同的部门人员打交道。如何更精确、更简练、更严谨的去描述bug，并保证开发人员可以接受你发现的bug，这都需要依靠良好的沟通能力去表达和说服。所以良好的沟通能力显得尤为重要。

我觉得沟通分两个方面：

1）书面沟通

一般公司发现bug会提一个工单给开发，写明bug详细，而这个工单很考验一个测试的水平，那么什么样的工单开发才喜欢呢？

先说一个不好工单例子：

我们看下这个bug工单有什么问题？

站在开发的角度我觉得这个工单问题有以下几个：

描述不清楚，仅仅一个标题就完事了，也不知道哪个账号，哪个推广地址，链接也不给，还要让开发去猜到底哪个地址，让开发去试哪个用户
标题中的推广权限分两种，也没标记是哪种
产品需求什么规则，没明确标记

开发希望从工单中可以找到核心信息，能立即重现此问题，如果模棱两可，信息不全，会造成当面的沟通成本。

2）口语表达

好的口才表达，让你工作效率更好的提高，让人更容易听明白你说的内容尤为重要。

拥有BA技能

BA就是业务分析师的意思，这要求测试人员有分析需求的能力，哪些需求是真需求，哪些需求是伪需求。真需求就玩命的测，伪需求在时间允许的情况下尽量的测。这个要求有点高，不过这个可以提高产品的质量，降低项目风险。

精确分析能力

很多公司的bug不进行分析的，即使分析也不给开发看，我觉得这不合理，首先讲下为什么要分析？

为了发现bug产生的根源，及早采取调整和控制措施，预防和控制问题的蔓延和新问题的产生，揭示软件质量、过程质量、人员能力、组织能力之间的关系，加强软件精细化管理，促进人、过程、组织持续性改进。

那么如果没人分析汇总，又没人团队参与总结，产品质量，团队成长能进步吗？

所以作为一名开发觉得，测试的分析能力是团队进步的催化剂。

一颗安静的心

浮躁的人总是找不出隐藏在深处的bug，良好的耐心，专注力是测试必备素质，每天测试对着n个设备反反复复对着同一个产品使用研究，不腻也烦了，真佩服他们这么专注和坚持了下来，开发表示佩服。

永不妥协

曾经遇到过这样的问题，开发说这个问题有点复杂，不好改，这个场景极少出现，一改的话要延期了，要不先放一放，等后面有时间了再改，测试要不要妥协放一马？强势一点的测试会占优势，妥协意味着你成功的把质量不好这口黑锅华丽的背在了自己的身上，后面时间久了就没人跟进这个问题了。

强烈的责任感

一般说男人要有责任感，你还怎么把测试妹子扯上责任感了呢？测试承担为产品质量把关的角色，而对产品负责的基本要素就是要以质量先行。如果测试没有责任心，敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果，影响公司的声誉。如果真有问题发生到用户身上，要即使的跟进，并做好后面修复工作的备案，不能逃避责任。

卓识的远见

一个好的测试，不仅仅停留在产品表面测试，有时候需要透过现象去看产品底层的结构，去发现异常测试场景，边界测试，安全问题测试等等。作为一名开发，我最喜欢测试的bug有水准，就是很难发现又比较严重的那种，这样才能反映我开发考虑问题的缺失和不足，有成长的空间，需要测试来推进改善。

还记得这张图片不，波音737飞机重大坠机事故，不得不说因为软件质量漏洞导致，测试开发难咎其责。确实有些问题很难找出，需要很大的技术含量和经验。同时很体谅我们的测试不容易，出了事故后还要背锅。