自动化测试流程的一个讨论

在无忧测试上看到这样一篇文章,关于自动化测试流程的讨论,其中的大部分观点我是认同的,比如自动化测试的适应对象,自动化测试脚本的质量保证. 有些观点有待商榷,希望有机会和这几位版主切磋.

下面是讨论原文:

早上看到我们的学员发的一个贴子是关于自动化测试流程的一些问题。我也参与了讨论,感觉还不错,呵呵,就整理了一下搬到博客上来,和大家一起分享、交流。

==============================================

wssgily:

我想请教几个自动化测试流程.

请问大家,你们公司的自动化测试是什莫阶段开始介入的?
自动化测试的入口和出口准则是怎样定义的?
大家又是如何保证自动化测试的质量的?

——————————————————–

xiaonan:

自动化测试是在测试执行阶段介入的.然后更多的用于后期的回归测试阶段.

入口条件:
其一:在制定测试方案时,觉得某部分功能测试,适合用自动化工具来完成.那么这部分用例就写的更加细致一点,等这部分用例已经完成.并达到了用例设计的标准,所有需求都已经完全覆盖到.
其二:系统已趋于一个稳定的阶段,不会再有大的改动.
达到这两个条件可以开始自动化测试.

出口准则:
所有用例全部被执行.测试报告已经通过评审.这部分可以和手工测试的要求相同.

首先测试质量在于前期的准备,包括用例的质量啊.自动化测试也不例外.还有保证录制的脚本能正确执行用例的意思.所以要保证脚本的质量.

——————————————————–

wssgily:

 

个人理解的是自动化应该在回归测试或者软件基本功能或者流程已经成型的条件下而且以后变动不大的情况下,就可以开始跑脚本了.

如何保证质量:还是要看测试用例的质量,如果提高测试用例的质量,还是要看对SRS理解的程度有多深,能提取出多少个测试点来.然后把有效的测试点和质量特性和要验证的特性相结合,来写测试用例和提高覆盖率.

个人认为自动化还是要看测试用例质量有多高的,还有就是前期准备相当重要.到最后实现起来就解决技术难点就行了.呵呵!

欢迎大家讨论自动化流程方面的东西。

——————————————————–

songfun:

自动化测试就和单元测试、集成测试、系统测试等阶段一样,都是一个独立而且完整的测试阶段。
它要经历自动化测试计划、自动化测试设计、自动化测试实现和自动化测试执行四个阶段(这就是所谓的V模型)。

楼上几位朋友所描述的是一个不完整、不规范的测试过程。这样的自动化测试实施起来的效果就不好说了。

按 阶段来看的话,它介于集成测试和系统测试之间,或者说是介于集成测试和确认测试之间,又或者贯穿于集成测试、确认测试和系统测试这个阶段(这就是所谓的H 模型)。具体要视具体情况来制定。比如你们的集成测试是做到子系统间的集成,那么这个阶段已经可以引入自动化测试了,要注意的一点是这个自动化测试最好由 独立的自动化测试团队来完成,使得项目进度不至于在关键路径上停留,可以并行开展。

入口和出口准则相对比较容易。就像系统测试会进行系统 预测试一样,自动化测试有自己的自动化测试用例,这部分的用例可能选取自系统测试用例或确认测试用例,而且很大一部分可能就是来自系统预测试的用例。通过 执行这些用例可以获得出口的准则(这里只是指自动化测试活动的通过标准,不是软件系统的通过标准),就是:所有的自动化用例100%的得以执行,用例密度 达到10cases/Kloc(这个数字只是举例而已)。而入口准则则是通过了冒烟测试(但是这不是绝对的,有可能是系统预测试之后)。

这里要把冒烟测试、BVT测试和系统预测试几个概念弄清,冒烟测试一般是由开发人员执行的,可以没有测试用例,这种测试是带有随机性质的。BVT测试发生在每日构建中,通常正是由自动化测试工具来执行的。系统预测试由测试人员选取重要级别相对较高的系统测试用例来进行。
之所以这样安排是因为:自动化测试能在人之前发现错误,避免浪费无味的人力资源。
其实如果安排在系统预测试之后也是一种方案。它的意义在于:对于系统趋于稳定的时候适合采用这种方案。而前面的那种方案适合在测试用例相似性非常大的系统中开展。
这 里又要纠正一个误区:自动化测试并非只是适合在需要大量回归的测试执行时才需要的。比如我们现在只做两轮的测试,这种情况是否就一定不适合采用自动化测 试?答案是否定的,假如我们的系统有如下的特征性还是可以采用自动化测试:测试用例具有极大的相似性。也就是说,可能测试的步骤都是一样的,只是输入参数 的不同。假设我们现在有一千条测试用例,每个用例的步骤都是一样的,只是输入数据不同(也就是说等价类非常多),那么这种情况即使只做一轮的测试,没有回 归,也还是可以采用自动化测试的。

关键是要结合具体情况进行具体分析。不能盲目的把书本上、课堂上的知识照搬照套。企业需要能随机应变的工程师。

至于说保证自动化的质量,那就不止是自动化本身的问题了。它取决于:人、技术、过程。好的过程需要有SEPG的参与,SQA的监督和指导。
保证了三者,才能保证自动化的质量。

 

This entry was posted in 测试自动化. Bookmark the permalink.

5 Responses to 自动化测试流程的一个讨论

  1. Jessica says:

    只是想说,感受到了另外种测试的流程规范和测试高手的厉害。
    ricky,多谢此方面知识的共享!

  2. ricky.zhu says:

    我目前所在的自动化实施流程是这样的:
    1. 首先系统测试部门从他们的测试列表中挑选出回归测试的列表,这些必须是经过很多轮测试比较稳定的,给出一个测试的优先级别
    2. 自动化测试部门会根据这个列表,由资深自动化测试工程师进行分析,用例的可行性,难度,是否有工具的需求等等,然后给出一个可自动化优先级别
    3. 自动化测试部门根据这个优先级别,安排相关的自动化测试工程师进行测试用例的分析,给出具体的分析报告
    4. 自动化部门根据这个报告,安排相关的review,然后进行计划自动化,当前,前提是我们的自动化测试平台已经具备,相关的基本库函数非常丰富
    5. 自动化工程师在自动化过程中,如果有业务问题,请求系统测试工程师的接口人,如果有自动化的代码或者基本库的需求,请求自动化平台工程师
    6. 自动化完成之后,系统测试工程师会进行相关的评估和演示,然后提出建议,如无则进入下一个阶段
    7. 测试计划中安排自动化测试的用例进行回归, 前期由自动化工程师执行,后期可以移交给系统测试工程师进行执行,同时执行过程中的问题和bug,记录下来,通过缺陷管理系统进行跟踪
    8. 测试执行完成之后,由自动化测试平台出响应的测试报告,和手工测试的测试报告一起汇总

    当然,每个产品的自动化流程也是不一样的,目前这套流程基本运转起来,其中有些环境会有细微的差异.

  3. Edenhu says:

    看不太懂,有点晕。 缺少这方面的基础,有机会补补去!

  4. ricky.zhu says:

    Eden,测试流程是一个组织的行为,需要多方面的协调和沟通,单凭个人的能力很难发挥作用。 不过做为组织的一员,应该理解流程,参与制定并遵守流程。

  5. meng_0819@hotmail.com says:

    感觉蓝色字体那一部分相当不错。

Leave a Reply

Your email address will not be published. Required fields are marked *