还在篮子里

TDS(2)边界测试 · 语雀

TDS(2)边界测试

前文提到,关于 测试驱动学习的概念。本文进一步扩散,讨论 TDS 关于边界的掌控。

首先我们讨论一下测试驱动开发的说法。

在中国,成为测试的要求较开发低,这造成了一些方法论如测试驱动开发水土不服。本来测试更能描述需求,意味着测试的进度远超开发的进度(不一定是代码量,而是和某一版本最终形态的距离),而在我们这里则相反。驱动,可以说是拉着走,也可以说是推着走。这要求不同地方的团队不要直接不顾敏捷开发方法论的前提条件就照虎画皮。考虑到自身的人员素质等情况再进行实施更靠谱。

测试驱动学习里的边界测试,是我从做业务中想到的道理。众所周知,做业务带来的提升并不是非常有价值,怎样让自己做业务变得不可或缺呢?就是深入了解你的业务,了解到你们周围的人知道,关于业务,业务代码,业务逻辑方面的问题问你准能解决。这要求的苦功比较多,需要投入的精力很多,学习上的收益相对于本身做业务也不是增加了很多,不过在学习之外的价值却变得不可或缺了。(时间是最有价值的东西,它即使用来换一些重复性的工作也能提供之外的价值。)

TDS 中的边界测试即是:在正常的开发工作中,你可以知道哪些工具有什么样的作用,当然,别人也知道。具体可能最大的差别是我没有做过而你做过,看起来你的经验更高。然而这个优势并不大,同时你学习到的,或者说从这个工具中得到的有效积累并不多。

而边界测试,意味着你深入了某一个工具,某一个功能,连他不可知的(仅仅会用的人不知道)部分你也有所尝试。这样这个工具才真正收入了你的工具箱中,而不是你只是可以使用哪个工具的一个人。

我们学习工具的时候,会被系统或者主动系统的学习工具的作用,常用功能和使用边界,意味着如果我们肯花功夫和时间学习一项成熟的工具,很快就能熟练应用掌握。

当然,你能,别人也能。

那么对于不是成熟的工具呢?对于你要做一件事但是这个工具没有相关的指导呢(当然逻辑上大家认为能做)。

边界测试的意味在于,我首要去探究和深入研究,去测试工具的边界,对于服务类的工具,可以做压力测试。主要是探寻什么呢?探索的就是非正常使用的情况下,会出现什么样的问题。如此,你对于一个工具的使用就能得心应手,不会出现选择一个工具却发现不够用或者冲突的情况。

正常的使用,开发者看文档能够很快的投入,但是针对于他们的需求,他们的特殊环境,这就不是正常使用能解决的了,或者说涉及到了这个工具的专业使用。而边界测试,让你成为的是这个工具的专家(某一个功能的)你能够很快知道在不同环境下使用的可行性和瓶颈。

我们论述一下上述两个情况的主动性区别,一个是,首先我需要解决什么问题,我知道了什么工具能解决我的问题,我找到一个会使用这个工具的人来解决(这个我代指)另一个是,首先我知道了我用做到什么,然后我找到了能做这个的人,他使用什么样的工具是他的选择(这个他就是熟练掌握工具的人)主体从工具变成了人,虽然对于需要解决问题的人来说是同样的结果,但是对执行人来说就不同了。

最后我们讨论一下边界测试和普通学习谁先谁后的问题。

我首先认为,边界测试优先,不过在测试之前,可以花极少的时间遍历一下普通的学习了解大概的作用范围和边界,然后针对你需要的目标直接进行测试。

因为我们要做的是有效地积累。

来源: TDS(2)边界测试 · 语雀

发表评论

电子邮件地址不会被公开。 必填项已用*标注