文章

如何正确理解自动化测试技术

谈到自动化测试,一般就会提到测试工具。许多人觉得使用了一、两个测试工具就是实现了测试自动化,这种理解是不对的,至少是片面的。的确,测试工具的使用是自动化测试的一部分工作,但“用测试工具进行测试”不等于“自动化测试”。那什么是“自动化测试”? 半自动化测试过程,算不算自动化测试?是否可以为“自动化测试”给出如下定义?   以自动化的方式完成测试?   测试过程的自动化?

  将手工测试的过程变成了自动化测试的过程?

  摆脱手工测试的各种途径和方法?

  自动化为测试而存在的,所以自动化测试的真正含义可以理解为“一切可以由测试是相对手计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”。它包含了下列3层含义:

  “一切”,不仅仅指测试执行的工作——对被测试的对象进行验证,还包括测试的其它工作,如缺陷管理、测试管理、环境安装、设置和维护等。

  “可以”,意味着某些工作无法由系统自动完成,如脚本的开发、测试用例的设计,需要创造性,其工作需要手工处理。

  即使由系统进行自动化测试,还少不了人的干预,包括事先安排自动化测试任务、测试结果分析、调试测试脚本等。

  严格意义上,“自动化测试(Automated Testing)”不等于“测试自动化(Test Automation)”。自动化测试,模拟手工测试步骤,通过执行程序语言编制的测试脚本自动地测试软件,自动地实施软件的单元测试、功能测试、负载测试或性能测试等。自动化测试集中体现在实际测试执行(test execution)的过程,也就是由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。自动化测试,强调借助工具(不仅仅是工具,有时包括策略和工件)来完成测试的执行,也就是用工具来帮助或辅助测试,这个执行过程可能是全自动的,也可能是半自动的。  测试自动化的要求高得多,侧重说明将测试用自动化设计和实现的过程,即所有的测试工作都能有计算机系统自动完成,包括:

  测试环境的搭建和设置,如上载安装包到服务器;   脚本自动生成,如根据UML状态图、时序图等生成可运行的测试脚本;   测试数据的自动产生,例如自动产生数据负载测试所需要的大量数据;   测试操作步骤的自动执行,包括测试执行过程的控制;   测试结果分析,实际输出和预期输出的自动对比分析;   测试流程的自动处理,即测试工作流的自动实现,包括测试计划复审和批准、测试任务安排和执行、缺陷生命周期等流程的自动化处理。   测试报告自动生成功能等。

  这样,测试自动化意味着测试全过程的自动化和测试管理工作的完全自动化,是测试工程师所追求的一种理想境界,但是很难实现的。往往不能完全通过全自动化过程来完成一个完整的测试任务,自动化到不需要人工参与的程度是不现实的。虽然不能完全实现那种理想境界,但是我们每时每刻可以向这个方向去思考,优化每项工作,一切可以由计算机系统自动完成的测试任务都已经由计算机系统或工具来承担并自动执行。

  在一般情况下,人们并不严格区分“自动化测试”和“测试自动化”,就是通过工具或程序来对软件进行测试,一般不需要大量的手工操作来完成测试,而只要很少的人工干预。自动化测试,理应从工作效率和产品质量的目的出发,而不是为了自动化而自动化,在某些时刻,也可能得不偿失,即投入过大,产出远远小于投入。脱离了目的,测试人员可能会变成自动化测试的奴隶。奢想做到百分之百地实现自动化测试,不仅不现实,所引起的代价可能会非常大,而且可能引起负面性,造成质量水平的降低。

  最后,我们还不得不承认,自动化测试和手工测试往往交织在一起,相互补充,工具执行过程往往需要人工分析,手工测试时也可以借助工具处理某些数据、日志或显示某些信息。也就是说,不是试图用自动化测试来代替所有的手工测试,而应该在尊重手工测试的同时,尽量采用自动化测试,根据各自的特点充分发挥各自的优势,使手工测试和自动化测试实现完美结合。

将测试人员整合到敏捷团队中

将测试人员整合到敏捷团队中,这是敏捷之道常常重复的一条箴言,可我们并没有认真想过这到底意味着什么或者应该怎么做。

团队中测试人员的角色具体负责什么呢?他们要:

  • 协助团队抽取并定义验收条件(或需求)
  • 提供相关质量信息,而不是通过自动化测试、探索性测试(exploratory test)[译注]来寻找bug
  • 与客户一起工作,识别风险
  • 在开发人员测试(单元测试与集成测试)的薄弱环节投入更多精力。比如,如果我们知道团队已经完成了对数据层的测试,但是GUI层难于进行单元测试,那测试人员就应该花费更多努力在这一层的测试上。

Read more

事物不断变化(流程也需调整)

Jonathan Kohl是一位咨询顾问、作家和知名博主,他提出了这样的观点:时下团队在工作中身处的或正在构建的技术环境,与过去那些曾诞生了许多通用开发流程的环境已经有了很大不同。他鼓励团队在检查流程时保持清醒和活跃,并让自己做好准备,以能够适应当今他们工作中身处的现实。
Read more

持续集成的实现与反思

持续集成作为一种敏捷软件开发实践,已经被越来越多的开发者所接受。持续集成倡导开发团队频繁地进行系统集成——通常一天一次到数次,每次集成都能被自动编译和测试验证,从而能在最短的时间内发现问题,缩短开发周期,提高软件质量。 Read more

矛盾:全部测试,除了Accessor类?

在Raikes学院的敏捷开发者技能课程上,我说我们通常不测试Accessor。但是我们不是可以测试所有的吗,这是不是很矛盾啊?
上周,我和切特, Cheezy参加内布拉斯加大学(林肯)Raikes学院的CSM 课程和一节敏捷开发者技能课。真是很有意思。在快结束的时候,大家提到一件关心的事,我决定提笔写写这个。 Read more

我的TDD经验

在我的职业生涯刚开始的时候,我曾经是一个编码人员,虽然我被叫做开发人员。我通常参与开发中小型项目和产品。在刚开始的几年,我把大部份时间都花在写代码和实现功能上面。虽然我尽了自己一切努力,但是我依然经常在项目上线或者交付给QA测试后,要经历一段十分艰苦的修BUG时期。结果,我开始和其他团队成员一起延长工作时间,然后挣扎着尝试把这些似乎永无止境的BUG修完。我们没日没夜地工作,甚至周末也需要加班,但是产出却总不尽如人意,可以说是非常糟糕。在每个版本发布后,开发团队总是会有很大的压力。 Read more