第一篇：《测试管理培训》心得
测试管理培训心得
这次培训主要针对测试管理方面的培训，包含测试流程、人员等的管理方法及技巧。由于组织这次培训的机构是第三方软件评测机构，老师不仅从第三方角度讲解了培训管理过程，而且还针对我们第二方测试管理做了相应的引导。
一、目前我国软件业大的背景如下：
1.测试需求不明确，测试不知在何时介入项目，即使知道在哪里介入，也没有发
挥很好的作用；
2.很多时候功能完成后，测试才开始执行测试工作，导致测试对需求的了解是通
过开发人员转述，造成测试人员按开发人员的理解去理解需求，使测试需求不
明确；
3.测试人员的工作都应是从文档中体现，但由于时间紧导致文档缺，无法衡量测
试人员的工作量和工作质量；
4.测试人员的文档应包括:测试计划进度计划、测试方案、测试用例、测试报告、会议纪要或沟通记录，但目前我们的测试人员很少有沟通记录的东西。
5.测试用例与需求存在很大差距，导致用例不能覆盖全部功能或用例无效；
6.没有计划的测试造成测试随意性很强，导致测试效果差。
7.配置管理混乱，导致版本混乱。
8.人员方面，合格的测试人员比较少
二、怎样管理
1.组织管理：组织架构、人员角色、人员培训
a)组织架构：质量监督（质量成果控制）、文档管理、配置管理、设备管理；
-----就目前公司现状，不需要单独文档管理和设备管理
b)人员培训：是长期工作，对新进员工培训及测试新技术培训都是要有的，但培训一定要有效果，因此培训后要有总结或考试，否则培训是浪费时间。
2.测试过程管理：测试计划、过程审核及工作产品
3.测试管理：以正确的方式对测试过程进行管理，选择合适的人建立有效的测试
团队。
三、测试分类
1.单元测试：一般由开发人员自己做，或开发人员之间互查，测试模块的可用性
及正确性，测试用例编写以详细设计为依据，使用白盒测试技术；
2.集成测试：是为了测试模块与模块之间的互通性，测试人员来做，测试用例编
写以概要设计为依据，结合使用白盒测试、灰盒测试；
3.系统测试：此阶段测试，不仅要测试软件，还要测试软件与硬件系统的结合程
序，因此，系统测试机的配置要与需求规格说明书硬件要求一致，是对整个软
件、硬软件系统测试，测试用例编写以需求规格说明书为依据；
4.验收测试：主要是业主方测试，测试用例以用户需求规格说明书为依据，此类
型测试一般不会在第二方测试；
5.性能测试：一般都是在现场环境测试，若由于软件性质问题，不能在现场测试，应该配置与现场1:1的测试环境测试，因为软件的性能不是和硬件环境成线性
比例的，因此在一个环境下测试结果，不能正确预估其它环境的测试结果。
关于测试类型还有阿尔法测试、贝特测试，但我们不是做市场化的产品，很少用到。
接着老师又从软件测试的预备阶段、准备阶段、执行阶段及收尾阶段分别详细讲解了各阶段的注意事项及中国软件评测中心在这几阶段怎么做的，其它的一些大公司是怎么做的，从中见识了一些大公司在软件测试方面的做法，从中借鉴了一些适合公司的实践。
由于时间关系，讲的不是特别细致，主要是点到为止，让我们知道测试管理有哪些关注点。主要的核心点是如何来预防缺陷要高于如何解决缺陷，缺陷越早发现解决成本越低。
很多测试人员在手工测试都不是很好的情况下，疯狂追逐自动化测试，其实一个软件在测试中，最主要的还是手工功能测试中发现的问题比例比较大，自动化毕竟还是需要人来设置场景和测试脚本，并且自动化测试在前期准备要花费大量的时间，花费大量时间写的测试脚本若没有重复使用的话，属得不偿失。当然自动化测试有它自身优点，自动化测试最大的优点就是把重复性的劳动交给计算机去做，每个版本更新后都需要重复测试的功能，或者是大量的数据的重复操作。这些如果在项目之前都开发完成的话，对于软件的效率会有极大的提高。但是它的局限性也比较大：
自动化测试前期投入很大，包括编写自动化测试工具，开发自动化测试脚本。如果
项目周期短，没有可持续性不适合自动化测试，例如我们公司目前的项目不太适合自动化测试方式。
自动化测试的技术门槛相对较高，测试团队整体水平不高的情况下无法完成工具的发开，心有余而力不足。
对于没有预期结果的测试，不适应自动化。
对于用户体验的测试，主观性比较强的不适应自动化。
测试人员的工作是基于需求、设计阶段的详细文档成果制定详细测试计划，和详细设计（测试用例及测试方案设计）可在同一时间完成。完美的测试是90%的测试任务和开发并行完成，10%的测试任务在开发之后完成，还是刚才说的，预防缺陷要比解决缺陷效果好的多。让开发人员边开发就边测试自己的代码使之都是有效代码。测试计划中除了包含常见的测试内容，功能测试，性能测试，健壮性测试，安全测试，界面测试等，还应该考虑到UE用户体验测试，因为用户体验的好坏是决定商业上是否成功的标准。不仅把产品做到能用，还要把产品做到好用。所以产品开发完成之后积累用户的反馈也很重要。需求不明确所导致的测试时间的延长，这些都要计算到测试风险之中。
制定测试计划中，人员不充分，经验不足怎么办？从工程的角度考虑问题，不仅仅
是要求测试人员之间分享经验，还需要有效的标准。一个好的模板，是节约人力成本的好办法。还能弱化对每个人的依赖度。还要检查需求细不细，避免主观语句（性
能高，响应速度快等这样的形容词），速度响应快，快到多少秒。一定要量化需求， 而不是主观感受。凡事以数据说话，这样才能有说服力。如何提高测试用例的编写水平？第一，积累测试素材，比如对于文本框的验证，一
般都是验证那几项，有效数值，无效数值。空格，空等等。这些测试用例在每个项
目中都可以反复使用。第二，测试方法的复用，对于有继承性的项目来说，用之前
编写的测试脚本或自动化测试工具以达到测试方法的复用(目前公司还用不到这
点)。如何判定测试是否充分？验证到每个对象的每个属性值，结合白盒深度测试。测试对bug的理解不一致怎么办？有争议的地方和开发人员商定，确认后建立checklist或者用户指南，列出检查清单。以后如发现此问题，对照清单解决问题。如果衡量缺陷的质量？1）检查环境，测试环境是否正常 2）是否可重现 3）检查
是否是重复bug 4）详尽的操作步骤 5）问题的定位 6）要能提出修改意见就更好了
缺陷的分类比一般的分类多的项有：测试引起的；由其他bug引起的；功能未实现的。
执行测试的过程当中，限定解决缺陷的时间，即check-in估计完成时间。真正把每个问题都落实到微观。这些缺陷分配理论上由项目经理来做。通过缺陷管理平台，所有缺陷平台管理员、领导知道某个开发人员的代码有效率是多少，即使他们未曾谋面。目前有很多跨地域管理的问题，管理者不可能时刻都盯着手下的人在做什么。重要的得到信息的方式，做到用数据管理，以事实说话。
测试后期到准备发布阶段，发布评估标准（Release Criteria）：
95%的测试用例通过率，且持续时间>5天。---针对目前公司发现缺陷的程度，要100%通过 代码覆盖率>85%---目前公司需完善的指标 ZBB（零基预算）零bug边界，保持15天—---针对目前公司小项目，应该取更少
天数比较好。
测试项目之中的管理，以数据为依据，分析bug的曲线，知道目前的项目进展状况并估算项目的进度是否在可控范围内，才能保证项目顺利进行。对于项目的流程的制定，过于复杂的流程如果过于难以执行，则会降低纪律的可执行力，所以针对不同的项目制定流程裁剪活动。流程裁剪一旦确定，就要落实。分配任务的时候要落实到每个人头上，不能把一个任务交给一群人做，要明确到每个人做什么模块。合理的制定里程碑之间的工作计划，循序渐进逐步完善：
短期计划：
针对这次培训，整理一个培训课件，找时间做一次测试培训；
完善测试组用到的模板；
规范测试流程，对JIRA的应用流程强调说明，在我们能掌控范围内将测试流 程向标准靠拢； 项目所有成果都要commit到SVN上，目前两个项目组已经有计划出来；
测试机与开发调试机分离，实现开发、测试两条线； 修改月绩效考核指标，制订一个符合测试组实际工作的考核指标； 中期计划：
调整缺陷管理库，做到测试用例和bug关联； 完善项目开发组用到的模板； 培训过程中，对培训效果要做评估，考试或培训总结，为了证明培训作用这一
项是必要的，即使是考试，题目题量是开放式的问题，而不是简单选择题。
长期计划：完善性能测试、系统测试环境。3天的测试管理培训时间并不长，简单介绍了一些软件测试国标规范，结合案例，老师给我们讲了一些测试管理的方法及流程。我们要想提供给客户一款满意的产品，关键在于对产品质量的要求，“在质量面前什么都不重要”。我个人对项目的简单理解就是，每个阶段把握每个细节，认真落实文档，凡是计划要出的文档，一定要把关文档质量，评审的目的就是让其他人帮你想遗漏的地方，然后严格遵循文档开发，用实际的数据说话；对测试的简单理解是，测试越早介入，BUG遗漏率越低，解决BUG的成本越低；总之，每个人都担当起QA的职责，监督团队的其他人，互相促进和发展，项目的质量就会大有保证。
第二篇：《测试管理培训》心得
测试管理培训心得
这次培训主要针对测试管理方面的培训，包含测试流程、人员等的管理方法及技巧。由于组织这次培训的机构是第三方软件评测机构，老师不仅从第三方角度讲解了培训管理过程，而且还针对我们第二方测试管理做了相应的引导。
一、目前我国软件业大的背景如下：
1.测试需求不明确，测试不知在何时介入项目，即使知道在哪里介入，也没有发挥很好的作用；
2.很多时候功能完成后，测试才开始执行测试工作，导致测试对需求的了解是通过开发人员转述，造成测试人员按开发人员的理解去理解需求，使测试需求不明确；
3.测试人员的工作都应是从文档中体现，但由于时间紧导致文档缺，无法衡量测试人员的工作量和工作质量；
4.测试人员的文档应包括:测试计划进度计划、测试方案、测试用例、测试报告、会议纪要或沟通记录，但目前我们的测试人员很少有沟通记录的东西。5.测试用例与需求存在很大差距，导致用例不能覆盖全部功能或用例无效； 6.没有计划的测试造成测试随意性很强，导致测试效果差。7.配置管理混乱，导致版本混乱。8.人员方面，合格的测试人员比较少
二、怎样管理
1.组织管理：组织架构、人员角色、人员培训
a)组织架构：质量监督（质量成果控制）、文档管理、配置管理、设备管理；
-----就目前公司现状，不需要单独文档管理和设备管理
b)人员培训：是长期工作，对新进员工培训及测试新技术培训都是要有的，但培训一定要有效果，因此培训后要有总结或考试，否则培训是浪费时间。
2.测试过程管理：测试计划、过程审核及工作产品
3.测试管理：以正确的方式对测试过程进行管理，选择合适的人建立有效的测试团队。
三、测试分类
1.单元测试：一般由开发人员自己做，或开发人员之间互查，测试模块的可用性及正确性，测试用例编写以详细设计为依据，使用白盒测试技术； 2.集成测试：是为了测试模块与模块之间的互通性，测试人员来做，测试用例编写以概要设计为依据，结合使用白盒测试、灰盒测试；
3.系统测试：此阶段测试，不仅要测试软件，还要测试软件与硬件系统的结合程序，因此，系统测试机的配置要与需求规格说明书硬件要求一致，是对整个软件、硬软件系统测试，测试用例编写以需求规格说明书为依据；
4.验收测试：主要是业主方测试，测试用例以用户需求规格说明书为依据，此类型测试一般不会在第二方测试；
5.性能测试：一般都是在现场环境测试，若由于软件性质问题，不能在现场测试，应该配置与现场1:1的测试环境测试，因为软件的性能不是和硬件环境成线性比例的，因此在一个环境下测试结果，不能正确预估其它环境的测试结果。
关于测试类型还有阿尔法测试、贝特测试，但我们不是做市场化的产品，很少用到。
接着老师又从软件测试的预备阶段、准备阶段、执行阶段及收尾阶段分别详细讲解了各阶段的注意事项及中国软件评测中心在这几阶段怎么做的，其它的一些大公司是怎么做的，从中见识了一些大公司在软件测试方面的做法，从中借鉴了一些适合公司的实践。
由于时间关系，讲的不是特别细致，主要是点到为止，让我们知道测试管理有哪些关注点。主要的核心点是如何来预防缺陷要高于如何解决缺陷，缺陷越早发现解决成本越低。
很多测试人员在手工测试都不是很好的情况下，疯狂追逐自动化测试，其实一个软件在测试中，最主要的还是手工功能测试中发现的问题比例比较大，自动化毕竟还是需要人来设置场景和测试脚本，并且自动化测试在前期准备要花费大量的时间，花费大量时间写的测试脚本若没有重复使用的话，属得不偿失。当然自动化测试有它自身优点，自动化测试最大的优点就是把重复性的劳动交给计算机去做，每个版本更新后都需要重复测试的功能，或者是大量的数据的重复操作。这些如果在项目之前都开发完成的话，对于软件的效率会有极大的提高。但是它的局限性也比较大：
自动化测试前期投入很大，包括编写自动化测试工具，开发自动化测试脚本。如果项目周期短，没有可持续性不适合自动化测试，例如我们公司目前的项目不太适合自动化测试方式。
自动化测试的技术门槛相对较高，测试团队整体水平不高的情况下无法完成工具的发开，心有余而力不足。
对于没有预期结果的测试，不适应自动化。
对于用户体验的测试，主观性比较强的不适应自动化。测试人员的工作是基于需求、设计阶段的详细文档成果制定详细测试计划，和详细设计（测试用例及测试方案设计）可在同一时间完成。完美的测试是90%的测试任务和开发并行完成，10%的测试任务在开发之后完成，还是刚才说的，预防缺陷要比解决缺陷效果好的多。让开发人员边开发就边测试自己的代码使之都是有效代码。测试计划中除了包含常见的测试内容，功能测试，性能测试，健壮性测试，安全测试，界面测试等，还应该考虑到UE用户体验测试，因为用户体验的好坏是决定商业上是否成功的标准。不仅把产品做到能用，还要把产品做到好用。所以产品开发完成之后积累用户的反馈也很重要。需求不明确所导致的测试时间的延长，这些都要计算到测试风险之中。
制定测试计划中，人员不充分，经验不足怎么办？从工程的角度考虑问题，不仅仅是要求测试人员之间分享经验，还需要有效的标准。一个好的模板，是节约人力成本的好办法。还能弱化对每个人的依赖度。还要检查需求细不细，避免主观语句（性能高，响应速度快等这样的形容词），速度响应快，快到多少秒。一定要量化需求， 而不是主观感受。凡事以数据说话，这样才能有说服力。
如何提高测试用例的编写水平？第一，积累测试素材，比如对于文本框的验证，一般都是验证那几项，有效数值，无效数值。空格，空等等。这些测试用例在每个项目中都可以反复使用。第二，测试方法的复用，对于有继承性的项目来说，用之前编写的测试脚本或自动化测试工具以达到测试方法的复用(目前公司还用不到这
点)。
如何判定测试是否充分？验证到每个对象的每个属性值，结合白盒深度测试。测试对bug的理解不一致怎么办？有争议的地方和开发人员商定，确认后建立checklist或者用户指南，列出检查清单。以后如发现此问题，对照清单解决问题。如果衡量缺陷的质量？1）检查环境，测试环境是否正常 2）是否可重现 3）检查
是否是重复bug 4）详尽的操作步骤 5）问题的定位 6）要能提出修改意见就更好了
缺陷的分类比一般的分类多的项有：测试引起的；由其他bug引起的；功能未实现的。
执行测试的过程当中，限定解决缺陷的时间，即check-in估计完成时间。真正把每个问题都落实到微观。这些缺陷分配理论上由项目经理来做。通过缺陷管理平台，所有缺陷平台管理员、领导知道某个开发人员的代码有效率是多少，即使他们未曾谋面。目前有很多跨地域管理的问题，管理者不可能时刻都盯着手下的人在做什么。重要的得到信息的方式，做到用数据管理，以事实说话。
测试后期到准备发布阶段，发布评估标准（Release Criteria）： 95%的测试用例通过率，且持续时间>5天。---针对目前公司发现缺陷的程度，要100%通过
代码覆盖率>85%---目前公司需完善的指标
ZBB（零基预算）零bug边界，保持15天—---针对目前公司小项目，应该取更少天数比较好。
测试项目之中的管理，以数据为依据，分析bug的曲线，知道目前的项目进展状况并估算项目的进度是否在可控范围内，才能保证项目顺利进行。对于项目的流程的制定，过于复杂的流程如果过于难以执行，则会降低纪律的可执行力，所以针对不同的项目制定流程裁剪活动。流程裁剪一旦确定，就要落实。分配任务的时候要落实到每个人头上，不能把一个任务交给一群人做，要明确到每个人做什么模块。合理的制定里程碑之间的工作计划，循序渐进逐步完善：
短期计划：
针对这次培训，整理一个培训课件，找时间做一次测试培训； 完善测试组用到的模板；
规范测试流程，对JIRA的应用流程强调说明，在我们能掌控范围内将测试流 程向标准靠拢；
项目所有成果都要commit到SVN上，目前两个项目组已经有计划出来；
测试机与开发调试机分离，实现开发、测试两条线；
修改月绩效考核指标，制订一个符合测试组实际工作的考核指标； 中期计划： 调整缺陷管理库，做到测试用例和bug关联； 完善项目开发组用到的模板；
培训过程中，对培训效果要做评估，考试或培训总结，为了证明培训作用这一项是必要的，即使是考试，题目题量是开放式的问题，而不是简单选择题。
长期计划：完善性能测试、系统测试环境。
3天的测试管理培训时间并不长，简单介绍了一些软件测试国标规范，结合案例，老师给我们讲了一些测试管理的方法及流程。我们要想提供给客户一款满意的产品，关键在于对产品质量的要求，“在质量面前什么都不重要”。我个人对项目的简单理解就是，每个阶段把握每个细节，认真落实文档，凡是计划要出的文档，一定要把关文档质量，评审的目的就是让其他人帮你想遗漏的地方，然后严格遵循文档开发，用实际的数据说话；对测试的简单理解是，测试越早介入，BUG遗漏率越低，解决BUG的成本越低；总之，每个人都担当起QA的职责，监督团队的其他人，互相促进和发展，项目的质量就会大有保证。
第三篇：测试培训心得
软件测试培训心得体会
1.1概述
2013年12月27日下午14：00-17：30，研究院邀请了测试支持部的XXX召开软件测试培训，本人非常荣幸的参加此次培训，通过这次培训让我系统的梳理了软件测试理论技术，对软件测试有了一个更深入更全面的认识。更为重要颜经理通过他的测试经验分享，可以让我在日后的工作中会少走一些弯路，以免犯一些不必要的错误。
1.2软件测试培训内容及自我体会
此次培训的内容主要包括VMS项目总结，SPMS系统测试流程及华为验收流程介绍，测试工程师需要的技能和软件，软件测评师的简述等 以下是自我体会
体会一: 软件测试在整个软件生命周期中的重要性
现状：国内大部分公司都存在对测试工作不太重视的现状,诸如软件测试就是为软件开发打下手，测试与开发的配比也存在严重的不足，一般公司都是1比3，更有甚的就是没有测试人员，放眼国外的大公司微软，测试与开发比例为1：1，软件测试它存在于整个项目周期，在项目开始之初需求调研的时候就开始了，在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重，能主导整个软件项目的走向，成败与否全在于开始阶段的决策。
体会二: 系统测试流程的严格执行很重要
学习了公司的SPMS系统测试流程和华为的验收流程，通过VMS项目的经验有１.需求及设计文档不够详细，导致了开发，测试，资料活动受阻，导致后期的沟通成本大幅增加，并出现了架构调整的重大风险2．需求及设计评审不足导致后期变更比较多3.没有全面地测试需求分析，未能从整个系统把握住所要测试的需求。以上经验都告诉我们系统测试流程的严格执行很重要，从项目前期的需求分析，总体设计到测试需求的分析及用例，再到后期的系统测试等，只有严格执行标准的系统测试流程才能把风险降低。
1.3个人想法和总结
通过这次培训，结合目前我的测试工作，接下来为了提高我们的软件能在质量上得到保障减轻项目后期维护验收的风险，在此做以下后期测试的想法； １.加强测试需求分析：第一：通过分析需求测试点，“尽早的了解被测系统”，第二，如果在需求分析阶段发现系统存在严重的Bug（此阶段的bug最多），或者发现不可测的地方，可以及时的进行修改，避免了后期修改bug的巨大的成本浪费。
２.规范开发转测试的流程：制定开发提交给测试软件的流程，使得测试工作会更顺利的开展，提高工作效率
３.测试管理工具的利用：去探索一些适用的测试管理工具，提高整体项目组的工作效率 通过这次培训，让我们学到了丰富的测试知识和经验，也让我们看到自身存在的不足，我和我们的同事必将吸取这次测试培训经验，把我们的整个软件测试流程做的更规范，更专业，更优秀，将项目的风险降到最低。最后感谢公司能够安排这样的培训，让我们能在公司得成长中学习，在学习中成长。
第四篇：软件测试-培训心得
个人浅谈培训之心得
2013年3月8日，黄老师在百胜软件进行了为期一天的测试管理培训，本人非常荣幸的参加了此次培训，通过这次培训让我充实了更多的理论方面的知识，拓宽了思路，有许多不能用语言来表达的收获，让我更进一步的了解了软件测试理论技术，对软件测试有了一个更深入更全面的认识，对于以后如何更好的工作有了更全面的认识。
参见培训以前，没有测试环境重要性的认知，通常是测试需要什么环境就配置什么环境，开发不能重现的bug在测试机器上修改的情况大有存在。这次培训让我了解到，测试的进步、高效率首先有在测试环境建立和管理的基础。在保证开发环境与测试环境的唯
一、纯净性的同时，必须建立一个科学的标准库。
磨刀不误砍柴工，同样测试设计并不会耽搁测试的进度和效率。我们大部分人是看到测试任务，读懂就开始啪啪啪的进行测试，并没有测试之前的思考和设计。
并不是所有的测试写的越细越好，根据产品形态、形式、周期的不同，测试用例的细化程度是为了实现高效率的可执行、低成本的易维护。
以前一直以为，自动化测试，会用工具，会写执行脚本就可以了。听完老师的培训之后，我认识到，测试用例的设计、维护在自动化测试中统一重要，自动话测试并不是为了发现bug而去测试的，自动化测试是为了检查没有bug，程序没有错误。
听黄老师的一席话，让我在软件测试的路上，少了些弯路、少了些挫折。公司这样的培训，虽然不能起到立竿见影的效果，但潜移默化之中，把我们的测试之路修的较为平整些，吸取的经验减少着我们的痛苦。
第五篇：软件测试培训心得
从事软件测试工作已经有三年了，在经历了小公司、大公司的功能测试之后，业务需求已经不是本职测试工作的阻碍了，这时的我们该想想接下来的路了……
通过qq群知道了有这么一个测试培训机构有这么一群不断努力的人。思来想去，周末在家无聊的荒废时间，不如试试加入他们，重拾刚毕业那会的昂扬斗志。
加入这个培训之后才从之中的同学那里知道，原来这个培训班已经办了快两年了，里面有很多学员都是从最初一直坚持到现在。培训课程设计范围也很广，包括系统的数据库、java编程、linux系统包括时下比较fashion的手机自动化测试等等知识，在讲述这些知识的同时老师会在课程中间穿插测试涉及的内容。课程完毕后，对应的老师也会一直在群里与同学互动，及时解决同学在实际测试应该过程中发现的问题，这个对于我们在职的软件测试人员还是很有吸引力的。
目前为止，我也只参加了两次培训，一次单元测试，老师是微软的开发人员。虽然测试人员一般不会做单元测试，但对于目前很多公司不重视测试的行业现状，多了解开发人员的工作流程或操作无可厚非，在必要的时候能够明白开发是用什么工具如何进行的也可以让开发对你的测试工作给予更多的肯定。之后的培训是手机自动化的，我因有事无法参加，不过看到群里大家在热烈的讨论时，还是有点遗憾
啊。最近的一次培训是selenium自动化测试，这次的培训不是用的selenium IDE而是通过结合浏览器自带组件自编代码进行各个浏览器的自动化测试，虽然这次讲的东西比较少，但对于我们实际的测试工作还是很有帮助，至少给我们的测试工作提供的思路，不是一提自动化测试就茫然无措了。
点击咨询 