qileilove

　　软件自动化测试

　　自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

　　前提条件

　　实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：

　　1）软件需求变动不频繁

　 　测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护 本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失 败的。

　　项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。

　　2）项目周期足够长

　　自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。

　　3）自动化测试脚本可重复使用

　　如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。

　　另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。

　　适用场合

　　通常适合于软件测试自动化的场合：

　　（1）回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；

　　（2）此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；

　　（3）采用自动化测试工具有利于测试报告文档的生成和版本的连贯性；

　　（4）自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖；

　　随着测试流程的不断规范以及软件测试技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本期所要讨论的话题。

　　目前，软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化（如单元测试、功能测试以 及性能测试方面）。在这两个领域，与手工测试相比，测试自动化的优势是明显的。首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模块的建立 和开发，从而提高测试覆盖率；其次，自动化测试更便于测试资产的数字化管理，使得测试资产在整个测试生命周期内可以得到复用，这个特点在功能测试和回归测 试中尤其具有意义；此外，测试流程自动化管理可以使机构的测试活动开展更加过程化，这很符合CMMI过程改进的思想。根据OppenheimerFunds的调查，在2001年前后的3年中，全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500%。

　　方案选型六大原则

　 　然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢？也不尽然，任何一种产品化的测试自动化工具，都可能存在与某具体项目不甚贴 切的地方。再加上，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台；或同一应用的不同版本之 间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。

　　以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则，这些原则是从笔者实际工作中凝练而成的，它包括以下六个方面的建议：

　　●选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本；

　　●测试流程管理自动化通常应该优先考虑，以满足为企业测试团队提供流程管理支持的需求；

　　●在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑；

　　●在考虑产品性价比的同时，应充分关注产品的支持服务和售后服务的完善性；

　　●尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持；

　　●应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。

　　过程

　　自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分 析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测 试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。

　　1）自动化测试需求分析。

　　当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。

　　2）自动化测试框架的搭建。

　　所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。

　　而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：

　　（a）公用的对象。

　　不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。

　　（b）公用的环境。

　　各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。

　　（c）公用的方法。

　　当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。

　　（d）测试数据。

　　也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。

　　在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。

　　探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。

　　对探索性测试最直白的定义是：同时设计测试和执行测试。探索性测试有时候会与即兴测试（ad hoc testing）混淆。即兴测试通常是指临时准备的、即兴的Bug搜索测试过程。从定义可以看出，谁都可以做即兴测试。由Cem Kaner提出的探索性测试，相比即兴测试是一种精致的、有思想的过程。

　　在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。

　　探索性测试

　　探索性测试强调测试设计和测试执行的同时性，这是相对于传统软件测试过程中严格的“先设计，后执行”来说的。测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多的关于测试的主意。

　　探索性测试的基本过程

　　探索性测试识别软件系统的目的；

　　识别软件系统提供的功能；

　　识别软件系统潜在的不稳定的区域；

　　在探索软件系统的过程中记录关于软件的信息和问题；

　　探索式软件测试一共分为自由式探索式测试、基于场景的探索式测试、基于策略的探索式测试和基于反馈的探索式测试。下面将详细介绍4种类型的应用场景。

　　一：自由式探索式测试

　　自由式探索式测试指的是对一个应用程序的所有功能，以任意次序、使用任何如数进行随机探测，而不考虑哪些功能是否必须包括在内。自由式测试没有 任何规则和模式、只是不停的去做。很不幸，很多人认为所有的探索式测试都是自由式的，从长远的观点来看，这种看法低估了探索式测试技术的能力，我们在随后 将看到这类测试的一些变种。

　　一个自由测试用例可能会被选中成为一个快速的冒烟测试，用它来检查是否会找到重大的崩溃或者严重的软件缺陷，或是在采用先进的技术之前通过它来 熟悉一个应用程序。显然，自由式探索式测试无需也不应该进行大量的准备规则。事实上，它更像是“探索”而不是“测试”，所以我们应当相应的调整对它的期望 值。

　　自由式测试不需要多少经验或者信息。但是，同以下提到的探索式技术相结合后，它将成为一个非常强大的测试工具。

　　二：基于场景的探索式测试

　　基于场景的探索式测试和传统的基于场景的测试有类似之处。两者都涉及到一个开商店，就是用户故事或者是文档化得端到端场景的开始之处，那也是我 们所期望的最终用户开始执行应用程序的地方。这些场景可以来自用户研究、应用程序、以前版本的数据等，并作为脚本用于测试软件。探索式测试对传统场景测试 的补充吧脚本的应用范围扩大到了更改、调查和改变用户执行路径的范畴。

　　使用场景作为指导的探索式测试人员经常会修改他感兴趣的输入或者是追寻一些并没有包括在脚本中的潜在副作用。不过，由于最终的不表是完成给出的场景，这些测试上的弯路、最终总是会回到脚本文件记载的用户主要执行路径。

　　三：基于策略的探索式测试

　　将自由式测试探索式与具有测试老手的经验、技能和感知融合在一起，就成为基于策略的探索式测试。它属于自由式的探索，只是他是在现有的错误搜索 技术下引导完成的。基于策略的探索式测试应用所有的已知技术（如边界值分析或组合测试）和未知的本能（如异常处理往往容易出现软件缺陷），来指导测试人员 进行测试。

　　这些已知的策略是基于策略的探索式测试成功的关键，存储的测试知识越丰富，测试就会更有效率。这些策略缘于积累下来的知识，它们指导软件缺陷隐藏在哪里，如何综合人工输入数据，那些代码路径常常出现故障。

　　基于策略的探索式测试结合了测试老手的经验和探索型测试人员的随机性。

　　四：基于反馈的探索式测试

　　基于反馈的探索式测试缘于自由式测试，但是随着测试历史的形成，测试人员们就会利用反馈来指导今后的探索。“覆盖”就是典型的例子。一名测试人 员通过咨询那些覆盖指标（代码覆盖、用户界面覆盖、特性覆盖、输入覆盖或者其中的某一些组合）来选中新的测试用例，以使这些覆盖指标得以提高。覆盖指标只 是收录反馈信息的标志之一。我们也会看其他标志，如代码改动数量和软件缺陷密集程度等。

　　基于反馈的探索式测试时一种“上一次测试”：在上一次我根据应用程序的最后状态选了每某一个输入之后、下一次我就会选中另外一个输入。或者是，在上一次遇到这个界面时我用A属性，这一次我就会用B属性。

　　基于反馈的探索式测试工具是非常有价值的，它可以是测试人员保存、搜索测试历史并据此采取实时行动。不幸的是这样的工具很少。

　　自动化测试（AT）与探索性测试（ET）

　　自动化测试在目前得到了越来越普遍的应用，自动化测试的优势也越来越明显。对于需求比较固定的功能，使用自动化测试工具通过编写自动化测试代 码。可以在以后得到多次的使用。这给回归测试带来了极大的方便性。也为持续集成（CI）的提供了很好的基础。看来自动化测试是软件测试领域中一项重大的革 命。

　　然而，自动化测试毕竟考虑时间有限，并且受到了一定的测试思想的制约，不可能在一次的测试设计中就能够就能够设计得很全面。另外自动测试对于测 试正常流程往往考虑的比较周全，而对于异常流程往往考虑得不是十分的充分。而对于一个有经验的测试工程师来说，bug往往在处理异常流程的时候被经常发 现，另外好些缺陷往往在一些怪异的，不确定的操作后出现。所以有了自动化测试脚本作为支撑，探索性测试（ET）的作用不可忽略。保证一个产品好的质量，既 要依赖自动化测试工具，另外人工为主的探索性测试也不可以遗漏，这样软件的质量才可真正得到保障。

