• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• 良好的心态

  2008-7-17

   

  
  

  我觉得做好测试有以下几个方面比较注意：
  
  一，不要浮躁，不要今天想学这个明天哪个的，要保持娘好的心态！
  二，要有自己的职业规划，知道自己每天该做什么；
  三，懂得一个循环，就是pdca循环。具体解释以下吧，
      1.p就是自己要计划，大家可能有很多的谋划，但记住一点，要实事求是，切实可行
      2.d就是自己去做或者执行，这大家也能做到，我相信
      3.c就是自己去检查或者核实自己的能力，这一点我不敢认为每个人都能做到，可能有一部分人可以吧
      4.a即使自己去改进，对发现自己的不足去完善。这一点，只有成功的人，可以体会到
  四，要善于积累自己的知识，水滴石穿，汇集成海！
  
  

  查看(29) 评论(0)

• 测试经验交流

  2008-7-17

  测试经验交流

  
  

  本文主要目的是加强项目组和测试中心之间的相互了解，分享一些测试人员在工作中的经验和成果， 从而使项目组和测试中心的配合更加默契，共同把握住产品的质量要素。
  一、 测试的目的和原则
  1、测试概念的范畴
  　　广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。如：设计评审、系统测试。
  　　狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同
  时对产品质量进行客观的评价。
  2、测试的目的
  　　简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把
  尽可能多的问题在产品交给用户之前发现并改正。
  　　具体地讲，测试一般要达到下列目标：
  　　1、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说
  明------在某种意义上与ISO9001是同一种思想。
  　　产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期 利益看，这是很不划算的。我有个感觉，接触过的软件产品，很少有向方正这样大大的产品、薄薄的文档。
  　　当然，书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难，也是最容易被忽略的。
  　　最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。
  　　2、 确保产品满足性能和效率的要求
  　　使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一 个有竞争力的产品。
  　　用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好 处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。
  　　3、 确保产品是健壮的和适应用户环境的
  　　健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。
  　　另外就是不能假设用户的环境(某些项目可能除外)，如：报业用户许多配置是比较低的，而且是和某 些第三方产品同时使用的。
  3、测试的原则---Good Enough
  　　对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。
  　　Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种 资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的， 什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题 具体分析。最明显的例子就是FIT3.0中文报版的产品测试。
  4、测试的规律----木桶原理和80-20原则
  　　1、木桶原理。
  　　在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测 试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说， 测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反 过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。
  2、 Bug的80-20原则。
  　　一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能 找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试 只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。
  二、 测试中心测试组织、测试实施的现状和改进
  1、测试中心的任务和发展目标----质量
  　　参与到监控产品生命周期中一切影响到质量的因素的工作中去。
  　　目前测试中心的主要任务是负责产品的系统测试。
  　　但实际上，因为单独的系统测试不能保证产品最终的质量，所以测试中心在部分项目中也参与到集成 测试和用户测试中。
  　　另外，测试中心也承担了部分系统评测的任务和用户技术支持的任务。
  　　测试中心将来的发展目标是研究院开发的产品的质量保证中心，我们的中心任务只有两个字："质 量"，测试中心也只对这两个字负责，并且将参与到监控产品生命周期中一切影响到质量的因素的工作中去。
  2、测试中心的组织方式----小组
  　　测试中心内部的个体分为测试人员和支持人员(管理人员属于支持人员)。
  　　测试中心的工作实体(最小组织单位)是测试小组和支持小组，分别由小组长全权负责。小组长向测试 中心主任负责。
  　　测试小组根据测试项目或评测项目的需要临时组建，小组长也是临时指定。与项目组的最大区别是生 命周期短，一般是2周到4个月。在系统测试期间或系统评测期间，测试组长是测试中心对外(主要是项目 组)的唯一接口，对内完全负责组员的工作安排、工作检查和进度管理。
  　　支持小组按照内部相关条例负责测试中心的后勤保障和日常管理工作，机构设置一般相对比较稳定。 主要负责网络管理、数据备份、文档管理、设备管理和维护、员工内部培训、测试理论和技术应用、日常 事务管理和检查等。
  　　另外，测试中心对于每一个重要的产品方向，如：报社系统(包括采编、FIT、RIP、字模等)、电视台 系统(包括点睛、新闻等)…，均设置1-3个人长期研究和跟踪方正及竞争对手的产品特征、性能、优缺点 等。在有产品测试时，指导或参加测试(但不一定作为测试组长)，在没有产品测试时，进行产品研究，并 负责维护和完善测试设计。目前希望在需求分析阶段多多参与(如：Chirashi2.1)。
  3、测试中心的运作方式----制度化并形成应用
  　　主要介绍一下项目组关心的系统测试流程：
  　　1、项目组提交系统测试申请给测试中心指定帐号。由专人检查文档格式和完备性。
  　　2、检查合格后交给该产品对应方向的研究人员，评价其内容的有效性和真实性。
  　　3、检查合格后由测试中心主任审查并通过，成立测试组，指定测试组长(但暂时没有组员)。
  　　4、测试组长根据该产品的申请报告、测试设计和以往测试数据，制定测试方案。
  　　5、测试中心主任审核通过测试方案后，根据测试方案指定测试组成员，并由支持组完成其他支持任
  务(如：设备的配备、测试数据库的建立、网络权限的修改…)。
  　　6、测试期间测试组根据测试方案进行实际测试，记录并跟踪测试缺陷报告，填写测试记录。测试期 间测试组长与项目组(测试经理)经常沟通，并获取产品的更新版本。同时，测试组长审查、修改并提交所 有缺陷报告，保证随时掌握产品的质量情况，并监督测试进度。
  　　7、产品进行到一定阶段后(标志是测试缺陷报告库中所有的报告处于归档状态)，由项目组和测试组 长共同决定产品进入稳定期测试。稳定期测试版本之前的版本必须在显着位置标明为测试版字样。
  　　8、稳定期测试期间所发现的缺陷报告也需要记录在测试缺陷报告库中，并在稳定期结束后由双方(有 时可能也有市场方面的意见)共同决定对这些缺陷的处理方式。如果需要改动产品，则重新开始稳定期， 否则通过稳定期测试。
  9、测试组长对于通过稳定期测试的产品填写综合测试报告，测试中心依此发布产品发行通知。
  　　10、测试组对整个测试过程和产品质量进行总结和评价，形成文档并备案。同时，将测试过程中对测 试设计的改动纳入基线。最后，组长整理并在指定地点保存相关测试数据和测试样张。
  　　11、测试中心解散测试小组。
  　　另外，在系统测试阶段，我们要求测试小组要进行一些常规内容测试(如：Y2K测试，病毒检查、裸机
  测试、加密检查、说明书检查…)，并要求写入测试方案中。
  4、传统测试流程遇到的挑战和对策----问题发现得越早，解决的代价就越小
  　　1、 自动测试工具和测试理论
  　　由于我们的产品开发模式还不够规范、相关文档不够完备，所以测试工具的应用效果不理想，只能部 分应用。如：SQA。
  　　对于测试理论，测试思想/测试理念的灌输工作还是有成效的，但是测试数学模型的研究和建立工作 进展不顺利，主要原因也是我们的产品生命周期内部操作不够规范。
  　　目前主要依赖于：测试人员的经验和素质；产品说明文档和项目组的技术咨询；测试设计。
  　　2、 测试分类
  　　根据目前的实际情况(已经由传统的瀑布开发模式、使用结构化设计和实现手段，变为现在的RAD开发 模式、使用OOD和OOP)，我们将把测试分为三种：产品测试、项目测试、系统评测。我们的依据是：问题 发现得越早，解决的代价就越小。
  　　产品测试的流程基本和上面提到的一样。
  　　项目测试的原则是尽早加入测试，并充分重视和支持用户测试。
  系统评测是简化工作流程。

   

   

  三、 测试中常见问题分析及对策
  　　我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为4类：死机(系统崩溃或挂起)、致命 (使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免 的)、严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)、一般(界面拼写错误或用户使用不方便)。
  
  　　我们也把发现的错误按优先级分为三种：高、中、低：一般是越影响用户接受或使用该产品的错误优 先级越高。
  
  　　但下面，将不对所有的问题进行列举和分析，而只是列出一些显而易见的、容易被项目组忽略的错 误，这些错误可能是容易修改的、或是容易避免的，但是对于测试组或用户来说可能却是非常头痛和不方 便的。
  
  1、形象类问题：---不专业、用户不信任
  
  　　1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快 捷键)。
  
  　　2、不够专业，缺乏基本知识，而又没有高手检查：CMYK(0-255)
  
  　　3、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词
  
  　　4、SETUP界面：CopyRight 1994-1996；缺省认为用户使用某种分辨率；
  
  　　5、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版禁则…
  
  　　6、程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(丢掉一些必要的模块或文 件)
  
  　　7、界面元素参差不齐，文字不能完全显示，TAB时鼠标乱走。
  
  2、可用性问题：---用户无法使用或不方便使用
  
  　　“用户比开发或测试人员在接触界面上要花费更多时间。表面上不重要的方面的影响会变得越来越 大，最终甚至会掩盖了产品得有用得方面。”
  
  　　下面是一些用户界面错误的例子：
  
  　　1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可逆料的后果
  
  　　2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导。如：数据库 中剩余记录个数；参数设置对话框中的预设值
  下面是一些低效的用户界面的例子：
  
  　　1、表达不清或过于模糊的信息提示
  
  　　2、要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修 改某些配置文件。
  
  　　3、为了达到某个设置或对话框，用户必须做许多冗余操作。如，对话框嵌套层次太多。
  
  　　4、不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。
  
  　　5、使用不完善的功能且不给用户以恰当的提示，如：对于TIF图片的不完全支持；Undo功能的局限 性。
  
  　　6、不经用户确认就对系统或数据进行重大修改
  
  3、稳定性问题：---影响用户正常工作
  
  　　1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低
  
  　　2、主系统和子系统使用同样的临界资源而互相不知道。如：使用同样的类名或临时文件名、使用同 样的数据库字段名或登录帐号。
  
  　　3、不能重现的错误，许多与代码中的未初始化变量(在Debug时一般是缺省初始化的)有关，有些与系 统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。
  
  4、其他问题
  
  　　1、文档匮乏：无标准；无新功能使用方法；无版本改动说明。我们不仅要认为没有说明文档的产品 不是是一个完整的产品，也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户 无法用得起来。
  
  　　2、运行时不检查内存、数据库或硬盘空间等
  
  　　3、无根据地假设用户环境：硬件/网络环境；有些动态库；安装程序换台机器不正确；假设网络随时 都是连通的
  
  　　4、提供的版本带病毒，或根本无法安装，或没有加密
  
  　　5、提供Debug版本给测试组或测试用户，或项目组与测试组使用不同版本
  
  　　6、用户现场开发和修改，又没有记录和保留
  
  　　7、错误反复出现，改动得不彻底、或版本管理出现混乱
  
  　　8、错误越改越多，改动得不彻底、或改动得不小心
  
  　　9、版本中部分内容和接口倒退
  
  　　10、有些选项永远是灰的；有些选项、菜单项在该灰时还不灰，并且还能状态显示
  
  　　11、资源没有和代码分离，不同语言版本间不能平滑转换
  
  　　12、缺少第三方产品的评估：广告管理系统2000年问题
  
  　　13、产品配合不利，准备当作一套产品或方案推出，互相之间却各不负责，(没有整个项目负责人， 是面向组织的而不是面向产品或方案的)，如：采编+FIT；Gallery+FIT。
  
  5、期望项目组关注的一些问题
  
  　　1、修改Bug的人考虑得不够周全，也可能是没有能力考虑周全---不懂全部程序
  
  　　2、问题留给测试组去发现的心态----不仔细测试、不小心修改、甚至不全面改(不彻底)
  
  　　3、自己不会用，不了解产品的用法。
  
  　　4、更多地从用户使用的角度考虑设计、编码与测试
  四、结语
  本文准备得匆忙，可能不够全面和细致。这里只希望我们的产品以高质量和全面为用户着想的态度来进入 世界市场，并垄断某些市场。切记：用户和市场是我们的衣食父母…

  查看(25) 评论(0)

