乔布斯曾经说过「每个人都应该学习编程,因为它会教你如何思考」,看,乔帮主都觉得所有人都应该学编程,那你说做测试的要不要学?当然要。
作为测试人员,除了上面这个原因,我觉得如果会编程,还有下面 3 个好处。
1、知道技术实现,可以设计更有针对性的用例
比如我在《需求评审之实战演练》中提到的关于计算器的测试,有些人会写一条用例是「测试一个超大的数」。
但是问到多大数算大?100000 算不算?很多人回答不上来。
也就是说,很多人知道需要测试边界值的情况,但是没人知道这个边界值到底是多少。
当然也不是所有人都不知道。
比如有人说,是 int 类型的最大值,得,能说出来这个就已经很靠谱了,试想下,如果你不会编程,你能知道什么是 int 类型?你能知道用 int 的最大值去做针对性测试?
2、更容易和开发进行逻辑层的沟通,更好的拓展测试思路。
比如一个同学发现一个 bug:
如果在 windows 的系统盘根目录丢一个 program.exe 的文件,某些程序在执行进程创建时,就会出错,把 program.exe 执行起来了。
于是这个同学就去找开发沟通。
第一个同学的沟通过程是这样的:
测试:「xgg,这个问题是什么原因导致的?」
开发:「目标进程路径带有空格,我代码中没有加引号,所以就出问题了。」
测试:「噢,好滴。」
另一个同学觉得还是有疑问,于是再次找到开发。
测试:「xgg,具体是哪个实现的问题?是我们内部的函数实现?还是调用的系统 API 有问题?」
开发:「我用的 CreateProcess API,他的第二个参数如果带有空格,又没有加引号,就会出这个问题。」
测试:「CreateProcess API 使用的地方很多,能否搜一下看看每个地方本次都做了修改?」
开发:「好,马上看。」
测试:「同样功能的 CreateProcessAsUser、CreateProcessWithLogon、CreateProcessWithToken 应该有类似的问题,可以一起搜一下看看都处理了没有。」
开发:「好,立刻看。」
如果你是开发,你喜欢和哪一位测试配合?
如果你是测试,你希望自己前面那位同学还是后面这位?
3、更好的自动化思维,把提效落实到实处。
现在很多功能,都会在逻辑中加一些日志,如果是调试版文件,日志输出就更多了,对于客户端产品来说,很多日志输出在 dbgview 里,我们可以通过一些过滤条件进行过滤,甚至设置高亮,但如果是输出的纯本地的文本日志,那么每次查看日志就必须要 Ctrl+F 然后输入关键字逐个去确认了。
我们看看手工操作的步骤:
第一步:找到日志文件并打开;
第二步:Ctrl+F 调起搜索框并输入关键字;
第三步:回车-检查-回车-检查,如此反复;
这时候如果有一个同学,会一些简单的脚本技术,可能会考虑对这个过程做一个优化,比如提供一个工具,只需要在工具中输入关键字,工具就会自动找到日志文件,并把所有关键字相关的记录都提取出来,会不会爽很多?
我们看看使用这个工具的操作步骤:
第一步:打开工具并输入关键字(工具自己查找日志路径,并且在每次操作时都保证获取的是最新的日志);
第二步:检查结果(结果中全都是相关性内容);
看起来只是节省了一步吧,但是工具这两步操作中,都隐含了大量的重复操作的优化。
比如第一步「打开工具并输入关键字」,其实工具是自己查找日志路径,并且在每次操作时都保证获取最新的日志,这样就避免了手工操作时每次都要重新打开日志的麻烦。
比如第二步「检查结果」,之前是在所有日志里面去一个个检查搜索结果,现在工具出的结果是只显示和关键字相关的上下文信息,可以极大地减少其他信息干扰,更快更准地找到自己需要的信息。
如果你不会编程,你会考虑用这个简单的工具去提效?
就算你考虑到能用工具提效,你能快速准确的把自己的需求提出来并找到人帮忙实现?
就算实现了,碰到一些小的体验问题你能总是不断找人帮忙优化?
最后再总结下我的结论。
做测试要不要学编程?我的答案是,要,会编程的测试可以往业务线的测试开发方向努力。
我不会编程能不能做测试?我的答案是,能,不会编程的测试可以继续在业务专家方向深耕。
以上,你会编程不?目前什么水平?自己团队小伙伴的编程技术都什么水平?你认为做测试到底要不要学编程呢?欢迎留言和我讨论。
当然,如果你支持我上面的观点,请点个「在看」让更多人来一起看。
本文首发于公众号「sylan215」,十年测试老司机的原创干货,关注我,一起涨姿势!
![sylan215](https://i-blog.csdnimg.cn/blog_migrate/23388f388d3d5d42a14d7e3042055e62.jpeg)