分析：BUG如何越写越少

我是谁？我为什么写这个文章？

我是一名java程序员，大概有4年经验了，为什么写这个文章，因为我也是深深的喜欢着不自测所带来的欢喜，毕竟反馈（报BUG）是写程序最不爽，也可能是最爽（因为有反馈）的事情之一。可是这毕竟是个不好的习惯，所以想细细分析一下，顺便看看能不能改掉它。

程序员写完功能一堆BUG？

我个人讨论这个问题的时候，认为我们写程序的时候有三种性格混合其中。第一是写程序的自大，第二是写程序的自信，第三是写程序的自卑。这三类性格深深的影响着我们整个编写软件的行为，所以我想讨论份这三类来讨论 “写功能为什么一堆BUG”

写程序的自大，你写程序的时候是否有这些想法？

需求写的我都记住了，直接写代码
外部系统依赖的情况我都记住了，直接写代码。
系统设计人员写的我都能想到啊，直接写代码吧
写完代码，直接扔给测试。
测试一堆BUG就来了。。
改代码的时候粗心大意多加了一个列，少加一个列

为什么会有这些想法？这些想法对吗？

点题了，因为自大。这种刚毕业的程序员尤为明显。因为是写业务代码，大部分都是CURD，以前写的程序也没接受过用户的测试，没有熟知软件开发的生命流程是贯彻在整个软件开发的过程中：需求分析，系统分析，系统设计，开发，测试，发布。

这些想法对吗？
职场是一个能者居上的职场，尤其是在技术界，如果你犯的错误越少，说明你当前的职位代表的能力已经足够了，老板才能放心把更多的任务交给你。

试问，如果一个BUG最多的人，他说他能胜任更高级的工作，他可以做到吗？老板也不太愿意相信吧。所以，要尽可能的减少错误。

如何更正？

如何更正将在 讨论写程序的自信里写。

写程序的自卑，你是否有过这些想法？

我一定要遍历完所有的情况才开始写代码。
写接口要遍历完所有接口的参数空与非空的情况。

这些想法对吗？

要知道，程序是必然会出错的。而且讨论所有参数空与非空的情况，那么只要一个方法的参数列表有3个，那么就得讨论 3! =6个测试用例 ,明显大于3个参数的方法是更多的测试用例。

所以可以知道这个问题：
要尽可能的测试完整是不可能的。

我们要求讨论的所有程序的错误，都得基于某个正常思考的用户能操作的场景。注意什么是低概率（也就是用户闲的蛋疼）：用户不停刷新当前页面，用户不停地退出登陆，登陆退出（闲的蛋疼的），但注意：用户因为等待不了，所以刷新当前页面，不是低概率事件。这是正常思考的用户能操作的场景，也属于用例。

如何更正？

如何更正讲在讨论写程序的自信里写

写程序的自信，你是否有过这些想法？

• 程序是必然会出错的，我的目的只是尽可能减少明显的错误。
  VS

我一定要遍历完所有的情况才开始写代码。
写接口要遍历完所有接口的参数空与非空的情况。

• 人的大脑记忆4个名次都会记错，记忆2个测试用例已经很吃力了。那尝试先写在草稿纸梳理逻辑？
• 再次重复强调职场是一个能者居上的职场，尤其是在技术界，如果你犯的错误越少，说明你当前的职位代表的能力已经足够了，老板才能放心把更多的任务交给你
• 所以应该把在大脑里写逻辑的顺序，交给在纸上写逻辑
  VS

需求写的我都记住了，直接写代码
外部系统依赖的情况我都记住了，直接写代码。
系统设计人员写的我都能想到啊，直接写代码吧
写完代码，直接扔给测试。
测试一堆BUG就来了。。
改代码的时候粗心大意多加了一个列，少加一个列

那么问题来了。

怎么样用草稿纸梳理逻辑？

无论你的工时是否有限，在执行代码开发之前，个人认为都要尽可能的遵循下面步骤

很多牛人都说过测试驱动开发。这是一个好方法，但大部分书籍里都是写一个教用代码写一个单元测试，然后写一大堆blabla，这些对于web开发不太友好

毕竟：

明明点点点就能完成的操作，为什么要靠写代码来完成，明显是增大工作量？

很多人说测试驱动开发，用代码写测试，这是为了回归测试，可是如果是遗留系统的话，这个方法应用起来还是实在是太困难了。尤其是小公司的敏捷开发。
今天想说的，是类似这个思想的另一个实施。写测试用例再开发

利用好草稿纸，写测试用例再开发

为什么要使用草稿纸，不在电脑上直接画图？
草稿纸有这个优势：

1. 自由（你想写什么就写什么），尽可能用铅笔与橡皮擦
2. 专注（你在纸上写一个问题，那么就特别专注思考一个问题）
3. 电脑画图你还得学习他的画图软件，而且经常因为线条问题让自己很烦恼。