版权声明：本文出自 jerrygu625 的51Testing软件测试博客：http://www.51testing.com/?162585

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　这几天在网上查询了一些资料，了解到比较常见的版本控制分支策略有三种：不稳定主干策略、稳定主干策略、敏捷发布策略。

　　下面是对这几种策略的摘录：

　　不稳定主干策略

　　使用用主干作为新功能开发主线，分支用作发布。

　　被广泛的应用于开源项目。

　　比较适合诸如传统软件产品的开发模式，比如微软的office等。

　　bug修改需要在各个分支中合并。

　　新代码在主干上开发，因此如果主干不能达到稳定的标准，就不可以进行发布。

　　这种策略的好处是没有分支合并的工作量，因此比较简单。

　　稳定主干策略

　　使用主干作为稳定版的发布。

　　bug的修改和新功能的增加，全部在分支上进行。

　　不同的修改或新功能开发以分支隔离。

　　分支上的开发和测试完毕以后才合并到主干。

　　主干上的每一次发布都做一个标签而不是分支。

　　每次发布的内容调整起来比较容易。

　　缺点是分支合并所增加的成本。

　　敏捷发布策略

　　敏捷开发模式的项目中广泛采用，敏捷开发的项目具有固定的发布周期。

　　为每个task建立分支。

　　为每个发布建立分支，每个周期内的task分支需要合并到发布分支发布。

　　在完成发布后，发布分支的功能合并到主干和尚在进行的任务分支中。

　　一种稳定主干策略的变体。

　　团队成员要求较高。

　　团队当前情况

　　负责互联网产品的开发，发布更新较为频繁。

　　有固定的发布周期，同时也存在比较多的hotfix。

　　修改任务通常比较小，改动范围通常不大，时间通常较短。

　　不同的功能页面有不同的小组负责，耦合度相对较低。

　　团队目前没有采用分支策略，开发人员协商进行增量更新，出现错误的几率较高。

　　已使用微软TFS做为版本控制工具，可以更充分的挖掘使用TFS的分支功能。

　　我的初步实践

　　参考上述策略，结合当前团队的现状，我初步设计了下面的版本控制解决方案。

　　此方案已稳定主干策略为主结合了一些敏捷发布策略的思路，具体实施方案如下：

　　1、主干时刻处于稳定状态，随时可以发布。设专门人员对主干代码进行管理，普通开发人员只读。

　　2、为开发任务建立开发分支。常规的可以以小组为单位建立分支，较大的任务可以建立专门的分支。

　　3、在发布日，从主干复制一个测试分支，需要在本发布日发布的各开发分支向此测试分支合并。

　　4、对测试分支代码进行测试，出现bug在测试分支上更改，无误后发布。

　　5、测试分支代码发布后，合并入主干，并在主干上进行标记。

　　6、对紧急修复（Hotfix）的情况，可以从主干复制出测试分支，在测试分支上进行紧急修改，并在测试后发布，发布后同样将代码合并会主干，做标记。

　　7、 Hotfix仅限于可以很快解决的小问题，如果更改时间过长，则需采用常规方法完成。

　　8、如果在测试分支测试过程中需要hotfix工作，则在复制一个新的测试分支进行hotfix，测试后发布。然后同时合并入原测试分支和主干，并在主干上做标记。此过程未在上图中画出。

　　9、测试分支发布后，开发分支可以删除；测试分支合并入主干后，测试分支可以定期删除。

　　方案的优缺点

　　方案优点

　　1、解决了没有实施分支策略时，代码不能经常签入的问题。

　　2、主干代码始终处于稳定的状态随时可以发布，降低了风险。

　　3、可以基于一个完整的测试分支进行测试及发布，而不是以口口相传的方式增量更新。

　　方案缺点

　　1、建立分支、合并分支增加了工作量。考虑实际情况，以及版本控制工具的辅助，增加的工作量应该可以接受。

　　2、如果某些开发分支工期跨越多个发布周期，修改过于剧烈，合并分支时可能工作量较大。可以考虑分解任务，避免过大的任务出现。

　　3、在同一时间最好只有一个测试分支，因此建立测试分支的权限需要限制，除hotfix场景外应当避免。

　　一、简介

　　简介部分就不用过多描述了，无非项目的背景，进行此次性能测试的原因，以及性能测试覆盖的范围等等，几乎所有项目文档都在开端对项目进行简单的阐述。

　　二、性能测试需求

　　寻找的被测试对象和压力点

　　要测试的对象不是凭空想象出来，而是经过分析与系统数据收集得到。下取几个典型的压力点

　　登录：对于一般的系统来说，登录是用户操作系统的前提，如果用户根本就登录不了，那么其它功能将毫无用处。例如网游戏，开新服的时候，玩家挤破了脑袋只为登录。

　　查询：查询一般比较消耗系统和数据库资源。搜索引擎的查询功能就是典型，如果你在输入框内输入内容，很久就得不到结果。我想被称为“互联网入口”的搜索引擎就不会存在。

　　交易：对于一些电子商务系统来说，交易过程的性能要求是很高的，如果交易过程消耗用户很长时间的话。我宁愿去超市买东西了。当然，除了交易速度外，对交易的成功率要求也是非常高的。不然，造成的损失也是不可估量的。

　　被测的系统应该是最重要的最基本的功能，也是用户使用最频繁的功能。

　　一般的性能要求包括：

　　系统容量：系统最大容纳多少个用户注册。

　　访问数：同时访问系统的用户数。

　　并发数：一个操作同时执行的并发数目，一个系统中应该有不同操作的并发数的组合（一般是有权限进行操作的用户）。

　　系统的最大用户数与最佳用户数：系统在承受的最大并发用户数量，系统在最佳状态下承受的并发用户数据。

　　响应时间：用户提交一个操作到得到响应的时间间隔。

　　吞吐率：系统每秒钟处理的TPS

　　性能测试关键的一个因素就是压力，性能是在系统设计满足的最大压力下的性能。并发数要不小于系统正常运行的峰值，数据总量不小于系统正常运行3个月的数据量。

　 　在描述并发用户数目时，总是会带有相应的时间段限制。系统的性能指标实质上应当使用单位时间内系统处理请求的个数以及请求响应时间描述。单位时间内能处 理的请求个数就是系统的业务吞吐量。虚拟并发用户的数量可以使用如下的公式换算：（真实用户数×每个真实用户请求数）/（总请求响应时间+真实用户总思考 时间）=（虚拟用户数×每用户请求个数）/（总请求响应时间+虚拟用户总思考时间）=吞吐量。

　　三、测试环境

　　这里的测试环境主要指的软件硬件环境和网络环境。

　　笔者认为性能测试最好在一个独立的环境内进行，这样不会受到外界的干扰，能够保证测试的数据是独立有效的。如果现你对某个已经上线的网站进行压力测试，那么你得到的数据不是独立的，因为你在做压力测试的时候，其它散户也在访问系统。

　　软件环境：

　　这里的软件环境主要指项目运行的环境，比如采用什么样的操作系统、中间件、和数据库。

　　硬件环境：

　　这里的硬件环境除了主要包括主机内部部件，cpu、内存、磁盘以及主板、网卡等，传输介质和路由器也应该考虑在内，

　　网络环境：

　　网络环境除了考虑测试机与被系统服务器在一个局域网中进行，还应该保证这个网络的独立性。如果在在性能测试的过程中，其它机子也在消耗着路由器资源。那么路由器也会影响到数据库的传输速度。

　　在很多时候，我们是要准备测试数据的，例如系统不允许相同用户的重复登录，那么必须要生成合法的用户数据。有时要对系统进行查询测试，只有在系 统有一定数据量进才能验证出系统的真实性能。一个数据库中有两条数据和有两千万条数据，同相一条查询操作，对系统造成的压力是完全不一样的。

