茹炳晟简介： 　　茹炳晟，男，毕业于上海交通大学，获硕士学位，现任惠普软件上海研发中心测试架构师，具有7年软件测试经验和3年开发经验，历任测试技术主管、高级测试工程师等职位，具有丰富的测试框架设计与自动化测试经验。曾负责无线路由产品的整体自动化测试方案、金融平台产品SDK测试框架设计、系统开发平台的白盒测试方案、DSP平台自动化测试方案、轨道交通安全软件平台测试、大规模产品链的自动化部署和多个大型Web项目的自动化功能测试与性能测试。 了解测试流程 　　51Testing：最近主要在从事哪方面的工作？ 　　茹炳晟：目前我在HP主要负责软件产品的GUI自动化测试方案设计、产品链的全自动化部署方案设计和API层面灰盒测试框架的设计与开发，同时为HP软件性能测试中心提供自动化测试相关的技术支持并负责两个新产品的性能测试工作。 　　51Testing：测试工作从产品立项后开始介入，贯穿于软件产品的整个生命周期。那么在整个软件测试过程中，需要关注哪些要素呢？结合一个具体例子说明 　　茹炳晟：这个问题非常大，可以说几乎涉及了软件测试的方方面面。同时对于不同类型的被测软件或系统，在生命周期的不同阶段，需要关注的点又都不尽相同。显然，对于一个嵌入式应用、一个WEB应用和一个开发平台SDK，虽说三者的整个生命周期阶段相类似，但是具体的测试方法和技术、管理关注点差别非常大。这里只能以一个相对正规并且具有一定规模的软件项目为例，简单笼统地罗列一下。 　　51Testing：软件测试的一般流程是什么？各阶段的任务和目标分别是什么？ 　　茹炳晟：正如前面提到的测试将从产品立项后开始介入，贯穿于软件产品的整个生命周期，我们首先必须明确地认识到软件测试是一个持续进行的过程，而不是一个阶段。通常来讲软件测试一般会经历以下几个主要过程： 　　需求分析： 　　需求分析主要包括软件功能需求分析、软件测试需求分析，测试技术需求分析，测试环境需求分析、测试资源需求分析等。可以说成功的需求分析是整个项目成败的关键因素。站在测试人员的角度，软件功能需求分析是要让测试工程师们搞清楚软件具有哪些功能，最终用户将以什么样的行为来使用被测软件，这是后面开展系统测试活动的基础。软件测试需求分析是系统测试设计人员的核心工作，在这个阶段，通过分析软件功能需求以及结合以往总结的经验，将归纳分析出软件的测试需求。举个例子的话可能更好理解，比如在一个Web应用软件的功能需求里面定义了软件系统具有用户登陆的功能，那么有经验的测试设计人员将会从多个角度提出软件的测试需求，从功能实现的角度需要测试登陆功能在正常用户登陆和非法用户登陆情况下的正确性，从性能角度将要考虑高并发大数据背景情况下登陆功能的稳定性和可用性，从安全的角度将会考虑设计应对SQL注入、跨脚本攻击的测试，从兼容性的角度涉及多浏览器支持的测试等等。测试技术需求分析主要解决系统测试方法选型，确定是否需要额外开发测试工具，是否需要开发提供方便测试的接口等。也举个例子吧，对于某个ERP系统的测试，我们可能需要人为在数据库端生成大量的数据，那么就可能需要写个小工具来帮助快熟可控的生成需要的数据，同时可能我们还需要关心一些server端的性能指标，这时如果开发能够提供定制系统log级别，我们就可以通过分析log来得到原本需要通过复杂的Profile工具才能得到的数据了。测试环境需求分析和测试资源需求分析可以归类到管理的范畴，主要解决测试环境机器配备，测试工具License申请或购买，人员协调安排等等，这里就不具体啊再展开了。 测试计划 　　测试计划是指导整个测试项目的纲领性文件，是成功测试的前提和必要条件，测试计划一般由测试项目经理和测试架构师一起编写，属于项目的正式文档，需要通过多部门评审以及需要纳入版本管理。测试计划的依据主要是项目开发计划和一系列测试需求分析的结果来制定。测试计划的内容可以说大而全，站在管理的角度可以说涵盖了测试活动的各个方面。通常的做法是采用预先定义好的模板，以防止某些环节遗漏或者欠考虑。介绍这方面内容的资料相当多，这里就不展开了。但有一点相提一下，就是计划永远赶不上变化，一份计划考虑再周到，当实际的实施过程中都会发现很难按照原有计划开展工作。如在软件开发过程中，需求的变更，开发周期的变化，重要缺陷的暴露，代码重构，资源匮乏、人员流动等都会对测试造成很大的影响。所以，这些就要求测试项目经理能够从宏观上跨团队地来调控以及测试架构师从技术层面的把关了。 　　测试设计 　　测试设计是测试工作的核心，主要包括测试方案设计，测试环境设计和测试用例设计三个方面。测试方案设计主要回答一下几个问题： 　　1、手动测试 VS 自动化测试：哪些部分采用手工测试，哪些部分考虑自动化 　　2、根据项目情况，方案需要预计引入的测试工具，比如HP QTP，LoadRunner， SOAPUI等 　　3、根据项目情况，确定需要开发的测试辅助工具并完成辅助工具的需求收集和初步设计，比如Log分析工具，数据生成工具和环境模拟仿真工具等 　　4、在技术层面，测试的入口以及出口策略（管理层面的出入口策略会在测试计划中定义） 　　5、方案的测试需求覆盖率策略 　　6、测试执行与测试结果分析的度量策略 　　7、测试用例的优先级策略 　　8、自动化测试的策略 　　9、方案的可持续集成能力以及与现有CI系统的集成方法 　　10、方案的缺陷与弱势，是否需要辅助其他手段等 　　对于测试环境设计和测试用例设计，相信大家平时接触都比较多，这里就一笔带过了。只想提一点关于测试用例设计的，因为我个人觉得这是一个非常好的实践。我们可以对于不同类型的系统测试建立一套知识库或称Checklist，知识库可以分为不同层面，比如业务流程层面，控件操作层面，数据库层面等，在每个层面中用于保存系统常见的缺陷类型和典型的测试用例设计。比如对于控件操作层面，我么把可以把对一个系统中文本输入框的常见测试用例归纳总结，比如输入正常字符，输入中文韩文日文，输入带引号或者转义符的字符串等等。对于数据库层面对于常用查询表的索引建立等等。有了这样的知识库，将会大大增强测试用例的质量，同时使得相对经验不足的测试工程师也能设计出高质量高覆盖的测试用例，帮助刚入行的同学快速成长。 　　测试环境搭建 　　不同软件产品对测试环境的要求差别很大。测试环境搭建的关键在于测试环境的设计，设计需要确保测试环境满足测试用例所描述的各种要求，通常对于一个系统级别的测试，往往需要根据测试的目的不同搭建多套测试环境，这些环境之间如何在相互不影响的情况下有效地共享资源也是必须要考虑的。 　　测试执行 　　在项目的不同阶段，对应多种不同阶段或类型的测试执行，主要包括单元测试执行，集成测试执行，BAT测试执行，系统测试执行，验收测试执行。每种测试执行又可分为测试开发和测试运行两个相互迭代的阶段，当然测试运行还包括手工回归测试和自动回归测试等。同时，测试执行过程中会遇到很多复杂并相互依赖的问题，比如某些缺陷将会阻碍后续测试的执行等，这就需要我们结合测试用例的优先级，随机应变，具体问题具体分析和解决。 缺陷管理 　　测试执行过程中发现的任何问题以及与需求不一致或者在某种程度上不能满足用户的需要的地方，都需要由测试工程师递交缺陷记录到缺陷管理系统进行统一跟踪和管理。缺陷本身不仅可以根据常规的严重等级进行分类，也可以根据缺陷的内容分为功能未实现或实现错误缺陷和程序缺陷。通常而言，缺陷管理需要解决以下两个问题：一是确保每个被发现的缺陷都能够被追踪并且最终被解决，二是收集缺陷数据并根据缺陷趋势曲线识别和预防类似缺陷的频繁发生。在谈到缺陷管理时，首先想到的是如何修正缺陷，而对根据缺陷分析进行有效预防缺陷却很容易忽视。事实上，在一个CMMI等级较高的项目团队中，缺陷数据的收集和分析是必须的，可以从缺陷数据中得到很多与软件质量度量的相关数据。 　　任何一个软件团队或组织都必须建立完善有效地软件缺陷跟踪与管理流程。没有完善的缺陷管理机制，将会使软件项目陷入失控状态，使测试人员递交的缺陷无法全面地追踪和管理，甚至会被遗漏，或没有人知道在新的软件版本里究竟纠哪些缺陷被修正了以及如何修正的，还有哪些缺陷未被纠正以及没有在该版本中修正的原因。更重要的是修正过程是否引入了新的缺陷以及新的缺陷是由那部分修正引入的也无法追踪。一个相对完备的缺陷管理过程通常会包括如下几个方面： 　　● 提交缺陷报告 　　● 评审缺陷分类并最终确定严重等级 　　● 分析和定位缺陷 　　● 评估影响范围并确定待修正版本 　　● 修正方案的同行评审以及评估可能的影响 　　● 执行软件修改 　　● 软件修改的代码评审 　　● 代码递交 　　● 缺陷修复验证 　　● 影响范围验证 　　测试总结 　　这个阶段的工作每个公司的差异会很大，不同软件能力成熟度的公司的关注点差别也很大，这里我就不想一一去举例了。只是简单提两点共性的目标，首先，需要汇集组织内部以前项目的经验教训，收集测试度量数据，制定组织级的量化度量指标。其次，一切工作需要围绕测试流程的持续性改进，从而使过程能力得到不断的提升。 　　测试维护 　　测试维护包含几方面的工作，第一是当软件正式发布后，在上线使用过程中难免还会有遗漏的缺陷暴露出来，这时候就需要修正这些问题，修正后再次对软件进行验证测试和有限的回归测试。第二是软件版本的升级会引入新的测试需求。第三是软件版本升级后自动化测试用例的维护与扩展。 　　51Testing：是否大公司的测试流程都是好的、完善的测试流程？如何合理的制定软件测试流程？ 　　茹炳晟：在讨论这个问题前，想先谈论一下我对流程的理解。流程是在某个特定上下文环境下固化下来的行事规则与经验，因为曾经已经取得过成功，并且也吸取了一定的经验教训以规避失败，因此在相同的情况下，流程会带来更大的成功概率，并形成权威，使后来者有效应用先前的成功经验，少走弯路提高效率。适合的流程能够指导人们正确地完成各种开发活动；而不合适的流程，则会把软件项目推入无底深渊。但是，就流程本身而言，我个人认为并没无好坏优劣之分，或者说衡量流程的度量指标不应该是好与不好，而应该是流程对当前组织或者项目的适用程度，只有真正适合自己团队的测试流程才是好的测试流程。有些重量级的流程固然有其权威和周全的考虑，但是对于小规模团队或者敏捷团队却完全不适用，靠行政手段强行推广只会适得其反，而有些看似很粗超简陋的流程却非常适合一些极具创新的研究型团队。所以说流程不能被神话，更不能被滥用。世界上不存在放之四海而皆准的流程，而只有因地制宜、因人制宜地选择合适的流程，并在执行过程中不断地加以改进和完善，才有可能取得成功。具体到测试流程的制定和完善，我想这也是一个非常庞大的话题，这里我就想简单提几条我个人认为比较好的最佳实践吧。 　　1、切记，不要盲目拷贝大公司的测试流程，而是要吸取他们的经验教训，取其精华去其糟粕，这样的测试流程对于我们来说才是有价值的，有改进意义的。 　　2、测试流程需要尽可能使得被测系统尽早地，频繁地进行测试，使问题在项目的早期尽可能多的暴露 　　3、流程需要能够有效加强各个团队间的交流与沟通，让每个项目干系人都有明确的渠道了解项目的测试状态和完成情况 　　4、流程上保证整个测试活动必须被计划，被控制，并且必须提供必要的时间与资源5、把测试产出（测试用例设计，测试脚本，测试工具等）作为产品的一部分等同管理，使用相同的版本管理和评审机制 　　6、具备入口条件的情况下尽早发布测试主计划并完成评审，所有其他工作和子计划都围绕项目主计划开展，使各个团队（产品管理团队，开发团队，项目管理团队和内部审计团队）对测试的范围与策略达成一致 　　7、在测试流程的各个阶段，维护测试需求和目标的风险以及优先级列表，并对各种已识别的高风险条目提供规避和缓解策略 　　8、测试完成后，必须执行测试度量和缺陷分析统计工作，不断总结经验，改进测试方法以及流程 　　9、流程的推行与执行必须以解决实际问题为基本出发点，尽量避免靠行政手段强行推广 　　10、对于已经达成一致的流程，有必要组织必要的培训，使各团队成员对流程在操作层面上有清晰的认识，这将大幅提高流程本身的执行力 改进测试流程 　　51Testing：你们团队是如何进行软件测试的？请介绍下你们公司的测试流程。 　　茹炳晟：HP的软件部门比较庞大，涉及的产品线也极其丰富，做测试的同学可能最熟悉的要属HP的QuickTest Professional、LoadRunner、Unified FunctionalTesting和Application Lifecycle Management（前身是Quality Center/Test Director）。其实这些仅仅是HP软件产品线的一部分。其他还有Service Anywhere,Business Service Management,IT Service Management,Autonomy等等，而且很多软件产品之间可以相互集成以形成一整套行业解决方案。另外，绝大多数产品的研发团队都是跨国分布的，比如需求和设计在美国，架构设计在以 {MOD}列，开发在中国，测试在印度，所以要想完整介绍整个软件研发团队的流程好像不太现实，这里只想重点聊一下我们在测试方法和流程上的最佳实践。 　　1、在自行开发工具（类似于Jenkins）的支持下，将软件项目整个生命周期的主要活动纳入持续集成，其中包括代码静态检查，单元测试，API测试，每日构建，自动化部署，自动化GUI测试等。每个步骤都有相应结果和报表于第一时间发送给项目干系人。 　　2、对于Saas项目，建立持续发布机制 　　3、所有的产品代码和部分测试代码的递交都在Review Broad支持下进行代码评审。 　　4、所有测试文档和测试资产都建立完善的变更管理与版本控制。 　　5、不搞“一刀切”，某些项目，恰当好处地利用轻量级的敏捷流程。 　　6、在系统测试层面，广泛推广利用业务逻辑驱动（BDD）模型，并建立了适用于BDD工作模型的流程。 　　7、在代码层面，部分项目推广测试驱动（TDD）模型，并建立了相应流程。 　　8、建立了完善的缺陷分布和趋势分析机制，很好的控制了产品的质量风险。 　　9、建立流程知识库和产品知识库，并提供内部相关培训。 　　10、严格执行软件产品质量度量，归档项目历史数据，为过程持续改进提供决策数据支持。 　　11、流程执行的高度透明性，并有高度定制的管理信息系统的支持。 　　12、提供预先定义的流程库，根据软件项目规模和性质，裁剪适合该项目的流程并提供管理层面的评审与审批机制。 　　13、充分利用类Wiki工具，推进内部知识的共享与积累。 　　51Testing：针对这一流程，您觉得还有哪些地方是需要改进的呢？ 　　茹炳晟：虽然我们目前的流程大而全，可以说包含了软件项目的各个方面，但是其中的问题也是有很多的。 　　1、某些产品由于有将近10年的生命周期，对应的研发和发布流程极其繁琐，用俗话来讲就是很“重”，当然这其中难免有很多历史遗留的原因，其中包括CMMI，跨国开发的要求等等，但是我个人的观点是很有必要根据当前的组织架构与分布重构一些已经不再适用的流程。 　　2、某些未纳入管理信息系统的流程的执行力不足，缺乏对流程本身的监管机制。 　　3、某些流程全盘照搬公司的海外的版本，在国内明显水土不服，不仅没有起到期望的规范作用，反而引入了很多负面的东西。 　　4、流程的执行高度程序化，一线的工程师对已实施的流程提出改进建议到具体实施的时间周期很长，很大程度降低了流程干系人对流程改进的积极性。 　　51Testing：依据您的经历，您认为测试流程改进遇到的最大阻力是什么？您是如何克服的？ 　　茹炳晟：其实在测试流程改进过程中会遇到的方方面面的阻碍相当多，但我个人认为归根到底的阻力还是来自人。人基于惯性思维往往都会不自觉地抵触变革。可能那些在企业中积极地推进过流程改进的人都可能遇到过下面的情形：公司大张旗鼓地进行流程改进，但最终的结果只是管理人员费尽心力的进行了一番流程的梳理，然后被束之高阁，根本没有机会顺利推行，即使使用了行政手段强制推行，最后也会发现没有带来任何实际效果。所以我始终坚持不要为了流程改进而去改进，而是要从现行流程的实际情况出发，识别出现行流程执行过程中的不足之处以及大家在流程执行中的痛苦点，抱着解决现有问题的态度，有针对性地改进现有流程，并做好新流程的积极宣传和推广，才能使流程的使用者，也就是人从主观上接受这些变更带来更大便利和价值，这样流程的改进才可能真正发挥作用。忽略问题的本质，忽略人，忽略他们可能带来的阻力，流程改进注定会以失败告终。当然在流程改进的过程中，我们也要避免唯流程论的思想，避免过程至上，奉流程为教条的极端思想，理想的状态应该是以流程为指导，重视流程，但不拘于流程，让流程服从于软件质量、效率以及业务目标。另外还多说一点，我看到过一些企业在流程改进过程中，将新流程的执行与个人的年度考评等挂钩，采用关乎个人切身利益的行政手段强行推广新流程，固然流程的执行力提高了，但我认为这是很危险的做法。 原文链接：http://www.51testing.com/?uid-604302-action-viewspace-itemid-832731