上周六参加了51esting组织的杭州测试沙龙，交流过程大家谈到需求变更这个话题，由于时间问题和自己个性问题没有机会发言，今天有点时间，我来谈谈自己的想法。

   首先我们测试管理者要正确面对需求的变更，需求变更不是洪水猛兽，我们应该拥抱变化，我参与或主导过上百个的项目，还没有一个项目不做需求变更的，变更只是大小不同。测试管理者需要明确产品或项目目标，我们不要把自己团队变成研发的敌人，我们是一个团队，当然我把握好我们的基本原则。当然我们作为测试的管理者应该积极的想办法最规避需求风险的发生，或者把影响变得更小。我来谈谈我常用的措施，有可能只适何我们公司，但是我觉得大家可以参考一下。

1.迭代开发周期尽量的缩小时间，一般建议迭代周期控制一周到两周之内，需求尽量的明确，开发任务能安排到天。这样的话要求产品人员这个迭代周期需求考虑的相对比较完整，开发人员在安排任务时因为把任务安排到天，就很容易发现问题，能在前期就规避现有需求的变更风险。

2.建立需求变更模型，从需求变更影响范围、需求变更时间点，需求的优先级和重要度判断需求能不能变更，变更的话要走什么样流程。

需求影响范围：

    如，影响整个业务流程、整个技术框架，一般不建议变更，若用变更必须经过分管研发副总裁同意，并且需要调整项目总体进度。

需求变更时间点：

   如，需求变更（增加需求），由于变更增加的工作量，超出该迭代周期剩余工作量30%，不建议变更，如要变更建议下个迭代调整，或者跟现有未做需求优先级置换。

变更优先级和重要性：

     紧急重要那（就得做，产品经理要检讨），重要不紧急（下一个版本），紧急不重要（是否要做），不紧急不重要（叫上开发，可以一起打产品经理了）

3.建立产品经理需求变更考核机制，整个项目中需求变更率不能超出30%。这个需求更率如何计划可以根据不同公司情况计划，需求点，需求规模、需求影响的工作量等。

4.当然有时特殊情况，比如市场急迫需要，大老板发话必须怎么样了。那么只好加班了，我们作为管理者只好想办好做好绩效，为兄弟们争取福利和做好后勤保障。当然如果测试时间严重不足我们做好测试策略比如确保主业功能的正确性等，还要做好与上级领导的沟通工作，留下证据（如邮件）。

   需求变更对每一个研发项目来说都会经常遇到，产生变更的原因很多，有外在的、有内在的，但不论是因为什么产生的变更，遇到了就要正确的、合理的分析、评估，给项目以正确的指导。许多变更是可以避免的，如，技术框架设计的可扩展，程序设计的可扩容的话，当发生变更时也可以把变更对项目产生的影响控制到最小。防微杜渐、未雨绸缪，还是那句话：“早发现、早处理”。

1.对上要很强的执行力，对下要有很高威信力

2.要有很深的专业能力，又要有很强协调能力

3.要懂开发又要懂测试，还得懂人情事故和原则

4.别人都说他不是BUG，但是你往要为他买单

5.平常你都不重要，只要客户投诉都是你的错

6.管理一两年，发现变老油条哈哈

走自己的路，做自己认为对的事，坚持就是胜利

我一直希望我们的团队能是一个学习型的团队，一直鼓励他们提问，最近收到几个问题，我也稍微想想回复了一些。

1.         在了解了基本的理论后，重点应先从哪些方面着手去进行学习？

回复：应从这几个方面进行学习。

a)         部门总体的测试流程，测试规范，包括各个阶段各个工作产物和每个细节。

b)         学公司习公司主要的业务知识，通过业务联系到现有产品的每个功能以及细节。

c)         尽快融入公司，部门，团队的文化，并保留自己现有好的特点。

2.         在描述某些方法时，最好能提供一些实际的例子（比如测试用例的设计方法）

     回复：你可以使用guest用户去查找别的项目的测试用例，看看其他同事是如何设计的。

3.         测试时经常会出于自己的惯性思维，怎样能更全面地、多角度地去展开测试，希望能给予一些启发？

回复：这个肯定会出现，其实好的办法就两点

             多看多想：就是通过 各种渠道包括专业网站，公司现有知识库，同事沟通，同行沟通并通过自己的“脑袋”转换成自己明白的。

            多应用多总结：把整明白的东西尽快现实工作中应用，应用过程进行 问题总结，并分享给同事。

