查看原文
其他

软件测试人员的自我修养

深度科技 研发部 深度操作系统 2022-06-15

作为一个不入流的软件测试人员以“测试人员的自我修养”为话题进行主题延伸,确实有点不知天高地厚。时至今日,我所掌握的测试技术别人都会,也没有自创的半点招式,如果用心,在网上都可以搜到相关资料,这个话题不如叫做《作为一名测试人员,我的自我修养之路》更合适。我承认,我之所以把主题那么直接的叫做《测试人员的自我修养》,我就是来吸引目光的,您被忽悠了


我对软件测试的感情是热爱和肯定的,如果不是因为热爱测试,不会心甘情愿的把六年多的青春“挥霍”在这一行业上,而在测试上投入的时间越多,反而更加深了我对测试的热爱。测试于我,已经是生活中不可分割的一部分,测试的思维在我日常生活中也多有助益。


作为一个软件测试人员来说,要和别人有何不同?需要具备了哪些特点呢?


我做测试之前,做了一年半的开发,当时用的过时的MFC框架,即便如此,我还是个不合格的开发。但我了解了开发过程中的很多原理性的东西,比如前端界面的各类控件、后端消息的响应处理、以及多线程通信、文件读写操作、硬件设备的IO操作等。现在这些东西,你让我上手去写代码是不可能了,因为已经全部忘干净了。但是,经验就有这点好处,比如你被开水烫过一次之后就不会再生吞开水,有了相关的开发经验之后,哪怕是入门级的开发经验,那各种语言、各种平台、各种产品,其实现的基础、原理性的东西有很多相通之处,而对于开发来说,无非是哪种实现方式更加方便,现成的库更多而已。


对测试来说,开发用什么语言实现的不重要,重要的是内部实现的逻辑。有了开发的经验时,阅读产品设计文档就不是太费解的事,开发如果想用违背原理性的说法来为其Bug辩护的话,你能够快速的知道他是在忽悠你。


测试人员自我修养之一:就是需要具备一定的开发经验,有框架思维。这点保证我们可以对软件实现的架构能正常快速的理解。


虽然开发的工资高、形象好,但是对我来说,开发是不可能的,这辈子不可能干开发的。



换工作同时也换了岗位,新生活的开始以新技能的掌握为基础。当时被招去干测试时,我还什么都没准备呢,只准备好了开始新生活,因为那个时候我家的小朋友即将出生。


当时学习氛围是很浓厚的,在华为当过新员工的都有感触,实习期间几乎就是不断学习理论知识和不断的实践的过程。我看华为之所以伟大的角度是华为是马克思主义的坚定践行者,理论结合实际,不脱离理论也结合实际,别人好的,拿过来用,比如花巨资引进的IBM那套管理方法,把经过实践证明的理论先固化下来,吸收之后再慢慢优化。


在新员工期间,各种测试的理论知识都必须学习,各种测试用例的设计方法如白盒测试用例设计的各种方法,黑盒测试用例设计的各种方法都需要学习并掌握。在华为,新员工是和老员工是被一视同仁的,新员工即便没有具体项目做,晚上也要免费加班,我们当时加班的内容要么就是自学要么就是参加分享会。分享会是新员工之间进行的学习成果的分享或者是老员工给新员工进行的测试经验分享。总之,新员工阶段,其虽然和后面正式转正后的生活相比是最幸福的一个阶段,但是,新员工时我们的生活强度依然很大。从这方面来说,作为一个测试,那孰知各种测试理论知识是必备技能,掌握各种测试用例的设计方法是必要手段,如果把测试比做打枪,那么其各种测试理论知识的学习就是我们不断的练习卧倒,端抢,瞄准的过程。


测试人员自我修养之二:有过硬的测试理论知识。



神枪手界有一个理论:神枪手都是一箱一箱子弹喂出来的。新员工转正之日就是要一箱箱喂子弹之时。脱离了蜜月期,就要真刀真枪的干了。


当时第一个接受的项目就是对高可用服务器的容错能力进行特性测试。简称linux RAS(Reliabilty,Availability,Serviceability)特性。


写到这里我发现网上有人可以把RAS的意思大概说的比较清楚,就直接拿过来用了


RAS,是Reliabilty,Availability,Serviceability的缩写,是对一台服务器可以被可靠使用的要求。这个是个相当粗糙的定义。如果深入一点理解,所谓R,表示服务器提供正确输出的能力,比如我要求你给我计算1+1,你给我回应了,但你说等于3,这R就有问题了。A表示能提供输出的能力,比如我让你给我计算1+1,你确实不说这等于3,但你什么都不说,那这个A就有问题了(总算是比说等于3好一点)。而S是说,如果你发现这个设备不能提供服务了(A出了问题),你把坏掉的部分换掉或者修好的能力。
但这仍是个非常粗糙,指向不明的定义。但RAS确实就是这么个不清不楚的定义。或者我们可以换个角度,整个RAS的最终评价标准,常常是MTBF,Mean Time Between Failure,也就是你的服务器有多长时间能“正确提供所需功能”。我们经常说某个系统是4个9还是6个9,说的就是MTBF这个指标。


好了,你想听我继续解释linux 内核RAS实现的细节吗?别多想了,时隔经年,我早无法回忆起开发的设计文档里面的内容了。不过,项目测试感觉还会永存心头。


当时导师让我做测试方案设计,我真是一头雾水。因为我还是习惯从瞄准镜里看靶物,战场上飞过的子弹让我蒙圈了。憋了一个星期,测试方案写的一塌糊涂。导师实在看不过去,只能又给我仔细讲解了产品的设计文档,从头再来。把产品的设计思路理清楚之后,就是找等价类,边界值,找测试工具,或者写脚本,设想各种异常和极端的场景去搞这个操作系统。最终,测试方案写出来了,算是达到了导师的要求。


