一个真正的软件测试工程师是怎么样的

     最近空余时间还是挺多的&＃xff0c;所以必须对以前的职业有一个总结。那么本篇讨论的是什么呢&＃xff1f;是一个真正的测试。那么期望是能写下这类文章&＃xff0c;这也是那些年我走过的路 :) 纯粹是个人的理解&＃xff0c;仅供参考。

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

●自动化在项目中的应用

●性能专项在项目中的应用

01

半个产品 半个开发

      有人觉得这个标题有点讽刺&＃xff0c;真正的测试&＃xff1f;&＃xff0c;难道我们不是真正的测试&＃xff0c;平常做的都不是测试的工作吗&＃xff1f;其实不肯定也不否定&＃xff0c;但这是一个包含关系&＃xff0c;如果只是评审&＃43;用例编写执行&＃xff0c;那么确实不是一个真正的测试。 
　　正如标题那样&＃xff0c;我认为真正的测试 &＃61;“半个产品&＃43;半个开发”。 

　　半个产品&＃xff0c;主要体现在理解这个需求为什么要做&＃xff1f;其核心价值在哪里&＃xff1f;吸引用户的特点是什么&＃xff1f;意味着在评审阶段&＃xff0c;你除了帮助完善功能需求外&＃xff0c;更重要的是理解这个需求对于用户有什么价值&＃xff0c;你是用户你会怎么想有什么感受,不能简单的走完流程就可以了&＃xff0c;比如一个播放视频类应用&＃xff0c; 多样性 流畅度 简易性 快速性等 这是在评审之后可以总结出来的&＃xff0c;那么抱着这个价值点&＃xff0c;围绕这我们的整个测试流程&＃xff0c;往往能够发现不一样的地方。比如还是播放类应用&＃xff0c;在我了解个特性后&＃xff0c;在测试过程中我会更加留意播放方面的性能&＃xff0c;以及兼容性&＃xff0c;在我设计测试方案的时候就会标明这几个测试重点&＃xff0c;以便我自己或者组员能够在测试过程中多加留意这部分的测试点&＃xff0c;然后在设计测试用例的时候会提高优先级和覆盖率。可以发现&＃xff0c;测试有了测重点。 

　　半个开发&＃xff0c;其实个人认为这是偏向于灰盒测试了&＃xff0c;体现在一个需求&＃xff0c;你除了要明确这个需求的业务逻辑&＃xff0c;其代码逻辑(数据流逻辑)也是需要知道的&＃xff0c;从后台获取的json数据结构到客户端展示再到存储至本地数据&＃xff0c;这一个流向&＃xff0c;都是需要去了解并测试的(这部分参照之前写的测试分析文章)&＃xff0c;所以测试验证的不仅仅是功能层面的东西&＃xff0c;还是内部的具体实现(当然&＃xff0c;具体到类方法的测试那是测试开发的职能&＃xff0c;不关咱测试的事)&＃xff0c;我们要保证的&＃xff0c;就是这一阶段数据的正确性和容错性。这样做的好处是&＃xff0c;能从内部发现缺陷&＃xff0c;在出现问题的时候可以大概定位到问题出在哪&＃xff0c;在出问题面对boss的质疑能够把责任丢给开发&＃xff0c;哦不&＃xff0c;是更好的解决问题。 

　　那么半个开发还体现在对工具效率的提升上&＃xff0c;能够通过小脚本&＃xff0c;小框架去提升测试效率&＃xff0c;这要求对于基本的语言要求是必须的&＃xff0c;大公司面试的某一轮考研的就是你的代码能力&＃xff0c;所以测试还是半个开发这一点是毋庸置疑滴。

02

职能范围

●评审

●测试方案的确立

●用例的编写维护

●技术点的分享

●BUG提交和总结

●输出测试报告

●集成测试

●发布版本

●论坛/其他渠道收集反馈

●服务器性能测试

●APP性能测试

●网页前端性能

●编写自动化脚本

●(暂时想到这么多&＃xff0c;嘿)

01

日常的工作流程

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

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

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

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