一个狂热软件测试工作者的自白(未完）
本帖最后由 maizixin 于 2018-11-12 17:52 编辑工作11年，软件测试八年，为什么可以坚持这么久? 除了生存需要，对于麦子姐姐我来说，对软件测试这个职业的喜爱显然是起了举足轻重的作用的。是的，用狂热来形容，不怎么过分;P那么做了这么多年测试，甚至都觉得自己狂热了，心得是什么？收获是什么? (当然了，热爱是热爱，在长沙想找份高薪测试工作可不太容易哦:'( ）
首先我觉得，要做好测试工作，真的得热爱的你的工作，把你要测的产品当做自己的孩子，自己的脸面。脸面要吧？那就把好产品最后一关。产品发布出去出了问题，开发是可以免责的，所有问题都是测试的问题，你没测出来嘛，很简单的道理。把产品当成自己的孩子，了解它，关心它，有个什么风吹草动的知道。拿我们自己的产品才说，我所负责的是租车系统后台的服务，后台服务又有很多层，每一个服务做什么的，实现哪些功能，这些得熟知熟知再熟知的。熟知到什么程度？可以为开发提供咨询。如果开发要做一个新的功能，可以来咨询你这样设计可不可以，对原有功能有没有影响。可以精准地为开发提供这项服务，表现不错，业务层面过关了。
其次，不要把自己当成一个测试，你是一个全才，OK？所以发现产品bug了怎么办，描述一下交给开发爱咋咋地？只想说这点层次真的有点低。假如你有点开发功底，应该这样做；假如你没有点开发功底，就先学点开发知道，基本语法得知道吧。比如说，如果你的产品是java的，学点java语法。好了，有点开发功底了，发现bug了在提交bug之前先看log，好的产品都应该有log，比如service log文件，event log，splunk log等。如果任何log都不会有的产品，还是别做了。拿到log用你敏锐的双眼找出和bug相关的信息来吧。一般来说如果是程序异常，通常都会在log里打印出了异常所在的类等等，这个时候再回过头来看开发提交的代码。相信你们都有很好的代码管理，比如说Git，去代码管理工具里面去找这个开发提交的代码吧，是不是能发现刚好和log里吻合的代码呢？这个时候是不是很开心呢？哦，原来是这里出了问题。有时候开发的问题也很low的，或许就是空指针判断没加，或许数据类型转换有问题，或许就是或与非的逻辑搞混了。。。好了，在bug里告诉他新功能有什么样的问题（或者新功能对旧功能造成了什么样的影响），然后告诉他哪个模块哪个类哪一行的代码似乎有问题。这样的bug是不是质量很高呢？:lol
这样分析与提交bug有很多好处：第一，加深你对产品的理解程度，咱可不是做表面功夫的哦！第二，下次再有新功能，更能驾轻就熟。第三，熟悉产品框架，增强你的开发能力。我向来觉得，只会做测试的测试不是一个好测试。如果你懂开发，你可以取代他呀;P如果框架复杂偶尔看点代码其实是很难取代开发的，不过咱可以做些简单新功能开发不也挺好的吗？还可以从易到难啊。第四，大大减少了开发修复bug的时间，想想看，你都告诉他哪一行代码有问题了，还不容易修复么。同时，还能获得开发的好感哦，他会想：嗯，这个测试不错，有思想！同事之间感情也是很重要的嘛。
不把自己单纯地当成一个测试还是许多其他方面，环境部署要会吧，环境有问题你要会分析和修复吧。新版本build也要会吧，发布产品要会吧，产品监控要会吧，生产环境产品出现问题要会分析和解决吧。总之整个产品周期需要做的事情你都要会。还有现在都是持续集成，如果你们有pipeline那么整个pipeline流程要懂啊，中间哪个环节出了问题要会分析解决啊。不会？学啊，只要用心，没有学不会的。当你各方面能力都有了，可能连开发遇到解决不了的难题都要向你咨询哦，有个实例在这:D
背景：开发发现一个生产环境问题，但怎么都debug不出原因。主要是因为框架问题，webservice不同action之间的跳转是不能直接debug过去的，你需要先大概知道可能是哪个action下出的问题，然后把断点打在里面才能找得到问题。可能也是实在没办法了，可能也是因为平时向我咨询得比较多，所以跑来问我，而我真的帮他找出来代码可能出现的问题在哪里，让他分析了两天的问题在那个下午解决了。所以他就会很信任你了，而且一旦你有什么问题都会义无反顾帮助你哦:)所以之后他多次说过'Anything for Meichun'，哈哈~~~
最后是工具。个人觉得前面所说的两点远远比工具重要，或者是前面两点是基础，没有他们工具再好也没有用。工具是一定要用的，做测试一定不要只做手工测试，手工测试多无聊，让自动化来代替吧。分享几个我们webservice用到的测试工具，有需要的话可以一起探讨。webservice接口测试-TestNG, Junit, UnitTest(Visual Studio) 性能测试：LoadTest, Jmeter。其他一些分析管理及持续集成工具如Splunk,Jira,Git,Jekins,Baizai,Kumo......那么我们webservice自动化比例多少？ 99.9%吧，1000多个自动化测试用例。 八年，做到了这些，收获了些什么？对于外包公司来说，只有客户的赞赏是还可以留下来的。作为乙方真的很被动，你个人表现再好客户从某个方面考究说把你们团队砍掉就砍掉，不会讲什么情面。虽然赞赏当不了饭吃，但每个人工作都是需要被需要的，这样才有满足感和成就感嘛。举个例子吧，我们有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
99.9%这么高啊？都是基于接口的自动化测试么？ applepen 发表于 2018-11-13 11:55
99.9%这么高啊？都是基于接口的自动化测试么？
嗯嗯，接口的 八年，高级工程师
小弟还差得远哦~
但是，小弟测试完了后，总是还有各种奇奇怪怪的bug，有些是需求漏掉了（敏捷开发，需求完全不漏，时间不够啊），有些是存量数据，有些兼容性，总之就是各种各样的bug
而且总是担心测试完了后还会有更多的bug
你文中也说了，经过测试上线的，出了问题就得找测试，这种感觉真不好啊 楼主这样的资深测试妹子不容易哟，佩服 好厉害啊，我只是一个黑盒的测试，公司都不给我看代码的权限，好想提高啊 时常学习 发表于 2018-11-15 16:37
八年，高级工程师
小弟还差得远哦~
但是，小弟测试完了后，总是还有各种奇奇怪怪的bug，有些是需求漏掉了 ...
对的呀，感觉bug永远测不完的 我是测试小白，你的心得清晰明白，太有用了!还有后续吗？持续关注 厉害 厉害
页:
[1]
