我的经验和发展（这些年工作的一个整理吧）
我的测试经验：从工作到现在，已经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 ]
我下个月就要用ROBOT了，不过是C的。
以后要好好请教了。 谢谢asks_zhuang与大家分享宝贵的经验 三年做的那么好，真不容易的，说明你是非常善于总结的，从你的文章可以看出 楼主，你说的太棒了，受益菲浅拉 好! 顶一下！ 佩服啊！ 写的不错帮顶！！！！！！！！！ 谢谢分享：） 很想听听楼主在自动化测试工作开展方面的一些经验。例如，自动化测试得以开展，对整个开发过程有什么要求——或者说环境是什么？自动化测试的开展获得了测试团队之外的哪些支持？
盼回复。 测试部门的结构分两部分：project内部的测试(in-Team测试Team),针对整个产品的的回归测试（自动化测试Team)
这种测试部门结构还是第一次听说，特别是其工作流程。不过我有一个问题，人力资源如何配置呢？如果是有很多的项目（产品）还好，如果是比较有限的项目（产品），如何利用这种模式有序的处理相关问题呢？ 强！ 我从毕业到现在已经作了两年的测试。我所在的公司因为实行测试比较早，所以测试的流程比较规范，但仅仅局限于手动的功能测试，曾经实行过一阵子的robot回归测试，但很多手工毕竟是工具所不能代替的，所以就不了了之了。我目前也正处于楼主的第一阶段的末期。领导将我晋升为teamleader，但目前我还不想往管理方向发展，因为我觉得自己的技术含金量不高，准备寻求技术上的发展。如果再呆在这个公司最多只能是经验的积累和业务知识的增加，但学不到任何的测试技术了。所以年前我想找一家测试完善的企业，想让自己多接触性能压力等各种测试及工具测试。面试了几家公司，发现国内的很多企业的测试都处于刚刚起步阶段，包括一些外企，但也碰到测试比较完善的外企，苦于本人虽然是六级但口语很差，最终没有抓住机会。于是在大受打击之后，参加了一年期的英语培训，希望在6月份口语有所提高，能找到比较理想的外企，实现自己第二阶段的发展。
自动化方面的一些交流
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包装；方便重用； 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的了解/充分的时间，前者可以通过培训来实现；后者就需要项目的管理和协调了
呵呵，和我的经历很相似的；一点感触，共勉：
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]
