51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4788|回复: 16
打印 上一主题 下一主题

[原创] 我的经验和发展(这些年工作的一个整理吧)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2005-2-23 16:32:09 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
我的测试经验:

从工作到现在,已经3年多了,做测试也已经2年多了,一些经验和体会记录下来,也让自己的思路更加清楚,明确。

在第一家公司,一直做的是一个Workflow项目,是一个Web平台,允许用户在这个平台上开发,运行自己的表单。比如一个企业内部有很多自己的流程,包括业务流程,工作流程,管理流程等等,这些流程具有很多共同特点,比如要分阶段,每个阶段可能是不同的人完成不同的工作等等.
简单的例子是请假流程,需要根据请假的天数,请假的类别决定这个请假单
需要哪些人来核准。我们的workflow项目就是提供这个请假单运行的平台,和开发这个请假单的平台.

这是一个WEB平台,而且平台上每天会有大量的表单,所以性能是必须要考虑的,而且表单运行过程中,会和其他系统交互,比如财务系统等,所以每个表单的完整运行,也是必须要求确保的,如果表单出现了问题,需要马上通知管理员

01年毕业,进入项目后,首先做的是开发, 当时使用了VB,XML,ASP,数据库是SQL 2000
做了不到一年开发,在02年4月时候建立了测试Team,当时是3个人,都是和我一起进入公司的,我是leader.(大概Product manager觉得我比较负责,比较主动并善于沟通吧)
在这之前,开发和测试是交互的,比如A开发的功能模块给B测试,B的C测,C的A测试...那个阶段,我曾经测试过一个‘表单设计模块‘,那个模块使用的主要是XML,当时接触了DOM/SAX/XSL/DTD/XSD等 (测试的原始阶段)

当时的测试都是集中在功能测试,没有什么测试工具,都是手工的;测试出来的bug记录在excel文件里面,通过email发送;
测试组,就我们三个人,当时统称QA组,负责软件功能的测试,Release,线上支持。其实这个组建立时候,任务就是一句话"确保产品的质量";具体的职责也是边做边说,并没有很明确。 (当时真有一腔热血的感觉,一心就是把工作做好;而具体的工作职责,Team的目标?自己在Team中的作用,怎么去带Team? 这些并没有一个明确的思路)
就这样,朦朦胧胧(模模糊糊更贴切吧)团队在发展,又进来了两个新人,老带新,我们公司的传统。两个新人,两个老人,还有我,5个人的Team了。当时的版本有两个,3.0版本和4.0版本,其实这两个版本之间没有必然的联系;3.0需要维护,4.0已经上线,一些功能在继续加强;工作量还是不少的。

长话短说,后来地把任务逐渐明确,工作流程也慢慢规范:要求每个阶段都要有对应的文档,并且文档需要相关人员的共同Review:
需求文档(PES)-〉需求确认-〉实现文档-〉实现文档的确认-〉测试计划-〉测试计划的确认-〉开发/测试阶段-〉Release-〉更新支持

在实现阶段,测试计划和实现文档分别由开发负责人员和测试负责人员完成,他们都是基于需求的,之所以测试计划需要在实现文档完成并review完成后开始,是因为测试人员需要了解功能的实现逻辑,并且针对逻辑检验是否可行(这个地方对测试人员的要求是高了些,有高的要求才可以有更高的进步嘛)

测试流程规范以后,针对流程的每个阶段需要的文档(输入/输出)经过大家的讨论,形成了统一的模板;(这点很重要,因为不同文档需要不同的角色人员来完成,必须考虑它们的意见
,只有大家都统一认识的模板才能真正的运行起来)(对一个团队来说,明确团队目标是第一步;然后就要根据资源,建立起适合自己的可行的工作流程,工作流程,流程中的每个阶段输入输出都需要记录下来,统一意见,形成纪录的过程本身就是一个规范流程的过程)

而bug也开始集中管理: Team内部开发一个bug管理表单(运行在我们的workflow系统上)-->部门开发并统一运行一个BMS系统(bug management system),是一个.net的web系统)


关于自动化测试工具,研究过不少,但是真正应用起来的没有;我学习过WAS,是MS提供的web application stress tool,一个压力测试工具;压力测试一个问题是收集到的参数不太容易分析;除了cpu used, memory used等参数,其他很多参数好像没有实际意义(这个地方是我的浅薄,参数肯定是有意义的,呵呵),而在web软件测试中,压力,性能是必须要考虑的
(这是我们测试的第二个阶段, 也是我成长很快的一个阶段,测试组的任务逐渐明确,工作流程也比较规范并文档化, 有了一些工具和平台体现这个流程,使其制度化的进行下去,测试自动化开始摸索)

工作的成绩也慢慢体现出来,线上运行环境也越来越稳定,2004年春节到了,我们的项目组获得了整个集团的年度最佳团队提名;这其间我的角色也有了变化;从负责Tester team到负责一个产品,后来的重新QA leader,自己的方向也慢慢明确,2003年结束,感觉在软件测试->SQA领域继续发展,还需要学习很多,比如技术方面就有自动化测试,性能测试等;继续留下来,工作会更偏重管理,而管理我一直觉得是需要和不同的人打交道,需要积累;在这个行业,技术是基础,我需要加强自己的技术;