4.         在实际的工作中，往往给予测试的时间、资源有限，不能按照特别规范的测试流程进行，测试用例来不及写得很全或者没有时间完全去执行测试用例，但是又必须保证质量，那么如何去平衡这样一种关系？或者说有什么比较好的方法分享？

回复： 这个问题提得很好，实际上所有人都想把一件事情都想做很完美，其实都是不可能的。测试用例也是如此，首先我们要把握两件事情，首先这个项目的目标是什么，当然是这个项目目标是合法的情况下。我们要根据这个目标结合测试资源制定我们的测试策略，可能存在的风险提交产品委员审批。策略中对测试用例设计你就可以根据进度，资源进行调整。目前我们常用只种方案。

a)         只对需求优先级高的设计用例

b)         只例出测试要点，不编写测试步骤

c)         只编写测试思路，不编写测试步骤

d)         ……

5.         想了解下怎样去搭建测试环境

回复：当工作到一定阶段的时候你的小组长会安排的，但是你自己先要熟悉项目中应用的数据库，应用服务涉及到的相关工具的基本使用。

测试活动

一.    完善各部门岗位工作流程和规范制度上的细节要求，落实到每个人的各种行为上，并让每个人形成一种习惯。

目前部门各个岗位工作流程和规范制度要求相对比较粗泛，未注重到每个细节。逐步完善每一个过程，每个工作产品的各个环节清晰的方法和要求并慢慢形成部门员工作手册。

二.    人员重组，测试小组合并成测试大组，大组成员之间实行项目轮换，提高资源利用，缓解目前测试资源紧张问题。

目前测试小组太多，而每个小组人员却很少，造成某些时间段资源不能有效使用。目前同时开展的业务较多，而目前测试人员熟悉的业务过于单一，不利各小组之间人员协助。通过合并小组变大组，测试项目人员轮换，促进测试人员同时掌握多种业务，方便测试组之间资源调配，又不影响原测试组的工作。

三.    QA配置在完善过程审计前提下，加强QA配置的产品审计

目前QA配置的过程审计已基本完善，但是产品审计还相对薄弱。加强QA力量，招聘一个经验丰富的QA工程师，争取2011年6月底之前建立项目占各个工作产品的检查项，并逐步完善。   

四.    规范测试过程，统一测试方法，重点改进测试用例编写方法

目前测试人员测试执行时特别是升级项目时随机测试所占比例太大，对“人因素”的依赖比较大。完善各种测试方法的经验总结，在5月底这前发布测试大全卷2：功能测试。对测试用例编写和要求完善细化，让测试执行中有75%以上是根据测试用例进行的。

五.    扩大测试范围，部分项目尝试将开展白盒测试。

在目前功能测试、性能测试，自动化测试基础之上，选择一些项目，对一些重要功能模块尝试开展白盒测试，并争取在年底整理一份适合团队的白盒测试方法。

六.    加强产品质量数据分析，已尽快发现项目中问题

根据对测试数据，QA配置审计数据以及项目其它数据，根据一些方法进行一些分析。及时发现项目中的问题，协助产品经理解决一些问题。

七.    大力开展部门内部培训机制，建立知识共享平台

定期、有计划、多形式进行部门各岗位内部培训，分享工作中积累的经验，使工作中碰到的问题及时有效解决。形式上可以是问题、知识交流，正规授课，邀请开发人员培训进行开发知识方面的培训。

2010是每个中国人引以自豪的一年上海世博会，广州亚运会。对于我们产质量管理部以下简称（质管部）来说也是最为快速发展的一年，研发项目成倍增长，人员队伍快速壮大。质管部这一年遇到很多意想不到困难并行开展项系繁多，业务、技术种类繁多，涉及的部门多，项目所在部门情况各异，内部人员稳定等等。但是在公司领导的帮助下，各部门同事的配合下，以及质管部各个成员努力之下我们都一个一个克服了。

1      工作总结

一.    初步建立一支专业的质量管理队伍，人员梯队逐步趋向合理，并对质管部各个岗位级别，技能要求，工资范围进行明确的定义，

部门人员从年初的9人（QA配置2人，测试7人），发展到年未14人（QA配置3人，测试11人），初级工程师6人，中级工程师5人，高级工程师3人。

在人力资源部配合之下对部门测试，QA，配置岗位定义别，技能要求。并对部分岗位级别不合理员工进行了调整。

二.    根据CMMI要求对公司所有研发项目过程进行了跟踪，并针对每个项目情况协助产品经理进行时过程优化。

对公司产品委员会立的所有研发项目，我们都会在公司CMMI的体系框架下，根据项目实际情况，如项目所在部门，是否是工程项目产品等配合产品经理进行过程裁剪，让过程更合理，使过程管理即对项目管理带来帮助的同时，又达到质量控制的要求。

三.    对项目CMMI过程中的立项过程，技术评审过程，结项过程进行重点优化。

配合公司产品委员对项目立项，技术评审，项目结项三个过程进行了优化。所有立项的项目都进行严格审查，归档。所有技术评审过程都进行跟踪，记录，反馈。所有结项的工作产品进行了严格产品验收过程。

四.    每月公司研发项目质量数据进行收集分析，并整理成质量月报，已发布了第11期。

3月份开始每月发布质量月报，我们对所有研发项目的质量数据（如：QA审计，测试数据，配置审计）进行日常收集，整理，汇总，分析最后整理成质量月了，目前已发布了11期。

五.    测试涉及面越来越广，应用测试方法越来越多，大力开展了性能测试，部分项目引入自动化测试

对公司多个研发项目和工程项目进行了性能测试，积累了经验和脚本，并对碰到有问题进行总结。在公司部分项目应用QTP工具进行自动化测试方面的尝试，如A产品，B产品，C产品。

六.    大力开展部门业务学习，整理并发布了《测试大全卷1：基础知识（第1版）》

今年公司新进人员较多，公司业务又相对复杂，为了让他们快速上手，也为其它项目开展测试工作时作为参考。在坚持执行公司帮带制度以外，部门整理了《测试大全卷1：基础知识（第1版）》,经后还将陆续更新和发布测试大全卷二（功能测试），卷三（性能测试）。

七.    建立完善公司产品配置库，公司研发项目都进行了严格的配置管理，对重要工程产品也进行最收集。

配置了专职的配置人员，所有研发项目都进行了配置管理。并对公司重点项目的工作产品进行收集，整理并纳入公司配置库。

2      存在问题

1.     研发项目过程稳定较差，很多项目需求不稳定，进度变化较多，项目人员质量意识不够。

2.     公司项目周期定义不合理，大部分结项时间都在年中和年终，造成测试资源某时间段严重不足。

3.     项目中代码审查力度不够，编码阶段没有有效监控手段，编码质量较差，造成提交测试时产品质量较差。

4.     QA和配置审计对产品审计较少，需加强这方面审计力度，积累审计方法。

测试任务单填写说明和要求：

1.每个测试小组一份，每周一个sheet页，
2.每周根据右键移动或复制工作表，并选中建立副本属性。
3.每天早上测试组长和小组成员确认每天工作计划，以及计划工作量。
4.每天下班标识完成状态，实际工作量，以及增加计划外的工作。
5.每周五下午1：00之前测试组长完成下周计划的编写。
6.计划状态，工作类型，完成状态，任务名称，实际工作量必填。
7.完成状态标识未完成，需编写备注说明，说明未完成原因。
8.任务名称中需标识项目名称，如：BSHRP5.0:药房系统住院发药部分单元测试
9.任务名称需编写清晰明了，要求达到可验证，不能太笼统。
10.项目例会和部门例会如果每周定义的，计划状态也请标识计划内。
11.如果计划内的工作由于各种原因没有执行，实际工作量请标识0。

   最近实在太忙了，一直没写博客，实际上发生故事挺多的。最近由部门扩张，招了不少新人，项目组反应，缺陷描述提交质量不是很好。我想了好多办法,也不起效，后面看到博客格式有模板，缺陷描述能不能有模板呢。我根据我们公司缺陷类型定议

