论一个真正的软件测试工程师

处在离职期,除了交接工作,空余时间还是挺多的,所以必须对以前的职业有一个总结。那么本篇讨论的是什么是一个真正的测试。那么期望是能写下这类文章,这也是那些年我走过的路 :) 纯粹是个人的理解,仅供参考,转载请注明出处(估计也没人会看 >.<)

  • 论一个真正的软件测试工程师
  • 自动化在项目中的应用
  • 性能专项在项目中的应用

一、 半个产品 半个开发

  正真的测试,难道我们平常做的都不是测试的工作吗?其实不肯定也不否定,但这是一个包含关系,如果只是评审+用例编写执行,那么确实不是一个正真的测试,只是包含在内的工作。
  正如标题那样,我认为正真的测试是半个产品+半个开发。
  半个产品,主要体现在理解这个需求为什么要做?其核心价值在哪里?吸引用户的特点是什么?意味着在评审阶段,你除了帮助完善功能需求外,更重要的是理解这个需求的意义所在,比如一个播放视频类应用,其价值在于 多样性 流畅度 简易性 快速性等 这是在评审之后可以总结出来的,那么抱着这个价值点,围绕这我们的整个测试流程,往往能够发现不一样的地方。比如还是播放类应用,在我了解其价值在这几个特性后,在测试过程中我会更加留意播放方面的性能,以及兼容性,在我设计测试方案的时候就会标明这几个测试重点,以便我自己或者组员能够在测试过程中多加留意这部分的测试点,然后在设计测试用例的时候会提高优先级和覆盖率。可以发现,测试有了测重点。
  半个开发,其实个人认为这是偏向于灰盒测试了,体现在一个需求,你除了要明确这个需求的业务逻辑,其代码逻辑(数据流逻辑)也是需要知道的,从后台获取的json数据结构到客户端展示再到存储至本地数据,这一个流向,都是需要去了解并测试的(这部分参照之前写的测试分析文章),所以测试验证的不仅仅是功能层面的东西,还是内部的具体实现(当然,具体到类方法的测试那是测试开发的职能,不关咱测试的事),我们要保证的,就是这一阶段数据的正确性和容错性。这样做的好处是,能从内部发现缺陷,在出现问题的时候可以大概定位到问题出在哪,在出问题面对boss的质疑能够把责任丢给开发,哦不,是更好的解决问题。
  那么半个开发还体现在对工具效率的提升上,能够通过小脚本,小框架去提升测试效率,这要求对于基本的语言要求是必须的,大公司面试的某一轮考研的就是你的代码能力,所以测试还是半个开发这一点是毋庸置疑滴。

二、 职能范围

  • 评审
  • 测试方案的确立
  • 用例的编写维护
  • 技术点的分享
  • BUG提交和总结
  • 输出测试报告
  • 集成测试
  • 发布版本
  • 论坛/其他渠道收集反馈
  • 做性能测试
  • 编写自动化脚本
  • (暂时想到这么多,嘿)

三、 日常的工作流程

  至少是我,在刚接触测试的时候,除了完成领导的任务(主要是看需求,写用例,执行并回归)外,没有什么事情可做,现在回想起来,其实能做事情还有很多,只是没被安排(咳咳,我可不是说我第一份工作的领导不好),好其实是没有意识去提高而已。
  其实就现在而言,我目前的工作流程是这样的(当然是以一个版本迭代为周期):

评审新需求,记录关键点–>编写测试点(用例)–>测试之前向开发了解部分实现–>执行测试(翻阅代码,查看主逻辑走向<可选>)–>提交BUG–>回归BUG(查看BUG代码改动)–>新需求的性能评估(可选)–>发布前的系统测试(结合自动化)–>发布–>自动化用例的补充(可选)–>业务逻辑总结归总–>休息

  那么基本流程就是这样了,那么可以看到一隔项目组的正真的测试人员,是要完成这么多工作的,所以这也是用来区分手工的外包人员和正式员工的区别,外包怎么样,大家都知道。

补充:
窃取某个大神的关于时间安排
时间 工作内容
30% 评审用例维护等准备以及后期工作
20% 执行测试用例,BUG回归
50% 自动化 && 新技术学习,引入

在学习的这段时间,整理资料已经成了我的习惯!下面是我对上面三个阶段学习的收集和整理在这里插入图片描述
对于学习软件测试的的朋友来说应该是最全面的备战仓库了,有很多朋友靠着这些内容进行复习,拿到了BATJ等大厂的offer,这个仓库也已经帮助了很多的软件测试的学习者,希望也能帮助到你!

乾坤未定,你我皆是黑马

关注微信公众号:【程序员二黑】 即可免费获取这份仓库资源啦!

猜你喜欢

转载自blog.csdn.net/m0_53918927/article/details/112911064