软件测试是为发现错误而执行程序的过程。这其中的错误，即程序中的bug，可以理解为人的错误。

现代的软件已经发展的比较成熟了，编程语言也是多种多样。从最早的BASIC，汇编语言，C，C++，C#，java，python，asp，php等等，都是比较经典的编程语言。每一种编程语言，都是编程思想的精髓。有其适用的场景和经典的算法。

不管何种编程语言，虽然语言本身有优缺点，但是在其既定的语法规则下，是不存在错误的。而代码中的错误，是代码编写者引入的。我们知道每种语言都会存在着各种各样的坑，如各种运算符操作 ，各种数据类型，例如左移操作，与操作，或操作等等，稍不注意便会在使用上带来问题。但是这些问题之所以产生，是因为使用者的使用不当引起的。可以这样说：

编程语言及其规则就在那，不管你用与不用。不用，即不会出现错误 ，用，就有出现错误的可能。

总之，对程序编写者进行分析，有助于我们发现软件中的问题。这似乎即是bug的源头。

在一个软件系统中，测试人员输入了一个边界值，而程序却提示输入的是非法值。究其原因，原来是代码中在判断输入的范围时，将判断边界值的>=写成了>，导致边界值不在被识别，而程序认为这是非法值，就按照流程进行了处理。到了这一层，我们似乎已经很清楚，该问题的原因是代码中判断条件里的>=写成了>,导致程序处理出错。

这样似乎是可以了，但是总感觉还不够。尤其是对那种比较最求完美的人来说，脑子里似乎总是存在着一堆的问题没有被解答：

“这个书写代码的程序员，他为什么把“>=”码成“>”，他当时的思路是什么？”

“是否是他正在写这行代码的时候，他别人突然过来找他讨论问题，他被分了心，敲了一个“>”而忘记了这里是一个“>=”? ”.

“亦或者他根本不知道这个边界值是个应该被支持的合法的输入”；

“亦或是他忘记了(曾经记得或知道)”。

总之，我们需要与这个代码bug的引入者进行交流，才能获知其引入该bug的过程。(这里并不是针对人，只是这样更有助于我们去分析代码中错误存在的场景以及进行软件测试的方向，以更好的发现软件中的问题，保证软件产品的质量)。

但是软件中的问题多种多样，我们不至于对每个问题进行刨根问底，搞清楚程序员为何引入这个bug，即使软件测试人员愿意这样做，程序员估计是无法忍受的，软件测试人员会被当成“找茬者”而不被欢迎。

其实，软件发展这么多年，我们大可不必从这些小问题入手，不妨从大的规律上进行系统的分析。

我们从开始学习编程语言，到一个程序员的岗位进行工作。对于编程的知识和能力是一个积累的过程，这对于任何一项工作任何一个人都是如此。我们可以把编程当作一项技能。这项技能可以拆解为两个方面：

1，编程能力：程序员对于程序设计语言本身的掌握。

2，产品知识：程序员对于要实现的软件产品的理解和掌握程度。

编程能力体现了程序员对于编程语言本身的掌握能力。这个就跟程序员本身有关系了，或者说跟人相关。有的人学习能力较强，短时间内就掌握编程语言的思想以及各种算法，有的人能熟练运用各种编程语言，有的人只会运用其中的某一种。有的人写出的代码比较的规范，细致，严谨，有的人 则不太注重编码细节以及编码的规范，写出的代码总是存在着低级的问题，如果在代码review阶段自己或者别人能检视出这些重大的bug，无疑是庆幸的，否则就需要软件测试人员拦截这些低级且重大的bug，如果软件测试人员由于各种各样的原因遗漏了，那这个重大缺陷就会给最终的使用者带来很大的麻烦，给企业或者公司也会带来更大的损害。

所以，看似简单的编程能力这个因素，其实也是蕴藏着很多问题的。我们可以尝试概括一下：

1)编程人员对代码规范的掌握

2)编程人员的习惯，如粗心，不严谨

3)编程人员对编程算法的掌握

对于第二点，产品知识的掌握，也是同样的道理，如果程序员只对编程语言比较了解，而不知道自己做的软件产品的实现方案原理，设计流程，那么也会出现问题，但这类问题不是因为编码能力不够，而是因为对产品的知识不了解，这就涉及到程序员对于行业的认知和理解了。已经多次提到过 ，现在的软件已经深入到各行各业中，加油站/银行系统/通信系统/电子产品等等，都是需要软件做支撑。所以，处在不同行业中的程序员，也要对这些行业有详细深入的了解，才能保证自己实现的代码的正确性。

在一个大型的商业软件中，一个程序员实现的需求或者功能往往是有限的，只是这个庞大的软件系统中的一部分，或者是其中的一个功能，甚至只是临时借调过来，补充其中的一段代码，然而，如果对整个系统的架构和方案不熟悉，往往会埋进去很多bug。虽然写出的代码从其本身看是没有问题的，但是放到整个系统中，可能被不同的函数分支调用，难免会出现不相匹配的情况，总是会出现各种各样的问题了。

综上，一个程序员，必须要对编程语言本身以及软件产品的系统设计有深入的了解，才能保证其实现代码的正确性。

那么，问题就迎刃而解了。

软件测试人员在进行测试策略制定时，就可以多了一个方向。

例如，例如某个加油站软件系统需要新增一个功能需求，而开发此需求的小王同学，是一个编程大牛，但是他有个短板，由于他刚进入油站行业，并没有油站行业的相关知识，从大学毕业后一直从事的也只是互联网行业，刚转入油站行业的他虽然上手很快，但是对该需求的实现背景以及实现的方案原理，还有很多油站的基本概念，都不是很熟悉，只是他写的代码很规范，对编程也是驾轻就熟。在这种情况下，在测试策略制定中，要重点关注的是该需求功能实现的正确性，尤其是时间较紧张的测试活动中，在覆盖基本的用例之外，更多应该考虑的是该需求的实现以及该需求与其他功能的关联性。

软件测试中，对开发人员本身的了解，有助于我们梳理测试策略的重点方向，以挖掘关键价值的问题，避免产品的关键缺陷遗漏至使用者或客户。

除了以上两点外，其实还有这许许多多方面的影响。因为只要涉及到人的问题 ，总是充满了不确定性。可能某个程序员最近几天因为家庭的琐事心情不好，整天无精打采的，以至于做任何事情都毫无兴趣;也有可能某个程序员刚刚跟相处了2年的女朋友分手了，整天魂不守舍，脑子里面尽是感情的事情，以至于本来时一个非常严谨细致的人，码写代码时却成了粗枝大叶，各种编程规范类问题层出不穷。

这种种的不确定性，给本来就已经充满了不确定性的软件测试工作，增加了又一层的不确定。但是我们应该乐观一些，这项由不确定的不确定叠加起来的工作，一定是充满了创造性。

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。