对于测试人员而言,TDD意味着什么?

jopen 8年前

        英文原文:What does TDD mean for me, the Tester?

        作为一名测试人员,似乎测试驱动开发(TDD)技术与自己没有太大关系,但是在实际工作中,我却发现 TDD 对测试环节也是有很好指导作用的。

        作为极限编程(XP)所倡导的方式,TDD 中的角色配置如下:

  • 程序员
  • 开发人员
  • 用户

        我对 TDD 的看法

对于测试人员而言,TDD意味着什么?

        除了要掌握 TDD 中提出的“红-绿-重构”环,我认为能否写出一个有效的测试缺陷是关键的一步,而能否弄清测试缺陷是什么更是关键中的关键。

        较少与写代码打交道的测试人员该如何参与 TDD 环节

        很多时候,人们认为程序员关注的是代码设计,测试员关注的是软件行为。但是这两者之间的界限其实是不需要太过明确的,他们双方可以形成互补。根 据软件测试大师 James Bach 的定义,测试人员有两个主要的职责:可控制性和可监控性。比方说:系统能否在我们设好的状态下正常运作以及我们该如何进行监控?程序能否在设定的关键点上 按时执行以及该如何进行记录?

        在谈及程序员的角色时,我习惯用时序图来描述系统中有关请求和响应的部分。这样会让程序员和测试员都能明白系统在不同状态下的走向,从而明白什么样的测试才是需要的。测试人员与程序员应该互相合作,避免重复或无效的测试。

        这是一个典型的 Web 程序时序图:

对于测试人员而言,TDD意味着什么?

        设计一个测试缺陷

        一般情况下,在 TDD 环中,程序员的工作始于代码,同时等候着单元测试那边的反馈。

        我会琢磨该选择哪种测试方法和什么样的边界测试用例,以及列出测试中可能遇到的情况。由于软件设计工作是渐进明细的,有不少问题会在这个过程中 产生。例如:需要就某个特殊情况对单元测试做出修改,或是边界用例需要代码做出变更。因此要设计好测试用例,尽早把潜在缺陷暴露出来。

        多沟通多测试

        程序员会与我就测试范围和时间进行沟通,然后我们会一起把代码以及测试计划粗略过一遍,商讨好具体的测试范围与标准,然后开展测试工作。

        我会尝试测试几个预先设计好的边缘用例和突发用例,以检查其有效性。这样做的好处是能有机会向客户展示软件,看是否符合他们的期望。一般情况下,这个双向的沟通交流过程需要几个小时。

        重构

        程序员继续完善代码,测试人员继续完成测试任务。以搭档的形式与程序员一起工作,可以更好地理解程序的流程走向,清楚什么测试才是需要的,以及找出程序的灰色地带和错误多发位置,进行改进修正。通过透明坦诚的双向沟通,会减少很多误会和无用功。

        闭环

        到了收尾阶段,我觉得这个工作与修补衣服差不多的。缝补的针线越细密,出差错的几率越少。

        要做软件功能性方面的审查,参与方不能仅仅是测试人员,还得与该软件相关联的人员或部门参与,如:运营部,市场部等。这样一来,在最后的项目结束会议中,多方可以各抒己见,从而最终评定该产品是否值得推出和推广。

        写在最后

        依据上述步骤,我在 TDD 环中加入了测试人员工作环节,形成 TDD-测试人员环,请看下图:

对于测试人员而言,TDD意味着什么?

        结合自己的实际情况,我还有以下几点提示,可以让 TDD-测试人员环走得更顺:

        1.   尝试情景驱动测试

        当刚从一个瀑布开发团队转入极限编程团队时,我经历了一段过渡阵痛期。而情景驱动测试的出现,帮助我最终顺利完成了转换。

        2.   做个细心的观察者

        程序员一般都会为自己的作品感到骄傲。我们不妨多花时间去了解身边的程序员,看看他们做了什么,怎么做的,又是如何得到今天的成就的。天道酬勤,你会有意想不到的收获。

        3.   干一行,精一行。

        我们不能仅仅关注自己的测试工作,所谓知己知彼,百战不殆;我们需要深入了解自己公司的产品,看看这个软件帮助客户解决了什么问题或还没有解决什么问题,将来会如何发展。只有凡事占得先机,我们在测试这条路上才会走得更好更远。

来自: CSDN