但问题是，按什么逻辑顺序来写用例呢？

首先。对于有界面的：

界面功能点分析–>权限（什么角色登陆进来能看到什么，也可以画用例图）—> 然后功能点分类（按钮，表单，分页，输入框，用例的功能）–>默认值(输入框默认值)—>布局对不对的上图。

使用测试的因果图（场景）—>等价类划分–>边界值–>逻辑覆盖 来完成整个开发前的准备工作

第一步：开始思考需求的场景（在测试里其实是因果图的思想），再考虑输入范围取值（个数，输入值的集合，必须是）

举例：场景：当当 --> 我的订单–>登陆–>跳转到我的订单–>点击退款

前提：用户已经登陆，已有订单
操作边界：
因：用户退出登陆。
因：（输入）点击退款
二阶因：（因为前面的因，可能导致的二阶推论）暂无
果：（输出）款项无法退回，款项退回

第二步：按照场景分类 ，编写输入数据，开始分析他的边界条件来设计用例

该例子没边界条件的例子，后面再想着补充

制作一个订单金额为发货中，运送中状态的输入数据

第三步：画出这个表格
开始根据第一和第二步的情况来制作第三步的表格

输入条件	有效等价类	无效等价类
点击退款	订单为发货中，订单为运送中	无

个人理解这个用例中，无效等价类是无的，因为第一，没有范围限制，第二没有阻止他进入下一步程序判断的。

第四步：画流程图，输入数据写在旁边，来完成逻辑覆盖

输入条件	有效等价类	无效等价类
点击退款	订单为发货中，订单为运送中，待发货中	无

制作发货中，运送中订单

clickButton->

logger.log(订单号为xxx,进入订单判断);
if ( 订单状态==未派送){
   logger.log(未派送，执行退货逻辑);
   执行退货逻辑
}else{
    logger.log(不能退货，但可拒收);
   返回提醒不能退货，但能拒收
}

这样做有什么好处？

优点，BUG是无法避免的，而测试每次报一个BUG，都是你的思维漏洞，这些都是可以用错题集来总结给你自己来更好的设计下一次的用例。

可惜写的自信还是无法避免

工时，需求变更，依赖外部系统，技术外债（旧系统的业务不清晰，在旧系统的业务上进行开发）。这些都无可避免增加我们放弃使用草稿纸，进行直接编码。

工时问题

没时间写测试用例，时间紧迫，直接开发吧。然而项目总监曾经统计过一个图表。在未发布之前，修改一个BUG需求经历：测试把BUG上报到 禅道系统，然后对开发进行沟通交流，开发了解复现步骤，开发模拟测试环境，然后进行BUG的改，改BUG提交给开发主管，主管给测试或帮测试更新到测试环境，测试验证BUG，验证BUG并关闭。这个过程大约至少会有1小时，多则5小时。所以大部分时间都是改一批BUG然后进行提交。

线上BUG更复杂，因为加多了一个外部系统，而且也不能模拟简单的模拟线上环境（因为数据库不能直接拿线上的）。所以需要进行更多的逻辑推理与判断，所以保守估计这个过程至少会有3小时，多则以天估算。

所以如果不尽可能的减少BUG，导致的时间浪费可能比直接写代码更多。

需求变更，需求遗漏问题

这个是老生常谈了。某个需求有问题，然而却没发现。或者写代码写到一半，忽然需求变更就来了。然而很多开发也是不按照草稿的方法来，导致问题越来越多。
这时候草稿纸上讨论的是

这个需求变更对我的草稿纸上的整个流程，造成了什么影响？用橡皮画出来，并且进行修正。

依赖外部系统问题

不可否认外部系统都是黑箱子，但是如果你依赖外部系统，先确定你是输入还是输出方，你需要确定的是他的用户请求图像。就类似于开发的原型图（只画出请求接口的表单参数即可），再与他讨论接口的参数可能的情况。这样草稿纸讨论的是：

画出原型图（参数的表单），大家讨论用户可能有什么情况

技术外债问题

如果你是在遗留系统开发，或者是外包接回的系统里开发，你需要花很长一段时间去整理整个系统的逻辑。草稿纸上有如下思路

1.角色有什么？
2.每个角色菜单有什么？
3.菜单下的功能有什么功能
4.界面功能点分析–>权限（什么角色登陆进来能看到什么）—> 然后功能点分类（按钮，表单，分页，输入框）–>默认值(输入框默认值)—>布局对不对的上图

注重使用维护与更新，迭代问题进行解决

我也思考过这个问题，草稿纸上生成的文档，那么下一次需要用上他的时候，该如何利用？
这个是个难题。毕竟给我在草稿纸上写的东西，我也很少把他最终留存在word里，因为二次修改的时候，你又得把他给抄写下来。

但注意：需求的流程图，用例图等，测试用例是能迭代。

你只需要抄写这些图，再继续你的迭代更新即可。