　　系统所需数据的分析可以参考以下方式：

　　历史数据分析有助于数据量级的确定。从历史数据入手，找出高峰期数据量。

　　从其他相似或者相同系统入手，进行数据分析，找出高峰期数据量。

　　无历史或者相关系统可以参考的时候，就要对系统的性能数据进行估算，包含系统容量，并发数等数据，估算以后给相关人员进行评审或者修订以后，按照大家同意的性能指标进行测试。

　　…………

　　测试数据最好和真实数据相同，如果能够获得真实系统运行3个月的数据，我们就可以在此基础上进行性能测试。

　　关于数据的生成，我们可以祝一个工具完成，如数据库数据生成工具，大小文件生成工具等。

　　五、测试工具

　　前面已经介绍如何分析需求，需求确定下来之后，我们可以考虑引入什么样的工具适合性能需求。

　　当然，在引入工具的时候除了考虑可以是否满足需求，还应该考虑工具的成本，这不单指工具的购买成本，还有测试人员对工具的学习成本。

　　关于测试工具的选择，后面会单独有一章节介绍，这里就不细说了。

　　如果你选择的性能测试工具不是足够的强大的话，你可能还需要其它的辅助的工具。如果jmeter利用badboy来录制脚本，更能提高脚本开发 效率。在压力测试的过程中也可能需要性能计数器来记录软硬件的性能。如监控服务器cpu、内存的计数器，记录中间件日志的监控中工具，监控数据库性能的监 控工具等。

　　六、测试策略

　　对于一个特定的业务系统，用户一般会分散在一天的各个时间段进行访问。在不同的时间段中，用户使用业务系统的频率不同，而系统的繁忙程度不同。 在一些特定的条件下，可能出现短时间内用户集中访问某个业务系统的情况。例如对于公文处理子系统而言，可能就存在短时间内大量用户查看并办理某条公文的情 况。 在进行性能测试时，应当使用“考虑最坏情况的原则”。也就是应当在用户使用业务系统最频繁、对系统造成最大压力的情况下对系统的功能进行测试，判断各功能 和页面是否能够满足性能的要求，系统的响应时间是否过长。

　　另一方面，系统性能的验证必须做到“覆盖全面”。虽然系统中各个功能的使用频率并不相同，一些功能的使用频率相对于其他功能来说比较低，但是在 进行性能测试和优化时，不能忽略这些功能，编制测试用例时也不能仅仅选择最常用功能。例如可能所有的用户都会访问我的通知列表，但是一般只有5%的用户会 使用通过系统设置模块查找某个用户的信息；但是在测试时，我们并不能因为查看用户信息功能的使用频率相对较少，而忽略掉这项功能的测试。所以，这里进行系 统性能测试时，对于不同业务，用户的访问比例应该做一个合理分配。

　　在测试策略上，我们还应该考虑，同一个系统在不同硬件环境下的性能表现。从而让系统满足需求的情况下，硬件配置也能达到一个最佳的状态。过份的增加硬件来满足需求也是一种浪费。再说增加硬件设备不是能解决所有性能问题的。

　　七、人力与时间安排

　　最后一条，就是要根据项目的进度要求以及规模，来进行人力与时间的安排。对于大型的性能测试，项目前期的需求调研，环境的部署，工具的选购或开 发，人员对测试工具的学习与使用，性能测试的后进行，后期数据的分析与调优。都需要人员安排的。有可以需要专业的，系统工程师、数据库工程师、软件开发工 程师、网络工程师以及性能测试工程师的共同参与配合完成。不是一个性能测试人员就可以全部搞定的。

　　笔者听说，最牛x的性能测试，需要几个国家的十几个城市的性能测试团队同步时行。前期的准备工作就需要几个月的时间。如何把控性能测试的同步进 行。后期测试数据的汇总与分析。是一个非常复杂的过程。这个例子有待考证，我想说明的是，对于大项目的性能测试，人员与时间安排也至关重要。

　　----------------------

　　根据项目的不同，我们在做性能测试计划椒考虑的问题不仅仅上面这些内容，这一节所罗列的内容是基本需要考虑的因素。

相关链接：

性能测试知多少----性能测试分类之我见

性能测试知多少---并发用户

性能测试知多少---吞吐量

性能测试知多少---响应时间

性能测试知多少---了解前端性能

性能测试知多少---性能测试工具原理与架构

性能测试知多少---性能测试流程

性能测试知多少---性能需求分析

　　探索式测试的奠基人和积极实践者Cem Kaner和James Bach都支持语境驱动测试。语境驱动测试的7条基本原则对于正确理解并应用探索式测试具有重要意义。

　　原则1：任何实践的价值都取决于其语境（Context）。

　 　这条原则几乎是不言自明的。中国人很早之前就有相似的认识，“南橘北枳”[ 语出《晏子春秋》，其成书于战国，后经西汉刘向整理。]指相同的种子在不同的环境中会结出不同的果实。因此古人建议“因地制宜”[ 语出《吴越春秋》，成书于东汉。]，即根据当地的具体情况，采用合适的措施。

　　然而，软件开发者 往往会在无意中忘记这条原则。开发团队会照搬以往的经验，却不考虑经验可能已经过时；会不假思索地采用他人建议的开发方法，却不怀疑南橘北枳的可能；会按 照高层的指示亦步亦趋，却不思索指令是否合理。更糟糕的是，在感觉到情况不妙后，却将错就错，不思变更。因此，开发团队需要频繁地反思其开发实践是否符合 当前的语境，并做出相应调整。

　　原则2：在特定语境下存在好的实践，但不存在最佳实践。

　 　这条原则看似有些武断，毕竟软件研发已经沉淀出一批公认的实践方法，它们是现代软件开发必不可少的核心实践。但是，细细一想便会发现这些方法也需要因地 制宜。“持续集成”是公认的最佳实践，但是不同的团队往往有不同的集成频率。对于小型项目，一次签入（Check-in）会触发一次完整的构建；对于大型 项目，开发团队可能每天做一次完整构建；对于超大型项目，做一次完整的构建可能需要几天甚至更长的时间。不同的构建频率和构建代价自然会导致不同的签入策 略和测试方法。虽然都在实施“持续集成”，但是不同的团队会设计出不同的流程和方法。

　　对于测试工作者，这条原则表示任何一种测试方法（包括探索式测试）都不是无条件的最佳选择。测试人员始终要评估当前情况，寻找适合当前语境的测试风格和技术。

　　原则3：人，在一起工作的人，是项目语境中最重要的部分。

　 　这条原则强调了软件开发的社会学因素。软件开发专家Tom DeMarco和Tim Lister指出：“本质上，我们工作中的主要问题，与其说是技术问题，不如说是社会学问题”。而社会学因素的根源是“软件开发是一个创造与沟通的协作游 戏（Game[ Game也可以翻译为“博弈”。本书将其翻译为“游戏”是为了突出软件开发的乐趣、协作、沟通与互助。软件开发团队的对手不是团队成员，而是亟待解决的问 题。]）”。在创造与沟通的过程中，一定是个体和他们的交互（Individuals and Interactions）起主要作用。

　　在软件测试中，以下观点反映了人的重要性。

　　● 软件开发是具有挑战性的智力活动，开发人员（包括测试人员）的责任感、技能、状态将强烈影响软件实现和代码质量。因此，招聘、培训、挽留高水平开发人员是软件企业最重要的工作之一。

　　● 软件开发是一种创造与沟通的游戏。软件企业应该营造一种开放、协作的工作环境，使得开发人员能够自如地去思考、去发明、去创造。

