分享：08年年度测试工作总结及09年工作规划分享：08年年度测试工作总结及09年工作规划
1 08年年终改进点分析
08年年终改进点分析，共从四个维度进行，分别是：财务、顾客、内部流程、学习创新
测试流程、客户满意度、财务与绩效以及学习创新。
维度一：测试流程
测试流程维度，将按照测试流程执行的五个阶段进行分析。五个阶段分别是：测试分析阶段、测试计划阶段、测试设计阶段、测试执行阶段以及测试总结阶段。
测试分析阶段
测试分析阶段包括：主要包含原始需求的分析、技术剖析以及原始需求的评审。
目前的问题：
1. 对于原始需求的管理，没有按照需求基线进行确认。
2. 对于原始需求的分析，没有明确的分析框架，在分析前没有明确的分析原则。
3. 对于原始需求中的测试风险，没有做到有效的跟踪与确认。
4. 对于原始需求中的不确定内容及实现方式，缺乏有效的培训计划。
测试计划阶段
测试计划阶段包括：主要包含测试需求提取、测试需求评审、测试方案编写、测试计划编写
目前的问题：
1. 测试需求提取：使用需求跟踪矩阵进行提取活动。测试需求分析，没有定义明确的分析原则。
2. 测试需求评审：使用逐条阅读的方式或交叉评审方式进行评审。针对一些业务较复杂的处理流程时，此方法不能较好的评估测试覆盖。
3. 测试方案编写：目前只是用来做一些简单的对象分析。没有将测试框架与测试方案结合。使得前期分析的测试思路和结论没有保存下来，在测试执行阶段，不便于对整体策略进行调整。
4. 测试计划编写：
1) 计划简介：未指出对应内容的项目受益人。未定义出各项目干系人，需要关注的部分以及需要重点评估的部分。
2) 测试计划的范围：应将测试计划简介中有关范围的部分移到测试计划范围中。测试计划的范围，应包括以下几块内容，功能调整（包含需求文档基线）、测试需求（功能测试需求与非功能测试需求）、测试类型（包含原始需求基线、测试分类、是否裁剪）、测试计划风险评估。
3) 测试计划的策略：
a) 策略类型：此处更倾向于系统整体的策略及原则定义（包括多种测试类型）。而测试方案的测试策略则侧重于对应某个功能点的技术剖析与测试框架思路整理。由此，应考虑将测试方案中的分析结果与测试思路，融合到整体测试计划中。
b) 测试类型与测试阶段：原测试阶段的划分是从执行阶段开始的，这里应该将测试过程的五个阶段均进行描述，并能有效估算每个测试阶段理论所需的时间。特别针对测试执行阶段，每轮测试所涵盖的测试类型、测试目标、
测试时间进行说明，这里可以根据测试规模的大小进行裁剪。
c) 测试环境：原测试环境仅将测试需要的软硬条件进行的说明，未对组网规划进行描述。特别是性能或功能测试中，有关多机测试的部分。
d) 测试工具：原测试工具的选用，写的比较模糊。应该根据测试框架的需求来进行描述。可考虑按照实际测试需求点，规划所对应需要开发或引用的测试工具，并说明其厂商和版本。
4) 测试通入/通过标准：除将测试指南中的约束标准集成外，还应该考虑针对于项目特色制定有效的项目监控标准，如：测试组度量数据需要按周统计，并将数据结果抄送项目经理。如项目测试过程中，出现高危风险，应立即与项目经理进行讨论，确定下一步处理的解决思路。个人计划偏差值高于2个工作日，需停止原计划分析进度延迟的原因。总体计划偏差值高于3个工作日，需要停止总体计划分析项目延迟的原因以及后续的解决思路。
5. 测试组织的结构：
1) 组织形式：未将测试工程师分组。
2) 角色和职责：未将测试工程师的分组，未明确每个测试组的职责与权利。未将测试工程师分类，未明确每类测试人员的职责与义务。并将测试组之间的关系进行定义，未将测试人员与测试组的关系进行定义。
6. 测试工作内容：需要调整个阶段的工作内容，将交付工作件与每个测试阶段的输入、输出相结合。
7. 测试交付工件：纳入评审发起的文档以及审计文档
8. 时间进度表：描述关键里程碑的时间点以及每个测试阶段预计耗时。
9. 测试培训计划：根据测试方案中分析的内容，制定更有针对的培训计划及时间安排，尽量与项目经理协商明确到人、时间以及与会地点。培训会议讨论的内容，由发起人指定项目成员进行记录，整理后放入配置库测试经验交流区进行备份，已供其它项目组成员参考。
10. 风险跟踪计划：将测试计划中风险跟踪表，纳入项目风险及问题跟踪表中，对测试计划估计的各阶段风险进行确认，若执行到该阶段测试风险仍然存在，需要与项目经理或上级经理再次对风险项进行沟通直至风险项被确认，或已有其它解决方案。
测试设计阶段
测试设计阶段包括：特性测试需求提取、特性需求评审、测试用例编写、测试用例评审。
目前的问题：
1. 特性测试需求提取：使用需求跟踪矩阵进行提取活动。特性需求分析，没有定义明确的分析原则。没有较好的对测试需求提取过程进行记录，度量数据模型未建立。
2. 特性需求评审：使用逐条阅读的方式或交叉评审方式进行评审。针对一些业务较复杂的处理流程时，此方法不能较好的评估测试覆盖。
3.
测试用例编写：未定义统一的编写模板，在测试用例编写完成后，未定义用例产出的标准工件集。如：Excel版的测试用例统计表以及Word模板导出的测试用例集。
4. 测试用例评审：使用逐条阅读的方式或交叉评审方式进行评审。针对一些业务较复杂的处理流程时，此方法不能较好的评估测试覆盖。没有较好的对测试用例编写过程及评审过程进行记录，无法有效的度量测试设计阶段返工与维护的工作量，度量数据模型未建立。
测试执行阶段
测试执行阶段包括：初验测试用例、第一轮测试用例、第二轮测试用例、第三轮测试用例、单轮回归测试、探索性测试、性能测试、异常测试
目前的问题：未计算测试计划中各子项的执行比率，包括：测试需求、每轮测试预计执行的测试用例与实际执行的用例。
1. 未计算每轮测试，用例执行覆盖率。
2. 未计算每轮测试，用例发现问题的比率。
3. 未计算每轮测试，测试需求的覆盖比率，这种统计有助于对下一轮工作重点及测试策略做出调整。
4. 未对计划交付工件进行确认，在项目完成时是否具有这些交付工件，是否符合项目结束的标准。
5. 探索性测试：目标性不明确，是否可通过测试需求覆盖来决定探索性测试策略。
6. 性能测试：测试分析与测试目标未融合，使得后期数据分析框架性不足、观点不明确，分析报告参考意义有限。
7. 异常测试：未对异常测试类型及异常场景进行归类，在特性需求分析时，特性拆分未基于统一的分析原则。
测试总结阶段
测试总结阶段包括：性能测试报告、功能测试报告、每轮测试数据分析、度量报告、项目总结报告。
目前的问题：
1. 未对每轮测试数据进行分析，测试策略未及时进行调整。
2. 项目监控度量数据，没有定义清晰的度量维度，进度与质量如何评估。
它将对我们的业务产生什么影响？
1. 通过这样的管理方式。将解决现有项目测试过程中，由于现场需求变化或方案修改，需要追加新的功能或对原有方案进行调整后，测试用例大规模返工或测试点考虑不充分等问题。同时，也有效的控制了每轮转测版本的测试重心，提升了测试周期迭代效率。
2. 通过对测试对象的技术分析，确定明确的测试框架与分析原则。将解决测试分析过程中，由于测试人员需求理解不一致、测试思路不统一、测试经验不对等的问题。同时，也为下一测试阶段，节省了大量沟通成本与不必要的用例返工。
3. 通过对测试过程中的问题及风险管理(非Bug)，将解决测试分析阶段遗留或未确定的原始需求及测试风险，从而，在项目前期对未来趋势进行预警。并将评审会议中，开
发与测试共同确认的技术方案及解决方式进行确认。从而有效的区分，项目执行期造成延误的原因及相关处理策略
3. 通过更有针对性的培训计划，在测试前期即与项目经理保持良好的沟通关系。在测试计划与设计阶段，提早规划培训时间，已确保开发人员有充足的时间编写及调测版本。同时，也为测试设计阶段，制定明确的测试策略奠定了基础。
维度二：客户满意度
客户对象分析：
1. 内部客户：其它相关部门或小组成员；要依靠您的工作完成他的工作职能的人。
2. 外部客户：我们提供产品/服务的买主、受众，可能是最终用户或经销商；具有消费能力或潜在能力的人。
改进点分析：
1. 处理感情：表达服务的意愿、体谅情感、表达承担替客户解决问题的责任
2. 解决问题：客户满意的理念与态度、先处理情感、然后解决问题、确认客户满意度
3. 处理事务：收集信息、分析问题、提供信息、核查理解、归纳总结
4. 业务能力：技术水平、工作效率、相关知识、公司的经验、努力工作
维度三：财务与绩效
1. 过程控制及测试计划的成本估算
2. 测试周期的控制与测试投入的估算
维度四：学习创新
提升点：性能测试，具体请参考《2009年性能测试规划》。
第一，总体框架规划
第二，测试数据模拟
第三，工件与测试结果的存放与维护
2 09年个人目标与规划
维度一：测试流程
什么是目标和行动计划？
1. 对于原始需求的管理：在现有需求矩阵的方式下，尝试建立需求基线，已应对项目过程中由于需求分散、变化频繁而导致的返工与测试分析不完全。对已基线的原始需求文档，有规划的进行测试分析活动。并在项目前期与项目经理协商整套产品的需求迭代过程，由测试组长，维护该文档。
2. 对于原始需求的分析方法：需要定义明确的分析框架与分析原则。在项目开始时，由测试组长组织测试人员对原始需求进行技术分析，确定各模块或功能点测试需求框架。框架确定后，将测试框架进行一定程度的分解。对分类的问题，确定统一的分析原则，如：针对性能而言，我们需要从哪几个方面进行考虑。
3. 对于原始需求的测试风险：需要有效的进行跟踪与确认工作。将这些测试风险以及未确定的需求及实现方式，进行统一的管理。在原始需求评审结束后，跟踪人需求明确风险直到关闭。
4. 测试培训计划：对于原始需求分析时，一些不明确的内容及实现方式，在原始需求评审阶段，测试组长应根据已确定测试分析框架，对需要进行培训的或技术方案讲解的部分，提出测试培训计划。
5. 测试需求提取：使用需求跟踪矩阵进行提取活动
。测试需求分析，没有定义明确的分析原则。
6. 测试需求评审：使用逐条阅读的方式进行评审或采用交叉评审，无法评估测试需求覆盖比率，特别针对一些业务流复杂的处理流程。
7. 测试方案编写：目前只是用来做一些简单的对象分析。没有将测试计划与测试方案结合，使得前期分析的思路和结论没有保存。在测试执行阶段，不便于对测试策略进行调整。同时，在已规划的探索性测试时间中，测试目标比较模糊。
8. 测试计划编写：目标是提升改进点中3-5项。
9. 特性需求提取：目标是提升测试框架分析能力。
10. 特性需求评审：目标是评围绕统一的测试分析框架进行。
11. 测试用例编写；用例编写对象定义不明确，用例执行与需求双向跟踪关系没有建立。
如何来衡量这个目标？
1. 对原始需求和管理：通过细节跟踪计划中需求迭代测试计划页签进行项目跟踪，明确以下内容：需求基线版本号、转测版本号、转测试说明、测试需求分解框架、变更类型及测试负责人。
2. 对于原始需求的分析方法：通过对原始需求文档的技术分析，测试人员需要编写被测对象的相应测试方案。测试组应对相应方案进行评审，确定各模块的分析思路是否正确。测试框架定稿后，测试组长应将问题类型进行分类，组织讨论统一的分析原则及分解目标。
3. 对于原始需求的测试风险：通过项目风险及问题跟踪表，测试组长将测试风险及项目问题统一管理。明确以下内容：问题描述、所属模块、阶段、类型、负责者、跟踪者、状态、计划完成时间、实际完成时间、延期、级别、进度备注/问题回复/解决方案及解决状态。
4. 测试培训计划：在测试计划中培训部分体现。
5. 在测试需求提取之前，测试组应对测试方案进行评审，确定各模块的测试需求提取原则以及结构规划，针对同类测试点，测试人员应基于同一种分析规则进行拆分，拆分的粒度，也应该测试需求提取之前予以定义。
6. 测试需求的评审：需要引入对原始需求或数据流的追溯。追溯过程应是双向的，需要评估测试需求覆盖原始需求的比率；若在已提取的测试需求中涉及到大量数据流，应该通过条件及路径覆盖来评估其覆盖是否有效。
7. 测试方案编写：测试方案的编写必须针对一个功能点或模块提出完整测试分析框架，将测试思路体现在测试分析框架中。测试方案中需要明确指出分类测试点的，拆分原则及拆分粒度。测试人员必须遵守这一原则，进行原始需求的分析、测试需求提取、特性需求提取以及测试用例编写。
8. 测试计划编写：
1) 计划简介：定义明确项目干系人，指定干系人角色应着
重关注的计划内容；测试范围：包含以下信息：功能调整（包含需求文档基线）、测试需求（功能测试需求与非功能测试需求）、测试类型（包含原始需求基线、测试分类、是否裁剪）、测试计划风险评估；
2) 测试策略：部分需要考虑融合测试方案中各功能模块的整体测试思路，将测试框架罗列在测试策略中；
3) 测试类型与测试阶段：描述测试执行的五个阶段，并在测试执行阶段着重体现测试类型的过程剪裁。预估每个测试阶段投入人天，测试人员及目标说明；
4) 测试环境：除对测试所需的软硬条件进行说明，应对性能测试的主网环境进行一定描述；
5) 测试工具：对应的测试需求点，规划与使用相应的测试工具，将工具特性与测试需求点相互对应；
6) 测试通入/通过标准：根据项目特性及项目经理监控要求，除测试指南约束的标准外。制定项目监控需要的措施及应对方案，主要用户控制测试整体进度及合理评估各阶段的产品质量；
7) 组织架构：定义更为清晰的组织架构，将测试人员的职责与权利明确划分，在各个环节中设置闭环的监控方式，力求每个环节的输入、输出均遵循测试指南；
8) 测试工作内容：将测试工件及提交物与测试阶段产出对应，对于每个测试阶段项目QA或高层经理可根据该检查表进行核对，已评估项目整体情况是否健康、是否出现延期等；交付工件：在现有基础上纳入评审发起及审计文档，明确指定各种报告中应交付的附件及相关数据连接；
9) 时间进度表：将project中的关键里程碑进行标识，区别于测试类型与测试阶段的时间估算，时间进度表主要描述各里程碑点或关键任务预计完成的项目日期，测试过程中将努力保证这些关键任务项同期完成，并根据实际开展情况及偏差比率控制加班任务量，校正任务规模的估算比率；
10) 测试培训计划：对于原始需求分析时，一些不明确的内容及实现方式，在原始需求评审阶段，测试组长应根据已确定测试分析框架，对需要进行培训的或技术方案讲解的部分，提出测试培训计划。测试培训计划，与测试工具引入一致需要细化到功能模块或大的功能点，如对于黑名单模块BOSS回传流程的讲解，培训时间及主讲人需要测试计划中予以明确，项目经理应考虑将培训时间计入项目开发周期时间内，已保证开发人员具有充足的时间进行代码编写与联调测试；
11) 测试计划风险：测试计划的风险主要来自以下几个方面。
第一， 来自于测试分析阶段：由于原始需求不明确或解决方案模糊所遗留的测试需求风险；由于原始需求测试分析框架思路不正确以及分析原则不统一所导致的测
试提取遗漏或忽略了模块间的关联等问题从而造成的风险；
第二， 来自于测试计划阶段：由于对测试规模及需求把握不足，关键性任务判断错误、测试阶段时间估算不合理等造成的计划执行风险；
第三， 来自于计划执行偏差：包括测试范围偏差、测试策略偏差、测试进度偏差、阶段质量目标偏差、各阶段需求覆盖、用例执行偏差等所造成的风险。
第四， 来自于计划目标偏差：包括各阶段预定义质量目标与实际完成阶段质量情况偏差、计划时间点与实际完成时间点偏差。应将测试计划中提出的风险，统一纳入项目问题及风险跟踪表。提出规避的思路或解决方案，跟踪人应将风险确认后，将该条风险状态置为解决。
9. 特性需求提取：在已定义测试方案分析框架中细化特性需求提取的原则及粒度。记录测试需求提取过程变更状态，统计变更的规模及处理变更所消耗的时间。
10. 特性需求评审：评审需围绕测试分析框架进行。
第一， 评审首要是关注分析原则是否按照测试方案定义的原则进行拆分。
第二， 特性需求提取产生的合并项，应关联到原始需求点，并评估原始需求的覆盖率。譬如：20个特性->3个测试需求->1个原始需求。
第三， 特性需求评审需要纠正测试分析框架中的错误或分析不完整的部分，并在一定程度上完善测试需求提取，从而保证双向一致。
第四， 特性需求评审可用于交互测试思路，特别针对模块与模块之间测试设计。是否合理，是否有针对性。对于测试人员而言，用例的编写应该突出这种目的性，正确引导开发人员评审时的思路。
11. 测试用例编写：测试用例编写过程，需要区别不同对象的阅读需求。开发人员与项目经理在进行用例评审时，需要透过用例引导开发对原始需求的理解。在实际项目运作中，开发对测试用例评审效果并不理想，反馈问题较少对于测试框架的指导意义不大。由此，我们希望能在09年提升这个点。必须考虑在测试用例的编写过程中，明细项目经理及各个角色的阅读需求。将测试标题与测试分析框架结合，给予开发人员正确评审引导。明确开发评审测试用例的这着重点与评审策略。以此，从侧面优化我们的评审质量。测试用例的编写，还应该考虑测试需求覆盖问题。在成型的测试用例集中，需要将测试需求覆盖纳入其中。已优化我们在测试执行过程中，用例不对应功能点而造成的策略调整问题。
12. 测试用例评审：将基于复杂业务流程的测试用例，使用数据业务流的方式进行评审。评审的原则，测试用例需要覆盖每个判断条件及分支流程。增加测试用例评审过程的记录，以此对该
产品在测试周期内所有发生变化的规模与状态进行统计。09年预计初步对这一过程进行建模，初步建立度量模型数据。
13. 测试执行阶段：
1) 通过细节计划跟踪表，完成对每轮转测版本用例执行覆盖计算，主要体现测试用例与测试需求的对应关系。以此跟踪测试用例的真实覆盖程度，已决定下一轮转测版本策略调整重心。
2) 通过测试用例执行跟踪表，完成对测试用例问题单管理与跟踪。将本轮NG或NT的测试用例，通过测试用例跟踪表汇总到视图表单中，在下一轮转测版本中进行执行。
3) 通过测试计划中，交付工件部分进行确认，明确每轮应提交的测试相关文档，并有计划对这些文档进行确认。以保证工件能按时、按计划、按质量进行交付。
4) 通过测试用例追溯测试需求，以此来决定探索性测试的策略与侧重点。将探索性测试、异常测试等测试方法及思维策略定期进行交流，测试人员可通过自行总结或团队讨论等方式进行交互，以此优化我们在测试过程中经验差异，更好的提升测试用例设计的质量。
5) 有关性能测试的部分：请参考2009年性能测试规划，主要明确了以下三点内容
第一，总体框架规划
第二，测试数据模拟
第三，工件与测试结果的存放与维护
14. 测试总结阶段：对每轮测试汇总进行统计与QA一起评价该轮版本整体质量情况，以此设定下一阶段质量目标。2009年需要在部门及公司层面的指引下，完成对各项目数据监控度量。在项目交付使用后，增加对产品版本间问题回溯时间，增加对TD库中共性问题的确认。增加开发与测试共同对共性的问题评估与确认，已确保发布版本不遗留共性问题。一旦发现共性问题需要在第一时间对问题风险与影响进行评估，迅速做好策略应对工作，以此决定是否需要发布补丁版本或该问题的后期版本规划，预防在升级补丁将该问题单遗忘或二次修改时引入新的问题。
维度二：客户满意度
客户对象分析：
1. 内部客户：
1) 完成对公司内部的客户定义。
2) 完成对各对象交付工件的定义。
3) 提供对内部客户产品策略引导与后期产品规划。
2. 外部客户：
1) 合作客户：提供合作客户的交付工件；与合作客户相互的资源支撑；辅助合作客户协助现场问题定位；反馈合作客户现网需求。
2) 现场客户：提供现网客户维护支撑；提供现网客户最新的产品咨询；提供现网客户完善的客户需求反馈；
3. 改进点与提升：
1) 处理感情：先区分客户的类型；把握关键时刻；掌握客户的情绪。
2) 解决问题：讨论解决问题的步骤；解决问题的策略与途径。
3) 处理事物：
a) 第一步：收集客户的配置信息、系统
日志及数据库基础参数设置等，了解客户的主网情况及机器配置。
b) 第二步：分析问题，需要基于一定的分析思路与分析策略。对现场问题与描述需要进行确认与记录，将用户表述第一手信息准确的传达给其他收益人共同分享数据结果。
c) 第三步：提供信息，将分析问题的结论反馈给客户，引导客户进行排查以确认分析结论是否正确。将分析的结论，有策略的告知用户，安抚客户的情绪。
d) 第四步：核查理解，将客户的理解，重新表述已确认与客户表达一致。
e) 第五步：归纳总结，总结共分为三个部分。第一部分，对应急策略的总结与归纳；第二部分，对分析策略的总结与归纳；第三部分，对客户问题的总结与归档。
4) 业务能力：
a) 测试技术：
第一， 是对产品熟悉度的提升，共分为五个层次：
第一层：对单个产品的需求与模块功能熟悉。
第二层：对单个产品的需求、业务与流程熟悉。
第三层：对多个产品的需求、业务与流程熟悉。
第四层：对多个产品的需求、特性及业务熟悉，可以间接的对一些问题的影响范围进行评估、预警，提出测试风险与项目风险。
第五层：对多个产品的需求、特性及业务熟悉，在评估风险的基础上，可有效对产品未来的功能演变进行预测，提出产品规划建议。对客户提出的需求正确判断，辅助项目经理进行风险评估。
第二， 是对测试方法的提升，共分为三个层次：
第一层：分析测试对象，明确测试需求，提出正确的测试方法。
第二层：在测试对象发生变更时，根据测试需求，调整测试方法与测试策略。
第三层：从测试瓶颈入手，在未来的测试中，规划与完善测试方法。
第三， 是对测试规划的提升，共分为三个层次：
第一层：能够根据测试需求，编写简单的测试规划，规划只针对局部功能点或局部性能验证。
第二层：能够全局的完成系统级别的测试规划，包括：测试需求、测试计划、性能计划等。
第三层：能够完成公司及部门层面的，某一类型的测试规划，包括：性能测试规划、自动化测试规划、测试工具规划等。
b) 工作效率：
第一， 时间管理，通过TimeSheets对工作事物进行统计，将按周、月对数据进行汇总分析，提升团队整体的工作效率。可间接提升，项目进度估算能力。
第二， 平滑度，通过完善各种测试流程、测试完成标准等，将测试组间的协调高度一致，将接口与输出标准统一，以求对工作效率的提升。
第三， 计划能力，测试开始前，应预留必要的规划时间，明确测试需求、测试方法在开工做事。有策略的进行加班控制，避免测试人员由于经常加班导致工作能力
下降或出现抵触情绪。
第四， 任务树，当同时有多个事物需要并发处理时，需要将任务纳入任务树中进行优先级的处理，明确哪些事物是目前紧要处理的，哪些事物是可以稍作延迟的。通过合理的划分，以求将每件事物都按时完成。
第五， 偏差与预警，当个人进度与项目进度偏差较大时，需要主动提出当前的问题与风险策略。通过小组会议评估后，明确测试方法或解决方案。通过合理加班或追加人员，以保证项目进度无延迟进行。当项目出现严重进度偏差时，项目人员需要集体讨论问题原因及规避措施，控制项目偏差度，确保产品按时上线或交付用户。
c) 相关知识：
第一， 测试行业相关——新的测试技术与方法、新的测试工具与引入、新的测试模型等。
第二， 行业背景相关——CTG-MBOSS电信业务架构、公司相关产品等。
第三， 同类型产品比较——中兴、诺基亚、朗讯、阿尔卡特等
第四， 项目管理相关——PMBOK、CMM、CMMI、ISO90001等
维度三：财务与绩效
1. 过程控制及测试计划的成本估算
2. 测试周期的控制与测试投入的估算
维度四：学习创新
提升点：性能测试，具体请参考《2009年性能测试规划》。
第一，总体框架规划
第二，测试数据模拟
第三，工件与测试结果的存放与维护
分享：08年年度测试工作总结及09年工作规划分享：08年年度测试工作总结及09年工作规划
1 08年年终改进点分析
08年年终改进点分析，共从四个维度进行，分别是：财务、顾客、内部流程、学习创新
测试流程、客户满意度、财务与绩效以及学习创新。
维度一：测试流程
测试流程维度，将按照测试流程执行的五个阶段进行分析。五个阶段分别是：测试分析阶段、测试计划阶段、测试设计阶段、测试执行阶段以及测试总结阶段。
测试分析阶段
测试分析阶段包括：主要包含原始需求的分析、技术剖析以及原始需求的评审。
目前的问题：
1. 对于原始需求的管理，没有按照需求基线进行确认。
2. 对于原始需求的分析，没有明确的分析框架，在分析前没有明确的分析原则。
3. 对于原始需求中的测试风险，没有做到有效的跟踪与确认。
4. 对于原始需求中的不确定内容及实现方式，缺乏有效的培训计划。
测试计划阶段
测试计划阶段包括：主要包含测试需求提取、测试需求评审、测试方案编写、测试计划编写
目前的问题：
1. 测试需求提取：使用需求跟踪矩阵进行提取活动。测试需求分析，没有定义明确的分析原则。
2. 测试需求评审：使用逐条阅读的方式或交叉评审方式进行评审。针对一些业务较复杂的处理流程时，此方法不能较好的评估测试覆盖。
3. 测试方案编写：目前只是用来做一些简单的对象分析。没有将测试框架与测试方案结合。使得前期分析的测试思路和结论没有保存下来，在测试执行阶段，不便于对整体策略进行调整。
4. 测试计划编写：
1) 计划简介：未指出对应内容的项目受益人。未定义出各项目干系人，需要关注的部分以及需要重点评估的部分。
2) 测试计划的范围：应将测试计划简介中有关范围的部分移到测试计划范围中。测试计划的范围，应包括以下几块内容，功能调整（包含需求文档基线）、测试需求（功能测试需求与非功能测试需求）、测试类型（包含原始需求基线、测试分类、是否裁剪）、测试计划风险评估。
3) 测试计划的策略：
a) 策略类型：此处更倾向于系统整体的策略及原则定义（包括多种测试类型）。而测试方案的测试策略则侧重于对应某个功能点的技术剖析与测试框架思路整理。由此，应考虑将测试方案中的分析结果与测试思路，融合到整体测试计划中。
b) 测试类型与测试阶段：原测试阶段的划分是从执行阶段开始的，这里应该将测试过程的五个阶段均进行描述，并能有效估算每个测试阶段理论所需的时间。特别针对测试执行阶段，每轮测试所涵盖的测试类型、测试目标、
测试时间进行说明，这里可以根据测试规模的大小进行裁剪。
c) 测试环境：原测试环境仅将测试需要的软硬条件进行的说明，未对组网规划进行描述。特别是性能或功能测试中，有关多机测试的部分。
d) 测试工具：原测试工具的选用，写的比较模糊。应该根据测试框架的需求来进行描述。可考虑按照实际测试需求点，规划所对应需要开发或引用的测试工具，并说明其厂商和版本。
4) 测试通入/通过标准：除将测试指南中的约束标准集成外，还应该考虑针对于项目特色制定有效的项目监控标准，如：测试组度量数据需要按周统计，并将数据结果抄送项目经理。如项目测试过程中，出现高危风险，应立即与项目经理进行讨论，确定下一步处理的解决思路。个人计划偏差值高于2个工作日，需停止原计划分析进度延迟的原因。总体计划偏差值高于3个工作日，需要停止总体计划分析项目延迟的原因以及后续的解决思路。
5. 测试组织的结构：
1) 组织形式：未将测试工程师分组。
2) 角色和职责：未将测试工程师的分组，未明确每个测试组的职责与权利。未将测试工程师分类，未明确每类测试人员的职责与义务。并将测试组之间的关系进行定义，未将测试人员与测试组的关系进行定义。
6. 测试工作内容：需要调整个阶段的工作内容，将交付工作件与每个测试阶段的输入、输出相结合。
7. 测试交付工件：纳入评审发起的文档以及审计文档
8. 时间进度表：描述关键里程碑的时间点以及每个测试阶段预计耗时。
9. 测试培训计划：根据测试方案中分析的内容，制定更有针对的培训计划及时间安排，尽量与项目经理协商明确到人、时间以及与会地点。培训会议讨论的内容，由发起人指定项目成员进行记录，整理后放入配置库测试经验交流区进行备份，已供其它项目组成员参考。
10. 风险跟踪计划：将测试计划中风险跟踪表，纳入项目风险及问题跟踪表中，对测试计划估计的各阶段风险进行确认，若执行到该阶段测试风险仍然存在，需要与项目经理或上级经理再次对风险项进行沟通直至风险项被确认，或已有其它解决方案。
测试设计阶段
测试设计阶段包括：特性测试需求提取、特性需求评审、测试用例编写、测试用例评审。
目前的问题：
1. 特性测试需求提取：使用需求跟踪矩阵进行提取活动。特性需求分析，没有定义明确的分析原则。没有较好的对测试需求提取过程进行记录，度量数据模型未建立。
2. 特性需求评审：使用逐条阅读的方式或交叉评审方式进行评审。针对一些业务较复杂的处理流程时，此方法不能较好的评估测试覆盖。
3.
测试用例编写：未定义统一的编写模板，在测试用例编写完成后，未定义用例产出的标准工件集。如：Excel版的测试用例统计表以及Word模板导出的测试用例集。
4. 测试用例评审：使用逐条阅读的方式或交叉评审方式进行评审。针对一些业务较复杂的处理流程时，此方法不能较好的评估测试覆盖。没有较好的对测试用例编写过程及评审过程进行记录，无法有效的度量测试设计阶段返工与维护的工作量，度量数据模型未建立。
测试执行阶段
测试执行阶段包括：初验测试用例、第一轮测试用例、第二轮测试用例、第三轮测试用例、单轮回归测试、探索性测试、性能测试、异常测试
目前的问题：未计算测试计划中各子项的执行比率，包括：测试需求、每轮测试预计执行的测试用例与实际执行的用例。
1. 未计算每轮测试，用例执行覆盖率。
2. 未计算每轮测试，用例发现问题的比率。
3. 未计算每轮测试，测试需求的覆盖比率，这种统计有助于对下一轮工作重点及测试策略做出调整。
4. 未对计划交付工件进行确认，在项目完成时是否具有这些交付工件，是否符合项目结束的标准。
5. 探索性测试：目标性不明确，是否可通过测试需求覆盖来决定探索性测试策略。
6. 性能测试：测试分析与测试目标未融合，使得后期数据分析框架性不足、观点不明确，分析报告参考意义有限。
7. 异常测试：未对异常测试类型及异常场景进行归类，在特性需求分析时，特性拆分未基于统一的分析原则。
测试总结阶段
测试总结阶段包括：性能测试报告、功能测试报告、每轮测试数据分析、度量报告、项目总结报告。
目前的问题：
1. 未对每轮测试数据进行分析，测试策略未及时进行调整。
2. 项目监控度量数据，没有定义清晰的度量维度，进度与质量如何评估。
它将对我们的业务产生什么影响？
1. 通过这样的管理方式。将解决现有项目测试过程中，由于现场需求变化或方案修改，需要追加新的功能或对原有方案进行调整后，测试用例大规模返工或测试点考虑不充分等问题。同时，也有效的控制了每轮转测版本的测试重心，提升了测试周期迭代效率。
2. 通过对测试对象的技术分析，确定明确的测试框架与分析原则。将解决测试分析过程中，由于测试人员需求理解不一致、测试思路不统一、测试经验不对等的问题。同时，也为下一测试阶段，节省了大量沟通成本与不必要的用例返工。
3. 通过对测试过程中的问题及风险管理(非Bug)，将解决测试分析阶段遗留或未确定的原始需求及测试风险，从而，在项目前期对未来趋势进行预警。并将评审会议中，开
发与测试共同确认的技术方案及解决方式进行确认。从而有效的区分，项目执行期造成延误的原因及相关处理策略
3. 通过更有针对性的培训计划，在测试前期即与项目经理保持良好的沟通关系。在测试计划与设计阶段，提早规划培训时间，已确保开发人员有充足的时间编写及调测版本。同时，也为测试设计阶段，制定明确的测试策略奠定了基础。
维度二：客户满意度
客户对象分析：
1. 内部客户：其它相关部门或小组成员；要依靠您的工作完成他的工作职能的人。
2. 外部客户：我们提供产品/服务的买主、受众，可能是最终用户或经销商；具有消费能力或潜在能力的人。
改进点分析：
1. 处理感情：表达服务的意愿、体谅情感、表达承担替客户解决问题的责任
2. 解决问题：客户满意的理念与态度、先处理情感、然后解决问题、确认客户满意度
3. 处理事务：收集信息、分析问题、提供信息、核查理解、归纳总结
4. 业务能力：技术水平、工作效率、相关知识、公司的经验、努力工作
维度三：财务与绩效
1. 过程控制及测试计划的成本估算
2. 测试周期的控制与测试投入的估算
维度四：学习创新
提升点：性能测试，具体请参考《2009年性能测试规划》。
第一，总体框架规划
第二，测试数据模拟
第三，工件与测试结果的存放与维护
2 09年个人目标与规划
维度一：测试流程
什么是目标和行动计划？
1. 对于原始需求的管理：在现有需求矩阵的方式下，尝试建立需求基线，已应对项目过程中由于需求分散、变化频繁而导致的返工与测试分析不完全。对已基线的原始需求文档，有规划的进行测试分析活动。并在项目前期与项目经理协商整套产品的需求迭代过程，由测试组长，维护该文档。
2. 对于原始需求的分析方法：需要定义明确的分析框架与分析原则。在项目开始时，由测试组长组织测试人员对原始需求进行技术分析，确定各模块或功能点测试需求框架。框架确定后，将测试框架进行一定程度的分解。对分类的问题，确定统一的分析原则，如：针对性能而言，我们需要从哪几个方面进行考虑。
3. 对于原始需求的测试风险：需要有效的进行跟踪与确认工作。将这些测试风险以及未确定的需求及实现方式，进行统一的管理。在原始需求评审结束后，跟踪人需求明确风险直到关闭。
4. 测试培训计划：对于原始需求分析时，一些不明确的内容及实现方式，在原始需求评审阶段，测试组长应根据已确定测试分析框架，对需要进行培训的或技术方案讲解的部分，提出测试培训计划。
5. 测试需求提取：使用需求跟踪矩阵进行提取活动
。测试需求分析，没有定义明确的分析原则。
6. 测试需求评审：使用逐条阅读的方式进行评审或采用交叉评审，无法评估测试需求覆盖比率，特别针对一些业务流复杂的处理流程。
7. 测试方案编写：目前只是用来做一些简单的对象分析。没有将测试计划与测试方案结合，使得前期分析的思路和结论没有保存。在测试执行阶段，不便于对测试策略进行调整。同时，在已规划的探索性测试时间中，测试目标比较模糊。
8. 测试计划编写：目标是提升改进点中3-5项。
9. 特性需求提取：目标是提升测试框架分析能力。
10. 特性需求评审：目标是评围绕统一的测试分析框架进行。
11. 测试用例编写；用例编写对象定义不明确，用例执行与需求双向跟踪关系没有建立。
如何来衡量这个目标？
1. 对原始需求和管理：通过细节跟踪计划中需求迭代测试计划页签进行项目跟踪，明确以下内容：需求基线版本号、转测版本号、转测试说明、测试需求分解框架、变更类型及测试负责人。
2. 对于原始需求的分析方法：通过对原始需求文档的技术分析，测试人员需要编写被测对象的相应测试方案。测试组应对相应方案进行评审，确定各模块的分析思路是否正确。测试框架定稿后，测试组长应将问题类型进行分类，组织讨论统一的分析原则及分解目标。
3. 对于原始需求的测试风险：通过项目风险及问题跟踪表，测试组长将测试风险及项目问题统一管理。明确以下内容：问题描述、所属模块、阶段、类型、负责者、跟踪者、状态、计划完成时间、实际完成时间、延期、级别、进度备注/问题回复/解决方案及解决状态。
4. 测试培训计划：在测试计划中培训部分体现。
5. 在测试需求提取之前，测试组应对测试方案进行评审，确定各模块的测试需求提取原则以及结构规划，针对同类测试点，测试人员应基于同一种分析规则进行拆分，拆分的粒度，也应该测试需求提取之前予以定义。
6. 测试需求的评审：需要引入对原始需求或数据流的追溯。追溯过程应是双向的，需要评估测试需求覆盖原始需求的比率；若在已提取的测试需求中涉及到大量数据流，应该通过条件及路径覆盖来评估其覆盖是否有效。
7. 测试方案编写：测试方案的编写必须针对一个功能点或模块提出完整测试分析框架，将测试思路体现在测试分析框架中。测试方案中需要明确指出分类测试点的，拆分原则及拆分粒度。测试人员必须遵守这一原则，进行原始需求的分析、测试需求提取、特性需求提取以及测试用例编写。
8. 测试计划编写：
1) 计划简介：定义明确项目干系人，指定干系人角色应着
重关注的计划内容；测试范围：包含以下信息：功能调整（包含需求文档基线）、测试需求（功能测试需求与非功能测试需求）、测试类型（包含原始需求基线、测试分类、是否裁剪）、测试计划风险评估；
2) 测试策略：部分需要考虑融合测试方案中各功能模块的整体测试思路，将测试框架罗列在测试策略中；
3) 测试类型与测试阶段：描述测试执行的五个阶段，并在测试执行阶段着重体现测试类型的过程剪裁。预估每个测试阶段投入人天，测试人员及目标说明；
4) 测试环境：除对测试所需的软硬条件进行说明，应对性能测试的主网环境进行一定描述；
5) 测试工具：对应的测试需求点，规划与使用相应的测试工具，将工具特性与测试需求点相互对应；
6) 测试通入/通过标准：根据项目特性及项目经理监控要求，除测试指南约束的标准外。制定项目监控需要的措施及应对方案，主要用户控制测试整体进度及合理评估各阶段的产品质量；
7) 组织架构：定义更为清晰的组织架构，将测试人员的职责与权利明确划分，在各个环节中设置闭环的监控方式，力求每个环节的输入、输出均遵循测试指南；
8) 测试工作内容：将测试工件及提交物与测试阶段产出对应，对于每个测试阶段项目QA或高层经理可根据该检查表进行核对，已评估项目整体情况是否健康、是否出现延期等；交付工件：在现有基础上纳入评审发起及审计文档，明确指定各种报告中应交付的附件及相关数据连接；
9) 时间进度表：将project中的关键里程碑进行标识，区别于测试类型与测试阶段的时间估算，时间进度表主要描述各里程碑点或关键任务预计完成的项目日期，测试过程中将努力保证这些关键任务项同期完成，并根据实际开展情况及偏差比率控制加班任务量，校正任务规模的估算比率；
10) 测试培训计划：对于原始需求分析时，一些不明确的内容及实现方式，在原始需求评审阶段，测试组长应根据已确定测试分析框架，对需要进行培训的或技术方案讲解的部分，提出测试培训计划。测试培训计划，与测试工具引入一致需要细化到功能模块或大的功能点，如对于黑名单模块BOSS回传流程的讲解，培训时间及主讲人需要测试计划中予以明确，项目经理应考虑将培训时间计入项目开发周期时间内，已保证开发人员具有充足的时间进行代码编写与联调测试；
11) 测试计划风险：测试计划的风险主要来自以下几个方面。
第一， 来自于测试分析阶段：由于原始需求不明确或解决方案模糊所遗留的测试需求风险；由于原始需求测试分析框架思路不正确以及分析原则不统一所导致的测
试提取遗漏或忽略了模块间的关联等问题从而造成的风险；
第二， 来自于测试计划阶段：由于对测试规模及需求把握不足，关键性任务判断错误、测试阶段时间估算不合理等造成的计划执行风险；
第三， 来自于计划执行偏差：包括测试范围偏差、测试策略偏差、测试进度偏差、阶段质量目标偏差、各阶段需求覆盖、用例执行偏差等所造成的风险。
第四， 来自于计划目标偏差：包括各阶段预定义质量目标与实际完成阶段质量情况偏差、计划时间点与实际完成时间点偏差。应将测试计划中提出的风险，统一纳入项目问题及风险跟踪表。提出规避的思路或解决方案，跟踪人应将风险确认后，将该条风险状态置为解决。
9. 特性需求提取：在已定义测试方案分析框架中细化特性需求提取的原则及粒度。记录测试需求提取过程变更状态，统计变更的规模及处理变更所消耗的时间。
10. 特性需求评审：评审需围绕测试分析框架进行。
第一， 评审首要是关注分析原则是否按照测试方案定义的原则进行拆分。
第二， 特性需求提取产生的合并项，应关联到原始需求点，并评估原始需求的覆盖率。譬如：20个特性->3个测试需求->1个原始需求。
第三， 特性需求评审需要纠正测试分析框架中的错误或分析不完整的部分，并在一定程度上完善测试需求提取，从而保证双向一致。
第四， 特性需求评审可用于交互测试思路，特别针对模块与模块之间测试设计。是否合理，是否有针对性。对于测试人员而言，用例的编写应该突出这种目的性，正确引导开发人员评审时的思路。
11. 测试用例编写：测试用例编写过程，需要区别不同对象的阅读需求。开发人员与项目经理在进行用例评审时，需要透过用例引导开发对原始需求的理解。在实际项目运作中，开发对测试用例评审效果并不理想，反馈问题较少对于测试框架的指导意义不大。由此，我们希望能在09年提升这个点。必须考虑在测试用例的编写过程中，明细项目经理及各个角色的阅读需求。将测试标题与测试分析框架结合，给予开发人员正确评审引导。明确开发评审测试用例的这着重点与评审策略。以此，从侧面优化我们的评审质量。测试用例的编写，还应该考虑测试需求覆盖问题。在成型的测试用例集中，需要将测试需求覆盖纳入其中。已优化我们在测试执行过程中，用例不对应功能点而造成的策略调整问题。
12. 测试用例评审：将基于复杂业务流程的测试用例，使用数据业务流的方式进行评审。评审的原则，测试用例需要覆盖每个判断条件及分支流程。增加测试用例评审过程的记录，以此对该
产品在测试周期内所有发生变化的规模与状态进行统计。09年预计初步对这一过程进行建模，初步建立度量模型数据。
13. 测试执行阶段：
1) 通过细节计划跟踪表，完成对每轮转测版本用例执行覆盖计算，主要体现测试用例与测试需求的对应关系。以此跟踪测试用例的真实覆盖程度，已决定下一轮转测版本策略调整重心。
2) 通过测试用例执行跟踪表，完成对测试用例问题单管理与跟踪。将本轮NG或NT的测试用例，通过测试用例跟踪表汇总到视图表单中，在下一轮转测版本中进行执行。
3) 通过测试计划中，交付工件部分进行确认，明确每轮应提交的测试相关文档，并有计划对这些文档进行确认。以保证工件能按时、按计划、按质量进行交付。
4) 通过测试用例追溯测试需求，以此来决定探索性测试的策略与侧重点。将探索性测试、异常测试等测试方法及思维策略定期进行交流，测试人员可通过自行总结或团队讨论等方式进行交互，以此优化我们在测试过程中经验差异，更好的提升测试用例设计的质量。
5) 有关性能测试的部分：请参考2009年性能测试规划，主要明确了以下三点内容
第一，总体框架规划
第二，测试数据模拟
第三，工件与测试结果的存放与维护
14. 测试总结阶段：对每轮测试汇总进行统计与QA一起评价该轮版本整体质量情况，以此设定下一阶段质量目标。2009年需要在部门及公司层面的指引下，完成对各项目数据监控度量。在项目交付使用后，增加对产品版本间问题回溯时间，增加对TD库中共性问题的确认。增加开发与测试共同对共性的问题评估与确认，已确保发布版本不遗留共性问题。一旦发现共性问题需要在第一时间对问题风险与影响进行评估，迅速做好策略应对工作，以此决定是否需要发布补丁版本或该问题的后期版本规划，预防在升级补丁将该问题单遗忘或二次修改时引入新的问题。
维度二：客户满意度
客户对象分析：
1. 内部客户：
1) 完成对公司内部的客户定义。
2) 完成对各对象交付工件的定义。
3) 提供对内部客户产品策略引导与后期产品规划。
2. 外部客户：
1) 合作客户：提供合作客户的交付工件；与合作客户相互的资源支撑；辅助合作客户协助现场问题定位；反馈合作客户现网需求。
2) 现场客户：提供现网客户维护支撑；提供现网客户最新的产品咨询；提供现网客户完善的客户需求反馈；
3. 改进点与提升：
1) 处理感情：先区分客户的类型；把握关键时刻；掌握客户的情绪。
2) 解决问题：讨论解决问题的步骤；解决问题的策略与途径。
3) 处理事物：
a) 第一步：收集客户的配置信息、系统
日志及数据库基础参数设置等，了解客户的主网情况及机器配置。
b) 第二步：分析问题，需要基于一定的分析思路与分析策略。对现场问题与描述需要进行确认与记录，将用户表述第一手信息准确的传达给其他收益人共同分享数据结果。
c) 第三步：提供信息，将分析问题的结论反馈给客户，引导客户进行排查以确认分析结论是否正确。将分析的结论，有策略的告知用户，安抚客户的情绪。
d) 第四步：核查理解，将客户的理解，重新表述已确认与客户表达一致。
e) 第五步：归纳总结，总结共分为三个部分。第一部分，对应急策略的总结与归纳；第二部分，对分析策略的总结与归纳；第三部分，对客户问题的总结与归档。
4) 业务能力：
a) 测试技术：
第一， 是对产品熟悉度的提升，共分为五个层次：
第一层：对单个产品的需求与模块功能熟悉。
第二层：对单个产品的需求、业务与流程熟悉。
第三层：对多个产品的需求、业务与流程熟悉。
第四层：对多个产品的需求、特性及业务熟悉，可以间接的对一些问题的影响范围进行评估、预警，提出测试风险与项目风险。
第五层：对多个产品的需求、特性及业务熟悉，在评估风险的基础上，可有效对产品未来的功能演变进行预测，提出产品规划建议。对客户提出的需求正确判断，辅助项目经理进行风险评估。
第二， 是对测试方法的提升，共分为三个层次：
第一层：分析测试对象，明确测试需求，提出正确的测试方法。
第二层：在测试对象发生变更时，根据测试需求，调整测试方法与测试策略。
第三层：从测试瓶颈入手，在未来的测试中，规划与完善测试方法。
第三， 是对测试规划的提升，共分为三个层次：
第一层：能够根据测试需求，编写简单的测试规划，规划只针对局部功能点或局部性能验证。
第二层：能够全局的完成系统级别的测试规划，包括：测试需求、测试计划、性能计划等。
第三层：能够完成公司及部门层面的，某一类型的测试规划，包括：性能测试规划、自动化测试规划、测试工具规划等。
b) 工作效率：
第一， 时间管理，通过TimeSheets对工作事物进行统计，将按周、月对数据进行汇总分析，提升团队整体的工作效率。可间接提升，项目进度估算能力。
第二， 平滑度，通过完善各种测试流程、测试完成标准等，将测试组间的协调高度一致，将接口与输出标准统一，以求对工作效率的提升。
第三， 计划能力，测试开始前，应预留必要的规划时间，明确测试需求、测试方法在开工做事。有策略的进行加班控制，避免测试人员由于经常加班导致工作能力
下降或出现抵触情绪。
第四， 任务树，当同时有多个事物需要并发处理时，需要将任务纳入任务树中进行优先级的处理，明确哪些事物是目前紧要处理的，哪些事物是可以稍作延迟的。通过合理的划分，以求将每件事物都按时完成。
第五， 偏差与预警，当个人进度与项目进度偏差较大时，需要主动提出当前的问题与风险策略。通过小组会议评估后，明确测试方法或解决方案。通过合理加班或追加人员，以保证项目进度无延迟进行。当项目出现严重进度偏差时，项目人员需要集体讨论问题原因及规避措施，控制项目偏差度，确保产品按时上线或交付用户。
c) 相关知识：
第一， 测试行业相关——新的测试技术与方法、新的测试工具与引入、新的测试模型等。
第二， 行业背景相关——CTG-MBOSS电信业务架构、公司相关产品等。
第三， 同类型产品比较——中兴、诺基亚、朗讯、阿尔卡特等
第四， 项目管理相关——PMBOK、CMM、CMMI、ISO90001等
维度三：财务与绩效
1. 过程控制及测试计划的成本估算
2. 测试周期的控制与测试投入的估算
维度四：学习创新
提升点：性能测试，具体请参考《2009年性能测试规划》。
第一，总体框架规划
第二，测试数据模拟
第三，工件与测试结果的存放与维护