一个狂热软件测试工作者的自白(未完）

maizixin · 发表于 2018-11-12 17:40:24

本帖最后由 maizixin 于 2018-11-12 17:52 编辑

工作11年，软件测试八年，为什么可以坚持这么久? 除了生存需要，对于麦子姐姐我来说，对软件测试这个职业的喜爱显然是起了举足轻重的作用的。是的，用狂热来形容，不怎么过分

那么做了这么多年测试，甚至都觉得自己狂热了，心得是什么？收获是什么? (当然了，热爱是热爱，在长沙想找份高薪测试工作可不太容易哦

）

首先我觉得，要做好测试工作，真的得热爱的你的工作，把你要测的产品当做自己的孩子，自己的脸面。脸面要吧？那就把好产品最后一关。产品发布出去出了问题，开发是可以免责的，所有问题都是测试的问题，你没测出来嘛，很简单的道理。把产品当成自己的孩子，了解它，关心它，有个什么风吹草动的知道。拿我们自己的产品才说，我所负责的是租车系统后台的服务，后台服务又有很多层，每一个服务做什么的，实现哪些功能，这些得熟知熟知再熟知的。熟知到什么程度？可以为开发提供咨询。如果开发要做一个新的功能，可以来咨询你这样设计可不可以，对原有功能有没有影响。可以精准地为开发提供这项服务，表现不错，业务层面过关了。

其次，不要把自己当成一个测试，你是一个全才，OK？所以发现产品bug了怎么办，描述一下交给开发爱咋咋地？只想说这点层次真的有点低。假如你有点开发功底，应该这样做；假如你没有点开发功底，就先学点开发知道，基本语法得知道吧。比如说，如果你的产品是java的，学点java语法。好了，有点开发功底了，发现bug了在提交bug之前先看log，好的产品都应该有log，比如service log文件，event log，splunk log等。如果任何log都不会有的产品，还是别做了。拿到log用你敏锐的双眼找出和bug相关的信息来吧。一般来说如果是程序异常，通常都会在log里打印出了异常所在的类等等，这个时候再回过头来看开发提交的代码。相信你们都有很好的代码管理，比如说Git，去代码管理工具里面去找这个开发提交的代码吧，是不是能发现刚好和log里吻合的代码呢？这个时候是不是很开心呢？哦，原来是这里出了问题。有时候开发的问题也很low的，或许就是空指针判断没加，或许数据类型转换有问题，或许就是或与非的逻辑搞混了。。。好了，在bug里告诉他新功能有什么样的问题（或者新功能对旧功能造成了什么样的影响），然后告诉他哪个模块哪个类哪一行的代码似乎有问题。这样的bug是不是质量很高呢？

这样分析与提交bug有很多好处：第一，加深你对产品的理解程度，咱可不是做表面功夫的哦！第二，下次再有新功能，更能驾轻就熟。第三，熟悉产品框架，增强你的开发能力。我向来觉得，只会做测试的测试不是一个好测试。如果你懂开发，你可以取代他呀

如果框架复杂偶尔看点代码其实是很难取代开发的，不过咱可以做些简单新功能开发不也挺好的吗？还可以从易到难啊。第四，大大减少了开发修复bug的时间，想想看，你都告诉他哪一行代码有问题了，还不容易修复么。同时，还能获得开发的好感哦，他会想：嗯，这个测试不错，有思想！同事之间感情也是很重要的嘛。

不把自己单纯地当成一个测试还是许多其他方面，环境部署要会吧，环境有问题你要会分析和修复吧。新版本build也要会吧，发布产品要会吧，产品监控要会吧，生产环境产品出现问题要会分析和解决吧。总之整个产品周期需要做的事情你都要会。还有现在都是持续集成，如果你们有pipeline那么整个pipeline流程要懂啊，中间哪个环节出了问题要会分析解决啊。不会？学啊，只要用心，没有学不会的。当你各方面能力都有了，可能连开发遇到解决不了的难题都要向你咨询哦，有个实例在这

背景：开发发现一个生产环境问题，但怎么都debug不出原因。主要是因为框架问题，webservice不同action之间的跳转是不能直接debug过去的，你需要先大概知道可能是哪个action下出的问题，然后把断点打在里面才能找得到问题。可能也是实在没办法了，可能也是因为平时向我咨询得比较多，所以跑来问我，而我真的帮他找出来代码可能出现的问题在哪里，让他分析了两天的问题在那个下午解决了。所以他就会很信任你了，而且一旦你有什么问题都会义无反顾帮助你哦

所以之后他多次说过'Anything for Meichun'，哈哈~~~

maizixin · 发表于 2018-11-13 08:30:48

最后是工具。个人觉得前面所说的两点远远比工具重要，或者是前面两点是基础，没有他们工具再好也没有用。工具是一定要用的，做测试一定不要只做手工测试，手工测试多无聊，让自动化来代替吧。分享几个我们webservice用到的测试工具，有需要的话可以一起探讨。webservice接口测试-TestNG, Junit, UnitTest(Visual Studio) 性能测试：LoadTest, Jmeter。其他一些分析管理及持续集成工具如Splunk,Jira,Git,Jekins,Baizai,Kumo......那么我们webservice自动化比例多少？ 99.9%吧，1000多个自动化测试用例。

maizixin · 发表于 2018-11-13 09:53:25

八年，做到了这些，收获了些什么？对于外包公司来说，只有客户的赞赏是还可以留下来的。作为乙方真的很被动，你个人表现再好客户从某个方面考究说把你们团队砍掉就砍掉，不会讲什么情面。虽然赞赏当不了饭吃，但每个人工作都是需要被需要的，这样才有满足感和成就感嘛。举个例子吧，我们有1000多个测试用例是用c# UnitTest写了，在移到TestNG，但是呢还只移了一部分，所以还是要依赖于原来.net框架里的回归测试的。问题出现在webservice更新到TLS1.2之后，所有从.net发出去的请求webservice都不接受了，这样所有回归测试都被block。尴尬的是开发主要做java，对.net框架不熟；测试虽然对c#写测试用例没问题，对这些框架之间的兼容性问题也不懂啊。有几个开发搜了几个解决方案还是解决不了，PPM（Primary Project Manager）都准备安排人把所有的回归测试用例都迁移到TestNG再跑回归测试了，我的个妈呀，几百个case，那么多业务逻辑，移到什么时候去了。最后小女子还是折腾折腾把它解决了，虽然其实当时连TLS1.2是啥都不知道。其实找到了解决方案也就是一些注册表的更新哦顺便分享一下解决方案吧：
- 设置 .net framework，让它不要用strong crypto（下面第一和第二个注册表项，32位和64位）
- 从系统层面去Enable TLS 1.2 （下面第三和第四个注册表项）
- 设置 .net framework，让它应用系统默认TLS版本（下面第五和第六个注册表项，32位和64位）
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /f /reg:32
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /f /reg:64
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32

applepen · 发表于 2018-11-13 11:55:23

99.9%这么高啊？都是基于接口的自动化测试么？

maizixin · 发表于 2018-11-13 14:26:11

applepen 发表于 2018-11-13 11:55
99.9%这么高啊？都是基于接口的自动化测试么？

嗯嗯，接口的

时常学习 · 发表于 2018-11-15 16:37:14

八年，高级工程师
小弟还差得远哦~
但是，小弟测试完了后，总是还有各种奇奇怪怪的bug，有些是需求漏掉了（敏捷开发，需求完全不漏，时间不够啊），有些是存量数据，有些兼容性，总之就是各种各样的bug
而且总是担心测试完了后还会有更多的bug
你文中也说了，经过测试上线的，出了问题就得找测试，这种感觉真不好啊