　　● 软件测试的核心任务是寻找并传递信息。在寻找信息的过程中，测试人员的能力和相互协作的水平将在很大程度上决定信息的数量和质量。

　　● 软件测试提供信息服务。服务就意味着有客户，测试人员是否成功，主要取决于是否很好地满足了客户的要求和最佳利益[Kaner01]。也就是说，测试人员的重要任务是理解客户，并与他们展开有效的交流。

　　原则4：项目的发展往往难以预料。

　 　在一些语境中，项目的发展是可以预料的。图1.1摘自Steve McConnell所著的《软件估算》，它显示了（对项目范围、代价、功能的）估算值是如何随着项目的进展变得准确的[McConnell06]。随着时 间的推移，项目的不确定性逐渐降低，当项目即将结束时，开发团队能够准确预期项目的结局。但是，图1也提示了在项目的开始阶段，项目的不确定性非常高。在 初始概念（Initial Concept）阶段建立的估算值可能是实际值的4倍。

　　该原则并不是一个悲观的见解，相反它体现了一种实事 求是的态度和对软件风险的成熟认知。探索式测试有助于快速获得信息，从而降低软件项目的不确定性。成功的测试团队在整个项目过程中会结合广度优先探索和深 度优先探索，在特定的时间选择适合的方法，从而更明智地利用测试资源。

图1 根据日历时间得到的不确定性锥（Cone of Uncertainty）

　　原则5：产品是一种解决方案。如果问题没有被解决，它就是无用的（Doesn’t Work）。

　　成功的软件必须帮助用户解决现实世界中的问题，辅助他们获得成功。在极端情况下，一个符合规格说明且没有技术缺陷的软件会遭遇失败，因为它没有 解决用户的问题，甚至阻碍用户解决问题。图1.1显示，在需求完成（Requirements Complete）时，不确定的范围会大幅缩小。但是，如果需求存在重大缺陷，甚至初始概念就是错误的，那么稳定的开发过程只会“稳定地”产生失败的产 品。

　　这一原则要求测试工作者用软件用户的视角考察整个产品，从显式规格说明（不完整、模糊、包含错误的项目文档）和隐式规格说明（包括竞争对手产 品、相关产品、已发布版本、电子邮件讨论、口头讨论、论坛反馈、博客文章、领域专著、测试经验等）中，挖掘、推导、发现需求。这是探索式测试人员需要掌握 的探索技能。

　　原则6：好的软件测试是一个具有挑战性的智力过程。

　　这又是一条不言自明的原则，相信本书的读者也会认同该原则。虽然您可能会质疑本书的一些观点，但是您的阅读已经说明软件测试的挑战性和复杂性需要认真研究与思考。

　　这条原则的推论是枯燥、机械、无成就感的测试过程不是好的软件测试。这样的过程压抑了测试人员的创造性，分散了他们的注意力，降低了他们的智力 水平。然而，本书的作者们也必须承认，我们在日常工作中也时常会感到枯燥、单调、缺乏创造力。对此，笔者的基本观点是：第一，测试人员应该以合乎要求的质 量完成自己的工作，这是测试人员必须履行的职责；第二，应该将单调的工作视为改进的信号，通过改变工作内容和流程，将更多的时间用于具有挑战性的工作。探 索式测试、技术创新和测试自动化是笔者的常用工具。

　　原则7：只有通过判断和技能，并在整个项目过程中协同练习（Exercise Cooperatively）它们，我们才能在正确的时间做正确的事，以有效地测试我们的产品。

　　软件测试领域的一些文献似乎在暗示，只要严格遵循“优秀”的测试过程或模板，就可以使普通的测试人员成为测试专家，并获得理想的测试结果。这种观点是不正确的，因为只有高素质的测试人员才能根据语境设计出合适的流程、计划、策略和用例，而这些才是有效测试的基础。

　　那么该如何培养高素质的测试人员呢？Cem Kaner指出：“测试过程的一个重要成果，是更好、更聪明的测试人员。”[Kaner01]优秀的测试人员具备高超的技能，而这种技能只能通过持续的学 习和实践才能获得。而且在一个合作与分享的环境中，测试人员可以学得更快、练得更好。

版权声明：本文出自 liangshi 的51Testing软件测试博客：http://www.51testing.com/?298785

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　测试人数的激增，除了各公司都开始重视测试和测试对象的种类扩大的原因外，其实最大的一个原因是测试的入门门槛不高，这对我们的从业人员是件好事情，只要懂点计算机，只要会使手机，其实就可以做黑盒测试，因为测试本身靠的是灵感和想法，其他的背景知识现学都可以。但是一旦进入这个行当，就会发现，慢慢的很多所谓的测试本身根本不需要动那么多脑子，只要手指头动就好了，只要会点鼠标就好了，因此就成为了重复的工作，测试人员也就成了廉价的测试机器。其实这对公司来讲，对于自动化测试还有待发展的现状，这也是没办法的办法。但是对于测试人员的发展之路来说，这并不是一个很好的信号。重复的动作，重复的测试行为，到底能带给测试者什么？ 是所谓的经验吗？这需要大家的反思，为自己的职业发展之路反思...

　　首先提高自己的测试理论基础。可以围绕自己所做的测试，有哪些相关的测试理论可以支持。所有的测试基础概念其实都是通用的：静态测试，动态测试，测试用例， 等等...以及一些测试相关技术：等价类划分，边界值，相信这些方法所有的人每天都在用，但是未必所有的人都能说明白。所以为自己每天所做的测试行动找点 理论基础，即有效率有与实践相结合，慢慢就会发现，其实平时所做的事情都可以找到测试理论来支持，这样拥有扎实的理论就有可以实现了.....这也是职业 发展的重要一步。

　　其次要对测试的整体流程有完整的概念。这个是目前很多初级测试人员所欠缺的。目前大多数人只知道自己测试的是什么东 西，但是不知道自己执行的测试处于什么阶段，下一个阶段是什么，也许整个项目做完不知道；这个问题的主要责任在于公司，很多小规模的公司由于受规模和成本 的限制，并不愿意在测试流程管理上花费时间，（当然也有可能是因为管理层没有这样的意识），认为公司规模不大，用不着那么多条条框框，让测试人员按需求说 明书测完了就OK了，而软件测试人 员也就不要知道什么是测试计划，什么测试策略，分哪几阶段的测试，反正测试完就好。但是实际上，在中大规模的公司，这些测试的流程管理是很严谨的，也就需 要员工有端到端的测试意识和对测试流程的概念的认可，所以很多测试人员在往大公司跳时往往因为这个原因而被拒--没有测试整体流程管理的概念。

　　因此，一定要避免迷失在日常重复的测试中，培养自己的测试整体流程的概念。主要的措施可以有：

　　1）看一些测试管理方面的书籍。

　　2）自己将自己参与的项目进行划分阶段“对号入座”。

　　3）在编写测试文档时要严格要求自己。

　　4）在测试结束时，及时对整个测试过程进行总结。

　 　第三，在进行测试工作中要弄明白为什么要这么做，为什么要执行这样的案例，为什么要执行相关的测试工作...。多问几个为什么。有一个问题要先讲清楚， 就是有很多人还没有注意到这个问题，领导让怎么做就怎么做，也许真的做的很熟练了，但是一年后去问他为什么要这么做，相信他也说不出太多，反倒觉得就应该 这么测。这样带来直接的弊端就是对自己的职业之路不负责任，所以目前已经意识到这问题的同行们已经占得先机。只有弄明白自己作的每件事，才能知道自己未来 要干什么....

　　那从哪些方面才能问寻找为什么呢？