04年3月,离开了第一家公司(真有一种离开大学的感觉)
新的环境里也开始接触到了更多的自动化测试工具:

测试管理工具:testdirector; 流程是:
从use case->test case->执行test->纪录,追踪bug(bug流程管理)
可以集中管理testcase,并记录bug.它可以把testcase和user case对应起来;检查是否所以的usecase都已经被覆盖;

自动化测试工具: robotJ,  silktest

自动化测试的第一步是record and playback,录制和回放
第二步是修改,主要是两部分的修改;首先是数据驱动;录制过程不可能输入很多的测试数据,这可以通过修改录制的脚本,使其从对应的数据源取得输入数据;并检查结果
第二部分是函数,方法等的修改;把一些经常使用的地方提炼成函数;方便重新使用
(RobotJ的script语法其实就是java本身的语法,它内部的IDE还是eclipse的,所以如果需要熟悉java的语法,并且了解oop的概念和应用,就方便多了)

有了脚本,就该运行这些脚本了;robotJ运行这些脚本后,可以检查预期的操作是否可以顺利完成,是否和预期的结果一致
(如果robotJ和testmanager相连, 这里的运行结果会显示在testmanager里面,否之就只能显示在html文件里)

由于不同的脚本可能访问相同的一个对象,比如录制的脚本A,脚本B都访问了系统登陆叶面的登陆button, 而如果登陆叶面上的button做了修改,变成了一个图片,这时候脚本A,脚本B都需要重新修改;可以看出这样做是比较麻烦的, 所以,可以让多个脚本公用一个对象定义文件(script object explorer);这样就可以对测试的对象集中,统一管理
方便修改;所以以RobotJ为例,这里的自动化测试脚本产生过程如下:

·        录制,把尽可能多的测试对象(objects under test)包含在一个对象定义文件里面

·        录制,常用的操作

·        把常用的操作提炼成函数,方便重新使用

·        修改录制的脚本成数据驱动: 需要的数据从统一的数据源取得,我使用的是每个testcase对应一个同名的xml文件;里面有对应的输入数据和部分预期的结果

后来这些script全部被silktest重新完成,因为按照要求,我们的整个产品需要用silktest来做回归测试

因为先前的项目已经完成了silktest很多公共函数的定义,这里要做的操作就是产生对象定义文件,把对应的对象名字,操作,输入参数和预期的输出参数保存在Access table里面,按照以前的例子,产生testcase,test case执行access table里面记录的操作,并检查结果; 如果需要新增加函数,增加对应的定义文件(所有函数必须编译然后才可以使用)
这里和以前的robotJ脚本的区别在于完全的数据驱动,对象,操作,输入,预期输出都保存在了Access table中;所谓的script,更可以理解成为table contents.

在这个自动化的测试过程中,需要明确并且详细的测试步骤,或者说明确的TestCase,而在项目开发前期中,由于use case可能的不稳定,继而Test case不稳定,所以大规模的自动化测试会有困难;
而我们的测试部门的结构分两部分:project内部的测试(in-Team测试Team),针对整个产品的的回归测试(自动化测试Team),前者跟随整个项目的开发过程,更多的是手工测试;当project稳定后,提交test case文档给自动化测试部门 ,后者把testcase转换成自动化脚本(silktest),然后完成对整个product的回归测试,这样product的每个版本出来以后,可以很快的完成回归测试
这也是我经历的第三个阶段,流程如下:
in-project testing ->Automation Testing

[ Last edited by asks_zhuang on 2005-2-23 at 16:33 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

该用户从未签到

2#
发表于 2005-2-23 19:07:11 | 只看该作者

我下个月就要用ROBOT了,不过是C的。

以后要好好请教了。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2005-2-24 00:31:00 | 只看该作者
谢谢asks_zhuang与大家分享宝贵的经验
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2005-2-24 12:01:46 | 只看该作者
三年做的那么好,真不容易的,说明你是非常善于总结的,从你的文章可以看出
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2005-3-14 15:48:15 | 只看该作者
楼主,你说的太棒了,受益菲浅拉
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2005-3-14 15:59:34 | 只看该作者
好!
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2005-3-15 15:19:33 | 只看该作者
顶一下!
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2005-3-15 16:12:53 | 只看该作者
佩服啊!
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2005-3-28 09:55:51 | 只看该作者
写的不错  

帮顶!!!!!!!!!
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2005-3-28 17:47:29 | 只看该作者
谢谢分享:)
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2005-3-29 13:19:58 | 只看该作者
很想听听楼主在自动化测试工作开展方面的一些经验。例如,自动化测试得以开展,对整个开发过程有什么要求——或者说环境是什么?自动化测试的开展获得了测试团队之外的哪些支持?

盼回复。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2005-3-29 13:53:11 | 只看该作者
测试部门的结构分两部分:project内部的测试(in-Team测试Team),针对整个产品的的回归测试(自动化测试Team)

