程序员如何减少开发中的 Bug?

周会上同事抛出了一个问题 , 程序员如何减少开发中的 Bug?很有意思的一个话题 , 本篇文章我们来进行探讨与总结 。
一、概述
爱因斯坦曾经说过:「如果给我一个小时解答一道决定我生死的问题 , 我会花55分钟来弄清楚这道题到底是在问什么 。一旦清楚了它在问什么 , 剩下的5分钟足够解答这个问题 。」
虽然我们软件开发过程不会面临生死的抉择 , 但是却直接影响着用户的使用感受  , 决定着产品的走向 。所以程序员如何减少开发中的 Bug , 既反映了代码质量  , 也反映了个人综合能力 。
那么我们该如何有效的减少开发中的 Bug 呢?
我觉得应该从两方面说起:业务层和代码层 。
二、业务层
软件开发过程我们就不细说了 , 直接来看最重要的几个节点:
1.需求讨论阶段
一定要明确需求 , 测试 , 开发 , 产品三方务必达成一致  。前期如果存在没有明确的问题 , 那么后期就会造成无效返工和不必要的争执 , 这在日常开发尤为常见 。
所以 , 软件开发前期 , 我们都会进行「评审 , 反讲 , 评估」三个阶段 。
2.开发完成阶段
开发完成后 , 程序员首先要完成「自测」 , 也就是软件开发中的「冒烟测试」 , 确保主流程无误 。否则 , 在开发工程师提交代码后 , 测试工程师步履维艰 , 无法有效开展测试 , 会造成极大的资源浪费 。
【程序员如何减少开发中的 Bug?】更规范的流程需要测试工程师在需求明确之后写出「测试用例」 , 开发工程师在完成开发后 , 自行对照「测试用例」完成初步验证 , 之后就可以代码提测了 。
这么做的好处就是既保证了「高质量的代码交付」 , 同时减少了测试工程师的工作量 , 我们何乐而不为呢?
3.提测
自测和提测有什么区别呢 , 从软件开发过程来看 , 其实开发工程师和测试工程师其实完成了不同阶段的测试:
开发工程师「白盒测试」:
是指实际运行被测程序 , 通过程序的源代码进行测试而不使用用户界面  。这种类型的测试需要从代码句法发现内部代码在算法、溢出、路径和条件等方面的缺点或者错误 , 进而加以修正 。
白盒测试需要从代码句法发现内部代码在算法 , 溢出 , 路径 , 条件等等中的缺点或者错误 , 进而加以修正 。
测试工程师实际进行的是「黑盒测试」 。那么什么是「黑盒测试」呢?
黑盒测试也称功能测试 , 它是通过测试来检测每个功能是否都能正常使用 。在测试中 , 把程序看作一个不能打开的黑盒子 , 在完全不考虑程序内部结构和内部特性的情况下 , 在程序接口进行测试。
它只检查程序功能是否按照需求规格说明书的规定正常使用 , 程序是否能适当地接收输入数据而产生正确的输出信息 。黑盒测试着眼于程序外部结构 , 不考虑内部逻辑结构 , 主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度 , 从输入数据与输出数据的对应关系出发进行测试的 。
很明显 , 如果外部特性本身设计有问题或规格说明的规定有误 , 用黑盒测试方法是发现不了的 。黑盒测试法注重于测试软件的功能需求 , 主要试图发现下列几类错误 。

  • 功能不正确或遗漏;
  • 界面错误;
  • 输入和输出错误;
  • 数据库访问错误;
  • 性能错误;
  • 初始化和终止错误等;
更多细节请查看文章:


    推荐阅读