|
|
我的测试经验：
从工作到现在，已经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 ] |
|
/1 
关于我们
发表于 2005-2-23 16:32:09
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主
发表于 2005-2-24 00:31:00
