自动化测试三个阶段 - CSDN博客
自动化测试三个阶段
1.1 录制/回放测试框架
录制/回放测试框架所采用的原理是通过录制应用程序产生的线性脚本进行回放从而达到自动化测试的目的。
其优点是简单，通过录制就可以得到所需脚本。但同时也有很大的缺点，它不具有逻辑判断的能力，可维护性差，效率低下。
1.2 数据驱动的自动化测试框架
该种框架的原理是采用了数据驱动脚本进行测试，数据驱动脚本是将数据输入存储在独立的数据文件中，脚本只存放控制信息，测试时输入直接从文件中读取，这样同一脚本可以运行于不同的测试用例中，实现了脚本与数据的分离。其优点是可以快速增加相似测试，测试者增加新的测试不必掌握测试工具语言，对此后的类似测试无额外维护开销；缺点是初始建立测试脚本的开销较大，进行数据扩展的脚本需要针对相同的测试内容并具有相同的测试逻辑。
1.3 关键字驱动的自动化测试框架
关键字驱动（表驱动）是对数据驱动的逻辑扩展，它的核心思想可以概括为三个分离，其核心思想就是对象、操作、值概念的诠释。
1）界面元素名与测试内部对象名的分离 在被测应用程序和录制生成的测试脚本之间增加一个抽象层，它可以将界面上的所有元素映射成相对应的一个逻辑对象，测试针对这些逻辑对象进行，界面元素的改变只会影响映射表，而不会影响测试。
2）测试描述与具体实现细节的分离把测试描述和测试的具体实现细节分离开来。测试描述只说明软件测试要做什么以及期待什么样的结果，而不管怎样执行测试或怎样证实结果。这样做是因为测试的实现细节通常与特定的平台以及特定的测试执行工具有着密切的联系。这种分离使得测试描述对于应用实现细节是不敏感的，而且有利于测试在工具和平台间的移植。
3）脚本与数据的分离 最后，可以把测试执行过程中所需的测试数据从脚本中提取出来，在运行时测试脚本再从数据存放处读取预先定制好的数据，这样脚本和数据可以独立维护。
以上这三个分离各司其职、互相独立，最大程度地减少相互之间的影响。从关键字驱动的思想可以看出，该种测试框架不仅实现了将数据和脚本相分离，而且实现了测试逻辑和数据的分离，大大提高了脚本的复用度和维护性，从而更大限度地实现了测试工具的自动化。
本文已收录于以下专栏：
相关文章推荐
用pytest做http协议的api自动化测试一用例格式version: 2.3.2
author: fireln
createtime:
我们在上一篇《漫谈自动化测试（二）——适用场景 》谈到了软件自动化测试的适用场景，对自动化测试的先决条件和适合的测试类型进行了分析说明。既然我们知道了要开展自动化测试，那也有必要知道自动化测试成熟度的...
猛然发现，离写《自动化测试第一阶段》过去了一年。在这一年中，除了不断编写自己的代码，还接触了自动化的一些思想反面的东西。这里先总结第二阶段的感想吧~~~
1.无论是开发还是测试的自动化代码，都需要“分...
测试环境中，保证新增接口功能正确性，原有接口的回归（保证原有接口不被修改“坏”）；
生产环境中，保证接口层面服务可用，功能的正确性（保证服务挂掉时，及时发现）
接口自动化功能正确性保证(第一...
自学自动化测试近1个月了，总结一下，这段时间来的感想吧~~~
1.有用的代码就那么点，思想才最重要
很多想学习自动化测试的人都有同一个问题：“我的代码基础不好，可以学习自动化吗？”或者“自动化测试中，...
好久没有总结自己在自动化测试上的工作，这里做个简单的小结。注：这里的自动化测试是手机端UI界面的自动化
在第一阶段所做的工作，就是实现页面元素的基本定位。无论是在web自动化还是手机自动化中，元素的定...
我们知道基于界面的软件自动化测试经历了4个发展阶段。
（1）无框架阶段（即简单的录制/回放）
　　在早期，自动化测试并没有框架这一说，自动化测试只是简单的录制/回放，由工具录制并记录操作的过 程或...
对测试认识的三个阶段
蔡为东，热爱测试工作，有超过10年的软件测试和团队管理经验。
邰:邰晓梅,独立测试咨询顾问
蔡：谢谢你的分享。虽然你的工作经历比较单纯，但我相信你在...
他的最新文章
讲师：何宇健
讲师：董岩
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)博客访问： 450483
博文数量： 100
博客积分： 2005
博客等级： 上尉
技术积分： 1061
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： IT职场
1、自动化能满足我们什么　　自动化能做什么事情原本是个很古老的命题，基本所有人都知道，而且也有很多人对这一点进行过论述和论证。所以这里不再多说，只为讨论问题的完整性简单进行阐述，以便读者在阅读和思考或讨论的时候能更好的上下文衔接。　　（1）提高执行的速度　　毫无疑问，无论使用什么工具，执行是使用机器部分代替人工执行的方式，10人日的测试执行量可以由5个人花2天也可以2个人花5天完成。自动化如果实现了80%，那么使用2个人1天可以完成剩下的20%手工测试；用一台PC Server组装10套虚拟系统，10套虚拟系统0.8甚至0.5天就可以完成所有这些自动化的测试执行。不考虑自动化开发的投入，还是2个人，1天就能完成所有的测试执行，所以说自动化测试提升执行速度真正的意思是使用同等的执行人力可以结合自动化在最短时间内完成测试执行，而并非说自动化的操作速度比人工快。　　（2）避免机械式重复工作　　虽然测试有像正交覆盖这样被证明了是科学的裁剪方法，但是一方面这些裁剪方法并不是所有的地方都能使用，再者即便都能用测试执行的工作量还是非常大的。无论是多有耐心的测试人员，在长期的测试执行中也会感觉疲惫和乏味，当然有些自制力比较强的同事还是能坚持下来的。自动化测试的好处就在于能替代人去做一些反反复复的工作，可以不眠不休不厌倦；这样可以解放出一部分测试执行人员，让他们向更需要他们的地方成长、发挥。　　特别是对于像我们这样做运营测试的同事来说，可能会有几年只负责测试某一个或几个系统的补丁需求的情况。自动化让大家可以腾出手来做更多的分析工作，一定程度上也能通过提高测试分析设计的投入来提升测试的质量；同时也能让测试人员减少一些乏味的感觉，日新月异的自动化技术和不断产生的问题与结合也让大家更有解决问题的欲望，在繁琐的测试工作中更容易收获一些乐趣和成就感。　　（3）避免手工易犯的错误　　虽然测试人员普遍比较耐心细致，但是偶尔的错漏总是难免的，笔者参照自己平时的工作总结了了一下，对于笔者来说主要有以下几种导致错误的因素：　　1、正确率总会有极限，就是说测试执行的时候可以细心一万次，也总会有那么几次是不小心就忘了一些什么东西，导致测试结果偏差；　　2、注意力被事物所分散，尤其在并行任务较多的时候很容易发生考虑不周全或者忽视了一些比较隐蔽的问题；　　3、不够耐心细致，上节说到反反复复的测试，或者受影响，使得测试人员产生懈怠的状况，这样测试出来的结果很难保证就是没有问题的；　　4、思维定势，长期的工作习惯和对某些系统较为熟悉的时候容易产生问题，按照自己的经验去判定一个测试结果的正确性；而实际上一些隐藏的问题在这种情况下较容易被忽视。　　当然，手工容易发生错误的情况肯定不止笔者说的这几种情况，大家可以自己参照一下自己平时的经验，看看都会遇到一些什么样的场景。这些列举的问题如果出现在测试分析和设计的时候自动化是很难替我们避免的，即使有严格的评审机制也不能保证就可以完全避免，所以这里主要是指测试执行的时候。　　（4）自动化最根本的目标　　上文分别说了自动化的三个最为明显的好处，还有一些其他的好处我们就不继续讨论了。虽然自动化测试有这么多好处，但是我们自己到底需要自动化做什么呢？其实还是经典的三个要素：成本、时间、质量；质量不用多说大家也理解，就是避免一些人工容易犯的错误。至于时间，因为执行速度可以得到提高，所以某些测试的周期可以得到控制，比较成功的实践甚至可以大幅缩短测试周期。而成本，这里很笼统的说“成本”二字而并非人力成本或者时间成本，因为好多人把自动化的这点作用理解为节省人力、节省时间，对于测试来说，成本不仅仅是测试人力和测试时间这两点。如果把测试与项目与部门、公司的整体利益孤立开来或许可以这么说，但是测试并不能随意与这些因素割离，因为联系是普遍的，请见第三章第3节阐述。　　2、避开自动化测试的误区　　（1）必须信任自动化测试　　自动化虽然已经经历了10来年的发展历史，但是很多同事潜意识里还是更愿意相信手工测试的真实可靠性。他们其中一部分认为自动化测试是不错的方法和思想，但是相比来说机器永远代替不了人的大脑，不够灵活、不懂得变通；另外一部分从根本上就不信任自动化测试所做的测试执行，认为执行结果不可靠，根本无法节约成本，而且反而会降低测试质量。对自动化测试到底怎么看还是受站在什么角度想问题、考虑问题是否全面等因素的影响。这些不看好自动化的想法很可能是来自没有自动化实践经历的凭空想象或者是有过失败的自动化经历；他们这种失败的经历中自动化测试没有选取合适的应用范围、方法不得当所占比重非常大，并且他们在失败之后没有进一步思考，没有总结出这些导致失败的诱因。比如，认为不够灵活的往往是因为要求太高而技术实现又达不到预期；为什么想要变通呢？想必是因为需求没有达到足够细致的程度，测试设计太模糊从而导致执行实际结果很容易产生一定的偏差：如果测试分析、设计上下了足够的功夫，那么所谓的变通是完全不必要的。自动化测试脚本或者工具为什么要替代人的头脑呢？换个角度思考一下，被测系统是否达到了替代人脑的功能呢？当然没有！自动化测试只是在对被测系统进行操作，每一处验证点的检查都是针对系统的设计和实现进行的，从根本上说，如果被测系统无法替代人脑的存在，自动化测试也没有这个必要去考虑这个问题。无法节约成本的看法是因为不懂得自动化的成本效益如何分析，一味的单从自动化开发投入时间和运行时长作比较；认为自动化会降低测试质量的看法则是由于不懂自动化测试理论、不懂测试理论导致的。　　对自动化测试作用的彻底信任是自动化测试开始的必要条件，抱着半信半疑的态度去尝试只会带来很多的困扰。犹犹豫豫地总是怀疑自动化测试是否值得很可能就会导致人力投入、其他设备资源支持上的问题，认识上的误差——尤其是管理者的误解会给自动化的策略和发展带来很大的障碍。不要把自动化作为一种资本或者实力的体现，从项目管理的角度来说，它只是在测试过程中实现测试周期调控和测试质量把控的手段而已，而在整个测试过程中是起到辅助手工测试的作用还是主导着测试主要是看自动化使用的水平和程度。　　（2）了解测试开发的模式　　前面也谈到开发模式略有不同，测试自动化开发也随着不一样，一般说来自动化开发有下面几种模式，我们来看下他们各自的特点。　　1、超前式，在项目设计编码的同时就开始了自动化脚本开发，依赖系统开发过程中的高度复用；是一种比较先进的自动化设计开发模式，能够在系统移交初期就完成自动化开发，并且得到很好的应用，但是极少有公司能达到这种水平。　　2、尾随式，在系统开发环境紧随编码进度去做自动化的开发，需要投入人力较多，开发进度稍滞后与系统编码进度，但是总体来说测试开发、调试完成之后还是能够得到较好的应用。　　3、基线式，在SIT或者FAT完成之后的某个较为稳定的版本上进行自动化脚本、程序的开发。开发的时候需要有一套独立的自动化开发环境（也可以是Staging环境），界面比较稳定；但是在后期需要同步更新的地方较多，测试运行基本只能够应用在ST的冒烟测试和回归测试。　　这几种只是几种相比其它方式较为正常、普遍的模式，也有一些不为笔者所了解的方法，如果大家能够补充一下就更好了。　　在第一、第二种模式里，比较容易出现的问题是没有满足相应的条件又去使用对应的自动化开发方法；比如在第二种方式里人力投入较少，那么自动化开发进度可能严重滞后，并不能达到预期的效果，这在第一章已有阐述。基线式最常见的问题是在测试过程中不断的更新项目版本，在不断更新的项目版本上进行不断地进行自动化更新。乍一看这种操作没有什么问题，可实际上系统开发过程中有缺陷修复带来的反反复复，UI变动也存在A-B-C-A的过程。由于测试脚本开发较晚，这种测试运行基本只能够应用在ST的冒烟测试和回归测试，中途的更新并不能带来什么实际的好处，不断地随项目版本的变更去进行自动化的更新反而会消耗更多的时间和人力。我们经常听到的是：“这个系统不适合做自动化测试”这种说法，究其原因，却是因为变更（需求）太多导致的。同时这种不适合做自动化的抱怨也是一种误解，只要调整对应的自动化开发策略，问题还是能够得到一定程度上的缓解的。　　那有些同事可能说“刚经过SIT或者FAT的版本和经过ST的版本有着天壤之别，后期的更新可能跟重新开发消耗一样的时间和人力，那最初的自动化开发不是一种浪费吗？！”很简单，拿出需求规格来看看，为什么有这么多的变更呢？这些变更如果没有对应的流程记录，那毫无疑问项目经理或者你的直接主管要为这么多的人力浪费买单；如果有已经明确知会的变更，那么请记得在自动化开发过程中要跟踪每次变更，同步更新测试需求和自动化开发需求。软件开发成熟度评估标准中有一项是对需求管理的指标，上文之所以强调软件开发成熟度对自动化的影响，其中一部分原因就在这个地方了。　　（3）莫为自动化而自动化　　无论是项目测试还是运营测试中，自动化测试的目的是测试而不是自动化，自动化测试应该是先进的测试手段，是提高测试质量、测试速度的手段，而并不是单纯为了技术研究而做的事情。在这一点上犯形式主义错误的人和事屡见不鲜，笔者总结有以下三种情况：　　1、主观上崇拜技术，只是为了要证明自己有做自动化测试的实力，进行自动化的出发点错误。把自动化测试技术作为第一要义，不注重测试的需求内容，盲目追求测试自动化实现的华丽程度，但事实上没有给系统测试做太多的贡献。费时费力并不可怕，可怕的是费时费力之后却没有得到应该得的东西；你可以鼓吹自己的自动化平台、技术多先进，但是却没有资格对别人说自己的自动化能来带什么样的收益。例如有很多人在有QC和QTP的情况下，喜欢舍近求远，放弃QC的预留接口和它与QTP之间非常好的兼容性，另起炉灶去开发难度较大的测试框架。这样技术投入上消耗了更多的资源，但是效果却并不一定有已有的东西好。　　2、偏离测试主旨，长期运作但是没有实际产出物。试想一下，每天上万的测试脚本反复运行，但是从未见有发现任何缺陷或者从来就没有对“每日回归”发现的缺陷进行统计分析，这是一种什么概念。按理说能进行每日回归并且我们这种几近无甄选的“每日回归”是非常强大的，即便是大家津津乐道的持续集成中的高频度构建也是能支持的；但是我们这里缺失了一个重要的环节：对当前版本上运行结果的分析。其实高频度的运行涵盖两个方面，一是冒烟测试，这是版本每次发布Staging之后的运行，另一个是回归测试，也就是版本定版之前的运行。那么有可能哪个版本移交过来之后就没有缺陷么？当然几乎没有！既然有缺陷，那么自动化运行失败而置缺陷不理，一味追求测试脚本的修复、更新又是所谓何来呢？那只能理解为你只求把自动化的运行用在回归测试上，但事实上回归测试的时候版本基本已经稳定，一般自动化运行是很难发现什么问题的。最终自动化测试成了回归测试时增加测试人员信心的手段，目的只是为了证明没有缺陷，而不是争取发现缺陷，这也就从根本上偏离了测试的主旨。如果能形成每次运行之后的报告分析机制，那么种情况或许能够得到改善，缺陷提交是自动化运行失败必须要做的，缺陷关闭是版本移交生产必须做的，这样卡住过程的首尾，自动化测试方能起到它该起的作用。3、剥离手工和自动化，没有立足系统测试本身，有些人潜意识里可能认为自动化技术含量比较高，手工测试技术含量低。由于这种“高低”之分，抑或是为了管理方便，很多公司把负责自动化测试开发的同事和手工测试的同事从行政上划分开来，组成自动化测试组或者测试技术支持组。据笔者观察，专职负责自动化的同事在自动化开发时候容易产生自我意识，按照自己对系统操作逻辑的理解去编写测试脚本，而不是严格按照系统测试用例的操作步骤去实现。这样容易导致没有准确的操作异常处理甚至操作本身就是错误的，在运行发生错误需要开发协助的时候很耗费沟通时间。对于这样的情况：　　a）首先，自动化脚本要经过严格的评审，不单包含编码规范性和框架使用的合法性检查，还要检查对业务操作和容错性、健壮性的实现程度。参与评审的除了有测试架构师、框架设计者和自动化测试负责人之外还必须要有SA和系统测试用例设计人员甚至业务系统设计、编码人员，由他们对脚本的内容做检查的重要性要比框架设计者和自动化测试负责人所做检查的重要性大的多。　　b）其次，笔者个人不建议把懂得或者擅长自动化测试开发的人都统一放到一个分组中再去支持每个系统、项目的自动化开发；如果需要组建测试架构、技术支持组，选择一两个或少数几个自动化测试技术较好、大局意识较强的同事加入就可以了，其他的能够参与自动化开发的同事还是归属各自的行政分组或者项目组。　　c）最后，不建议给自动化开发的人冠以“自动化测试工程师”的头衔，笔者觉得非常有必要扭转一下“自动化至上”的风气。要让大家明白，自动化测试技术只是测试技术中必备的一种，而不是能够凌驾于测试基础理论和丰富的测试经验之上的东西；同时要有相应的考核指标，对参与自动化测试的同事有一个客观的评价，对他们的技术水平和贡献度进行评定。　　（4）不要过分追求覆盖率　　本章开头举了个2×5和5×2的例子，这个例子里，如果能实现100%的自动化测试，那么测试执行周期就会更短，看起来更能体现自动化测试的优越性。不过自动化覆盖程度也是要和自动化开发的投入挂钩的，下面这个图是笔者根据自己的经历、感受描绘的，这里不讨论其科学性，意思很简单：覆盖率越接近100%，需要的投入也就越多，并且不以线性关系呈现。不过这不是针对所有的系统，比如查询、报表类的系统就是很接近直线的一种趋势。　　为了论述简单，我们姑且认为人力、技术投入和自动覆盖率的下图这种关系是正确的，持否定态度的请稍安勿躁。如果有些同事认为曲线走势有少许偏差那么请忽略之，这无伤大雅；如果认为是直线或者开口朝下的右半抛物线那只能说明咱们的经历实在相差太远，您就姑妄听之、看之。另外，我们不妨先定义几个概念：　　1、自动化覆盖率：自动化运行场景数除以所有测试场景数，而并非自动化测试开发完成的案例数除以总案例数；　　2、自动化完成率：自动化测试脚本个数除以所有测试案例个数；　　3.狭义的自动化收益：是指自动化测试运行总次数乘以每次运行的总时间减去测试开发投入的总时间，这也是经常被大家所津津乐道的“自动化效益”。　　首先，在业务场景方面，对于简单的录制、回放来说，本身运行的稳定性已经很难保证，加上脚本的复用程度非常低，所以要达到较高的覆盖率是要投入非常多的自动化开发人力的，所以自动化覆盖率本身就很难达到一个较高的水平。对于数据驱动和关键字驱动层次的自动化来说，自动化场景的覆盖率比较依赖测试数据的覆盖率。在业务操作和数据分离之后，流程、场景的组合相比较低层次的录制、回放更加灵活；测试数据准备的足够全的情况下，业务场景的组合将足够丰富，带来的覆盖率更高。第一个矛盾在于对框架设计的要求很高，单个脚本设计平均耗时较多。第二个矛盾在于虽然系统测试提供多少数据就会有对应数量的场景、流程，然而系统测试中并非所有数据都能支持复用或支持数据状态回退操作，所以自动化测试数据准备本身就比较消耗时间。例如保全系统中的保单犹豫期内退保项目的每日回归就需要每天有源源不断的新承保的保单数据产生才能支持该保全项目的自动化测试运行，而新保单承保取决于新契约系统投保功能正常、新契约系统自动化测试运行正常，中间有任何环节出问题则保全系统该项目的自动化测试数据将无法获取得到。这种因实时性要求较高而储备不多的数据准备在手工测试时一般都有一定的缓冲时间；但是自动化却是无法等待的，所以有些时候未必实现了自动化就能一直应用于自动化测试执行，有时候权衡过后，即便是已经自动化的也还是要手工测试的。如果时常受这种数据问题的困扰，那么在受困扰的时候放弃这部分的自动化运行也是可以考虑的，当然牺牲一定的覆盖率，也赢得了灵活性。　　其次，在技术难度方面，我们一般不提倡把不是非要在一开始就必须解决的问题放到自动化开发的最初阶段来解决，这样很可能会因为技术卡壳影响开发进度甚至打击测试人员的信心。于是，实现上技术难度偏大的模块和功能很可能会被推后开发，开发计划制定的时候一般也会尽量这么安排，否则计划频频变更可能会难以避免。从而在自动化开发后期，技术攻关几乎成了测试开发人员的主要话题——当然，并不是每个项目都能碰到技术问题。那么在稳定的自动化开发投入持续到遇到技术瓶颈的时候，我们何不考虑一下重新评估这些没有实现自动化的模块、功能是否必须实现自动化呢？如果现有的自动化测试脚本加上手工测试用例执行的总周期能够满足版本发布测试的频度和时效要求的话，那么从项目测试角度笔者建议不要再继续开发，避免消耗更多资源；从运营维护的角度考虑可以暂缓——待系统稳定之后再考虑去解决这些问题。　　最后，结合以上两点分析，从理论上推断不难得出下图中自动化收益和自动化覆盖率之间的关系。也就是说自动化覆盖率的提升带来了人力投入的非线性增长，人力投入的非线性增长也带来了自动化收益上的非线性下降，所以自动化覆盖率的线性增长就间接带来了自动化收益上的非线性降低。至于到底是如何的一种非线性关系，各位还是从图中理解吧，笔者那点数学知识早就还给老师了。感谢：
阅读(2205) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。5115人阅读
软件测试-自动化测试Selenium（7）
软件测试-测试理论（5）
中华传统文化源于《易》，成于孝，孝为德之本。孝顺：孝则顺，不孝则不顺。
不久前，参加Thoughtworks组织的一场自动化测试的分享，同事由于出差国外不能参加，特意嘱托我提问两个问题：
在互联网这个将“敏捷”与“持续集成”进行积极实践的环境里，“敏捷测试”与“自动化测试”成了一个大家经常探讨的话题，
那么自动化测试最佳的实行时间是在什么时候？如何推行最有效的自动化测试？
以下谨代表个人观点：
个人整理了一些测试最佳实践并参考查阅了一些测试理论的书籍，又综合了个人工作经历的一些经验，总结了以下几点：
1、测试人员尽可能早的进入产品或项目的相关工作(这里指的产品或项目，指的都是从头开始的)，从产品的计划、需求调研、评审工作的开始测试人员就进行参与，这么做的目的有如下几点：a.让测试人员尽可能多的了解需求、了解业务，积极的提出问题，b.在下一步系统架构和接口设计之后，测试人员可以进行尽早设计系统的接口测试用例，c.还可以为下一步编码工作的单元测试做一个良好的铺垫，在后期设计单元测试用例的同时，懂代码的测试人员可以直接的检查开发人员的代码逻辑和业务逻辑是否符合要求，这也就实现了用最少成本“双人编程”。
2、综合一些实际情况考虑：根据一些实际调研，一般开发与测试的比例在1:6--1:10左右，能达到1:6的已经很不容易了，暂时不去讨论这个比例问题，因为这个需要根据项目的实际情况来看，个人看来：一些大型的互联网公司是不差钱的，所以他们会尽可能的在测试方面多投入或者说投入较高的，还有一些公司是不愿意在测试方面多投入但是又想多做测试的，还有一些就是尽可能少投入的，其实这些都可以调整，调整的依据是两个方面：一是确保公司对这个项目的重视和公司是真正的做测试，如果没有领导的支持，准确的说没有大领导的支持，测试工作是很难有效推进的，二是有效的安排测试人员，就是在项目的不同阶段安排不同测试人员，在测试不是很多是时候，可以使用半个人或者更少的测试人员，实现这一点的方法就是让一个测试人员去服务多个项目即可，当然这个多个也是有数量限制的，因为一个人的精力也是有限。
3、从第前2条提出来的一个疑问：作者一直提倡让测试人员尽可能早的接触产品和项目，这样能让测试人员充分了解项目，那么如何让一个人服务于多个测试项目？首先：明确一点，不是测试人员不从项目的开始就介入，测试人员就不能了解需求、不会测试。对于一个有经验的测试人员来说，快速的熟悉项目的需求并不是一件难事，如果说项目的各种逻辑真的是很复杂，项目经理也可以根据用户故事或者进行一些更为细致的安排来让这些协调过来的测试人员开展测试工作。一人服务于多个项目，这种事情在国内应该是屡见不鲜的。
4、如何安排人员也是一个如何花钱的问题：这种体会最深的就应该是外包公司，是先花钱还是后花钱还是超支还是项目失败，想必外包公司对这方面算的是最细的了。早期发现问题早解决问题，后面的压力就会小，不能早期的发现的问题，后面的团队压力就会像滚雪球一下越来越大。早期的测试投入看成一份成本的话，用这一份成本，来提早的发现问题的降低风险，后期才开始投入测试的话，也算是用一份成本，但是如果发现问题，开发人员就追踪、修改的成本是要远远大于初期的，项目的庞大和不稳定是让开发人员准确定位问题最大的困扰，还有测试人员做测试验证、回归测试、自动化脚本的修改这一切成本。
5、在项目的中后期如何做好自动化测试工作？在项目中期的时候，问题会逐渐积累，测试的东西也会越来越多，开发和维护的东西越来越多，维护是指测试人员测试出来的bug需要修复，但是又不能因为修复bug就停止项目开发工作。随着项目的推进，测试的效率保证是一个关键问题，这个时候自动化的推进和效率却成了一个矛盾的问题。原因有三：1.自动化代码需要编写和调试 2.自动化代码测试结果需要和手动测试结果进行比对 (自动化测试结果和手动测试结果不一致会有发生)3.自动化测试代码需要维护，尤其是在需求变更和设计变更的时候，手动测试只需要肉眼对比，而自动化测试可能会将代码进行较大改动。这三个问题大大降低了测试效率，这是手动测试必须成为项目的主导。解决这一问题的办法就是在项目测试集中的阶段调整手动和自动测试人员的比例，自动化人员测试的范围需要有一个合理的规划，必须定时的提交自动化测试代码，在手动测试完成后必须尽快的补充自动化测试代码，在完成测试工作的同时也自然的与手动测试的结果进行了比较，相当于进行了1次回归测试。也就说还是全部由手动测试人员进行第一轮全面覆盖的测试。
6、在“敏捷”开发过程中，自动化工程师先对哪一部分功能进行优先的用例实现：可以从以下几个方面进行考虑：1.优先考虑数据对比类型的功能，这种功能人工操作比较费眼力和时间 2.优先考虑已经测试出问题的功能，这样可以有效的对bug的功能进行回归检查 3.用户使用比较频繁的功能 4.项目优先级比较高，比较核心的功能
7.强调一点：手动测试和自动化测试对于项目来说同等重要，不存在自动化测试人员高级于手动测试人员。如果说一定要说哪个最重要的话，只能是看项目的不同阶段，在项目前中期的时候的时候，手动测试占据了核心地位，在后期的时候，自动化的全面覆盖保证了回归测试的有效进行。
8.总结：关于敏捷开发和敏捷测试的一点心得：敏捷现在已经被推向了一个高潮，何为敏捷？太多人有不同的见解，说到最后与敏捷最分不开的一词就应该是“实践”，敏捷是实践出来的，不是效仿出来的，现在太多的公司和团队在盲目的追求敏捷，拿scrum来说，有多少公司在做的只是scrum最最表象的一些东西，安排站会，制定sprint，总结会等等，但是这些真的给你的团队带来了改善了吗？想必答案只有他们自己清楚。我心中的敏捷：敏捷---敏-结，敏就是敏捷，简单的说就是要一个高效率，结：是指项目团队的协作和内部团结,这一点非常重要。看那些成功实施敏捷的团队和诸多的最佳实践团队他们都是团结一心的，整个项目团队都有一个共同的目标和追求，而不是每天项目经理在驱使着大家在前进，每个人都积极上进学习，遇到不懂的问题去总结、去学习，去突破，再去分享，而不是说，“这个问题太难了，这个技术太难了，这个。。。我可做不了”，如果每个成员都采用这种排斥的心里，那么这个团队就永远都敏捷不起来，还有就是在需要协作的时候，两个项目组不要互相“踢皮球”，而是要勇于承担责任，最普遍的现象就是项目出现了问题，然后大家在会上开始掐架。这时候有人会问，自己出来担责任不是傻吗？其实不然，一个明智的老板当然看的懂到底是谁的责任，是否真正的需要人来承担责任。如果这都做不到，证明这个老板也就。。。再谈实践，笔者看来，很难有一个很细致的又可以公用的敏捷方法，即使现在最流行的scrum，也是一个非常抽象的概念，所以才有诸多屡实施又不见成效的团队，最好的推进敏捷的方法就是实践，只有实践才能发现问题，才能解决问题，最好找到一个适合自己的敏捷方法。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：856042次
积分：5306
积分：5306
排名：第5578名
原创：79篇
评论：130条
文章：14篇
阅读：542985
阅读：74610
文章：12篇
阅读：104646
(1)(1)(1)(6)(1)(2)(1)(6)(14)(3)(6)(5)(5)(2)(3)(1)(1)(2)(1)(1)(2)(1)(2)(3)(7)(4)(1)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'