　　1、从行业角度。看自己所从事的是哪个行业的测试，电信的测试、 网页的测试 、手机的测试，应用的测试等等，因为每个行业的测试的规律，规范，经验，特点都不同，从这个角度可以寻找到自己为什么要这么做测试的答案，因为这些也直接 决定你每天所做的活动。比如手机测试，那么要求更多的是黑盒测试，包括各个功能的组合输入，那每日执行的测试案例里就更多和这些相关，所以当你质疑自己要 每天这么测试时：你从手机行业和手机的特点入手就知道自己为什么每天要重复的测来测去

　　2、从测试用例的角度。弄清楚用例的到底是测试什么，测功能？ 测试性能？测界面？在用例里用了哪些方法，这样就可以把不同类型的测试和不同的测试方法积累并对应上。 另外就是看测试的功能点是不是来自于需要点，这样可以锻炼如何从需求点里提炼测试需求。

　　3、从测试工具的角度。也就是总结一下为什么要用这个工具，这个工具与自己要测试的对象有什么关系。

　 　4、从测试文档的角度。每个人都会接触测试文档，少的会接触测试用例，多的还会接触测试计划等高层次的文档。从每个测试文档的功能出发，因为对于测试管 理流程来说，测试文档起的是非常重要的承载作用，作用不一致，而且都很重要，当你在写每个文档时，可以查查相关的资料，看这些测试文档的作用是什么，有哪 些职责的人要看这些文档，文档要注意什么，要写些什么，这样就明白自己工作的目的性和重要性了。

　　1、把工具的学习作为自己职业发展的重要策略之一。也许你的测试经验不多，但是也许就因为会熟练地使用一个测试工具，你也许就会得到一个 offer，现在测试工具的专家奇缺，所以这就是个机会，虽然说会使工具的人大有人在，但是真正可以使用的有深度的人还在少数，而往往从浅显的使用到深度 的使用并没有那么难，但是或许获得的职场机会多很多。

　　2、树立学习测试工具的信心。这是对于很多没有过开发经验或者其他的专业的测试者要说的话。有一些测试人员由于没有开发背景，对编程语言不熟 悉，所以对很多工具的使用没有信息，其实完全没有必要担心，开发背景和测试工具没有必然的联系，工具中涉及的编写脚本的过程很简单，语法简易，稍稍用心学 一下就没有问题，关键心理上要没有障碍。

　　3、挑选前景好的测试工具。目前性能（压力）测试工具、测试案例管理工具和问题管理工具最普遍，前景最好，相信大家对此应该没有异议。

　　4、如何快速学习测试工具。这点可以应付工作中突然出现的要求，也适用于对于测试工具的深度学习。

　　1）认清使用工具的目的，也就是这个工具到底能干嘛，认清这个就不会迷惑，对于工具的这种认识度最好一针见血。

　　2）结合实例学习。切忌直看使用说明。

　　3）从主要功能入手， 先放弃一些高端的功能

　　4）对于工具输出的报告要能够读懂，这是和实际的测试联系起来的重要一步。

　　本篇对测试职业发展之路的反思虽然要结束了，但是对测试职业发展之路的思考还将继续。在这几天和朋友的交流中发现，对测试职业发展之路的思考其 实在每个测试同行的心中，大家都有各种各样的迷惑，所以达人觉得仅仅在这篇文章里是无法全面的答疑解惑。所以达人准备启用专题的方式来进行讨论，达人希望 自己的文章能引起所有测试从业人员的思绪，引起测试行业的大讨论，虽然只有我的微薄之力，但是达人愿意全新全力为所有的测试同行们做点有意义的事情。

　　后续达人会讨论的测试职业发展话题会有：

　　1、如果公司的测试流程不规范，测试人员该怎么办？

　　2、从事测试行业2年，应该达到什么样的水平？

　　3、如何让自己在测试行业中尽快升值？

　　4、如何从测试人员走向测试管理人员？

　　5、在项目中，如何面对“嚣张”的开发人员？

　　......

　　把这些话题抛出来，也希望所有来达人部落的朋友们提出自己的看法和想法，达人会根据这些话题和大家的感受有针对性地提出自己的见解。

　　只有多思考，才能多进步。也许我们不知道我们来自哪里，但是我们一定要知道我们要去何方。

版权声明：本文出自 coolors 的51Testing软件测试博客：http://www.51testing.com/?130939

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　我曾经和来自不同开发机构的人探讨过关于他们如何管理软件开发，如何组织，他们遵循什么样的开发实践，以及什么样的开发实践真正有效。工作在小团队的大部分人都没有人手帮他们测试程序，因为测试人员们不是真正开发软件的人，所以通常觉得他们是多余的。这就意味着程序员许要自己测试他们的软件 – 或者用户来测试。

　　敏捷团队中的测试人员能做什么？

　　很少敏捷团队会觉得需要测试人员。测试人员被看作是瀑布时代的产物（需求、设计、编码、测试）。在XP团队，每个人都是程序员，每个程序员都要负责测试自己的代码，写自动的单元测试，使得用户需要的验收测试自动化。Scrum根本没有定义测试要做什么 – 团队会最终找到解决方案，因为他们会检阅自己并调整自己，以获得最佳的实践。

　　如果程序员已经测试了他们的代码（也通过结队的方式进行了代码审查），那么他们需要测试人员做什么呢？

　　Janet Gregory和 Lisa Crispin写了一本书来说明敏捷团队中测试人员的作用，它向程序员和测试人员说明测试人员是如何配合敏捷开发的，但这仍然没有改变大多数团队的看法，尤其在“工程驱动的文化”（程序员创立的创业团队）中更是如此。

　　他们的论点是敏捷团队的步伐相对于测试人员来说太快了，黑盒测试人员们仅仅通过写测试计划，通过手动的测试代码来测试，或许要不断的更新他们的质量中心或Selenium UI回归测试，这些都不可能追得上在短时间内就要发布新功能的团队的进度。如果测试人员不会用Fitness或Cucumber写验收测试，或者没有足够的业务知识帮助填补客户/产品拥有者的空当，不能回答程序员的问题的话，那么他们又有什么优势呢？

　　这个问题在持续开发中更为显著，一些公司如IMVU和Facebook，使得某种编程实践变得流行起来，他们查看自己的工作，写自动测试用例，查看代码看看测试是否通过了，更新都是很快的，然后自动发布到在线系统中去。

　　让用户来测试你的代码

　 　一些公司把持续开发看作是“众包”（crowdsource）他们测试的机会 – 让他们的客户来为他们测试。这实际上很有竞争力。然而也很难用这种方法写出可靠安全的软件 – 可能也是不可能的。针对持续发布给用户的系统的质量问题，James Bach有一篇批评的文章，是关于他们花了20分钟时间去测试一个持续部署的程序，就发现在很短的时间内就发现了问题。

　　有一些持续部署的公司更小心些，他们按照Etsy/Flickr的做法，在晚上上线：持续的发布更新，但是在用户量很大之前就进行了测试，他们还会密切关注结果。

　 　然而，很重要的一点是用户只能测试某些功能，事实上，也只有用户可以测试它们：一个功能是不是有用，一个功能是不是可用的，他们需要什么信息才能正确的 完成一个任务，工作流程应该如何优化。这才是对比测试所应该达到的效果 – 通过实验不同的想法，功能和工作流程，收集数据，然后找到用户最喜欢什么，以及他们不喜欢什么。去尝试不同的方法，并获得反馈。

　　你需要从测试团队中获得什么？

