个人认为软件测试人员在初期选择软件测试职业的时候，重点应该放在软件测试的能力锻炼和软件测试项目经验的积累上。这个时间应该在开始软件测试职业后的1年到1年半左右。

   当你进入软件测试岗位后，在当前的行业背景下，你的工资可能在2000～3000左右。建议你在这个阶段不要把心思放在如何如何增加你的工资上，而是集中你的所有精力如何快速的打好软件测试的基础、多参加项目、多经历。1年半后，你的工资大概在4000左右。

   同老徐共事过的软件测试人员大概在300人左右，在测试人员的工资情况上老徐还是有一定的发言权的。

   如果你选择的是性能测试这一个软件测试职业工种时，而你又具备了非常强的软件开发能力，你的最佳成长方式就是多多的参与各种软件测试项目，当然这个“各种软件测试项目”指的是大型的软件项目的性能测试工作，例如银行的各种大型应用系统、移动的大型应用系统、税务的大型应用系统、网通/电信的中大型应用系统等，在这个成长过程中还要发挥你的自学和刻苦精神，不断的学习诸如不同类型的操作系统（包括HP UNIX、Windows、Linux、IBM AIX等）、应用平台（包括Bea WebLogic、IBM WebSphere、Oracle IIS等）、数据库（Oracle、SqlServer、Sybase），对于这些，你不需要精通，但是要熟悉它，了解在性能测试中监控它的方法，掌握它的基本性能诊断方法，能向软件开发项目组提供有建设性的调优意见。

   我见过很多软件性能测试人员的发展历程，这当中有几个符合上面的最佳成长方式的人员，他们的工资在三年间从3000多快速的增加到了12000以上。

性能测试的实施成功性来源于对系统用户行为的正确分析；

而性能测试的执行成功性来源于性能测试脚本和性能测试场景的开发正确性；

因此，性能测试工具的操作正确性和熟练程度导致了性能测试脚本和性能测试场景的开发正确性；

例如，在LR中，参数化、检查点、事务、动态数据关联、场景启动方式的设置等，都会对性能测试脚本和性能测试场景的开发存在正确性的影响。

老徐的个人建议：

当你学习Loadrunner的工具操作方法时，先花一周的时间练习LR的基本操作技能，例如事务的添加、测试数据的参数化、检查点的添加、动态数据的关联等，在练习这些基本的操作技能的时候，你不需要了解事务能用来做什么、参数化能用来做什么、检查点能用来作什么、动态数据关联能解决什么问题，只需要练习操作工具，学会这些内容的操作方法。

当你熟练掌握了工具的基本操作方法后，再去学习和理解事务是为了获得用户关心的响应时间、检查点是为了确保获知性能测试执行是否成功、参数化是为了给大量虚拟用户提供不同的测试数据，模拟实际情况、动态数据关联是为了适应服务器处理结果的变化性，等等

这样的方法练习性能测试工具，是一个事半功倍的方法

个人建议，请多指教

　　在进行自动化测试实施时，由于要涉及软件开发方、业务方、手工测试方、自动化测试方、测试管理方等不同的机构或单位，尤其是业务方的人员和软件测试的人员对软件测试的认识处于不同的理解层次，因此，需要自动化测试的实施组事先对自动化测试中要使用的一些概念向各个机构或单位普及，才能使大家在脑海中建立相同的概念范畴，使得自动化测试的实施事半功倍。

　　我把曾经在建立自动化测试体系的过程中规定的一些主要的自动化测试名词分享给大家，以期参考：）

（１）测试需求：

　　是指在一定的测试策略前提下，对应于验证某个系统的业务需求或功能需求的测试要求

1       测试组

测试组需要由以下人员组成：

u          测试项目经理（可以是业务分析师或者业务代表），负责进行测试的管理和作为测试组的代表。

u          测试人员（具有业务知识的人员），负责描述测试案例和定义/选择测试数据。

u          自动化专家（QTP专家），负责依据测试人员提供的信息创建测试自动化的脚本。

1.1    测试准备

测试的准备是一个独立的、分离的阶段，测试员在这个阶段中基于需求文档准备测试（业务设计图）。

测试的准备要依据标准的方法，并应基于本阶段的工作生成标准化的文档。

1.1.1   业务功能测试

基于风险评估，针对每个业务功能的不同风险级别都应有一个对应的测试过程和方法组合：

1）A级风险

利用等价类和组合进行系统性的测试

完全自动化

2）  B级风险

