最近在改一个其他公司几年前做的一个信用卡系统,因为年代久远,需求、代码的不全面,导致对同一个问题不断的修改。
需求1:导入大机的打卡文件,文件是一个文本文件,每行是一条记录,根据其中的联名编号找卡种,联名编号只有两种,8位编号或者8个0。如果没有找到卡种则报错退出。(联名编号是信用卡联名组织的一个编号,比如中石油卡,联名组织是中石油)
对卡种表加一个字段保存联名编号,默认值是8个0,然后一条sql解决问题:select * from cardtype where jointlyno = ?
上线后出问题了:运通卡文件无法导入。
调试跟踪后发现,运通卡的打卡文件的联名编号是8个空格,和以前的需求描述不一样,只好修改代码。
得到的需求是--
需求2:如果是8个空格的肯定是运通卡
于是代码变成了先判断jointlyno是否是8个空格,如果是则直接返回全部的运通卡卡种,不是才是以前的那条sql
上线后又出问题了,有一个文件导入报错,没有说明什么卡等具体细节。
只好把那个文件拿过来调试跟踪,发现是有两个卡种比较怪异,他们的联名编号是10013xxx,3个x表示可以随意变化,因为这个是学生卡,3个x表示的是学校编号。问题就出现在这里,打卡文件里面的联名编号是确定的,比如是10013001,但是卡种表里面的却是10013xxx,所以按照那条sql 返回的记录是空。
看来只好继续改程序,变成了再加一个判断,如果联名编号前五位是10013的则不管后面3位是什么,判断前五位即可。即select * from cardtype where substr(jointlyno,1,5)= ? ,这个 ?是 jointlyNo.subString(0,5)。
这里出现一个
需求3:如果联名编号前五位是10013的则不管后面3位是什么,判断前五位即可
这么一个简单的问题为什么需要反反复复的修改呢?能否避免反复修改?如果无法避免,如果有效快速地应对这些修改?
这个案例很显然地原因就是客户对需求理解的不全面,以致于他自己在不断完善自己的需求,而代码也跟着需求在修改,这个修改是无法避免的,如果无法反抗,按照敏捷的做法那就拥抱变化吧,问题是怎么拥抱?我觉得需要用完备的测试来细化对需求的理解。
对于需求1,需要测试三种情况,1) 00000000 2) 正确的联名编号 3)错误的联名编号
8个空格就是第三种情况,10013001也是第三种情况。 但是这种情况都是在需求1中被客户声明说不会出现的情况,恰恰变化就出在这边。需求的变化是把几个错误的编号变成了正确的编号,这种完全相反的变化完全无法预料的。
需求2出现后 需要增加 一个 8个空格的测试,非8个空格的测试落入刚才3个测试中。
需求3出现后 需要增加 1)10013001的测试,2)10013888(假设10013888这个联名编号存在,而且对应的卡种不是学生卡) 3)10013999(10013999是一个不存在的联名编号)
如果第2、3两个测试的情况发生,那现在的代码就有bug。但是现在需求是10013开头的联名编号肯定对应的学生卡,这两个杞人忧天的测试需要吗?
很简单的一个问题,但是要写这么多的测试,每个case要写完备的测试真不是一件简单的事情,不知道有什么成套的测试写法。而且这些测试带来的作用仅仅是对需求的细化理解,并不能对代码的修改产生多大的帮助。这些测试如果用图来表达其实也不错,为何一定需要这么完备的单元测试代码呢?
分享到:
相关推荐
什么是单元测试?如何做好单元测试? 单元测试是指,对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作,这里的最小可测试单元通常是指函数或者类。 单元测试都是以自动化的方式执行...
70、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。 21 71、测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的? 22 72、您所熟悉的测试用例...
《有效的单元测试》是一本关于单元测试的专著,由资深敏捷技术实践专家撰写,不仅系统且深入地阐释了单元测试用于软件设计的工具、方法、原则和最佳实践,而且对各种测试常见问题进行了深入分析,包含大量实践案例,...
很适合测试初学者,希望能给大家带来帮助。本课件为PPT格式,内容充实,简单易懂。
单元测试 今天的前端夜点心我们来聊聊在项目中单元测试应该测些什么? 以国内互联网的开发节奏,在前端业务项目中全面覆盖单元测试有时显得不太可行,主要是因为以下这些绊脚石: UI交互复杂,路径难以覆盖全面 ...
单元测试-理论篇[1]软件测试测试是软件开发的重要环节之一。按照软件开发的过程测试可分为:单元测试...单元测试能给我们带来的好处。之后我们将介绍单元测试的范畴,最后将讨论很多朋友不写单元测试的借口。希望本文能
软件测试PeterRitchie最近开始担心他认为很不妙的趋势,即开发者为了坚持TDD与BDD而无法写好单元测试。特别地,他认为对“交互测试”的顶礼膜拜,最终带来的后果是不完整的单元测试;测试无法证明某个单元(对象)能在...
javascript是一门动态类型语言,这给她带来了很强的表现能力,但同时也使编译器几乎不能给开发者提供任何帮助。因为这个原因,我们感受到编写任何javascript代码都必须有一套强大完整的测试。angular拥有许多功能,...
单元测试------理论篇[1]单元测试代码测试是软件开发的重要环节之一。按照软件开发的过程测试可分为:单元测试、集成...单元测试能给我们带来的好处。之后我们将介绍单元测试的范畴,最后将讨论很多朋友不写单元测试
本文阐述了执行单元测试的方法、优点和难点,然后描述了C++Test任何能够给C/C++开发人员带来巨大的好处。什么是单元测试?我们对单元测试的定义是测试应用中最小的单元,如C/C++中的一个类。C/C++单元测试的目的是...
即使不赞成极限编程(eXtremeProgramming,XP)或者其他敏捷方法能够带来好处,单元测试也应该成为你的软件开发生命周期中的一个基础实践。从概念上说,持久层可以分为3层,而iBATIS使得对这些不同的层进行单元测试...
Lurkerbelow在公司里是唯一执行单元测试的一名开发者,他深知单元测试带来的好处,也积极提倡单元测试。他甚至与公司的管理层人员、开发者都讨论过单元测试,但却无人对此感兴趣。为了与开发人员形成一条战线,...
博主最近在接触一些Android单元测试方面的工作,发现自己并没有体会到大多数文章所宣传的“单元测试会带来工作效率的巨大提升”之类的诸多好处,于是本着批判与自我批判的精神对 博主最近在接触一些Android单元测试...
任何软件在开发过程中都会留下缺陷,带有缺陷的软件产品如果提交出去,可能会给公司带来不可估量的损失,我们必须在客户之前发现尽可能多的问题,从而保障客户满意。而发现问题的这个过程称之为测试。 问题二:简述...
然而单元测试的编写也不是一件容易的事情,除非使用TDD方式,否则编写出容易测试的代码不但对开发人员的设计编码要求很高,而且代码中的各种依赖也常常为单元测试带来无穷无尽的障碍。令人欣慰的是开源社区各种优秀...
VSTS开发版不仅注重为开发者带来强大方面的功能,同时也注重于开发者和团队之间的协作,每一个功能几乎都可以于TeamFoundation进行无缝结合,主要体现在以下几个方面:代码度量单元测试代码分析团队协作下面我们会...
主要内容如下:单元测试的目的以及测试内容Android中的单元测试分类JUnit注解本地单元测试仪器化单元测试常用的单元测试开源库实践经验其他一、单元测试的目的以及测试内容为什么要进行单元测试?提高稳定性,能够...
测试目标: 确保“测试需求”中对应的所有工作版本的内部单元组合到一起后能够按照设计的意图协作运行,接口的调用正确。 技术: 重用为系统测试准备的测试用例、 分析测试用例对接口的覆盖情况,对没有覆盖的接口...
公司现在对单元测试越发的看重,这对减少上线之后bug的减少会带来很好的帮助,在笔者就职的公司里,在编写代码阶段,开发人员需要做如下一些事情 公司现在对单元测试越发的看重,这对减少上线之后bug的减少会带来...
这样的架构会给测试驱动开发和单元测试带来一些麻烦。这篇文章是运用MRUnit,Mockito和PowerMock的真实范例。我会介绍1.使用MRUnit来编写HadoopMapReduce应用程序的JUnit测试2.使用PowerMock和Mockito模拟静态方法3....