　　就算是最好的，最负责的，最有经验的程序员都会犯错。在我们公司，每个人经验都很丰富，其中有些人工作了10-15年以上了。他们很仔细的测试 代码，每次check-in之后都会更新自动测试用例。在持续集成过程中这些测试都会运行 – 我们非常依赖于这些测试（现在已经有成千上万的测试用例了，并有较高的覆盖率），静态分析的缺陷核查，以及安全核查工具来对付基本的代码错误。所有的更改 都会让另外一个高级的程序员来核查，从来没有过例外。

　　但就算有好的方法和工具，优秀的程序员还是会犯错：一些细微的问题（不一致，界面问题，数据转换和建立问题，没有编辑等问题）以及一些基础的问 题 （负载下的运行失败，同步问题，缺少需求，规则错误，异常处理中的错误）。我想确保在用户发现错误之前发现大部分（尽管不是全部）的错误。程序员也是。

　　这也就是测试团队起作用的地方了。我们拥有一个小的，但是经验丰富的，有特别专长的测试团队。一个测试人员专注于验收测试，验证功能需求，可用 性，以及业务工作流程。另一个测试人员专注于功能的回归测试以及业务规则的正确性和覆盖率，找到程序员测试用例中的规则漏洞，并在API层让集成测试自动 化。还有个测试人员主要做操作测试，压力测试，以及soak test来找到峰值和垃圾回收的问题，破坏测试 – 尽可能的破坏系统。当其中一个人不在的时候，他们也知道如何担负他人的职责，但他们有自己独特的专长和技能，以及自己的解决问题的方法。

　　当我们初次建立系统的时候，我们有一个更大的测试团队，主要通过写测试计划，详尽的手工测试核查表，在UI层编写自动的回归测试，来测试覆盖率和可靠性。但用这种方法浪费了许多时间。

　　现在我们更依赖于程序员针对功能覆盖率和回归保护自己编写的自动测试用例。我们的测试团队将精力更多的放在探索性的功能以及操作，基于风险和以 用户为中心的测试中去了，以找到最重要的缺陷，发掘系统的弱点。我们都喜欢这种方法，因为我们在测试中找到了真正的重要的缺陷，那些躲得过代码审查和单元 测试的缺陷。

　　当程序员作了更改后，测试人员马上测试更改。他们和程序员一起结队去测试新功能，和程序员一起运行模拟来找出运行错误，竞态条件（race condition）以及现实世界中的时间相关的问题和工作流程问题。他们摧毁系统以确保错误探测和错误恢复机制是成功的。他们测试安全功能，和顾问一起 搭建和管理测试。他们也和操作人员一起，和新用户以及新部门处理集成检查。他们和团队的其他人员一起以非常快的速度，每两周就发布到在线系统（有时更频 繁）。

　　测试团队也会负责软件的发布。他们将每个发布都集中在一起，查看依赖，决定发布什么时候进行，什么将会发布，什么不会发布，他们会核对我们是否完成了整个团队同意去做的更改，他们会测试过去的测试用例还有数据转换测试，最后和操作人员一起发布到在线系统中去。

　　他们没有让整个团队的进度慢下来，他们也没有阻碍我们发布软件。他们确保了软件上线的时候正常工作。

　　测试人员找到更多的缺陷

　　我为高可靠性，高集成性的业务工作了很久，没有测试人员是不可取的 – 犯错的代价太高了。我不认为你可以创建真正的软件，而不需要人来测试它。除非你是在创业的早期，还处于概念的迸发期，或者你只有一个小团队，仅仅为内部使 用而写的软件（可能你也没堵到这篇文章），否则你需要人来为你测试系统以确保系统是正常运行的。

　　不管你如何工作，不管你用什么方法 – 敏捷开发还是瀑布开发方法，都改变不了需要测试人员的事实。如果你推进得太快了，测试人员需要加快步伐，以适应能够获取信息的方式。好的测试人员可以做到的。

　　我就算再蠢也不会认为测试团队能找到所有的缺陷——虽然这是他们的工作。当然，我希望测试人员会在客户发现之前找到明显的错误。

　　我需要为他们做的也正好帮自己回答了一些重要的问题：我是否可以发布了？有什么还是粗糙的或者不稳定的或者不完善的？什么需要迟些发布？什么需 要更进一步审查或者重写？设计中什么地方很薄弱？什么地方没有自动测试用例？哪里需要更好的测试工具？什么功能难以理解或不一致或者很难搭建？什么消息漏 掉了，或者容易误导人的？我们是否做太多了，做太快了？我们是否需要更改设计，代码，还是设计或编码的方式，以使得系统更好用，更可靠？

　　测试不能提供所有的信息，但能提供一部分。好的测试可以提供许多有用的信息。——James Bach （Satisfice）

　　没有测试人员，你不仅发布了一些你本来应该没有错误的代码，你也失去了一些重要的信息，譬如你的软件真的那么好吗，例如你可以做什么让它更好。如果你想构建好的软件，那么现在你的机会来了。

　　1989年，我在田纳西大学读研究生的时候，完成了从软件开发人员到软件测试人员的转型。而这一转型并非出于我自己的选择。我命运的改变发生在一个早晨，我的教授质问我为什么缺席那么多开发会议。我解释说因为会议被安排在星期六早上，很不方便。

　　而怍为一个生平第一次离开家的新入校的研究生，这个时间段有些麻烦。十分有意思的是，等待我的惩罚并不是一纸解聘通知书，而是被判罚为该小组的唯一一个测试人员，且不能与开发团队有任何交流。

　 　对于我的职业生涯来说，这是一个意义多么重大的决定啊！正是这个决定最终成就了几十篇关于测试的论文，构建了多得连我自己也记不清的各种工具，出版了五 本书，带来了无尽的快乐工作时间。测试一直就是我拥有的那份具有创造性和技术挑战性的快乐职业。不过，并不是所有人都喜欢这样。可以说我最早接触测试是在 攻读研究生期问，不可否认，那时的高强度学习和 工作确实让我受益匪浅。另外，我认为从初学者阶段到专家阶段之间存在着一个“测试的山峰”，人们需要通过一系列个人辅导、获取信息和接受常规指导来翻越山 峰。成为一个测试初学者是很容易的，成为职业的测试人员也并不艰难。本章的重点正是讨论如何翻越那座位于职业测试人员和测试专家之间的山峰。

　　回到未来

　 　在软件测试领域，时间似乎已经停滞了。我们在21世纪做事的方法与上个世纪几乎完全相同。Bill Hetzel在1972年出版的测试知识丛书至今仍然相当有价值。而我自己所写，于2002年首次出版的How to Break Software（如何攻破软件）系列，到今天仍被作为实用软件测试技术主要资源的代名词。

　　确实，如果我们可以把20世纪70年代的测试人员转换时空用在今日，我猜想他们的的技巧足够应付现代软件的测试。当然，他们需要学习网络和各种网络协议，但是他们拥有的实际测试技术将能得到很好的应用。如果从20世纪90年代找一个测试人员，则不几乎不需要任何训练。

　 　对于开发人员来说，却不是这样，他们所掌握的那些上世纪的技巧几乎已经完全过    时。让一个有一段时间不写代码的人重新开始编程，看看会有什么样的反应。让我感到很不安的是，我们可以从马路上直接雇用人手，而雇来的这些人从第一天起就 能够测试，就能够有收获。事情真的有那么简单吗？或者是我们的期望值只有那么低？让我更加不安的是，我们没有任何可预测的方式将合适的测试人才从胜任工作 状态训练为测试专。测试真的就那么困难吗？

　　这又是那个山峰了。门槛很低，但通往精通的道路却很艰难。

