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

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

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

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

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

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

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

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

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

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

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

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

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

敏捷团队测试人员和开发人员的比例

软件开发世界里有这样一个长期存在的问题是:测试人员和开发人员的比例多少才合理?Scrum开发列表中最近有一个帖子,询问敏捷对这个比例有什么影响。对第一个问题,答案应该“视情况而定”。对第二个问题,Elisabeth Hendrickson认为,敏捷团队能够用更少的测试人员,但是做更多的测试。

测试人员和开发人员的比例多少才合理?

Read more

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

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

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

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

Read more

敏捷测试之我见

前两天听了公司一个关于敏捷开发的培训,就在想是不是也有敏捷测试。尽管一个同事说根本没有敏捷测试这个概念,但我仍不死心。Google了一下,这方面的文章确实有限,不过有就是对自己想法的一个最好肯定。

  在我的理解对应敏捷开发的管理就是敏捷管理,同样对应敏捷开发的测试即是敏捷测试。只是敏捷管理和敏捷测试同样可以应用到非敏捷开发的项目中去。同样敏捷管理和敏捷测试在敏捷开发中将会得到最大的体现,但能不能管理好和测试好就看你做的是不是真正的敏捷管理和敏捷测试,看你是不是真正的将敏捷的思想融入到管理与测试中去了。 Read more

热衷敏捷测试的十大理由

最近,Kay Johansen 提出问题“为什么你会热衷于敏捷测试?”收到的答案从严肃到诙谐,不一而足。

1.    不再需要手工测试脚本! - 相反,自动运行的脚本让测试人员有更多的时间来挖掘测试。

2.    开发人员喜欢我了! - 迭代结束之前发现问题,而且因为开发人员对代码还有一个比较清晰的印象,所以比较易于找到问题。

3.    现在我可以在撰写特性之前就分解特性!(Kay 与 Philip) - 在撰写特性之前开始测试,测试人员可以预防问题。

4.    自动化测试在一天之内运行很多次 - 任何修改都能得到快速反馈。

5.    营造团队导向的氛围 -(John Overbaugh)- 每位团队成员不仅关心编码,也会关心测试是否完成(Lisa Crispin)

6.    测试人员可以解决偶发性bug(Lisa Crispin)- 自动化的测试让每个人都舒服。

7.    经常复审测试实践的机会(Adam Knight)- 不再是对过去行为的简单重复,实践经常会被复审。在 Adam 的例子里面,过去要5天完成的手工测试减少到只需要30分钟。

8.    我只花很少、很少的时间来调试(Adrian Howard)- 当我犯了错,我能很快得到反馈 - 所以轻而易举就找到问题,然后解决。

9.    真正改进质量,而不是仅仅记录在文档上(John Overbaugh)- bug很快就被解决,而不是只放在bug表里面。

10.   因为测试先行,测试的时间总是有的 - Josue Barbosa dos Santos 讲述了在巴西的一个政府办公室工作的故事,那里测试被安排在项目的最后阶段。开发工作总是落后于项目时间表,面临截止期限的项目不测试就发布给用户。引入 TDD和ATDD之后,最少有一部分测试会随着软件开发同步进行。

Kay热衷敏捷测试的首要原因是:我想听到人们说“这是我迄今为止工作过的最好项目!”

 

作者:Mark Levison(金明 译)

单元测试的7境界

1         以各种借口拒绝单元测试Unit Test,比较常用的是“你没有足够的时间(进行单元测试)”。

2         尝试单元测试并且立刻开始在自己的博客商鼓吹单元测试和测试驱动开发Test Driven Development的好处。

3         单元测试一切。为了能够完成单元测试,而将私有private的方法和属性修改为内部internal;为了达到单元测试覆盖率100%而测试getter() 和 setter() 属性(方法)。

4         无法忍受脆弱的单元测试,在没有弄明白是什么的时候,就匆忙转向“集成测试” integration test。

5         发现了一种模拟 mocking 框架,并且乐于使用强制语义(strict semantics)。

6         模拟mock所有可能模拟mocked的对象。

7         开始真正有效单元测试

三种单元测试工具介绍

