在代码签入之前运行测试

很久没有写文章,看着每天仅有的可怜的访问量,实在觉得对不起读者,决定再写点什么吧。

测试工程师应该做什么?如何体现测试工程师的价值?类似的问题如果放到一些测试会议或者沙龙上讨论,估计一定很热闹。每个人心中都有自己的认识和答案。我个人理解的较为简单,假如整个团队没有测试,会达得到什么样的一种成就?那假如把测试加进去这个团队,能否帮助大伙提高成就?如果测试是在做正功,那么就是有价值,至于价值多少不容易衡量,如果测试在做负功,那还是自求多福吧。

软件天生就有缺陷(Defect, Bug),缺陷从哪来?缺陷从不平白无故地出现,它总是伴随着功能(Feature)而来,谁创造了功能?随便啦,但是最后通常来是开发工程师动手的,所以大部分时间开发都会负责修bug。一般的流程都是:1. 写了一些功能; 2. 测试;3. 发现一些bug;4. 修bug。如果我们可以加速这个反馈的时间,那么也算是做了正功了。

在网上找到一张很好的图: http://www.jetbrains.com/teamcity/features/delayed_commit.html 很好的解释了怎么样在真正提交代码之前运行测试。至于如何做,基本上每个代码管理工具都有类似的支持,例如Git的Hook: http://git-scm.com/book/en/Customizing-Git-Git-Hooks, 又例如一个号称更加好的Hook:https://github.com/jish/pre-commit,SVN也行:http://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.pre-commit.html

我只分享一下我自己在使用上的一些经验:

  • 如果你的测试是Flaky的,不要放在pre-commit里面去。一切看起来很没好,但是如果当开发经常在写完一段代码正准备提交的时候,被一个fail的测试挡住了,然后花了半天时间发现不是他的代码有问题而是测试有问题,结果谁都不太爽
  • 不要把大量的end to end测试放在pre-commit里面跑,想一下让你跑10分钟测试才能提交代码,你能不抓狂吗?
  • 要让开发写测试,而不是测试工程师写测试。这样做的好处是开发自己了解测试代码,可以自己修改测试,更新测试,而不需要等测试来做修复。另一方面,产品质量真的不是测试工程师能保证的,大家测才是真的测
  • 不要在刚开始的时候就添加过多的测试,少量的测试总是比较容易跑过并且让大家接受
  • pre-commit测试不是万能,千万不要生搬硬套

测试用例的重用

跟测试工程师打交道最多的可能就是测试用例了,先设计出一些测试用例,然后这些测试用例要经过评审,之后要执行这些测试用例,完了以后还有可能需要对这些测试用例进行更新。测试用例的重用是一个很有必要的活动。那怎么重用呢?很多人可能第一时间想到了一些测试管理工具能帮上忙,例如Quality Center,Test Link;又或者是一些保存测试用例的工具,例如Word,Excel。

不过这些东西真的能帮助我们重用测试用例么?我想未必。测试用例的重用,应该是测试用例里面的设计思想的重用,而不是具体某个测试用例的,因为对于功能测试的测试用例来说,大多数的测试用例都跟某个具体的被测应用有想到大的关联性,例如要测试一个博客编辑器,对于MySpace的博客编辑器和facebook的博客编辑器来说,它们的主要功能是相似的,都有发表博客,编辑博客,修改博客等……但是由于这是两个不同公司的产品,他们的具体功能或者UI是完全不一样的,所以拿到的两套测试用例,也应该是不一样的。如果分别提取出测试用例的核心思想(就是那些可以重用的部分),应该能看到很多的共同点,或许会有这么一条共同的用例思想。
Continue reading “测试用例的重用”

《Software Testing》第二章 – 软件开发过程

软件开发过程,软件就是一件产品,那么这个产品的生产过程是什么呢?在这个过程中都有些什么中间产物呢?

Customer Requirements(客户需求)

Specifications(说明书),说明书是从需求转化而来,定义了产品是怎么样的,能干什么等等

Schedules(进度表)

Software Design Documents(设计文档)书上说的5种,有些也可能只是某文档的一部份而已。我自己见过比较常见的High-Level Design(概要设计), Low-Level(Detail) Design(详细设计)。书上说的数据流图,状态转换图等等,有时候就出现在HLD里面了

Test Documents(测试文档)包括了测试计划,测试用例,问题报告,统计报告等……这里我自己讲讲体会,刚到SPSS实习的时候看文档的时候我看到了Test scrīpt这个名词,一开始我以为是自动化脚本,后发现其实就是Test Case,所以说这些所有名词都可以有其他叫法。

以上就是作为一个测试工程师会经常遇到的文档。
Continue reading “《Software Testing》第二章 – 软件开发过程”