1、测试驱动开发,用例指导结果,数据记录变化

  “测试驱动开发”(TDD)是一个比较新的概念,在网上可以看到很多介绍文章,它主要讨论如何让开发的代码更奏效(Work)更洁净(Clean),“测试驱动开发的基本思想是在开发功能代码之前,先编写测试代码”。可以看到,TDD是建立在“代码”级别的驱动,但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

  首先我们需要纠正一个态度,很多人认为黑盒测试的技术含量不高,可思考可拓展的内容不多,主要的工作是用鼠标在那里瞎点,于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80%以上都是黑盒测试发现的,手工操作软件仍是目前检验软件质量有效的一种方法。

  如何在黑盒测试中做到测试驱动开发?我认为可以从用例级别做起,以业务用例指导过程和结果。

  开发人员通常比较关注技术,对于业务上的理解容易忽视并出现偏差,而需求文档又不会很明确的指出应该实现怎样的结果,这使得从业务到功能出现一个“阅读上的障碍”,如果后程序错误了还需返工,这样耗费的人力物力非常大了。使用业务用例驱动开发,是一个比较好的方法,同样这也需要运用测试中的各种方法,列举出业务流程里数据的等价类和边界值。

  业务用例的构造要先于程序实现,与需求和开发人员沟通一致,并以此作为一个基准,保证程序实现不会错,还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面,但一定要有数据的支持。这是测试主导变化的另一点“数据记录变化”。

  我们不仅要应对变化,还要记录变化,使测试用例成为对程序持续性的监控,数据可以作为基本、简单的支持。当一个业务很复杂时可以拆分成段(业务段与程序中以窗体或页面的划分是不一样的),使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享,理想的情况是建立一个“数据库”,每个业务用例都从“数据库”中取得输入数据和预期结果,这个数据只是针对业务入口和出口的,当程序内部设计变更时,保留的数据不会因此而作废。举一个例子,例如我的程序要从某种文件中读取数据并计算结果,一段时间后程序内部字段增加了,如果是以保存的文件附件方式提供数据,则现在程序很可能打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入,而不关心程序内部结构。

  再进一步的话“数据库”开始涉及到程序内部的接口了,这需要开发人员的配合。

  2、为用例标明时间(版本)和优先级

  为测试用例标明时间或版本可以起到一种基准的作用,标明项目进度过程中的每一个阶段,使用例直接和需求基线、软件版本对应。同样这需要规范流程,也是对变更的一种确认和控制。或者可以为用例增加一个状态,指明这个用例目前是否与程序冲突,当程序变更时改变用例的状态,并更新用例版本。

  为测试用例标明优先级可以指出软件的测试重点、用例编写的重点,减少用例回归的时间,增加重点用例执行的次数,帮助项目组新人尽快了解需求,在自动化测试的初期也可以参考这个优先级录制脚本。

  3、功能用例与业务用例分开组织

  将功能用例与业务用例分开组织,按照不同关注点列举执行路径。业务用例应在开发前或同期编写,帮助测试人员和开发人员明确业务,了解正确流程和错误流程。功能用例更依赖于程序界面的描述,但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug,也许与业务无关,但用户往往很容易这样操作(例如登录名,你是否考虑到很长的名字,或者用户的键盘有问题,总是敲入n多空格在里面,这与业务无关,但程序将会怎样处理?)。

  4、审核用例,结对编写

  测试组长或经理对用例进行审核可以做到用例的补充和校对,但一般情况下是很难做到的,我们可以采用另一种方法,是结对编写测试用例(前提是你有两个以上的测试人员),内部审核。

  测试用例不是一个人编写一个人执行,它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”,同时也能拓展思维,加强测试重点的确认,小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理,提高组员的参与积极性。

  四、发展

  上面的这些解决方法只是一种建议,具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的,传统的黑盒测试并不是毫无新意,测试工作怎样适合我们而发展,将给予我们更多的思考。