利用等价类进行系统性的测试

       完全自动化

3）  C级风险

随意性测试

手工执行，在TestDirector中提供文档化的执行过程

       对于每个测试过程和方法组合，要提供一个标准的文档进行方法论级的阐述和规定，每个测试人员依据这些标准的测试过程和方法组合进行测试。

在TestDirector中要将测试用例的准备结果作为业务功能的附件。

1.1.2   业务流程测试

业务流程测试是将所有的业务功能组合在一起，使用同一组数据进行工作。

测试员的任务就是要确定每个业务功能的组合是否能连贯的执行。

判断的结果使用矩阵来表示，例如下图：

注：yes（+）；no（-）

业务流程矩阵

从上面的表中我们能获得三个业务流程测试案例：

1)        1，2，2，3，2，4，1，1

2)        1，5，4

3)        1，2，3，4

1.1.3   业务集成测试

使用现有的回归测试案例进行业务集成测试。

在第一个阶段，测试案例仅被自动化，而不考虑测试的覆盖率。

在第二阶段，测试案例将被改进，以提高测试的覆盖率。

对于所有的新项目，回归测试应该在业务功能测试阶段和业务流程测试阶段的测试结果的基础上进行建设。

依据业务流程矩阵创建测试案例集，这个测试案例集应该能覆盖被测系统的所有外部接口。

假定我们的被测系统是Mercury的机票预定系统，它的架构图如下：

业务流程矩阵的设计如下图：