• RUP

  2008-7-17

  RUP

   

   

        RUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。 RUP和类似的产品--例如面向对象的软件过程（OOSP），以及OPEN Process都是理解性的软件工程工具--把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。

  一、六大经验

        迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结束，可以鼓舞开发人员。

   

  http://www.itisedu.com/phrase/200604231308415.html

        管理需求。确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以被证明是捕获功能性需求的有效方法。

        基于组件的体系结构。组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。

         可视化建模。RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。

        验证软件质量。在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。

        控制软件变更。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。

   

  二、统一软件开发过程RUP的二维开发模型

  　　RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。如图1：

  

  
  三、统一软件开发过程RUP核心概念

        RUP中定义了一些核心概念，如下图：

  

  
        角色：描述某个人或者一个小组的行为与职责。RUP预先定义了很多角色。
        活动：是一个有明确目的的独立工作单元。
        工件：是活动生成、创建或修改的一段信息。

  四、统一软件开发过程RUP裁剪

        RUP是一个通用的过程模板，包含了很多开发指南、制品、开发过程所涉及到的角色说明，由于它非常庞大所以对具体的开发机构和项目，用RUP时还要做裁剪，也就是要对RUP进行配置。RUP就像一个元过程，通过对RUP进行裁剪可以得到很多不同的开发过程，这些软件开发过程可以看作RUP的具体实例。RUP裁剪可以分为以下几步：

  1) 确定本项目需要哪些工作流。RUP的9个核心工作流并不总是需要的，可以取舍。

  2) 确定每个工作流需要哪些制品。

  3) 确定4个阶段之间如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每个制品完成到什么程度。

  4) 确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容。

  5) 规划工作流内部结构。工作流涉及角色、活动及制品，他的复杂程度与项目规模即角色多少有关。最后规划工作流的内部结构，通常用活动图的形式给出。

  五、开发过程中的各个阶段和里程碑

  　　RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

  1． 初始阶段

  　　初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。 初始阶段结束时是第一个重要的里程碑：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。

  2． 细化阶段

  　　细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。 细化阶段结束时第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

  3． 构造阶段

  　　在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。 构建阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。

  4． 交付阶段

  　　交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。 在交付阶段的终点是第四个里程碑：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

  六、统一软件开发过程RUP的核心工作流(Core Workflows)

  　　RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

  1． 商业建模(Business Modeling)

        商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。

  2． 需求(Requirements)

  　　需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。

  3． 分析和设计(Analysis & Design)

  　　分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作实现用例的功能。 设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

  4． 实现(Implementation)

  　　实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

  5． 测试(Test)

  测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确　　认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。

  6． 部署(Deployment)

  　　部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

  7． 配置和变更管理(Configuration & Change Management)

  　　配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

  8． 项目管理(Project Management)

  　　软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

  9． 环境(Environment)

  　　环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。

  七、RUP的迭代开发模式

  　　RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。 传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期（见图2）。这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。

   

  
  　　一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目（见图3）。

   

   

  图3 RUP的迭代模型

  　　与传统的瀑布模型相比较，迭代过程具有以下优点：

  　　降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。

  　　降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。

  　　加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

  　　由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

  八、统一软件开发过程RUP的十大要素

  1. 开发前景
  2. 达成计划
  3. 标识和减小风险
  4. 分配和跟踪任务。。
  5. 检查商业理由
  6. 设计组件构架
  7. 对产品进行增量式的构建和测试
  8. 验证和评价结果
  9. 管理和控制变化
  10. 提供用户支持

  让我们逐一的审视这些要素，看一看它们什么地方适合ＲＵＰ，找出它们能够成为十大要素的理由。
   
  1. 开发一个前景
        有一个清晰的前景是开发一个满足涉众真正需求的产品的关键。 前景抓住了ＲＵＰ需求流程的要点：分析问题，理解涉众需求，定义系统，当需求变化时管理需求。 前景给更详细的技术需求提供了一个高层的、有时候是合同式的基础。正像这个术语隐含的那样，它是软件项目的一个清晰的、通常是高层的视图，能被过程中任何决策者或者实施者借用。它捕获了非常高层的需求和设计约束，让前景的读者能理解将要开发的系统。它还提供了项目审批流程的输入，因此就与商业理由密切相关。最后，由于前景构成了“项目是什么？”和“为什么要进行这个项目？”，所以可以把前景作为验证将来决策的方式之一。 对前景的陈述应该能回答以下问题，需要的话这些问题还可以分成更小、更详细的问题： ? 关键术语是什么？（词汇表） ? 我们尝试解决的问题是什么？（问题陈述） ? 涉众是谁？用户是谁？他们各自的需求是什么？ ? 产品的特性是什么？ ? 功能性需求是什么？（Ｕｓｅ Ｃａｓｅｓ） ? 非功能性需求是什么？ ? 设计约束是什么？

  2. 达成计划
          “产品的质量只会和产品的计划一样好。” (2) 在ＲＵＰ中，软件开发计划（ＳＤＰ）综合了管理项目所需的各种信息，也许会包括一些在先启阶段开发的单独的内容。SDP必须在整个项目中被维护和更新。 ＳＤＰ定义了项目时间表（包括项目计划和迭代计划）和资源需求（资源和工具），可以根据项目进度表来跟踪项目进展。同时也指导了其他过程内容（原文：process components）的计划：项目组织、需求管理计划、配置管理计划、问题解决计划、QA计划、测试计划、评估计划以及产品验收计划。

        在较简单的项目中，对这些计划的陈述可能只有一两句话。比如，配置管理计划可以简单的这样陈述：每天结束时，项目目录的内容将会被压缩成ZIP包，拷贝到一个ZIP磁盘中，加上日期和版本标签，放到中央档案柜中。 软件开发计划的格式远远没有计划活动本身以及驱动这些活动的思想重要。正如Dwight D.Eisenhower所说：“plan什么也不是，planning才是一切。” “达成计划”—和列表中第3、4、5、8条一起—抓住了RUP中项目管理流程的要点。项目管理流程包括以下活动：构思项目、评估项目规模和风险、监测与控制项目、计划和评估每个迭代和阶段。

  3. 标识和减小风险
        RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具，又作为确定迭代的基础。

  4. 分配和跟踪任务
        有一点在任何项目中都是重要的，即连续的分析来源于正在进行的活动和进化的产品的客观数据。在RUP中，定期的项目状态评估提供了讲述、交流和解决管理问题、技术问题以及项目风险的机制。团队一旦发现了这些障碍物（篱笆），他们就把所有这些问题都指定一个负责人，并指定解决日期。进度应该定期跟踪，如有必要，更新应该被发布。（原文：updates should be issued as necessary。） 这些项目“快照”突出了需要引起管理注意的问题。随着时间的变化/虽然周期可能会变化（原文：While the period may vary。），定期的评估使经理能捕获项目的历史，并且消除任何限制进度的障碍或瓶颈。

  5. 检查商业理由
        商业理由从商业的角度提供了必要的信息，以决定一个项目是否值得投资。商业理由还可以帮助开发一个实现项目前景所需的经济计划。它提供了进行项目的理由，并建立经济约束。当项目继续时，分析人员用商业理由来正确的估算投资回报率(ROI，即return on investment)。 商业理由应该给项目创建一个简短但是引人注目的理由，而不是深入研究问题的细节，以使所有项目成员容易理解和记住它。在关键里程碑处，经理应该回顾商业理由，计算实际的花费、预计的回报，决定项目是否继续进行。

  6. 设计组件构架
        在RUP中，件系统的构架是指一个系统关键部件的组织或结构，部件之间通过接口交互，而部件是由一些更小的部件和接口组成的。即主要的部分是什么？他们又是怎样结合在一起的？ RUP提供了一种设计、开发、验证构架的很系统的方法。在分析和设计流程中包括以下步骤：定义候选构架、精化构架、分析行为（用例分析）、设计组件。 要陈述和讨论软件构架，你必须先创建一个构架表示方式，以便描述构架的重要方面。在RUP中，构架表示由软件构架文档捕获，它给构架提供了多个视图。每个视图都描述了某一组涉众所关心的正在进行的系统的某个方面。涉众有最终用户、设计人员、经理、系统工程师、系统管理员，等等。这个文档使系统构架师和其他项目组成员能就与构架相关的重大决策进行有效的交流。

  7. 对产品进行增量式的构建和测试
        在RUP中实现和测试流程的要点是在整个项目生命周期中增量的编码、构建、测试系统组件，在先启之后每个迭代结束时生成可执行版本。在精化阶段后期，已经有了一个可用于评估的构架原型；如有必 要，它可以包括一个用户界面原型。然后，在构建阶段的每次迭代中，组件不断的被集成到可执行、经过测试的版本中，不断地向最终产品进化。动态及时的配置管理和复审活动也是这个基本过程元素（原文：essential process element）的关键。

  8. 验证和评价结果
        顾名思义，RUP的迭代评估捕获了迭代的结果。评估决定了迭代满足评价标准的程度，还包括学到的教训和实施的过程改进。 根据项目的规模和风险以及迭代的特点，评估可以是对演示及其结果的一条简单的纪录，也可能是一个完整的、正式的测试复审记录。 这儿的关键是既关注过程问题又关注产品问题。越早发现问题，就越没有问题。（原文：The sooner you fall behind, the more time you will have to catch up.）

  9. 管理和控制变化
        RUP的配置和变更管理流程的要点是当变化发生时管理和控制项目的规模，并且贯穿整个生命周期。其目的是考虑所有的涉众需求，尽可能的满足，同时仍能及时的交付合格的产品。 用户拿到产品的第一个原型后（往往在这之前就会要求变更），他们会要求变更。重要的是，变更的提出和管理过程始终保持一致。 在RUP中，变更请求通常用于记录和跟踪缺陷和增强功能的要求，或者对产品提出的任何其他类型的变更请求。变更请求提供了相应的手段来评估一个变更的潜在影响，同时记录就这些变更所作出的决策。他们也帮助确保所有的项目组成员都能理解变更的潜在影响。

  10. 提供用户支持
        在RUP中，部署流程的要点是包装和交付产品，同时交付有助于最终用户学习、使用和维护产品的任何必要的材料。 项目组至少要给用户提供一个用户指南（也许是通过联机帮助的方式提供），可能还有一个安装指南和版本发布说明。 根据产品的复杂度，用户也许还需要相应的培训材料。最后，通过一个材料清单（BOM表，即Bill of Materials）清楚地记录应该和产品一起交付哪些材料。 关于需求 有人看了我的要素清单后，可能会非常不同意我的选择。例如，他会问，需求在哪儿呢？他们不重要吗？我会告诉他我为什么没有把它们包括进来。有时，我会问一个项目组（特别是内部项目的项目组）：“你们的需求是什么？”，而得到的回答却是：“我们的确没有什么需求。” 刚开始我对此非常惊讶（我有军方的宇航开发背景）。他们怎么会没有需求呢？当我进一步询问时，我发现，对他们来说，需求意味着一套外部提出的强制性的陈述，要求他们必须怎么样，否则项目验收就不能通过。但是他们的确没有得到这样的陈述。尤其是当项目组陷入了边研究边开发的境地时，产品需求从头到尾都在演化。 因此，我接着问他们另外一个问题：“好的，那么你们的产品的前景是什么呢？”。这时他们的眼睛亮了起来。然后，我们非常顺利的就第一个要素（“开发一个前景”）中列出的问题进行了沟通，需求也自然而然的流动着（原文：and the requirements just flow naturally.）。 也许只有对于按照有明确需求的合同工作的项目组，在要素列表中加入“满足需求”才是有用的。请记住，我的清单仅仅意味着进行进一步讨论的一个起点。

  九、总结

  　　RUP具有很多长处：提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。但同时它也存在一些不足： RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；此外，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端，但并不完美，在实际的应用中可以根据需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。

   

  查看(7) 评论(0)

