真正的测试 =“半个产品+半个开发”

TestWhite 2018年7月18日02:08:01
评论
1323字阅读4分24秒
云小站

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

● 自动化在项目中的应用

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

半个产品、半个开发

有人觉得这个标题有点讽刺,真正的测试?难道我们不是真正的测试,平常做的都不是测试的工作吗?其实不肯定也不否定,但这是一个包含关系,如果只是评审+用例编写执行,那么确实不是一个真正的测试。

真正的测试 =“半个产品+半个开发”

半个产品,主要体现在理解这个需求为什么要做?其核心价值在哪里?吸引用户的特点是什么?

 

意味着在评审阶段,你除了帮助完善功能需求外,更重要的是理解这个需求对于用户有什么价值。你是用户你会怎么想有什么感受,不能简单的走完流程就可以了。

 

比如一个播放视频类应用, 多样性、 流畅度 、简易性 、快速性等,这是在评审之后可以总结出来的。

那么抱着这个价值点,围绕这我们的整个测试流程,往往能够发现不一样的地方。

 

真正的测试 =“半个产品+半个开发”

 

如还是播放类应用,在了解个特性后,在测试过程中会需要更加留意播放方面的性能,以及兼容性。在设计测试方案的时候就会标明这几个测试重点,以便自己或者组员能够在测试过程中多加留意这部分的测试点。

 

然后在设计测试用例的时候会提高优先级和覆盖率。可以发现,测试有了测重点。

半个开发,其实个人认为这是偏向于灰盒测试了。体现在一个需求,你除了要明确这个需求的业务逻辑,其代码逻辑(数据流逻辑)也是需要知道的。

 

真正的测试 =“半个产品+半个开发”

 

从后台获取的json数据结构到客户端展示再到存储至本地数据,这一个流向,都是需要去了解并测试的(这部分参照之前写的测试分析文章)。

 

所以测试验证的不仅仅是功能层面的东西,还是内部的具体实现(当然,具体到类方法的测试那是测试开发的职能,不关咱测试的事)。

 

我们要保证的,就是这一阶段数据的正确性和容错性。

 

这样做的好处是,能从内部发现缺陷,在出现问题的时候可以大概定位到问题出在哪,在出问题面对boss的质疑能够把责任丢给开发,哦不,是更好的解决问题。

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

 

 

2

职能范围

● 评审

● 测试方案的确立

● 用例的编写维护

● 技术点的分享

● BUG提交和总结

● 输出测试报告

● 集成测试

● 发布版本

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

● 服务器性能测试

● APP性能测试

● 网页前端性能

● 编写自动化脚本

3

日常的工作流程

真正的测试 =“半个产品+半个开发”

其实就现在而言,目前的工作流程是这样的(当然是以一个版本迭代为周期):

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

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

  • 补充:

窃取某个大神的关于时间安排

时间   工作内容

30%   评审用例维护等准备以及后期工作

20%   执行测试用例,BUG回归

50%   自动化 &新技术学习,引入 !

图文来源网络,如有侵权联系删除

 

继续阅读
  • 我们QQ群
  • QQ扫一扫
  • weinxin
  • 微信公众号
  • 公众号扫一扫
  • weinxin
TestWhite
  • 本文由 发表于 2018年7月18日02:08:01
  • 请您在转载时请务必保留本文链接:https://www.playezu.com/13864.html
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: