爱如凉水
如何有效制定软件测试计划？
刚看到同行在论坛里提这个问题时，感觉这个问题问的太大了，真是不知道该怎么帮助这位同行，今天想想，就从一些硬件方面着手说说吧，我这里说的硬件指的是大概把握点；软件方面是指如何有效灵活应用，由于各种情况太多，个人能力有限，这里就只谈谈要把握的几个基本点。
测试计划的制定，要考虑的因素确实很多，但要抓住最主要的就可以避免大的测试执行风险。
为了有效的制定测试计划，首先要清楚，制定这个测试计划的目的是什么，作用是什么。
考试大认为测试计划的主要作用是：明确工作内容、工作完成时间、工作资源、工作风险等、最终目的是提高测试的工作效率，作为保障测试工作顺利、保质保量完成。
那么，如何有效制定测试计划？ 第一：根据自身实际情况的项目、团队管理情况，要有个合适的测试计划文档模块用于编写测试工作的测试计划、便于向项目中的其它成员告知测试工作是如何安排和进行的。
测试计划文档现在在网上有一堆，看了好几个，自己综合后整理了一个，最终认为测试计划文档大纲要包含如下内容： ------目录 ------1. 简介 ----------1.1 编写目的 ----------1.2 编写背景 ----------1.3 使用范围 ----------1.4 参考资料 ------2. 测试说明 ----------2.1 测试项说明 --------------2.1.1 系统名称 --------------2.1.2 应测试项 --------------2.1.3 非测试项 ----------2.2 测试资源 --------------2.2.1 硬件设备 --------------2.2.2 软件设备 --------------2.2.3 人员安排 --------------2.2.4 测试工具 ----------2.3 测试安排 --------------2.3.1 测试培训 --------------2.3.2 测试进度 ----------2.4 测试文档 ------3. 系统风险 ------4. 测试优先级 ------5. 测试策略 ----------5.1 接口测试 ----------5.2 集成测试 ----------5.3 数据和数据库完整性测试 ----------5.4 功能测试 ----------5.5 用户界面测试 ----------5.6 性能测试 ----------5.7 负载测试 ----------5.8 强度测试 ----------5.9 容量测试 ----------5.10 安全性和访问控制测试 ----------5.11 故障转移和恢复测试 ----------5.12 配置测试 ----------5.13 安装和反安装测试 ------6. 评价准则 ----------6.1 范围 ----------6.2 尺度 --------------6.2.1 测试覆盖率 --------------6.2.2 质量评测 --------------6.2.3 缺陷报告 --------------6.2.4 性能评测 上面这些内容大家看起来会觉的很多很全，这个模板适合大的测试项目，个人用着感觉不错；可能，有的人会问，我可能只是做功能的测试，我只是做一个数据迁移的测试，可能涉及的测试项根本没有那么多，那么我该怎么写我的测试计划呢？ 第二：根据具体测试工作任务情况编写测试计划，剪裁适合自己的测试计划模板 上面给的都是在写测试计划中要考虑的点，就像在执行测试时都要执行的测试用例点有哪些。
具体在写测试计划中，那些信息是需要考虑的，那些东西是不需要考虑的，可以根据自己项目的具体情况进行裁剪和设计即可。
模板只是起到提醒作用，提醒在测试前需要注意考虑的信息都有哪些？在具体编写中，如果没有经验，要适当请教公司内部有经验人士给予评价和指导，便于制定出来的计划是可行的并没有遗漏重要点。
下面是通常非常小的测试任务中，我用过的感觉非常好的测试计划模板表格，供大家参考： 第三：测试计划不是一层不变的，随着项目的进行，会由于各方面的因素（如：提交测试的程序版本质量低、bug量大修改慢、需求变更等等）导致测试计划无法按原计划执行，这时要适当的调整测试计划。
关于如何有效制定测试计划，我只是范范的写这么几点，不知道是否会给大家一些启发；最后还想补充点：在制定测试计划时，关于人员分工这部分，要根据每个人对系统的熟悉程度以及能力情况进行分配，让大家的能量都能得到最大化的发挥。
如何制定软件测试计划
制定计划 1. 分析产品 分析什么 用户（他们是谁，他们做什么的） 操作（这个操作是干什么用的） 产品结构（代码，文件，等）产品功能（这些功能是干什么用的） 产品数据（输入的，输出的，状态，等） 平台（外部的硬件和软件） 怎么分析 走一下产品/原型的主要流程 评审产品和项目文档 咨询设计人员和用户 与类似的产品做比较 可能的工作产出 产品的功能范围概要 注释性的文档 产品的问题列表 执行状态检查 设计人员有没有确认以及批准了产品的功能范围概要？ 设计人员有没有认为你已经正确理解了这个产品？ 你能不能将这个产品形象化并且预测正确的行为？ 你能不能造出产品的测试数据（输入和结果）？ 你能不能配置和操作这个产品？ 你有没有理解这个产品是怎么样被使用的？ 你有没有注意到设计中的漏洞或不一致的地方？ 关于这个产品你还有没有未解决的问题？ 2. 分析产品的风险 分析什么 产品受到的威胁 产品的易受攻击的地方 失败的方式 失败后的影响 怎么分析 评审需求和规格说明书 评审出现问题的一些事件 咨询设计人员和用户 通过探索性风险分析和质量判据列表来评审产品 识别基本的错误/失败方式 可能的工作产出 组件风险列表矩阵 失败模型概要 执行状态检查 设计人员和用户有没有对风险分析达成一致？ 你有没有发现所有的重要的问题，而这些问题是否在测试过程出现呢？ 你是否知道在哪些地方要集中测试精力并获得最大的效率呢？ 设计人员有没有做一些事情使得重要的问题更容易的发现，或减少其发生的概率呢？ 如果你的风险分析是正确的，你是怎么发现的呢？ 3. 设计测试策略 基本策略 Domain testing（包括边界值） 用户测试压力测试 回归测试 Sequence testing State testing 基于文档的测试 结构化测试（单元测试等） 怎么计划 对于风险和产品功能匹配策略 将特殊的和实际的策略形象化 分析是否可用自动化的机会 使用原型去测试probes和harnesses 不要强加计划，让测试人员自己决定 可能的工作产出 各个类型的报告怎样应用的测试策略文档 风险/任务的matrix 已选择的策略中存在的问题或挑战列表 对产品覆盖比较少的部分提供的建议测试用例（如果是必须的） 执行状态检查 设计人员对这个测试策略达成一致了吗？ 这个策略对于项目每个参与人员以及协助人员都有用吗？ 这个测试策略是否很基本了？是否也容易的应用到这个产品中？ 这个测试策略是否透露了所以的重要的问题 4. 计划安排 安排的内容 测试时间的评估和计划 易测性的工程分析 测试团队人员（详细的能力） 测试人员的培训和监督 测试人员的任务的指定 产品开发信息的收集和管理 项目会议，沟通，协调的方式 与其他已存在的功能之间的关系，包括开发过程中 测试平台的认购和配置 测试工具盒自动化 需要用到的测试桩和mock 测试套的管理和维护 建立和输出协议约定 测试周期管理 问题报告系统和约定 测试状态报告的约定 代码冻结和增量测试 测试后期的压力管理项目阶段输出协议约定 测试效率的预估 可能的工作产出 问题列表 项目风险分析 任务和责任matrix 测试时间表 与开发之间的约定和协议 执行状态检查 这个项目所列的安排是否支持测试策略？ 是否存在一些问题会阻碍测试的执行？ 在可见性的问题面前，这些安排和策略是否适合？ 你现在是否开始测试还是以后整理剩下的问题？ 5. 分享计划 分享的方式 让设计人员和股东都参与到整个测试计划的制定过程中 更主动的获取关于测试计划的意见 尽最大可能帮助开发人员保持进度 帮助开发人员理解他们做什么会影响测试 与技术支持和写技术文档的人分享产品质量信息 让设计人员和开发人员评审并且批准所以相关的文档 记录并加强与开发之间的约定 让参与人员评审测试计划的细节 在测试计划中尽量减少没必要的信息以增加评审的效率 目标 对于测试过程达到一致的理解来自：领测软件测试网。
我本人觉得挺赞的。
软件测试项目的启动、规划有哪些呢？
一般地，项目启动过程组包括两个过程[参见PMBOK2004版]：即制定项目章程和制定项目初步范围说明书；而项目规划过程组则会综合项目的成本、范围、时间、质量、风险、人力、沟通、采购等因素制定项目计划，该项目计划将用于指导项目的实际执行。
对任一项目而言，有三个文件是非常重要的。
即：项目章程、项目范围说明书，项目管理计划。
这三个文件均产生于项目启动阶段和项目规划阶段。
其中项目章程被认为是三大文件之首（项目章程、项目范围说明书，项目管理计划）。
一个项目，不论大小，都应该有项目章程。
一个典型的项目章程包括如下内容：1）项目名称及背景描述；2）项目经理任命及职责范围界定；3）项目业务需求描述；4）项目发起的原因；5）主要项目干系人及其初步需求；6）产品及预期交付成果描述；7）项目假设和约束条件。
项目章程由项目发起人（Sponsor）签发，自签发之日起，项目经理即获得法定权力。
项目经理在获得法定权力之后的第一动作是制定项目初步范围说明书。
为了制定这份文档，他/她将广泛地收集来自项目发起人的需求，以便在项目计划正式编制之前，与项目发起人在项目范围的理解上达成一致。
项目初步范围说明书还将在后续项目范围规划过程中进一步细化，并融入项目客户、执行组织、项目干系人等各方面需求，进而形成完整的项目范围说明书。
项目初步范围说明书编制完成以后，项目经理将进入项目计划编制阶段。
这个阶段将会涉及项目管理方方面面的规划、计划。
比较典型的有项目范围基线、项目成本基线、项目进度计划、项目质量计划、项目风险分析及应对计划、人力资源计划、项目沟通计划以及项目采购计划。
这些计划、规划经过权衡、调整，最终将集成为一个完整的项目管理计划。
项目管理计划经由项目发起人、高级管理层审批以后，即可生效。
此后，项目经理将召开项目开工会议（Kickoff meeting），宣布项目正式开始进入执行阶段。
学习软件测试未来的职业发展怎么样？
1 、就业竞争小软件测试工程师目前正在成为IT行业中一个新亮点，不仅其从业人员薪水高、人员需求增加快而广受关注，而该行业未来良好的发展前景也受到肯定。
据国家权威部门统计，中国软件人才缺口中，其中30%的人才为软件测试人才。
软件测试作为软件质量把关的重要环节，已经愈来愈引起国内软件企业的关注，致使软件测试人才的需求升温，但是，由于我国企业对于软件测试技术在整个软件行业中的重要作用认识较晚，因此，这方面的专业技术人员在国内还是凤毛麟角，人才供需之间的缺口超过20万，这已成为影响中国软件产业发展的瓶颈。
据招聘网站51job数据显示，软件测试工程师将成为2018年最紧缺的人才，该类职位的需求主要集中在沿海发达城市，其中北京、上海的需求量分别占33%和29%。
同一时间中华英才网发布了最新一期的IT职场人气排行榜，IT人才仍是企业需求量最大的人群，作为软件开发流程中的重要一环，软件测试岗位渐渐“浮出水面”，并凭借其庞大的人才需求和广阔的职场发展前景日渐成为IT职场就业的大热门。
2 、职业发展方向由于工作的特殊性，测试人员不但需要对软件的质量进行检测，而且对于软件项目的立项、管理、售前、售后的等领域都要涉及。
在这过程中，测试人员不仅提升了专业的软件测试技能，还能接触到各行各业，项目管理、沟通协调、市场需求分析等能力都能得到很好的锻炼，从而为自己的多元化发展奠定了基础。
经过软件测试岗位洗礼的人才往往是行业中的多面手，比其它IT人才具有更强的可塑性，在技术、管理、市场甚至其它非IT领域都能得到良好的发展。
3 、越老越吃香软件测试员的一生如同一名医生的一生，随着职业阅历和临床经验的丰富累积，到一定的年龄他们通过“望闻问切”就能知道毛病出在什么地方。
因此，有人说软件测试员和医生是最不需要用“青春”来保证和延续自己职业寿命的职业。
软件测试工程师地位‘翻天覆地’的变化，源自信息产业的发展以及软件企业自身、用户成熟度的不断加深。
”。
一方面，计算机使用越来越普及，越来越多的领域使用了计算机，特别是一些重要领域如国防、银行、金融、通、航天等，他们对软件质量要求很高。
同时一些重大事故的发生，也引发了人们对软件质量的关注。
毋庸置疑，在经历了长期的不为人知和可有可无后，软件测试工程师目前已变得非常抢手。
4 、高薪没商量软件测试工程师作为软件质量的把关者，其职能在于保证交付到客户手中的软件可靠好用，运行畅通无阻。
从产品定义到产品开发再到产品维护，都离不了软件测试。
但由于软件测试的重要性是近两年才被充分认识到的，高校教育和企业培养都还没有跟上，致使软件测试人才严重供不应求，出现跑步上岗、快速提升的状态，薪资也逐步走高，优秀的软件测试人才年薪可达十万，甚至二、三十万或更高。
软件测试的发展现状怎样？
&nsp；软件开发中出现错误或缺陷的机会越来越多，市场对软件质量重要性的认识逐渐增强。
所以，软件测试在软件项目实施过程中的重要性日益突出。
但是，现实情况是，与软件编程比较，软件测试的地位和作用，还没有真正受到重视，对于很多人（甚至是软件项目组的技术人员）还存在对软件测试的认识误区，这进一步影响了软件测试活动开展和真正提高软件测试质量。
软件测试的历史和发展
软件测试发展史软件测试是伴随着软件的产生而产生的。
早期的软件开发过程中，那时软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。
对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试 到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。
这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。
人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证（SQA）的主要职能，包含软件质量评价的内容，Bill Hetzel在《软件测试完全指南》（Complete Guide of Software Testing）一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动。
测试是对软件质量的度量。
”这个定义至今仍被引用。
软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题 软件测试已有了行业标准（IEEE/ANSI ）,1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。
这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。
它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。
软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。
进入上世纪90年代，软件行业开始迅猛发展，软件的规模变的非常大，在一些大型软件开发过程中，测试活动需要花费大量的时间和成本，而当时测试的手段几乎完全都是手工测试，测试的效率非常低；并且随着软件复杂度的提高，出现了很多通过手工方式无法完成测试的情况，尽管在一些大型软件的开发过程中，人们尝试编写了一些小程序来辅助测试，但是这还是不能满足大多数软件项目的统一需要。
于是，很多测试实践者开始尝试开发商业的测试工具来支持测试，辅助测试人员完成某一类型或某一领域内的测试工作，而测试工具逐渐盛行起来。
人们普遍意识到，工具不仅仅是有用的，而且要对今天的软件系统进行充分的测试，工具是必不可少的。
测试工具可以进行部分的测试设计、实现、执行和比较的工作。
通过运用测试工具，可以达到提高测试效率的目的。
测试工具的发展，大大提高了软件测试的自动化程度，让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。
采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。
设计良好的自动化测试，在某些情况下可以实现 “ 夜间测试 ” 和 “ 无人测试 ” 。
在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。
而测试工具的选择和推广也越来越受到重视。
在软件测试工具平台方面，商业化的软件测试工具已经很多，如捕获/回放工具、Web测试工具、性能测试工具、测试管理工具、代码测试工具等等，这些都有严格的版权限制且价格较为昂贵，但由于价格和版权的限制无法自由使用，当然，一些软件测试工具开发商对于某些测试工具提供了Beta测试版本以供用户有限次数使用。
幸运的是，在开放源码社区中也出现了许多软件测试工具，已得到广泛应用且相当成熟和完善。
软件测试的发展方向
相信每个工作时间在1-3年的人大多都有这种想法，我也有。
不过我现在有了新的想法。
什么东西该学？什么都该学。
有多少东西要学？太多。
该学到什么程度？越深越好。
学什么对我将来有好处？很多。
……………………类似的问题困扰了我好久，也让自己变得很累，现在我轻松了很多。
-------因为，做好工作就是最好的学习，其实，不管什么都是在工作中学会，用好的。
做好现在的工作才是最最重要的！！！！如果心里有太多的想法，肯定会被拖累，工作做的没有乐趣，也没有学到东西，是不是什么也没有得到，对自己一点帮助也没有，过的也很累。
再者说我看你的工作挺好的，测试就是这样，有黑盒有白盒，你要是懂一门语言的话到时可以找下白盒的，我有没有就是这样的还有，黑盒测试和业务有很大关系，相信你知道这个，你的还是财务的，确实挺好的。
总结下，还是好好工作，该学什么就学什么，没问题的。
。
。
肺腑之言，希望对你有些帮助。
。
。
。
我的团队【测试我知道】，邀请你加入！！！！！...
软件测试的工作计划和目标
每天在忙忙碌碌的维持生计的工作中，甚至没有好好想过我在这个阶段应该做什么？而不是被要求去做什么。
经过这么几年在软件测试行业的折腾，也有好好的想过这个问题，在特殊的阶段我们应该做好什么？尤其在软件测试行业。
大家都比较看好软件测试行业，只是因为表面上看起来：钱多事少加班少。
其实这个都是针对个人运气好的童鞋才会有此待遇。
在不同的阶段做好不同阶段的事情，才有可能离这个目标更近，作为一枚软件测试人员，也许下面才是我们最真实的写照。
{第一年} 当年也是一头撞进了软件测试行业。
迫切的想要了解这个行业，它的升职模式，如何才能薪资更高。
但是以过来人的经历，告诉你：做好当前的事情。
把上司交给你的每一份任务都仔细认真的去完成，体现你作为一个初入职场的新人的价值。
新人进去，不奢望你能够做多大的贡献，只希望交代给你的事情，不用给你擦屁股就行。
第一年，如果你每天都很积极，迫切的想要完成更多的任务，那么这一年的你将会进步最快。
对功能业务逻辑的整体把握感，对测试用例的编写能力，对功能测试进度把握，这些都将会成为你以后工作的坚实基础。
这一年，请打好你的基础，暂时忘记自动化代码工具这些，你没有坚实的软件测试行业内知识和接触到的一些专业名词，你拿着工具也都是徒然。
{第二年} 经过第一年的努力，你已经具有比较牢靠的软件测试基础，已经完成了一轮一轮的重复的手工测试，对，在这个阶段我们应该做什么？是每天上班等下班还是利用这段时间做点有意义的事情？毋庸置疑，如果你是积极向上的请你，那答案肯定是后者。
建议是：把你每天做的重复的功能测试，利用工具来做。
不建议大家过早的接触代码或者是性能这块，如果你还是职场第二年，因为你还见识的太少，根本达不到写代码和性能的这个阶段，要能够写脚本和做性能，需要你对整个测试框架和业务逻辑都有一个比较强的把握能力，否则，你做的事情，就会是无用功。
就好比你学写代码，却发现自己永远停留在print(“hello world”)的水平；你学性能，缺发现自己永远停留在录制脚本的水平。
可以接触的工具：QTP/Jmeter，这两款工具都可以帮助你减少相对的劳动力，把一些重复的工作都利用工具来进行。
学好了用活了，下次升职加薪或者是换工作，幸运之神都不会错过你。
{第三年} 终于迈入了第三个年头，恭喜恭喜，还能够坚持说明你没有被这个行业淘汰。
经过两年的基础打底，如果你不是混混过日子，那么你的基础会让你的工作效率大步提升，你也会有更多的时间来做的别的事情，毫无疑问还是：学习。
这个时候，我们可以尝试着接触一些代码和一些框架，把你自己所学的知识融入到你自己的项目中去。
能够把自己的项目整理出一个测试框架，那么你就是对这个公司的工作是有非常大的推进作用的！ 建议：学习Python,selenium等。
{第四年} 有了代码基础后，发现你的工作量又被简化&优化了。
这个时候我们应该对网站的架构，代码知识，数据库知识，网络瓶颈，系统优化等各个方面都有了比较深入的了解，我们终于可以进一步来做性能测试了！这个时候，我们突然明白：做性能测试不仅仅是录制脚本了！你需要去优化脚本，去设计场景，去获取目标用户量，去执行压力测试，去分析压力结果，做好这些之后，去综合分析发生性能瓶颈的是数据库优化问题，还是网络瓶颈问题还是本来的架构就存在问题？ 推荐：LR/Jmeter {第N年....} 未完待续.......如果你能坚持到第五个年头，我希望是对软件测试行业而言是个有用的人；对软件测试行业有点点推动的人；对公司软件测试工作有建树的人。
女生做软件测试前景如何？ 有什么职业规划吗？
我也是女生..大三暑假报的培训班学的软件测试..现在在一家语音公司实习快四个月了..软件测试的前景是蛮好的..但前提是要学会很多东西..像楼上那位讲的..“至少要了解2种以上的OS基本知识。
第二、要能编写测试计划、测试用户、缺陷报告、测试报告。
第三、要至少掌握一门自动化或性能测试工具，且能独立编写测试脚本”等..其中最重要的是“要至少掌握一门自动化或性能测试工具”.如果你做到这点..你的测试前景应该就蛮好的..至于职业规划..我目前培训加实习这段时间觉得我的编程基础太差..准备自己先学习点实用的语言.其次英语也很重要..一定要努力学习英语..然后自己看看网上招测试的要求.向那个目标发展..找到工作后.边工作边学习..一两年之后.相信你的测试之路就会越走越顺.....
软件测试人员都有什么职业发展方向？
从事了1到3年左右的常规测试工程师，在经过对个人性格特点剖析后，如果认为自己是一个倾向于“高管理-低技能”的类型，那么想要实现自己的职业提升，可以向中级发展域的配置管理工程师、质量保证工程师、业务测试工程师转型。
配置管理（SCM）与质量保证（SQA）同是CMM中的关键过程域（KPA），也同是现代软件工程里的必要角色，与软件测试同属软件开发团队的重要组成部分。
只因这两个角色在软件工程里的人员配比数量相对较少，还不如软件测试这样规模化乃至于形成行业，而最多是一个职业；另外一个社会现象是，企业很少直接从社会直接招聘配置管理工程师和质量保证工程师，而通常的做法是从企业内部的现有测试员工队伍里选拔，而转型后的测试工程师，就成为SCM或SQA。
分析其原因，我们可以感知，SCM、SQA与软件测试工程师都是关注于软件质量的相似职位，社会对于配置管理、质量保证的定义和工作内容并未普及，与其直接从社会招聘“0”基础的人来培养，倒不如从软件测试人员里升华！一般来说，这两种职位的上报对象是项目经理或相同级别管理者。
转型后的配置管理与质量保证工程师，一定要转变一个意识，那就是常规测试工程师的工作范围很大一部分（不是全部）只限于测试流程，而配置管理和质量保证的工作范围是面向整个软件开发流程，二者的职业要求都非常重视软件工程知识体系的建立和软件开发总体流程的实施能力。
由于配置管理工程师除了企业配置管理流程的搭建与实施外，一般会涉及配置管理工具的管理与维护，而质量保证工程师更多的工作是软件开发流程的控制与维护，故而配置管理对技术的要求稍高于质量保证。
随着我国软件行业水平的不断发展，众多软件公司纷纷通过CMM/CMMI，企业对于软件开发团队的角色配比制度也将逐渐健全，当前社会对配置管理与质量保证工程师的职位需求日益增加，种种现象表明，对于软件测试工程师出身的从业者，转型至SCM/SQA不失为突破个人职业生涯瓶颈的又一通道！ 业务测试工程师，笔者定义为面向行业类软件业务逻辑与工作流测试的人员。
当前软件开发类型，很大一部分是行业类软件的应用，如ERP、SCM、CRM、OA、电信、金融、财务、嵌入式、通信、手机、游戏……这就要求从事行业类软件测试的人员具备行业背景、业务知识，熟练该行业工作流程。
从社会上出现的很多对此类经验要求的测试工程师招聘信息中，我们更加肯定这种趋势；所谓存在即是道理，既然社会上有了需求，那么就可以作为个人发展的方向。
而另外一个特点是，业务测试工程师的工作内容主要是黑盒测试，属于功能范畴，因此对技术要求不大，设置一些大型行业类软件公司的业务测试工程师薪资丰厚，但是完全可以不懂技术，因为它的工作性质决定了不需要懂很多的技术！他们甚至连软件的界面测试都不做——交给常规测试工程师实施，而完全关注软件的业务性和易用性，由于其深厚的行业背景，可以为软件的在正式发布前提出很多建设性的意见，而这些建议正是软件开发商提高产品易用性、增加用户满意度、开拓市场、创造利润的关键因素之一！ 当管理路线的中级域方向继续上升至高级域，就分别到达配置管理经理、质量保证经理、产品经理、业务专家，这类人才地位高、待遇厚，一般资深的软件工程领域专家都聚集于此。
如果说配置管理工程师、质量保证工程师更加侧重于配置管理流程、质量保证流程的实施与日常管理维护，那么配置管理经理、质量保证经理就是更侧重于配置管理流程、质量保证流程的建立与改进。
一般在中小软件企业，可能没有这两个角色，而全部的配置管理或质量保证工作都由工程师担当；但是大中型软件企业对资深配置管理经理、资深质保经理求贤若渴。
软件系统越庞大，软件开发团队规模就越庞大，软件开发流程中出现问题的几率就越高，高效管理软件开发流程，不断改进软件质量，是每个软件公司在技术上没有顾虑后的下一个急需攻破的难关！ 业务专家，属于行业内咨询、顾问的角色，已经几乎脱离了测试工作本身，而更多为企业的产品需求分析、设计、开发、测试等各个环节提供指导工作，其目的也是提高软件的易用性和稳定性，减少后期不必要的需求变更。
该职位也同样在目前热点行业的大中型软件企业有所设立。
产品经理，这个职位在很多企业有所设立，笔者认为它是质保经理的派生，只是它更侧重于软件在产品化之前的质量监控工作，包括软件开发流程、软件测试等技术与管理的各个方面。
由于该职位在业内没有明显定义，而根据不同企业的职位定位不同，这里无法统一陈述。
管理路线的最高发展域是咨询域，与技术路线的专家域类似，在配置管理、质量保证、软件产品化、行业领域达到高深造诣的人才，他们有丰富的从业经验、深厚的管理底蕴，具有对软件工程高瞻远瞩的慧眼和胆识，往往供职在专业的咨询与培训公司，提供IT业管理类咨询与培训的服务，推动着软件行业的前进。
国内外很多为软件企业进行CMM咨询和实施的公司里，就是这些人才的大本营之一！
转载请注明出处51数据库 » 软件测试如何全面发展规划
