作为测试人员，除了上面这个原因，我觉得如果会编程，还有下面 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 调起搜索框并输入关键字；
第三步：回车-检查-回车-检查，如此反复；
这时候如果有一个同学，会一些简单的脚本技术，可能会考虑对这个过程做一个优化，比如提供一个工具，只需要在工具中输入关键字，工具就会自动找到日志文件，并把所有关键字相关的记录都提取出来，会不会爽很多？
我们看看使用这个工具的操作步骤：
第一步：打开工具并输入关键字（工具自己查找日志路径，并且在每次操作时都保证获取的是最新的日志）；
第二步：检查结果（结果中全都是相关性内容）；
看起来只是节省了一步吧，但是工具这两步操作中，都隐含了大量的重复操作的优化。
比如第一步「打开工具并输入关键字」，其实工具是自己查找日志路径，并且在每次操作时都保证获取最新的日志，这样就避免了手工操作时每次都要重新打开日志的麻烦。
比如第二步「检查结果」，之前是在所有日志里面去一个个检查搜索结果，现在工具出的结果是只显示和关键字相关的上下文信息，可以极大地减少其他信息干扰，更快更准地找到自己需要的信息。
如果你不会编程，你会考虑用这个简单的工具去提效？
就算你考虑到能用工具提效，你能快速准确的把自己的需求提出来并找到人帮忙实现？
就算实现了，碰到一些小的体验问题你能总是不断找人帮忙优化？
最后再总结下我的结论。
做测试要不要学编程？我的答案是，要，会编程的测试可以往业务线的测试开发方向努力。
我不会编程能不能做测试？我的答案是，能，不会编程的测试可以继续在业务专家方向深耕。
以上，你会编程不？目前什么水平？自己团队小伙伴的编程技术都什么水平？你认为做测试到底要不要学编程呢？欢迎留言和我讨论。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