1 功能
语法：
<模块名><操作步骤><错误现象>【错误原因】
实例：
挂号处理中新病人建档时，如果姓名输入超过四个汉字保存失败，原因ms_brda.brxm字段长为8.
2 界面
语法：
<模块名><错误现象><正确结果>
实例：
挂号查询中挂号科室显示是内部ID，应显示科室名称
3 易用
语法：
<模块名><目前操作情况><建议情况>【优点原因】
实例：
挂号处理模块新病人建档时，选择省份时只能下拉选择，建议可以通过拼音码调入，方便用户操作。
4 数据
语法：
<模块名><错误现象><错误原因>【错误结论】
实例：
资产财务月报中折旧数据不对，经查发现资产重置以后，资产月结的时候和zc_yjjl（资产月结记录）的重置金额未更新，折旧金额还是按照重置前的金额计算，造成资产月报数据不对。月结处理算法不对，请修改。
5 代码
语法：
<模块名><操作步骤><错误现象>【错误原因】
实例：
挂号信息查询中点击查看发票报错，原因是ms_fpxx缺少zfpb字段，PDM中也没这个字段。
6 性能
语法：
<模块名><性能现象><原因分析>【解决方案】
实例：
 医嘱处理模块当超过10个用户同时进行医嘱处理通过拼音码调入项目时延时超过5秒。原因调入项目是直接从数据取，而项目字典和药品字典超过2万条。建议登录时下载到本地缓存操作。
7 建议
语法：
【模块名】<合理化建议>【优点原因】>
实例：

注意：<>必填 ，【】可选

自动化测试我们搞了快三个月，自动测试小组的人总是开玩笑“老大你又显摆去了”。我说这是必须的。是的最近我老碰到一个人我跟讨论自动化，给演示自动化测试的新结果，包括公司的领导，产品经理，开发人员等。

我认为要想在公司最好自动化测试，必须做好宣传，不然肯定无法推广。推广做不好最后肯定是失败的下场。宣传包括三方面公司领导上层，测试部内部，开发团队。

对公司上层重点是要经常像他汇报自动测试的进程，应用了多少项目，带来什么成效了。年中总结会我第一条就是“引入自动化测试，填补了公司之方空白，并且已三个项目测试中已应用”，引起公司领导的关切，问了很多问题，我又滔滔不绝了一把。

对测试部内部要恩威并施，其实公司现在每个项目组测试都很忙，大家都知道自动化测试初期肯定会带来很多工作量，而且不少。我又发挥了我们特长，说自动测试的好处，开专题讨论会，让自动测试小组保姆帮他们录制，调脚本，最后让执行，最后上当了。下半年我在测试考核中增加回归测试自动化比例。

对开发团队实际要让自动化测试产生信任，我经常是这样我用自动测试测出来的问题，先自己手工确认以后，并查明原因。经常请开发人员来看看，开发人员看了以后常说傻哥，这是好东东。

初初算来自动化测试我们搞了快三个月了，从刚开始的期待，兴致勃勃，到痛苦并快乐，到现在初见曙光。

4月份我提出要组建自动化小组，我看到团队中有迷惘的眼神，期待的眼神。开发组听到这事的时候也是将信将疑，甚至有人开玩笑跟我说“傻哥，这事搞成，你们可以下岗了”。

首先，我找到我们分管领导，提出我的想法，领导是技术出身，还是比较支持，我首先跟我们团队的人一起选择合适的自动化测试工具，后面确定了使用QTP。然后我开始招聘合适的自动测试工程师。

然后我们确定自动化测试今年的目标建立适合自己公司的自动测试框架，并明确了三个里程碑分别是7月份之前应用三个项目，10月份完成公司所有业务脚本，12月整理出初步的自动化测试框架。目前已完成了第一里程碑已在四个项目中应用。

第一个里程碑我们是这么操作，我选择了一个业务相对简单的项目开始，同时自动测试小组同步安排培训课程（QTP入门，QTP在项目中应用碰到的问题）。由于我们产品开发语言的特殊性（PB），碰到很多很怪的问题，这些问题连在国外的专业网站也找不到。好几次小组人员都在抓狂之中，有好几次都想放弃。但是我觉得我必须坚持，不然开发组不仅要笑话我，也会笑话我们整个部门。 这种事绝对不能发生，我们碰到问题的时候，三个人关在小会议室，叫上项目的业务测试组长，后面发现有很多问题技术层面解决不了，业务层面可以解决。如果业务层面解决不了换个思路，发现也解决了，兴奋中。

第二里程碑现在已开始，我们选择了公司主要业务进行录制，并对前面四个项目整理并都进行配置管理，分成开发库和基线库。并对公司原有测试岗位标准都进行修改，加进了自动化测试能力的要求。

第三里程碑计划是根据积累的脚本和经验，对一些公用功能进行函数化，对部分功能脚本模块化，可以自定义业务流程的组合。对一些功能模块进行测试数据分离，进行一些原始数据和动态数据进行控制。初步建立一套具有自己公司特色的自动化框架。