程序员如何减少bug？

程序员(开发)如何减少bug？

程序员要多跟产品交流

• 需求文档不清晰的地方，要及时跟产品确认。切忌独自揣测，随意开发。
• 在跟产品沟通时，要有自己的想法，描述问题，并给出解决方案，不要一味地抛出问题。
• 需求变更，必须录入需求系统。没有记录，需求变更也会被误认为是bug。

程序员多看error日志，能减少bug

开发多看error日志，能够减少bug。测试有时发现不了一些代码类的异常bug，比如空指针、数组越界之类的异常。
开发不仅要看日志，最好还要多看测试环境的error日志，多看生产环境的error日志。

做好单元测试，提高单元测试的覆盖率

做好单元测试，保证各个方法，各个接口正确运行。
提高单元测试的覆盖率，有些bug就是因为走到了特殊的分支才导致的，如果覆盖了对应的分支就能提前发现问题。

冒烟测试

开发人员都知道要自测，但是大多数都不知道如何有效地自测。很多程序员都是把代码更新到测试环境后，随手点几下，想到哪就点到哪。
有些甚至只在开发环境自测，没有到测试环境去自测。这样的自测明显是不够严谨的，还是会有不少bug，最好是在测试环境对着测试用例自测。冒烟测试，能够有效地减少bug。
冒烟测试，可以是一些主流程的测试用例。
冒烟的测试用例，没有必要太详细，太详细了会浪费很多时间。
测试同学写的测试用例，绝对是比开发人员乱点更加严谨的，覆盖率也会更广。
如果公司的平台，能够做到自动化冒烟，那就更好了。

冒烟测试的流程

• 冒烟测试最好在测试环境进行
  如果在开发环境冒烟，到了测试环境，还是有可能会有问题，或许会少了这个配置，少了哪个sql脚本。

• 开发评估工作量时，要多留1天的时间自测
  对着测试用例自测，是会比普通的自测费时间的。毕竟测试用例的内容会比较多。一般，主流程跑通就可以了。

• 必须评审测试用例
  测试用例必须评审。评审测试用例，能够加深开发和测试对需求的理解，让开发和测试对需求的理解与产品同学更加接近。三方达成共识，是最好的。
  评审测试用例的过程中，开发会对需求的理解更加深入，能减少踩坑，避免方向错误，做了不必要的或者错误的需求。

• 产品最好参与评审测试用例
  产品经理不参与评审，那么只有开发与测试达成共识，还是有可能偏离产品规划的需求。

• 测试人员最好在提测的前两天评审测试用例
  如果是在提测的前一天甚至当天评审，那开发人员就没有足够的时间自测了。
  评审过程中发现开发、测试、产品三方的分歧越大，开发需要修改的东西越多，花费的时间也越多。

• 测试用例，必须分优先级，比如P1,P2,P3
  如果所有的测试用例，都要开发去冒烟，那开发的时间就会非常紧张。
  可以选择优先级为P1的用例，进行冒烟。

• 开发人员要保持耐心
  冒烟测试，对着测试用例自测，实际上也是不小的工作量，这个过程会有一点无聊，需要保持耐心。
  如果时间确实不多，至少主要的分支得自测过一遍。

冒烟测试的其他客观条件

• 团队必须要求测试写测试用例。。
  这个是一切的基础，如果测试不用写测试用例，那后续的工作无法展开。

• 团队不应该考核测试提出的bug数量
  如果考核测试提出了多少个bug，那么bug的数量关系着测试同学的利益。
  测试会反复地跟开发人员拉扯，有时会为了一个问题究竟是不是bug而争吵半天，这样是没有意义的。
  测试为了绩效，也是不会心甘情愿地写好测试用例的。

• 团队减少紧急需求，也尽量不要倒排需求。

• 这种做法虽然能减少bug，但是比较耗费时间，对程序员的技术成长并没什么帮助。如果不是特别重要的项目，不太建议这么做。