文章目录
我是谁?我为什么写这个文章?
我是一名java程序员,大概有4年经验了,为什么写这个文章,因为我也是深深的喜欢着不自测所带来的欢喜,毕竟反馈(报BUG)是写程序最不爽,也可能是最爽(因为有反馈)的事情之一。可是这毕竟是个不好的习惯,所以想细细分析一下,顺便看看能不能改掉它。
程序员写完功能一堆BUG?
我个人讨论这个问题的时候,认为我们写程序的时候有三种性格混合其中。第一是写程序的自大,第二是写程序的自信,第三是写程序的自卑。这三类性格深深的影响着我们整个编写软件的行为,所以我想讨论份这三类来讨论 “写功能为什么一堆BUG”
写程序的自大,你写程序的时候是否有这些想法?
需求写的我都记住了,直接写代码
外部系统依赖的情况我都记住了,直接写代码。
系统设计人员写的我都能想到啊,直接写代码吧
写完代码,直接扔给测试。
测试一堆BUG就来了。。
改代码的时候粗心大意多加了一个列,少加一个列
为什么会有这些想法?这些想法对吗?
点题了,因为自大。这种刚毕业的程序员尤为明显。因为是写业务代码,大部分都是CURD,以前写的程序也没接受过用户的测试,没有熟知软件开发的生命流程是贯彻在整个软件开发的过程中:需求分析,系统分析,系统设计,开发,测试,发布。
这些想法对吗?
职场是一个能者居上的职场,尤其是在技术界,如果你犯的错误越少,说明你当前的职位代表的能力已经足够了,老板才能放心把更多的任务交给你。
试问,如果一个BUG最多的人,他说他能胜任更高级的工作,他可以做到吗?老板也不太愿意相信吧。所以,要尽可能的减少错误。
如何更正?
如何更正将在 讨论写程序的自信里写。
写程序的自卑,你是否有过这些想法?
我一定要遍历完所有的情况才开始写代码。
写接口要遍历完所有接口的参数空与非空的情况。
这些想法对吗?
要知道,程序是必然会出错的。而且讨论所有参数空与非空的情况,那么只要一个方法的参数列表有3个,那么就得讨论 3! =6个测试用例 ,明显大于3个参数的方法是更多的测试用例。
所以可以知道这个问题:
要尽可能的测试完整是不可能的。
我们要求讨论的所有程序的错误,都得基于某个正常思考的用户能操作的场景。注意什么是低概率(也就是用户闲的蛋疼):用户不停刷新当前页面,用户不停地退出登陆,登陆退出(闲的蛋疼的),但注意:用户因为等待不了,所以刷新当前页面,不是低概率事件。这是正常思考的用户能操作的场景,也属于用例。
如何更正?
如何更正讲在讨论写程序的自信里写
写程序的自信,你是否有过这些想法?
- 程序是必然会出错的,我的目的只是尽可能减少明显的错误。
VS
我一定要遍历完所有的情况才开始写代码。
写接口要遍历完所有接口的参数空与非空的情况。
- 人的大脑记忆4个名次都会记错,记忆2个测试用例已经很吃力了。那尝试先写在草稿纸梳理逻辑?
- 再次重复强调职场是一个能者居上的职场,尤其是在技术界,如果你犯的错误越少,说明你当前的职位代表的能力已经足够了,老板才能放心把更多的任务交给你
- 所以应该把在大脑里写逻辑的顺序,交给在纸上写逻辑
VS
需求写的我都记住了,直接写代码
外部系统依赖的情况我都记住了,直接写代码。
系统设计人员写的我都能想到啊,直接写代码吧
写完代码,直接扔给测试。
测试一堆BUG就来了。。
改代码的时候粗心大意多加了一个列,少加一个列
那么问题来了。
怎么样用草稿纸梳理逻辑?
无论你的工时是否有限,在执行代码开发之前,个人认为都要尽可能的遵循下面步骤
很多牛人都说过测试驱动开发。这是一个好方法,但大部分书籍里都是写一个教用代码写一个单元测试,然后写一大堆blabla,这些对于web开发不太友好
毕竟:
明明点点点就能完成的操作,为什么要靠写代码来完成,明显是增大工作量?
很多人说测试驱动开发,用代码写测试,这是为了回归测试,可是如果是遗留系统的话,这个方法应用起来还是实在是太困难了。尤其是小公司的敏捷开发。
今天想说的,是类似这个思想的另一个实施。写测试用例再开发
利用好草稿纸,写测试用例再开发
为什么要使用草稿纸,不在电脑上直接画图?
草稿纸有这个优势:
- 自由(你想写什么就写什么),尽可能用铅笔与橡皮擦
- 专注(你在纸上写一个问题,那么就特别专注思考一个问题)
- 电脑画图你还得学习他的画图软件,而且经常因为线条问题让自己很烦恼。
但问题是,按什么逻辑顺序来写用例呢?
首先。对于有界面的:
界面功能点分析–>权限(什么角色登陆进来能看到什么,也可以画用例图)—> 然后功能点分类(按钮,表单,分页,输入框,用例的功能)–>默认值(输入框默认值)—>布局对不对的上图。
使用测试的因果图(场景)—>等价类划分–>边界值–>逻辑覆盖 来完成整个开发前的准备工作
第一步:开始思考需求的场景(在测试里其实是因果图的思想),再考虑输入范围取值(个数,输入值的集合,必须是)
举例:场景:当当 --> 我的订单–>登陆–>跳转到我的订单–>点击退款
前提:用户已经登陆,已有订单
操作边界:
因:用户退出登陆。
因:(输入)点击退款
二阶因:(因为前面的因,可能导致的二阶推论)暂无
果:(输出)款项无法退回,款项退回
第二步:按照场景分类 ,编写输入数据,开始分析他的边界条件来设计用例
该例子没边界条件的例子,后面再想着补充
制作一个订单金额为发货中,运送中状态的输入数据
第三步:画出这个表格
开始根据第一和第二步的情况来制作第三步的表格
输入条件 | 有效等价类 | 无效等价类 |
---|---|---|
点击退款 | 订单为发货中,订单为运送中 | 无 |
个人理解这个用例中,无效等价类是无的,因为第一,没有范围限制,第二没有阻止他进入下一步程序判断的。
第四步:画流程图,输入数据写在旁边,来完成逻辑覆盖
输入条件 | 有效等价类 | 无效等价类 |
---|---|---|
点击退款 | 订单为发货中,订单为运送中,待发货中 | 无 |
制作发货中,运送中订单
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里,因为二次修改的时候,你又得把他给抄写下来。
但注意:需求的流程图,用例图等,测试用例是能迭代。
你只需要抄写这些图,再继续你的迭代更新即可。