在业务集成测试阶段中的测试案例开发
		1	2	3	4
		预定一个航班	打印机票	查看(866) 评论(0) 收藏 分享 管理 老徐最近翻译的Mercury“最佳功能测试实践”－第二部分 2007-03-04 16:20:18 1.1    测试策略和计划 在制定测试策略时，要基于被测软件的质量目标。质量目标就是测试的需求。它们决定了测试的阶段和质量的目标。要想最优化测试的活动并制定一个切实可行的测试计划，需要将被测软件分解成为一个一个的业务功能。在进行业务功能分解时，要以黑盒的方法来看待被测软件的功能，即独立于软件的实现方法。若想计算测试的效果并且保证测试的活动适合于特定业务的需要，则需要引入风险评估的手段。 1.1.1   需求 测试的必要条件是要确定预期结果或者需求。 为了能更好的了解需求，将需求进行分类是非常有帮助的。 以我们的观点，可以将需求分为功能性需求和质量需求（非功能性需求）。 功能性需求描述了在业务上期望如何使用新的软件系统，且该系统中应该包括哪些功能。 质量需求包括的是软件系统的通用特性，且独立于功能。 1.1.1.1             功能性需求 功能性需求以业务设计图的方式记录于文档中。 为了在TestDirector中将需求作为测试的基础，需要将需求导入到TestDirector中。 相应的业务设计图作为需求的附件存在，并作为将来测试活动的依据。 1.1.1.2             质量需求 质量需求由两部分构成， 一部分是为整个产品或者项目定义的质量目标， 另一部分是每个业务功能的质量需求， 这些业务功能的质量需求取决于风险评估的结果。 1.1.1.2.1       质量目标 1）适应性 组件被修改以适应新需求的难易程度。 2）完整性 组件实现所有需要的能力的程度。 3）正确性 a)        组件在规格分析、设计和实现过程中无错误的程度 b)        组件满足需求或者用户需要与期望的程度 c)        基于给定输入产生相应输出的能力，并且这个过程符合或者满足需求 4）有效性 当组件完成指定任务时，能最少使用所需资源的程度。 5）可维护性 组件被修改以纠正错误，提高性能或其他属性，或者适应被改变了的环境的难易程度 6）模块性 软件系统由离散的组件组成的程度，即改变一个组件时能将对其他组件的影响降至最低。 7）可移植性 软件系统或组件能被转移到其他硬件平台或者软件平台上的难易程度。 8）可靠性 组件在一定的时间内、一定的条件下执行所需完成功能的能力。 9）可用性 用户对软件组件的理解和操作的难易程度。 1.1.1.2.2       业务功能的质量需求 业务功能的质量需求是依据业务的风险进行定义的。 业务风险和技术复杂度的信息存储在测试的需求中。 这两个参数决定了测试的程序和测试的工作量。 另外，针对业务功能分配测试员，并且将测试活动的当前状态落实到纸面上。 只有这样做才能在针对业务功能的整个测试过程中监控测试的状态。   1.1.2   测试阶段的定义 依据已经定义的质量目标，我们需要将测试阶段进行合理的划分。 通常情况有以下几个阶段： 1）开发员自测试阶段（不在我们的考虑范围之内） 2）业务功能测试（单元测试） 3）业务流程测试（应用级的集成测试） 4）业务集成测试（端到端的集成测试） 5）性能测试 6）系统集成测试 下面的表中描述了每个测试阶段需要达到的质量目标：   业务功能测试和业务流程测试是在软件项目开发过程中完成的。 而业务集成测试和系统集成测试则组合成回归测试，用于软件系统上线前或者发布为产品前来检验软件的质量。 1.1.3   质量门 测试是在不同的阶段中完成的。 划分不同阶段的原因就是将不同的质量目标分配到不同的阶段中，从而能将测试的执行尽可能的提前。 所以，在相邻的测试阶段中设置一个质量门就成为保障成功的关键要素。 下面的图中展示了每两个相邻阶段的质量门是如何设定的：     下面是对质量门的一种详细定义： 1）在业务功能测试之后 u          业务功能测试的测试用例执行了80%以上 u          业务功能测试的测试用例（A级风险）执行了100% u          少于5个服务器端错误 u          少于30个中级错误 u          无致命性缺陷 2）在业务流程测试之后 u          业务功能测试通过 u          业务流程执行了100% u          无业务流程完全失效，所有的错误都可以被修复 u          无致命性缺陷 3）在业务集成测试之后 u          业务流程测试通过 u          业务集成流程执行了100% u          无致命性缺陷 1.1.4   功能分解 在计划测试活动之前，功能分解应该作为第一个要完成的活动。 进行功能分解时，应该邀请业务方面和需求分析方面的代表共同参加。 通常情况下，要遵从下面的原则： 1)        每个用户情形都是一个业务功能 2)        如果一组用户情形非常相似，那它们应该组合在一起形成一个业务功能 3)        如果一个用户情形非常大或者非常复杂，则应该将其分解为两个或者更多的业务功能 进行功能分解的思路体现在“将测试的单元确定为包含少量功能点的单位”， 这样，每个测试单元的测试用例的数量就会被限制在一定的范围之内。 我们可以将分解的目标设定为每个业务功能只有最多30-40个测试用例。 1.1.5   风险评估 既然质量保证的基本思路是降低缺陷破坏业务的风险，同时为了确保质量保证的资源得到充分的利用，我们需要对每个业务功能进行风险的评估。 还要考虑到的是，我们也要对技术影响进行分析。 这样我们能对完成每个业务功能的测试活动所需的工作量进行估算。   1.1.5.1             业务风险分析 业务风险评估需要针对被测软件的所有业务功能。 评估的标准应该在整个业务的范围内是唯一的，才能在企业范围内使不同的评估结果具有可比性。           结果 标准 A 高级风险 B 中级风险 C 低级风险 流程的类型 计算/验证 数据的改变 显示 业务影响 合法性 错误信息 无 使用频度 非常频繁 经常 极少 受影响客户的数量 大量/非常重要 查看(968) 评论(0) 收藏 分享 管理 老徐最近翻译的Mercury“最佳功能测试实践”－第一部分 2007-03-04 16:14:42 1       概述        本测试过程作为功能测试的最佳实践，用于实施不同机构的功能测试工作。它可以作为测试计划工作的基础，应用于每个软件开发的项目。在这个测试过程中描述的活动既可以用于新开发的组件，亦可以用于改进现有的回归测试。 2       测试管理 为了能顺利地获得测试的结果，将测试作为独立管理的过程是非常必要的。测试管理可以分为下面四个领域。 1）测试计划 2）测试执行 3）测试控制 4）测试过程改进 用于支持测试管理各个领域的工具可以采用TestDirector。 查看(1288) 评论(2) 收藏 分享 管理 351/212> cloudxu 用户菜单 给我留言 加入好友 发短消息 我的介绍 论坛资料 空间管理 我的栏目 软件性能测试 软件自动化测试 企业测试管理 测试职业发展 软件功能测试 软件测试人生 标题搜索 我的存档 2007年04月 2007年03月 数据统计 访问量: 37559 日志数: 35 建立时间: 2007-03-03 更新时间: 2007-04-12 RSS订阅 清空Cookie - 联系我们 - 51Testing软件测试网 - 交流论坛 - 空间列表 - 站点存档 - 升级自己的空间 Powered by 51Testing © 2003-2021 沪ICP备05003035号 Open Toolbar