• 软件测试的职业发展方向

  2008-7-07

  

  软件测试职业发展模型图

  本文引自:http://sinckyzhang.blog.sohu.com/

  　 软件测试职业发展方向，大体上与上述的通用职业发展路线图相吻合，也可以分为管理路线、技术路线、管理+技术路线；只是针对该行业本身，有其特殊性和细致性。其图示如同两个重叠的”V”字样，我们为其命名为“双V模型”；该模型适用于大多数行业性软件测试从业人员，一些特殊领域如游戏测试、嵌入式测试、硬件测试，也可作为参考。本文是三部曲之一，只介绍职业发展方向定义，在下一曲会介绍各个职业方向应该具备的知识与技能体系！

  　　 双V的底点是测试工程师，属于软件测试职业生涯的初级域，其适用范围是入行软件测试3年内的常规测试从业者，其主要工作内容是按照测试主管（即直接上司）分配的任务计划，编写测试用例、执行测试用例、提交软件缺陷，包括提交阶段性测试报告、参与阶段性评审等。初入测试行业，进入企业从事测试工作的人员，都要从该层次做起，虽然有时感觉乏味无趣，甚至迷茫困惑，但是我们可以根据个人的兴趣与特长，向上选择适合自己的路线，因为谁都不会甘心一辈子只做一个普通的测试工程师，那么大家看到这里，就可以摩拳擦掌，看看向上发展的通道中，哪一个适合自己，然后立刻从现在开始，确定自己未来5年、10年甚至一生的发展目标迈进，用笔者经常跟学员说的一句话来形容：把握现在，即刻做起，相信自己是最强的！

  　　 首先是常规路线，即双V模型的重叠线，这条发展路线要求管理与技术并重，因为软件测试的行业特点决定了这个因素：测试工程师向上晋升到测试主管、测试经理、测试总监，直至咨询域的更高方向！

  　　 测试主管是企业项目级主管，对于中小型软件公司也可以是企业级主管，属于中级发展域，适用范围是2到5年职业经验的测试从业者。其工作内容是根据项目经理或测试经理的计划安排，调配测试工程师执行模块级或项目级测试工作，并控制与监督软件缺陷的追踪，保证每个测试环节与阶段的顺利进行。严格来说，这个级别更多属于测试的设计者，因为企业的测试流程搭建是由更高级别的测试经理或相关管理者来做的，测试主管负责该流程的具体实施；而更多的工作，是思考如何对软件进行更加深入、全面的测试。因此笔者认为测试主管比较有创造性的工作内容就是测试设计，而恰恰很多公司忽略了或没有精力来执行此工作内容！应该说，在一个企业里做了3年左右测试工作的人员，很容易晋升到该职位，而之所以晋升，是与个人测试技术的过硬、测试方法的丰富，加上对测试流程的监控力与执行力的职业素质息息相关！

  　　 测试经理是更高级别的测试管理者，属于高级测试方向域。对于大中型软件公司，该职位尤为重要，并且对其职业要求也比较高，一般适合4到8年的测试从业者，在管理与技术能力双双比较成熟的情况下，可以结合具体环境晋升到该级别。测试经理负责企业级或大型项目级总体测试工作的策划与实施。随着软件行业的发展，企业对软件工程里各个角色的定位逐渐明显，测试经理完全与开发经理（一些公司也成为项目经理）平齐，除了需要统筹整个企业级或项目级测试流程外，还要对于不同软件架构、不同开发技术下的测试方法进行研究与探索，为企业的测试团队成员提供指导与解决思路，同时还要合理调配不同专项测试的人力资源（如业务测试工程师、自动化测试工程师、白盒测试工程师、性能测试工程师），对软件进行全面的测试；另外，一些企业里，测试经理还需要与客户交流与沟通，负责部分的销售性或技术支持性工作。嘿嘿，看看那些高薪招聘测试经理的企业对该职位的要求里外语口语的描述，就可见一斑！

  　　 测试总监，属于常规发展路线的最高域，如果再往上发展，那只能是咨询域了；不过笔者并没有将其在图中标记出来，因为该职位对于国内目前的大多数软件公司根本没有设立，也就没必要再在图中体现了。该职位一般在大型或跨国型软件企业，或者专向于测试服务型企业有所设立，由于其企业自身的职位定位不同，以及软件测试整体行情所处的阶段，这里不好归纳陈述；但是一般设立测试总监的企业，该职位都相当于CTO或副总的级别，是企业级或集团级测试工作的最高领导者，驾驭着企业全部的测试与测试相关资源，管理着企业的全部测试及质量类工作。而其职业要求，也是技术与管理双结合；基于目前软件测试行情看，这种高管理-高技能的发展目标，不会适合大多数人的选择，社会也不会提供如此众多的测试总监职位让我们去应征！

  　　 应该说，大多数测试从业者都不是技术与管理双优的人，而如今一些到达测试经理或测试总监级别的优秀测试人才，已经领先一步开辟了这条发展路线的先河，希望这些朋友和大家多多分享经验，让更多的朋友弥补自己管理或技术上的不足，在这条路线上有所建树，共同提高，在实现个人人生价值的同时，也自然而然的推动了软件测试行业的发展；行业发展了，测试人员不再被忽视了，待遇自然也提高了，也就不会有很多朋友迷茫的跟我说“我的日常工作只是点击按钮和按键盘”了，因为我们相信行业的不断成熟，会逐渐将软件测试职业细化，我们的从业者就可以真正的在如下的管理路线和技术路线找到自己的位置，并潜心走向深入的！

  　　 软件测试，是技术主导的职业；不管选择哪条发展路线，都是需要一定的技术沉淀，只是相对来说，管理路线对技术方面要求不高而已。那么我们就先挑重头的技术路线展开讨论。一般来说，一个普通的测试工程师刚入行，3个月左右熟悉企业的工作流程和模式，那么今后的工作内容趋于平稳。然而社会是残酷的！如果单单停留在测试工程师的阶段，若干年后，相信你再也竞争不过那个时候的应届毕业生，当你的工作技能和职业素质趋于与那些朝气蓬勃的年轻人相当时，企业会毫不留情的选择他们，而release你，因为你的成本消耗要比他们高，这是大实话！然而现实又是公平的！因为软件开发技术的不断日新月异，软件功能需求的不断丰富多样，决定软件开发这一系统工程的错综复杂，因此为了保证软件的质量，就要提高测试的水平，这也就为软件测试职业的细化起到先决因素，也是目前社会上出现招聘专项测试工程师的必然趋势！因此，这个趋势给了我们这些常规测试工程师一个空前的好机会！所谓“以毒攻毒”，软件开发靠的是技术，为了测试软件，也必须用技术；那么我们就来看一下从技术路线，软件测试职业发展有哪些方向。

  　　 技术路线，笔者结合国内外软件测试行业现状，划分为三个半方向，分别是自动化测试工程师、白盒测试工程师、性能测试工程师和认证测试工程师，在“双V模型”中右侧体现；前三者适用于通用软件测试领域，认证测试工程师乃嵌入式测试领域职位，至少目前仅出现在嵌入式领域，因此以虚线标记，即“三个半”的“半”。前三条路线对技术的要求程度逐渐增加，三条曲线的斜率也依次递增（认证工程师不参与比较）。

  　　 自动化测试工程师，笔者为其定义在功能测试范畴，指通常所说的依靠自动化测试工具进行软件黑盒测试的工程师。笔者接触的很多测试界朋友，尤其年轻的刚入行者，对测试工具充满了无限的兴趣，他们喜欢那种编写脚本、调试成功后的快感，喜欢看到自定义的日志里记录了本来手工测试烦琐的无聊头顶的工作、而采用自动化方式实现后如此清晰丰富的内容后的兴奋！可以理解，因为笔者也是从那段时光走过来的，现在也负责于我们学员的自动化测试教学工作。从大环境讲，自动化测试是软件测试执行阶段的必然趋势，社会对于软件测试的认可度以及对自动化测试人才的需求必将日益增加，从目前国内做自动化测试的从业者薪资情况看，也普遍高于常规测试工程师，最浅显的道理是“自动化测试比手工测试有了技术含量，^--^”虽然自动化测试在整个行业的普及不是一朝一夕，但是从个人角度讲，自动化测试可以作为个人的发展方向之一，因为如果你率先掌握了这种技术，等到社会需要时，你已成为这个职位的成熟操作者！而国内的51testing把握了时代前沿，与自动化测试工具巨头厂商Mercury（美科利）合作，在中国唯一推出Mercury自动化测试全套技能认证（CPE/SP/CPC），相比其它初等认证，它的实效性和价值性更具意义，也为测试从业者提供了一个进入自动化测试领域的快捷方式！

  　　 白盒测试工程师，笔者定位于在软件测试周期的单元测试阶段对软件进行的代码级测试的人，包括代码走读、代码功能与逻辑测试、代码内存泄漏检查、代码运行效率检查、代码测试覆盖率分析等。如果说，自动化测试只是依靠脚本语言完成测试脚本编写与调试的过程（因为自动化测试工程师的工作重点不在编写脚本），对于自动化测试工程师的技术要求要相对偏低的话，那么白盒测试工程师就要对大型程序开发语言的完全掌握，因此其技术要求相对偏高！而另一方面，白盒测试在目前国内软件行情下，一些公司根本不做，其成本高、代价大的特点决定了这个现状，而一些对软件质量要求非常高（如军事类、电信类、财务金融类等）的企业，也会调动开发工程师来实施此事。但是，还是那句话，测试行业在发展，测试人员能力在提升，软件的开发技术在复杂化，要对软件进行尽可能全面的测试，白盒测试不可忽视！当下专门高薪招聘白盒测试工程师的企业也比比皆是，从中我们可以感知，白盒测试工程师会是很多有开发背景、意欲进入测试行业的良好突破口，白盒测试人员的需求也会逐渐增加。

  　　 性能测试工程师，即在系统测试阶段、功能测试后对软件系统性能指标进行采集分析和运行效率检测的人。笔者认为，在一个尽量压缩的测试流程里，功能测试可以手工进行，白盒测试可以不做，但是性能测试必须要做，除非该软件非网络类软件即单机版软件！这里笔者再提一个观点供大家参考：软件测试，从宏观上可以划分为三个大方面：功能测试、性能测试、安全性测试，功能测试说明软件做对了，功能测试+性能测试说明软件做好了，三者结合起来说明软件做的非常好！安全测试暂且抛之不提，这是下一个发展域的内容，但是为了把软件做好，为了真正保证软件的质量，性能测试绝不容忽视；只因目前很多企业由于时间、成本、人力条件的限制，暂且不做性能测试。性能测试工程师相对来说，是三个技术路线里技术要求最高的，因为软件的性能瓶颈归根结底落实到代码的运行效率这个问题上，因此性能测试要做好，性能测试工程师起码要懂开发；而为了发现性能问题，要懂软件开发架构；为了定位性能问题，要懂操作系统、网络协议、应用服务器乃至数据库的原理与使用；为了最终解决性能问题，要根据定位的问题有针对性的对代码、操作系统、网络架构、服务器、数据库进行优化！当然性能测试是一个系统工程师，绝对不是一两个人的事情，对于常规性能测试工程师，具备定位性能问题的能力即可。正因为性能测试工程师技术要求的高超，该职位的待遇也是目前测试技术路线最高薪的一个，实为综合技术能力较强的测试人员的明智选择！

  　　 上述四职业路线由于其技术程度的突出，一般在企业里由测试经理直接所属，与测试主管级别具有相同的待遇，并处于相同发展域。

  　　 进入技术路线的高级域，根据中级域的四个路线，可以细分成五个路线，分别是资深自动化测试工程师、资深白盒测试工程师、资深性能测试工程师、安全性测试工程师、标准化工程师，这些高级技术类人才完全与常规测试经理平齐，属于软件测试职业发展高级域。

  　　 资深自动化测试工程师由自动化测试工程师晋升而来。如果说常规自动化测试工程师只是负责自动化测试脚本本身的设计与开发，那么资深自动化测试工程师的工作内容就是自动化测试这项工作的实施！笔者早年在IBM公开讲座时候，讲过一篇《以RUP原则实施自动化测试》的主题，RUP里提倡自动化测试是一个庞大的系统工程，绝对不是有了技术、有了工具、有了掌握技术和使用工具的人就可以实施的，而是应该把自动化测试当成一个针对企业自身的项目来看待，需要经过引入、计划、设计、测试、执行、配置管理等环节（参加sincky的blog“天行健-君子以自强不息”），而这些自动化测试的流程搭建，就是资深自动化测试工程师的份内之事。另外，笔者要强调，按照国内外自动化测试领域的发展趋势，我们把自动化测试划分为四个发展阶段（我的blog里也有阐述）；也就是说，录制脚本-添加验证点-回放脚本只是最初始的自动化阶段，要在企业实施自动化测试，要有资深自动化测试工程师来设计数据驱动，开发测试框架，甚至一些企业内部自主开发小型测试工具（而非商业工具）的先例，这些也都是建立在资深自动化测试工程师具有深厚的技术底蕴后，主导其他人员协调完成的事情。

  　　 资深白盒测试工程师，其工作内容包含常规白盒测试工程师的内容，除此之外，要协助测试经理或测试总监攻关测试方法与技术性难题，因此其技术水平更加雄厚。如果常规白盒测试工程师是停留在某种程序设计语言类型的代码级测试，那么资深白盒测试工程师就要脱离程序设计语言本身，结合不同架构、多种开发技术交互的情况下，寻找代码测试方法，并具有对代码优化的能力。由于该路线在国内很少有实例参考，这里不再赘述。

  　　 资深性能测试工程师，来源于常规性能测试工程师，按照常规性能测试工程师的技术要求，资深性能测试工程师应该具备性能测试整体方案的设计能力，以及软件系统性能问题定位和性能优化的能力！初此之外，也要对主流的软件开发模式下的应用系统具有敏锐的洞察意识和感知意识。软件开发的架构会日益复杂化，软件应用的各种软硬件平台、数据库类型、服务器类型、网络协议层出不穷，不得不说，都为性能测试的从业者们提出了严峻的考验！值得庆幸的是，各种同类产品的厂商在开发产品时都遵从业内统一标准，性能测试人员结合自身的丰富经验，加上对软件性能测试技术的研究，这样的考验我们欣然面对，这样的人才则会日益增多，在软件测试行业里充当佼佼者地位。

  　　 安全性测试工程师，笔者将其从性能测试工程师衍生出来，因为只有具备性能测试经验的人，才对软件的开发模式、实现架构和技术本身充分了解，才会感知和预见软件系统存在的安全漏洞，加上其本人是测试出身，才知道如何通过系统漏洞尝试攻击软件系统，达到测试的目的。目前国内软件行业对于安全性测试的认识尚未清晰，该职业也更没有普及，一般只限于军事类、机密类、防病毒类或其他高安全性软件的测试工作中。

  　　 再次强调，人类进入文明社会后，任何社会活动都不是独立的个体能够实现的；在高度讲究团队合作、协同办公的今天，软件测试工作更不是测试工程师几个人就能做完所有的事情的；上述各发展路线的技能要求，只是为了增强个人职业突破的砝码，你的砝码越多，“被利用”价值越大，为企业创造利润的程度越高，企业自然给予你更丰厚的回馈！达尔文伯伯的“优胜劣汰”自然规律不会变，“多劳多得、少劳少得”的市场规律也不会变！

  　　 曾经有如此众多的测试职业发展路线放在我面前，结果我没有珍惜；等到软件测试行业发展到成熟阶段，我想入行却入不了行的时候，我才后悔莫及；尘世间干测试最大的不幸莫过于此；如果非要问sincky：再往上的发展通道是什么，那么sincky一定要告诉你，技术专家域！

  　　 在技术路线，向上继续提升的方向，我们称之为“技术专家”；如果说前面描述的技术职位的所涉范围都定位在企业内部，即企业级资深性能测试工程师，那么技术专家，我们可以看作是领域级专项人才！随着软件测试行业的职位不断细化，每个人在自己擅长的领域走向深入，都可以成为该领域的技术专家，技术专家在自已经营的领域里，具有个人独到的见解和深厚的技术实力，而这类人才可以不再从事具体的测试工作，而是提供行业性测试技术咨询、培训等，为软件测试整体行业的发展，起到了鲜明的带头作用。在一些专业的咨询、培训公司，或者IBM、Microsoft等巨型公司，不乏这样的人才；然而目前在我国，这样的人才较少，但是却可以为我们大家提供努力方向，只要我们每个在技术路线供职的测试从业者，规划好自己的职业人生，并以坚韧的毅力和顽强的斗志，若干年后，你我皆可笑谈测试人生，把酒临风，其喜洋洋者矣！而目前在国内几个IT行业发达的省市，专项于软件测试服务或一些大型软件企业，也有这样的职位暂露头角，我们深信，社会对高端人才的需求趋势是越来越大的，更多的优秀企业也会为员工提供更多、更广的发展空间，值此大好形势，就看我们个人如何充分利用这些上升通道了。

  　　 在我们的软件测试从业人员里，有这样一部分群体：他们非计算机相关专业毕业，不懂软件开发，由于国内种种对软件测试人才的偏激认识，认为测试人员不需要懂开发，只要会编写文档、执行用例即可；因此很多测试工程师并不具备开发背景，并且对软件技术掌握肤浅，而对于没有技术底蕴的人强迫其走技术路线，不能不说是一种折磨！因此，这个群体里的朋友，是不是认为自己只能做一辈子常规测试工程师呢？答案是否定的，因为在“双V模型”的左侧，是软件测试职业发展的管理路线。软件测试的管理路线，与通用职业发展示意图的“高管理-低技能”并不完全相同，只因软件测试独具的行业特点，我们认为软件测试行业的非技术路线发展方向，更多的是从软件测试行业衍生出来的职位，如质量保证、配置管理。如果说软件测试职业发展的技术路线更侧重于职业技能的提升，那么这条管理路线则更侧重于职业素质的积累（笔者强调是“侧重”，并不表示不需要）；换句话说，技术路线更侧重人的智力因素，而管理路线更侧重人的非智力因素。

  　　 从事了1到3年左右的常规测试工程师，在经过对个人性格特点剖析后，如果认为自己是一个倾向于“高管理-低技能”的类型，那么想要实现自己的职业提升，可以向中级发展域的配置管理工程师、质量保证工程师、业务测试工程师转型。

  　　 配置管理(SCM)与质量保证(SQA)同是CMM中的关键过程域（KPA），也同是现代软件工程里的必要角色，与软件测试同属软件开发团队的重要组成部分。只因这两个角色在软件工程里的人员配比数量相对较少，还不如软件测试这样规模化乃至于形成行业，而最多是一个职业；另外一个社会现象是，企业很少直接从社会直接招聘配置管理工程师和质量保证工程师，而通常的做法是从企业内部的现有测试员工队伍里选拔，而转型后的测试工程师，就成为SCM或SQA。分析其原因，我们可以感知，SCM、SQA与软件测试工程师都是关注于软件质量的相似职位，社会对于配置管理、质量保证的定义和工作内容并未普及，与其直接从社会招聘“0”基础的人来培养，倒不如从软件测试人员里升华！一般来说，这两种职位的上报对象是项目经理或相同级别管理者。

  　　 转型后的配置管理与质量保证工程师，一定要转变一个意识，那就是常规测试工程师的工作范围很大一部分（不是全部）只限于测试流程，而配置管理和质量保证的工作范围是面向整个软件开发流程，二者的职业要求都非常重视软件工程知识体系的建立和软件开发总体流程的实施能力。由于配置管理工程师除了企业配置管理流程的搭建与实施外，一般会涉及配置管理工具的管理与维护，而质量保证工程师更多的工作是软件开发流程的控制与维护，故而配置管理对技术的要求稍高于质量保证。随着我国软件行业水平的不断发展，众多软件公司纷纷通过CMM/CMMI，企业对于软件开发团队的角色配比制度也将逐渐健全，当前社会对配置管理与质量保证工程师的职位需求日益增加，种种现象表明，对于软件测试工程师出身的从业者，转型至SCM/SQA不失为突破个人职业生涯瓶颈的又一通道！

  　　 业务测试工程师，笔者定义为面向行业类软件业务逻辑与工作流测试的人员。当前软件开发类型，很大一部分是行业类软件的应用，如ERP、SCM、CRM、OA、电信、金融、财务、嵌入式、通信、手机、游戏……这就要求从事行业类软件测试的人员具备行业背景、业务知识，熟练该行业工作流程。从社会上出现的很多对此类经验要求的测试工程师招聘信息中，我们更加肯定这种趋势；所谓存在即是道理，既然社会上有了需求，那么就可以作为个人发展的方向。而另外一个特点是，业务测试工程师的工作内容主要是黑盒测试，属于功能范畴，因此对技术要求不大，设置一些大型行业类软件公司的业务测试工程师薪资丰厚，但是完全可以不懂技术，因为它的工作性质决定了不需要懂很多的技术！他们甚至连软件的界面测试都不做——交给常规测试工程师实施，而完全关注软件的业务性和易用性，由于其深厚的行业背景，可以为软件的在正式发布前提出很多建设性的意见，而这些建议正是软件开发商提高产品易用性、增加用户满意度、开拓市场、创造利润的关键因素之一！

  　　 当管理路线的中级域方向继续上升至高级域，就分别到达配置管理经理、质量保证经理、产品经理、业务专家，这类人才地位高、待遇厚，一般资深的软件工程领域专家都聚集于此。

  　　 如果说配置管理工程师、质量保证工程师更加侧重于配置管理流程、质量保证流程的实施与日常管理维护，那么配置管理经理、质量保证经理就是更侧重于配置管理流程、质量保证流程的建立与改进。一般在中小软件企业，可能没有这两个角色，而全部的配置管理或质量保证工作都由工程师担当；但是大中型软件企业对资深配置管理经理、资深质保经理求贤若渴。软件系统越庞大，软件开发团队规模就越庞大，软件开发流程中出现问题的几率就越高，高效管理软件开发流程，不断改进软件质量，是每个软件公司在技术上没有顾虑后的下一个急需攻破的难关！

  　　 业务专家，属于行业内咨询、顾问的角色，已经几乎脱离了测试工作本身，而更多为企业的产品需求分析、设计、开发、测试等各个环节提供指导工作，其目的也是提高软件的易用性和稳定性，减少后期不必要的需求变更。该职位也同样在目前热点行业的大中型软件企业有所设立。

  　　 产品经理，这个职位在很多企业有所设立，笔者认为它是质保经理的派生，只是它更侧重于软件在产品化之前的质量监控工作，包括软件开发流程、软件测试等技术与管理的各个方面。由于该职位在业内没有明显定义，而根据不同企业的职位定位不同，这里无法统一陈述。

  　　 管理路线的最高发展域是咨询域，与技术路线的专家域类似，在配置管理、质量保证、软件产品化、行业领域达到高深造诣的人才，他们有丰富的从业经验、深厚的管理底蕴，具有对软件工程高瞻远瞩的慧眼和胆识，往往供职在专业的咨询与培训公司，提供IT业管理类咨询与培训的服务，推动着软件行业的前进。国内外很多为软件企业进行CMM咨询和实施的公司里，就是这些人才的大本营之一！

  　　 笔者认为，在“双V模型”的管理路线里，中低级发展域的人才对技术与管理的区分较为明显，而到了高级与更高级发展域，更多的是复合型人才，软件业以技术为主导，没有一定技术积累，还是很难达到高级境界；要在管理路线练出“上乘武功”，还是希望大家在主攻管理与流程类课题的同时，多丰富下自身的技术层面，嘿嘿！

  另外，笔者提倡管理与技术两条路线的平齐，而并非目前社会上认为的技术要比管理低一等，技术是靠吃青春饭，在这些人才到达最高发展域的“咨询”与“专家”层面，二者应该完全具有相同的地位和待遇，只是“称谓”不同罢了！

  　　 “双V模型”是sincky结合当前国内外软件测试行业现状提出的职业发展流程图，仅供测试从业者参考，并非一个“死”的框架，大家不要拘泥于流程图本身；其实目前国内很多上升到高级域或最高域的资深人才，很多都是跳跃式、甚至跨越式的职业发展，因为命运掌握在自己手里，任何人都剥夺不了设计自身人生蓝图的权利；而另外一个角度是，任何人都不该不珍惜为自己规划职业生涯的机会！

  　　 软件测试，一个日出东方的国际型行业，虽然偶尔会弥漫晨雾，甚或有暴雨来袭，但是我们都该坚持！有人说：“什么叫失败？”答曰：“放弃就是失败！”每一次当我们身处逆境时，决不能用软弱的眼泪作为走向明天的见证，更不能用脆弱的感情去拴住生命的航线；是雄鹰就该搏击长空，是蛟龙就该挽起狂澜；沧海横流，方显英雄本色，疆场搏斗，可露壮士肝胆！人生没有豁免权，每位从业者只有怀着不息的斗志，乘千里长风，破万里巨浪，才能支配命运走向辉煌的明天！

  　　

   