　　在通往测试山峰 的入口，我们倚仗的是这样一个事实：测试的很多方面都很容易掌握。大多数人都可以学得有模有样。甚至只要将一点点常识应用于输入的选择，就可以，我出缺 陷。这个层次的测试就如同在桶里钓鱼，简单到足以让任何人都认为自，自己很聪明。然而过了入口以后，道路迅速陡峭起来，而测试知识变得越来越晦涩难懂。我 们发现有人擅长于此，我们称这些人为“有天赋的人”，并欣赏他们的本能。

　　难道一定要依靠本能么？对于那些看起来不具备特长的人们，是否 存在着一条翻越山峰的途径？是否可以以某种方法传授测试技能以培养出更多的专家呢？为认为这座山峰是可以通行的，而这一章正是我关于应该如何走这条路的笔 记，你可以在自己的职业生涯中加以应用。这并不是一份食谱配方，一份职业生涯烹调书。不过你可以做一些事情来加速你的职业成长。但是，正如你可能已经猜到 的，真正是说来容易，做起来难。

　　上山

　　测试职业的早期阶段主要是为征服测试山峰的 漫长攀登做准备。我所能给出的最好的建议是从两个方面来思考问题。对于你参与的每一个项目，都有两部分（不一定相等）的任务。第一部分的任务是保证当前的 测试项目获得成功。而第二部分的任务是学习你应该做些什么以便使下一个测试项目更加容易。我把它称为“测试今天的项目，准备明天的项目”。如果你做每一个 项目把它都分割成为上述的两半，那么几乎可以保证你能持续获得进步。这样，你就可以随着每一个参与的项目逐渐成长为更优秀的测试人员。

　　现在就让我们来关注第二部分的任务------为下一个项目做准备。我们需要注意三个概念：重复、技术和漏洞。

　　重复

　 　做任何一件事，绝不要重复两次而不意识到或质疑这其实是个问题。我希望所有年轻的测试人员都牢记这一点。我见过很多初学者，他们在单调的任务上浪费了太 多的时间，比如，设置测试机器，配置测试环境，在实验室里安装待测试的应用程序，选择一个产品版本来测试-这些任务列表可以变得很长，最后你会发现真正花 在测试软件上的时间少得可怜。

　　这是许多新手常犯的错误。他们没能看到他们日复一日所做的工作的重复本质，儿当他们意识到这种重复时，几 个小时已经过去了，而在这几个小时内他们没有做任何实际的测试工作。关注这些重复劳动，并且留意由此造成的真正的软件测试工作时间的流逝。为了能翻过测试 的山峰，必须做一个测试人员应该做的工作，而不是实验室管理员或者测试机管理员的工作。

　　测试自动化是解决重复劳动的方案，也是本章稍后的主题。

　　技术

　　测试人员常常会对软件失效进行分析。分析缺陷时，我们从开发人员的失败中学习如何编写可靠的代码。我们也分析那些被我们忽略的缺陷。在应用程序 上市以后，客户就会开始报告缺陷，我们将要面对处理一大堆失效的情形并寻找其中的重要缺陷。用户报告的每一个缺陷都说明我们的流程用问题，我们的测试知识 还不够完善。

　　但是分析我们的成功也同样重要，儿许多新入职的测试人员却没能利用这个唾手可得的资源。我们在测试中找到的每一个缺陷都说明我们的的测试流程正在有效工作，都是一次成功。我们需要紧紧抓住这种绝好的机会，只有这样才能使成功不断的重复下去。

　　运动队常常这样做，他们会观看比赛录像，并分析每一个动作为什么奏效或者为什么不奏效。我清楚地记得一个小故事，我的一个朋友拍下了我儿子踢足 球的一些照片。其中一张照片记录了她踢球的瞬间，那个球超过对方守门员成功进球了。当我把它给我儿子看时，我之处他站立的那条腿的姿势非常完美，他踢球的 脚尖紧绷且出球点在鞋带间恰到好处的位置上。他盯着那张照片很长时间，从那以后他很少用不正确的姿势踢球。他那次得分可能只是碰巧做对了，但从此以后他有 意识的运用这些技术使之接近完美。

　　现在回到新手测试人员的课程上来。我们每一个人都会有得意的时刻。我们找到重要的漏洞或发现优先级很高的缺陷，并为此雀跃不已。不过先花点时间 考虑一下整体状况。我们使用什么技术找到了那个缺陷？我们是否可以创建一种方法来找到更多这类缺陷？我们是否可以记住…些实际的测试经验并不断地加以应用 来帮助提高我们的工作效率？软件的哪些症状可以提示我们它具有缺陷？我们将来能否从那些症状中得到更多的警示？换句话说，这不仅仅是一个缺陷或是一次成 功，这个缺陷教会了我们什么，是否使得我们将来成为更好的测试人员正如我儿子的进球一样，尽管第一个缺陷是偶然间发现的，但它不代表其余的成功都是偶然。 理解我们成功的原因很重要，只有这样做，成功才能被复制。对于测试人员来说，这种保证成功的原因就是一系列的测试技术、建议和工具，它们可以提高我们在未 来项目中的工作效率。

　　漏洞

　　测试人员最终都会变得很擅长寻找缺陷，但是要翻过测试的高峰，我们必须更快并且更有效率：高速低阻。换句话说，我们必须拥有一种本身不含缺陷的缺陷查找技术！

　　我喜欢这样来考虑问题：测试人员检视自己的工作时也需要发挥那种寻找缺陷的能力。我们必须使用和寻找产品缺陷一样的流程来寻找我们自己的测试流程，测试过程中的缺陷。我的测试流程是不是有问题？这里面是否有缺陷？这里是否存在着妨碍我提高效率的障碍？

　　你必须一直寻找更好的方法。有意识地去确定那些限制能力、阻碍前进、减缓速度的东西。就像缺陷限制了软件满足用户需求的能力一样，是什么限制了 测试的能力？使用你拥有的测试能力来最优化自己的测试流程，这会帮助你在测试的山峰上快速攀登并增加你翻越山峰后成为专家的机会。

　　测试山峰的巅峰处是一个美好的地方。如果你成功地到了那里，恭喜你．但这并不是最终日标。这表示你已经成为一个杰出的测试人员。而此时的下坡路 就是用你的洞察力和专家知识来帮助周围的人也成为优秀的测试人员。自己一个人登顶是一回事，帮助其他人（那些能力不如你的人）登顶却完全是另外一回事。

　　一般来说，那些成功登上测试巅峰的人会成为使用工具的大师。那些商业工具、开开源免费工具，和自己写的工具（我个人最喜欢的工具）是极好地提高 工作产出、增加工作成效的方法。不过，工具只是实现该目标的一种方法，但在许多其他方面它反而是一种限制，因为太多的人看不到工具的功能之外的东西。他们 被限制在工具能为他们所做的事情中，没能看到或理解对工具还有更多的需求。登顶需要真正掌握的是“信息”。因为很多工具能处理信息，并使得信息的获取更加 容易，所以测试人员变得过于依赖于他们的工具。但是信息本身以及如何利用这些信息才是真正的成功关键。

　　熟练掌握信息，指理解有哪些信息，这些信息将如何影响测试，保证最大限度地利用这些影响。有几类信息是测试登顶者必须关注的。这里我要谈的是其中两种：来自应用程序的信息和来自之前测试的信息。

　　在微软，我们有一个游戏测试组织（Games Test Organization，GTO），负责Xbox和PC游戏的测试。谈到利用应用程序的信息，他们是最优秀的。游戏是难以想象的丰富，测试起来非常复 杂。游戏中很多可测试的内容都是隐藏的（因为让那些玩家找寻可以交换的物品正是游戏的乐趣之一）o如果GTO的测试人员所做的仅仅是玩游戏，那么他们找到 的问题不会比最终用户更多。为了能做得更好，他们与游戏的开发人员合作创建了一些信息控制板，这些控制板暴露了一些基本上可以算得上作弊的信息给测试人 员。这样，测试人员就能提前知道怪物会被投放在何处、物品被隐藏在哪里，他们可以看到墙的另一边，可以控制敌方的某些行为。他们的作弊工具（即测试上具） 基本上使他们成为游戏里的神，让他们可以控制看到的信息以便更快更巧妙地测试。这个例予给有测试人员都上了一课。