测试人员自我修养之三:不要有畏难情节,只要坚持不懈,再难搞得系统都可以搞的飞起。



如果一个公司的产品比较多,那么恭喜你,测试可是要面对多个开发项目的。产品和产品之间差异可能非常大,你会发现你刚把某一种技术知识玩的飞起就被切换到另外一个项目测试中。来吧,收起你的得意,整理你的行装,奔赴下一个战壕吧。现在的产品都在追求快速迭代,如果你不尽快适应新的产品,快速的阅读并理解产品文档和设计文档,那你会发现你的时间会越来越少。


如果你被这种快节奏弄晕了,那么你就不是一个好抢手。记住,别乱。越是节奏快的项目,越是不能乱。如果产品负责人只给了你很短的测试周期,那么对他你也不要客气,尽量提你的要求,提加时间加人手的条件,尽量说出你看到的风险点。但是,同时也要做好没有更多资源来帮你的打算。你必须加班加点,必须一个流程都不少的完成测试方案,测试计划,测试用例等等不可缺少的准备工作。这些东西哪怕只有写出一个提纲的时间,那也是有胜于无,这些东西可以在你边执行测试时边完善,别想着大家一起乱干完之后再回去补充文档,那会是一个很痛苦的过程。


测试就是这么一个环节,产品,开发包括测试自身可能都觉得测试好欺负,不重视,但是,自己绝对不能因为别人不重视自己而不去重视产品质量。属于我们需要完成的工作一定要认真完成,而且要眼观六路耳听八方,盯着产品和开发,他们如果有犯错,你一定要帮他们喊出来。你就像一个心不为外物所动的老猎手,趴在你的战壕只盯着你的猎物(产品质量),天上就算下刀子,你也不能乱。


测试人员自我修养之四:敌军围我千万重我自岿然不动。



测试人员的工作就是找毛病,我相信,如果你在日常生活中经常挑一个人的毛病,那他把你揍一顿就算轻的。想像一下,你走大街上,拽住一美女说:你这行为不合常理,这么冷的天,你只穿一个丝袜,会老寒腿的。


事实上,测试就是这么一个人物,开发好不容易撸了几天的代码,结果一转到我们测试手里就搞了个致命错误,而且我们测试还可能经常指出开发某个提示信息不对,标点符号用错了,界面配色不养眼等等。我相信,不少测试都被开发问候过。测试人员就是不断的摧残我们的产品,尤其,这个产品还是开发的孩子的时候,这些行为看起来像是摧残开发的自信心。


那怎么办?我的办法是:脸皮厚,吃饱肉。测试一定要学习脸皮厚,如果产品实现的方式写的不清楚或者自己理解不了的,请不要觉得丢脸,主动的让开发给你讲清楚,一遍没讲清楚,那么,请厚着脸皮让他再讲第二遍第三遍,当然,脸皮厚也要配合嘴巴甜。


如果转测试的时候,交付的资料不全,也不要不好意思要,该要的就要大胆的要,该给我们的一个都不能少,只能多。哈哈,不给,那就不帮助开发测试。


测试人员自我修养之五:脸皮厚。



一个产品从立项到结束,都可以找到测试的身影,虽然说产品经理是整个项目的灵魂人物,但是,测试人员也是不可忽略的重要有生力量,产品最终要的属性是质量,产品质量的好坏,从测试人员介入的深度就可以提前预知,比如在需求评审界面,测试就能了然产品的各个实现细节,提前暴露出不合理的需求。产品设计阶段,开发撸完几天代码处于自嗨的过程中,此时测试可以主动的把自己已完成的测试用例给开发,让他们按照测试用例自测,这些方法都可以使测试提前介入,众所周知,问题越早暴露,成本越低。


测试就像一个watchdog一样,在项目的各个环境都可以发挥重要作用,所以,测试一定要学会沟通,沟通顺畅,每个人都愿意配合测试,沟通不畅,每个人都当测试不存在。


其实,很多测试都自我感觉不受重视,这跟测试自身的性格不无关系,测试人员可能自认为代码能力不如开发,多少会有自卑感,所以介入每个流程也不积极发表自己观点,担心出错。在我这种脸皮厚之人看来,大可不必这样。要知道我们的产品和开发们都是温顺的小绵羊,他们只是也刚好不善于表达而已,所以我们测试就一定要主动勾着他们,让他们在我们面前主动的暴露缺点,所谓言多必失么,哈哈,这也是一个发现开发Bug的一种手法。


测试人员自我修养之六:学会不讨人烦的沟通技巧。



需求阶段,测试就需要着手写测试策略,测试计划,测试报告了。在开发阶段,就需要跟上编写测试用例,理想状态下,版本转测试之前,我们无遗露的测试用例就需要准备齐全,只需要执行即可,在测试过程中,提交的Bug需要规范,最好有Bug的现场截图等有效开发定位的信息。测试结束之后,需要尽快完成测试报告。所以你看,测试人员需要写很多文档,开发可以只专注于代码,但是,测试一定要把自己的工作量体现在文档当中。


编写测试报告最好采用图文并茂的方式编写,这就要求测试人员在编写测试报告的时候,需要对数据进行处理,所以相关的文档处理技术也是需要的。


测试人员自我修养之七:学会并擅长写文档。



正所谓功夫在诗外,测试理论知识就是那么多,理论知识掌握之后就要不断的参与到项目中来,一个一个项目的练习,锻炼自己的发现Bug的能力,就算随机测试,一个好的测试和一个坏的测试,他们发现问题的能力也是完全不同的。以上完全是个人的一点体悟,未必上的了台面,各位看官,看的时候也请多多批评,虽然我未必会改



【相关链接】

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存