这种测试部门结构还是第一次听说,特别是其工作流程。不过我有一个问题,人力资源如何配置呢?如果是有很多的项目(产品)还好,如果是比较有限的项目(产品),如何利用这种模式有序的处理相关问题呢?
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2005-3-29 17:28:17 | 只看该作者
强!
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2005-3-31 08:57:27 | 只看该作者
我从毕业到现在已经作了两年的测试。我所在的公司因为实行测试比较早,所以测试的流程比较规范,但仅仅局限于手动的功能测试,曾经实行过一阵子的robot回归测试,但很多手工毕竟是工具所不能代替的,所以就不了了之了。我目前也正处于楼主的第一阶段的末期。领导将我晋升为teamleader,但目前我还不想往管理方向发展,因为我觉得自己的技术含金量不高,准备寻求技术上的发展。如果再呆在这个公司最多只能是经验的积累和业务知识的增加,但学不到任何的测试技术了。所以年前我想找一家测试完善的企业,想让自己多接触性能压力等各种测试及工具测试。面试了几家公司,发现国内的很多企业的测试都处于刚刚起步阶段,包括一些外企,但也碰到测试比较完善的外企,苦于本人虽然是六级但口语很差,最终没有抓住机会。于是在大受打击之后,参加了一年期的英语培训,希望在6月份口语有所提高,能找到比较理想的外企,实现自己第二阶段的发展。
回复 支持 反对

使用道具 举报

该用户从未签到

15#
 楼主| 发表于 2005-3-31 13:34:03 | 只看该作者

自动化方面的一些交流

Originally posted by jackei at 2005-3-29 01:19 PM:
很想听听楼主在自动化测试工作开展方面的一些经验。例如,自动化测试得以开展,对整个开发过程有什么要求——或者说环境是什么?自动化测试的开展获得了测试团队之外的哪些支持?

盼回复。


1。首先还是从我们自动化的流程开始,由于我们的自动化工作是在project稳定后开始的,具体就是in-project tester完成并通过了测试以后提交test case给automation testing team, 所以自动化过程没有项目的压力,时间一般比较充分(这一点是蛮重要的,项目稳定后再开始自动化,因为这时候需求是很明确的了,又不需要承担项目开发过程的时间压力)

2。自动化测试的定位就是给提高整个产品回顾测试的覆盖率,如果没有自动化脚本,产品的每个built出来以后,就需要每个project对应的in-project tester来做对应project回归测试;而这对project team来说是一个负担;
所以每个project完成以后,都想尽快交给automation testing team;
自动化测试team的工作上游是project team,需要他们提供详细的testcase,并根据需要解释test case;
工作下游是build/release team;他们根据产品回归测试的结果,评估是否可以release product.

3。自动化测试team内部,主要有两类分工,一部分负责把project的手工testcase转化为automation test script,一部分负责在silktest基础上作二次开发,开发出一个自动化测试的框架,同时也对经常使用的测试script包装;方便重用;
回复 支持 反对

使用道具 举报

该用户从未签到

16#
 楼主| 发表于 2005-3-31 13:47:47 | 只看该作者
Originally posted by Nio at 2005-3-29 01:53 PM:
测试部门的结构分两部分:project内部的测试(in-Team测试Team),针对整个产品的的回归测试(自动化测试Team)

这种测试部门结构还是第一次听说,特别是其工作流程。不过我有一个问题,人力资源如何配置呢?如果 ...


我们这里in-project testing team和automation testing team是互相独立的两个team;
前者是后者的上游;automation team的需求都是从项目组来的,大多时候都是项目组内的tester提供的;这中间就有一个‘传送过程的信息衰减‘,测试归根究底,应该是基于需求的;对需求,in-project tester更了解

所以建议如果项目比较有限,就可以由项目组的tester来负责产生自动化测试脚本的工作;
他们的优势是对需求更了解;更方便;
可能缺少的是对automation script的了解/充分的时间,前者可以通过培训来实现;后者就需要项目的管理和协调了
回复 支持 反对

使用道具 举报

该用户从未签到

17#
 楼主| 发表于 2005-3-31 13:59:39 | 只看该作者

呵呵,和我的经历很相似的;一点感触,共勉:

Originally posted by xixi021 at 2005-3-31 08:57 AM:
我从毕业到现在已经作了两年的测试。我所在的公司因为实行测试比较早,所以测试的流程比较规范,但仅仅局限于手动的功能测试,曾经实行过一阵子的robot回归测试,但很多手工毕竟是工具所不能代替的,所以就不了了 ...

个人发展也是全方面的;工作方面,就需要技术/管理/领域知识/沟通能力/外语等;
就我自己的经验,找工作时候技术是基础的,包括相应的开发技术/工作流程的理解/经验的积累等;这部分是基础,但并不是最重要的
管理/沟通的经验是通过实践/总结/分析/讨论出来的,往往给会被看重;
外语的确很重要;更重要的是表达出沟通愿望和技巧;外语的目的就是沟通;
而这些在工作,在应用中更能提高和锻炼

[ Last edited by asks_zhuang on 2005-3-31 at 14:03 ]
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-9 03:52 , Processed in 0.077335 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表