我想请教几个问题:

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

[ 本帖最后由 songfun 于 2007-2-1 23:50 编辑 ]

我们公司的自动化测试入口是在完成系统集成测试以后，准则是按照测试用例的设计。

"请问大家,你们公司的自动化测试是什莫阶段开始介入的?"

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

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

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

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

先想到这些,呵呵,待续...

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

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

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

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

还有人是最重要的，必须要有能进行自动化测试的技术人员

质量三要素嘛!组织,技术,流程!谁都不能少啊!

代码的维护相当重要,不知道你们是不是有专人来维护代码呢?还是由编写的人去维护??

我们公司的开发系统很大,自动化测试只用在了很小的一部分.验证报文这部分.流程是这样的:这个项目的测试负责人写测试用例,准备测试用例,其实我们的测试用例都准备在XLS里.然后测试执行人员负责运行QTP.提交报告.测试负责人再根据测试报告自己验证正确性.最后返回给开发负责人.给我的感觉自动化测试流程在我们公司是很小的一部分.

刚开始都是这样的,不可能一上来就特别大的,那样风险很大的,得慢慢技术流程各方面成熟一些了,会加大投入的!

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

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

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

入口和出口准则相对比较容易。就像系统测试会进行系统预测试一样，自动化测试有自己的自动化测试用例，这部分的用例可能选取自系统测试用例或确认测试用例，而且很大一部分可能就是来自系统预测试的用例。通过执行这些用例可以获得出口的准则（这里只是指自动化测试活动的通过标准，不是软件系统的通过标准），就是：所有的自动化用例100％的得以执行，用例密度达到10cases/Kloc（这个数字只是举例而已）。而入口准则则是通过了冒烟测试（但是这不是绝对的，有可能是系统预测试之后）。
这里要把冒烟测试、BVT测试和系统预测试几个概念弄清，冒烟测试一般是由开发人员执行的，可以没有测试用例，这种测试是带有随机性质的。BVT测试发生在每日构建中，通常正是由自动化测试工具来执行的。系统预测试由测试人员选取重要级别相对较高的系统测试用例来进行。
之所以这样安排是因为：自动化测试能在人之前发现错误，避免浪费无味的人力资源。
其实如果安排在系统预测试之后也是一种方案。它的意义在于：对于系统趋于稳定的时候适合采用这种方案。而前面的那种方案适合在测试用例相似性非常大的系统中开展。
这里又要纠正一个误区：自动化测试并非只是适合在需要大量回归的测试执行时才需要的。比如我们现在只做两轮的测试，这种情况是否就一定不适合采用自动化测试？答案是否定的，假如我们的系统有如下的特征性还是可以采用自动化测试：测试用例具有极大的相似性。也就是说，可能测试的步骤都是一样的，只是输入参数的不同。假设我们现在有一千条测试用例，每个用例的步骤都是一样的，只是输入数据不同（也就是说等价类非常多），那么这种情况即使只做一轮的测试，没有回归，也还是可以采用自动化测试的。

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

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

[ 本帖最后由 songfun 于 2007-2-1 21:27 编辑 ]

这个版主确实有些想法!牛

引用:

原帖由 songfun 于 2007-1-31 09:57 发表
自动化测试就和单元测试、集成测试、系统测试等阶段一样，都是一个独立而且完整的测试阶段。
它要经历自动化测试计划、自动化测试设计、自动化测试实现和自动化测试执行四个阶段（这就是所谓的V模型）。

楼 ...

学习!强!又温习了一次,感觉所讲的和我们公司的现状有很多相似的地方,Continuous Improvement 中.

[ 本帖最后由 wssgily 于 2007-2-1 11:39 编辑 ]

sdlkfj9
超级版主就是强...

偶要加油咯老
呵呵

晚上回去整理一下 弄到空间上切 嘿嘿

呵呵!songfun的确强人啊.学习啊看来对自动化的理解还需继续深入...

sdlkfj9

刚上来重新更新了一下这篇文章，有个地方觉得表达的不够规范。

整理为：


通过执行这些用例可以获得出口的准则（这里只是指自动化测试活动的通过标准，不是软件系统的通过标准），就是：所有的自动化用例100％的得以执行，用例密度达到10cases/Kloc（这个数字只是举例而已）。而入口准则则是通过了冒烟测试（但是这不是绝对的，有可能是系统预测试之后）。

呵呵,这点我也注意到了.测试用例100%通过,这个不是测试所能控制的.所以我们所能做的就是把规定密度下的所有用例100%执行.

呵呵，还是xiaonan兄弟细心，谢谢~sdlkfj5

大家有没有兴趣说说和整理一下,关于测试流程方面的经验?
我上次测试一个刷新页面的程序，就是因为刷新结束后没有任何的提示，所以这个用QTP测试不太容易测试，后来让开发加了一个弹出提示框，就容易测试了．
那时就想到了一点，需求评审时，有可测试性需求，所以在评审时要考虑到以后自动化测试的可测试是相当重要的．比如开发要严格按照规范来写程序，尽量写标准的控件．这样也方便以后的测试，看到帖子里很多都是控件不支持的．我想除了一些真的是QTP不支持以外，还有一个原因是开发的时候没有严格按照规范开发．这个过程是需要我们测试去推动的．推动整个组织的一些规范的东西的出现，我想这也是测试人员的职责所在吧．

学习中...