• 如果你有过开发经验，哪怕一点点，并且一直以来从事的是功能测试工作，那么推荐你学习自动化功能测试工具，并在此方面深入研究下去。该职位待遇一般是本地城市手工测试工程师的两倍左右，如果到达高级自动化测试工程师职位，从事自动化测试设计或测试框架的开发，待遇会更高。Mercury公司的winrunner和quicktestpro，是目前最主流的自动化功能测试工具，学习二者的方法也很简单，只要懂得c语言和VBscrīpt即可。要深入学习，当然还要熟悉自动化功能测试的流程、管理及深层开发（包括测试框架、库函数等）。当前国内的应用软件开发，主流还是c/s与b/s两种架构，前者一般采用vb、vc、delphi、pb或java等开发，而winrunner工具对此类软件支持得比较好，很适合在这样的软件测试活动中采用自动化测试；后者一般是采用.net或j2ee技术开发的基于浏览器类软件，测试该类软件就非quicktestpro莫属了，它是mercury公司专门针对web程序的自动化测试工具。由于自动化功能测试工具品牌多，入门简单，因此，也是众多立志成为自动化测试工程师的首选。
• 作为一名软件测试从业者，我们知道执行性能测试，使用手工方式是无法想象的，因此借助工具来实现是非常必要的。目前业内存在两种现状：一是很多公司为了节约购买工具的成本或本身不要求软件性能指标而干脆不执行性能测试；二是由于性能测试是一门博大精深的技术工作，起步较高，因此这方面的高手不多，造成很多大中型软件企业或外企严重缺乏性能测试工程师！性能测试工程师待遇，一般是本地手工测试工程师的三倍甚至更多；我们接触的企业客户需求里，很多开价上万的性能测试工程师职位，竟然很难招到。随着软件开发技术越来越高深，业务逻辑越来越复杂，对软件的质量要求同样也会越来越高，软件一定会存在性能缺陷，因此对软件的性能要求也会随之而来；况且，软件的性能指标是软件用户手册里的重要组成部分，从正规测试流程上来说，凡是网络应用软件，不可不做性能测试！但是，从事性能测试的工程师，需要掌握太多的知识，包括计算机网络、数据库、操作系统、服务器等，而且还要有深厚的性能测试计划、设计、分析能力，以及丰富的性能测试经验，这些如果单靠个人的自行摸索，肯定是不太实际的。Mercury公司的loadrunner，是目前国际上性能测试工具的绝对领导者，具有百分之75的市场占有率；在国内，业界同行也都是提起性能测试首先想到loadrunner；因此loadrunner是在软件测试领域里立志成为一名合格的、优秀的性能测试工程师的朋友们的绝对首选。
• 如果你从来没有过软件开发经验，一直从事的只是手工测试，而且对软件测试的流程管理有着浓厚的兴趣，尤其对于那些从事测试的姑娘们！testdirector都听说吧？它集测试需求、测试用例、测试执行、软件缺陷管理于一身，将软件测试的整个流程统一管理，并支持异地分布式测试资源管理。和众多的软件测试同行接触，我们愈加发现一个问题，那就是我们很多的业界朋友，缺乏完整的、系统的软件测试知识体系，喜欢满足现状，而不去思考如何更加有效的实施软件测试活动，优化软件测试流程。针对这种现状，学习国外优秀的软件测试流程与管理经验，就理所当然了。而testdirector就是当前市场上最优秀的软件测试流程与资源管理的工具，目前本人还未见过一款测试管理工具集成如此众多功能（当然它的升级版quality center也是mercury公司的）。因此，掌握该款工具的使用，是立志成为软件测试管理者的一个非常必要的方面。
• 其他自动化测试领域，本文暂不讨论，例如白盒测试、特殊类型测试等