自动化测试领域充满了争议性的话题,这里尝试用 5W1H 法谈谈我现在对自动化测试的看法。

What : 什么是自动化测试?

自动化测试,顾名思义,指的是自动化的软件测试,与传统的人工测试方式相对应。通过在给定情景(测试用例)下,比较软件的输出与期望结果,来判断软件功能是否符合预期。

Why : 为什么要自动化测试?

虽然自动化测试的定义简单明了,但大家对为什么要进行自动化测试莫衷一是,主流的是以下观点之一或组合:

  1. 保证产品质量,减少程序中的 bug;
  2. 避免垃圾代码,不写超出需求的代码;
  3. 护航项目重构,保证程序功能一致;
  4. 进行回溯测试,不犯重复的错误。

上述观点都值得参考借鉴,但不可偏听偏信。设计测试方案时,只有先决定了测试的目的,才能决定测试的结构和内容。

Who : 谁负责写自动化测试?

曾经流行的 “测试工程师” 头衔已渐渐日薄西山。一方面是大家对测试的要求越来越高,不了解业务代码的专职测试工程师并不能很好地独立完成任务;另一方面是常规的人工测试,可以交由团队的其他成员完成。许多互联网公司已经不再招聘专职的测试工程师,并开始要求开发工程师承担起撰写自动化测试脚本的责任:谁开发,谁测试。

When : 什么时候写自动化测试?

程序员有三种,先写测试再写代码,先写代码再写测试,和不写测试。因此什么时候写测试,是程序员群体中最大的分歧之一。

个人认为除非是 TDD/BDD 的粉丝,追求 “红-绿-重构” 的成就快感,否则先写代码再写测试,能尽量减少测试带来的成本,除非测试用例简单至极。

Where : 什么地方放自动化测试?

总算来到一个观点较为一致的问题。

如今大家都习惯于把代码放在 /spec/test 文件夹下,并且通常都配有一个 /spec/spec_helper.xx/test/test_helper.xx 为每个测试脚本加载共同的依赖。

文件夹下按测试对象分为不同的子文件夹,还有一个 fixtures 用于放置测试数据。

How : 怎么写自动化测试?

常见的测试有以下四种类型:

  • 静态检查 - Eslint, JSCS
  • Unit Test - Karma, Jasmine, Mocha
  • End to End Test - Protracker, Nightwatch, Selenium
  • 持续集成 - TravisCI, CircleCI

(to continue…)

参考资料