|
我的测试经验:
从工作到现在,已经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 ] |
|