一、JTEST

1、简介:

jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个java类,然后自动生成junit测试用例并执行用例,从而实现代码的最大覆盖,并将代码运行时未处理的异常暴露出来;另外,它还可以检查以DbC(Design by Contract)规范开发的代码的正确性。用户还可以通过扩展测试用例的自动生成器来添加更多的junit用例。Jtest还能按照现有的超过350个编码标准来检查并自动纠正大多数常见的编码规则上的偏差,用户可自定义这些标准,通过简单的几个点击,就能预防类似于未处理异常、函数错误、内存泄漏、性能问题、安全隐患这样的代码问题。 Read more

敏捷测试用例设计

敏捷宣言:

个体和交互比过程和工具更有价值;

能工作的软件比全面的文档更有价值;

顾客的协作比合同谈判更有价值;

及时响应变更比遵循计划更有价值。

并非每个企业都能严格按敏捷的相关开发方法进行项目管理,例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓,我认为很多方法、很多地方都可以应用敏捷的思想,实现敏捷的管理。

测试用例的设计是其中一项。

测试用例的粒度

测试用例可以写得很简单,也可以写得很复杂。最简单的测试用例是测试的纲要,仅仅指出要测试的内容,如探索性测试(Exploratory Testing)中的测试设计,仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样,会指定输入的每项数据,期待的结果及检验的方法,具体到界面元素的操作步骤,指定测试的方法和工具等等。

测试用例写得过于复杂或过于详细,会带来两个问题:一个是效率问题,一个是维护成本问题。另外,测试用例设计得过于详细,留给测试执行人员的思考空间就比较少,容易限制测试人员的思维。

测试用例写得过于简单,则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”,只是把需要测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测试计划,提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求,检验需求,并把对软件系统的测试方法的思路记录下来,以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键,也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

软件是开发人员需要去努力实现敏捷化的对象,而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则,则关键是考虑怎样使设计出来的测试用例是能有效工作的。

基于需求的测试用例设计

基于需求的用例场景来设计测试用例是最直接有效的方法,因为它直接覆盖了需求,而需求是软件的根本,验证对需求的覆盖是软件测试的根本目的。

要把测试用例当成“活”的文档(Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin),因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。

不要认为测试用例的设计是一个阶段,测试用例的设计也需要迭代,在软件开发的不同的阶段都要回来重新审视和完善测试用例。

测试用例的评价

测试用例设计出来了,质量如何,如何提高测试用例设计的质量?就像软件产品需要通过各种手段来保证质量一样,测试用例的质量保证也需要综合使用各种手段和方法。

测试用例的检查可以有多种方式,但是最敏捷的应当属临时的同行评审。我认为同行评审,尤其是临时的同行评审,应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”,要强调测试用例设计者之间的思想碰撞,通过讨论、协作来完成测试用例的设计,原因很简单,测试用例的目的是尽可能全面地覆盖需求,而测试人员总会存在某方面的思维缺陷,一个人的思维总是存在局限性。因此需要一起设计测试用例。

除了同行评审,还应该尽量引入用户参与到测试用例的设计中来,让他们参与评审,从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛,关键在于你怎样定义测试,如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是指对开发提供帮助和支持,那么顾客显然就是程序员了。

因此,参与到测试用例设计和评审中来的人除了测试人员自己和管理层外,还应该包括最终用户或顾客代表,还有开发人员。

测试用例数据生成的自动化

在测试用例设计方面最有希望实现自动化的,要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现,但是数据则不同,数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。

很多时候,测试用例的输入参数有不同的类型、有不同的取值范围,我们需要得到测试用例的输入参数的不同组合,以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛,我们又需要科学地筛选出一些有代表性的数据,以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。

可利用一些工具,例如TConfig、PICT等来产生这些数据。

在性能测试、容量测试方面,除了设计好测试用例考虑如何测试外,还要准备好大量的数据。大量数据的准备可以使用多种方式:编程生成、SQL语句生成(基于数据库的数据)、利用工具生成。

工具未必能生成所有满足要求的数据,但是却是最快速的,编程能生成所有需要的数据,但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具,例如DataFactory等。