　　来自测试的信息意味着你必须关注在测试时所做的一切，并使用获得的信息来影响今后的测试。你是否知道你的测试是如何与需求结合的，知道何时某一 特定需求已经得到足够的测试？你是否使用代码覆盖率来影响未来的测试？你知道当代码更新或缺陷修复时那些测试会受到影响，还是知识重新运行所有的测试？理 解测试进行到什么程度并随着测试调整测试策略，这是测试成熟的标志。

　　我以前曾在微软的Visual Studio的一个小组工作过，我们大量使用代码改动量（由于添加新特性或修复缺陷而改变的代码）和代码覆盖来影响我们的测试。我们花了很大的力气将代码 覆盖和代码改动量通知测试人员，帮助他们理解哪些测试用例对覆盖率有贡献，帮助他们测试改动过的或修改过的组件。最终的结果是在代码确实被改动时，我们清 楚地知道哪些测试会被影响而只重新运行那些测试。我们还知道每个新的测试用例是如何对总体的接口，特性和代码覆盖率产生作用的，从而指导我们的测试人员， 让团队中的每个人在他们所创建的所有测试用例基础上，写出更有意义的测试。

　　你用哪些信息来指导你的测试？你如何保证信息是可获取的，以便在测试中随时可以得到？你如何使得信息变得有用，以便它能以良好的方式影响你的测试？这些问题的答案将决定你在走下专家测试山峰时的前进速度。

　　下山

　　到达测试山峰的顶峰的时候，你已经成为一个十分能干的测试人员了，能力也许相当于你组里所有同事能力的总和。无论你在做什么，请不要试图做得比 你的整个团队都好，不管你对此感觉有多好，或是你的老板对你遏得有多紧。一旦你走在下坡的路上，就不要再去争取“找到最多缺陷的人”或是“找到最有意义缺 陷的人”这样的荣誉头衔。反而我推荐你减少花在测试上的时间，而把创新作为你的首要任务。

　　在测试上创新指不急于向前，而是仔细观察、洞察先机、找到瓶颈并改进团队中所有其他人的工作方式。你的工作变为帮助其他人进步。在微软，我们有 一个专门为此而设的正式职位——测试架构师。不过，不要因为缺少一个很酷的头衔而让你沮丧。无论别人怎么称呼你，当你在“下坡的路上，你能做的最好的事就 是尽量保证更多的人能成功地爬上山峰的另一侧。

　　问题

　　问：传统的团队如何转化为敏捷团队（步骤，要点，注意事项等）？

　　问：如果使用敏捷开发，在公司组织架构上有没有什么建议？

　　分析

　　在谈到何为敏捷团队之前，先看看传统团队的问题，不要把团队转化完了，问题还存在；换言之，解决问题是目标，转化团队是手段。

　　1、各部门打架严重

　　来自于分工中的灰色地带 / 各自目标和绩效的不一致。

　　典型的是开发/测试团队，扩展而言，还包括市场/销售团队。

　　后两者也很关键，很多时候开发和测试团队和谐了，联合起来和销售团队打架，公司的整体效率仍然上不去。

　　不过，如果没有在市场/销售团队的工作经验，或管理他们的经验，谈论和过问与他们跨职能的难度很大。但这不等于这个问题不存在，可以请公司更上层的人去关注这个问题。本博客未来会提到市场/销售/开发团队的跨职能问题。

　　2、各部门流程/文档繁杂

　　为了解决打架问题，需要流程和文档来规范接口。

　　常常被过度写作的需求文档和设计文档，就是因为要跨过多个部门，才需要被“签字”“确认”“协调一致”，所以其写作的水平，往往超过“以能编写出软件为准”，而是达到“能交给下一个部门，让他们看完以后能编写出软件”为准。

　　跨职能团队是敏捷开发提出的团队模型（自组织是跨职能的产物，下面会看到），通过消除部门分割，来解决上面的两大难题。

　　直接方案

　　直接方案是那些几乎不需要其他实践，就能直接使用的方案，虽然他们也有一些先决条件。

　　世界上没有无条件的事，也没有生下来就有条件的人，所以很容易把喜欢找借口胜过方法的人卡住。如果下面这个事情仍然觉得很难办，那么多半还没有到谈论团队转型的阶段，请继续努力吧！

　　3～5人规模的小组内实现跨职能（小组长可推行）

　　这个是无需行政授权，小组长就能做的事情。

　　本人非常推崇通过1-3-9团队形成L型代码结构（文后有链接），局部的“部门”打架和文档问题迎刃而解。

　　139团队中，整个小组的目标是一致的，而且成败都由师傅负责，因此他会成为跨人员的桥梁，把整个团队的事情当作自己的事情，解决个人的打架问题。

　　L型代码结构可以有效降低文档量。当积木代码基本形成后，所有功能大致只有界面和业务逻辑的设计，经常一个功能只有50行代码左右，很多设计都可以因此省略。

　　生态方案

　　生态方案多半不能直接就上，需要另外一些条件具备。

　　10～20人规模的开发组内实现跨职能（项目经理可推行）

　　实际上没有办法让10～20人可以互相修改别人的代码，但在这个规模上，合作的需求更高，代码的复用利益更大，跨职能势在必行。

　　这里所说的跨职能，不是代码级别的，而是在业务接口问题上，大致有以下几种情况。

　　一是经常有一些接口类功能，说不上来该谁做，这时候项目经理（就是10～20人的头）要协调其中一方完成，并为这方争取更多的资源（工期和人数）。

　　这里多少要建立团队可以提请要人的机制，而且项目经理能临时分配人员，比如把小李交给老王那组工作一段时间之类的。在139团队里边这个相对好办一些，如果是1个人管理12个人，就很难办。

　　组织方案

　　1、进度-质量目标的合并（研发的部门经理可推行）

　　也就是无论是否还有开发-测试的分割，必须把进度绩效和质量绩效统一管理。

　　一个项目延期了，测试也有责任；一个项目质量差，开发也有责任。结果大致会变成：

　　测试团队与开发团队融合

　　一般是测试团队分解到开发组，从事自动化测试的执行工作。

　　多数自动化脚本开发团队可以编写，但是多半要配置一些脚本、写一些测试用例什么的，由测试人员执行。

　　这种模式下，对测试团队的人数要求很少。

　　测试团队与需求团队融合

　　质量工作彻底交给开发团队负责，测试团队只负责业务级别的验收测试（还负责早期的需求理解和机遇需求的测试用例编写）。

　　开发团队分化出一些人负责执行测试，这些人的数量一样要求很少；开发团队同时对进度和质量负责。

　　这两种方法都不容易做到，而且还有无穷无尽的问题，但告诉大家一个方法来解决：那就是每当自己心里想问：“可是，怎么……呢？”，自己要先想三个答案，然后再问；有时候会发现不用问了，答案已经被自己说出来了。

　　2、市场/销售/产品/研发的跨职能（总经理/副总经理可以推行）

　　简单说就是市场/销售/产品团队，要为研发的成本负责（比如销售要先扣除研发成本，再谈提成）；而研发要为销售/市场负责（比如如果销售额上升，研发团队也有一个提成）。

　　日后有机会再谈这个，很多企业都已经有成功经验了，只是都不太分享而已。