测试开发工作者日记：2020.7.9
作者：互联网
大概十天 没有更新这个系列了。
最近一直在更新接口测试平台系列，每天都有不少粉丝进行友bao好li反cui馈geng
所以今天还是说说测试开发的日记吧...
最近几天在支援一个点点点的测试任务，一个新的商城。这个已经不是第一版了，甚至已经在线上运行了一段时间，这次就是添加了一个小功能。我想着那还不是分分钟就测完么，但是一看到半个月的排期，我就知道没这么简单
第一天，我在需求文档都懒得看的前提下进行测试，不到2个小时，找到了二三十个bug，此时的我震惊了。
产品妹子发现我没看文档，我就用我多年的高端撕x经验回复：知道我为啥不看文档么？因我对这个项目来说是一个新鲜的血液注入，为了避免被产品文档先入为主，控制思维。所以我要以一个普通用户的身份和角度去感受这个产品，如果我发现和我使用习惯和逻辑别扭的地方，到时再看文档，如果文档和我想法一致，那么就找到了bug，如果不一致，那么你文档错了，得改。毕竟，产品文档严格来说也是要经过我们测试的静态测试流程的，既然这里没有，那么我这首轮不看文档测试就恰好也可以测你产品文档的不足之处。
其次，如果我看不懂这个商城怎么买东西，需要借助文档才能理解。那么说明这个产品设计是有问题的，毕竟线上用户可不会先研究你文档再使用商城。针对iso9126来说，你的易用性内的易理解性，易使用性，易学性等可都可能有问题，那么怎么来测呢，就必须是一个完全没有接受你产品文档先入为主的新人来测。而且时间紧迫，我看你文档都要很长时间，还不如直接来测，我们测试培训当年的一门绝技就是不看文档，对着界面直接出写用例。我这招可谓是一箭多雕。
然后..... 经过了我长篇大论的大道理论证之后，全场鸦雀无声。紧接着我亮出来30多个bug，这些里面一大半都是之前线上就有且漏掉的。我为啥能迅速发现呢，因为我没看文档啊，用这种强势的结果导向思维，来论证我以上的观点的价值是很高的。
最终机智如我，成功化解了一次信任危机。
当然这里建议测试小伙伴不要学我，功力不够 容易被产品和开发打脸。
最近这几天公司进行了升职答辩，想必观众老爷们或多或少自己或者朋友的公司都在搞这个，每年1-2次，都是这个时间点。我司也不例外。被搞了个突然袭击，没啥心里准备，直接被告知做个ppt，然后马上去答辩。这样的结果就是我的ppt上连个像样的图都没有，全是字。然后我答辩时候打算照着念。
因为疫情影响，各公司答辩的成功率 也直线下降。且对职级较高的我来说，这次说实话成功几率渺茫，甚至无限趋近0。
心想反正也成功不了，还要跟其他各部门如算法，架构的顶级大佬pk抢有限的名额，我去涨涨见识就可以了。
没想到 就是这个放松的心里准备，让我在答辩过程中夸夸其谈束，思维活跃，气氛爆场。全然忘记了台下8个副总裁级别和hrbp总监的存在。然后严重超时.....
对于是否超时这个事，其实有利有弊，弊端是一定会扣分。利就是你能不能牺牲这扣掉的分数。在超时的几十分钟内展现更多会加分的技术。最终反而多加。这个是个危险活。45分钟到了，你感觉自己分数不够，要被淘汰。你可以冒个险，喝出超时来讲解更多震撼的技术和未来设想。
所谓 富贵险中求，要么被扣光，要么加高分。
结果我说到了饭点，导致下一位答辩选手被安排在了第二天早上。
好巧不巧，第三天的时候，通知就到了，晋升成功......
之后呢，打算给大家出一篇专门讲测试开发晋升的技术 的文章，欢迎期待。
言归正传：最近接到了一个大需求，app埋点自动化测试。
就是在你的ui自动化中，要加入顺便能测试 app发出去的http请求的内容的自动化脚本，我们手工测试是用charles postman等工具抓包。但是如何用自动化来抓包并且断言呢？这个我早有解法。所以当开发们老大跟我说这个需求的时候，我一口同意了，这是个大活，无论是技术还是量。等之后有机会给大家出一个 埋点自动化测试 的技术文。期待不？ 晋升的加分项～okr的有力任务哦～
好了欢迎继续关注接口测试平台代码开发教程，有些小伙伴反馈说有点跟不上，我之后会做相应调整。看着最新的一篇阅读量都没破百，我觉得可能确实内容输出有点快了.... 大家跟着做，这是测试开发的门槛，也是未来测试的出门证。
标签：这个,2020.7,开发,文档,测试,答辩,超时,日记,工作者 来源： https://blog.51cto.com/u_15282986/2953187