测试架构支撑商业成功（第二部分）
上一篇 / 下一篇 2012-02-13 15:51:43 / 个人分类：文档
什么是测试架构？商业成功的关键是什么？测试仅仅是找bug吗？经过多年商业环境中测试工作的经验和实践，我将在本文分享心中的——测试架构支撑商业成功。51Testing软件测试网|1zaMo I g[*l
首先，请大家看图一，后续的内容将是对图一的一个全面阐述，告诉大家测试架构，测试活动的执行对商业成功的价值和意义。51Testing软件测试网HV pL)r7W+g6B
图一51Testing软件测试网 bH-Z*[v*t6]:r
三、测试的输出
测试计划
测试计划与一个产品商业项目计划没有太大本质的区别。
测试计划主要包含内容有：
测试范围；测试入口和出口标准；测试用例集；测试用例开发；测试预算；测试进度；测试工具和其他测试资源；用于测试的风险管理；测试状态报告。
测试计划本身至少需要考虑包含如下核心要素：
测试范围——测试计划所要达到的商业目标的范围，也可以理解成需要为多少商业目标提供检测服务，这是决定项目成本，项目进度，项目质量的源头。如果测试范围的制定过于主观，脱离现有资源的现实或工程科学性，那么可以说这个测试计划就只会是一个“无限通用”但又没有实际指导意义的计划。而好的测试范围则能帮助阅读测试计划的项目经理，开发经理，测试工程师们清晰明白的知道在后续的测试活动中，我们测试团队将会对哪些商业目标进行检测活动，测试工程师明白测试的商业目的，项目经理和开发经理知晓是否本计划的测试活动最终与项目目标对齐，有无对商业需求的遗漏。
测试项目的大小和资源——有经验的测试经理会根据测试范围的内容，预估本测试计划项目的大小（项目需要多少测试人力来执行），需要多少相关测试工具等资源。
测试进度——依据测试范围和测试项目的规模(大小和资源)来制定，完成测试范围所需要的里程碑。
风险管理——在测试计划中，测试计划的制定者需要依据项目的情况预先进行项目的质量风险预测，并针对预先识别出来的质量风险进行风险管理，针对不同的风险值制定不同的测试策略。
总体测试策略——将为整个测试计划确立不同的测试阶段，为测试范围选择不同的测试技术和测试活动。
测试计划本身的内部冲突：
当公司所要求的测试进度与测试质量要求发生冲突时，如何处理呢？为了保障测试本身的质量水准，应该在制定测试计划时通过减少测试范围的内容来应对。这样既能保障公司所需要的进度，又不失质量。
测试计划本身的成本：
1年左右的项目，可考虑用几周时间来制定；
1个月左右的项目，可考虑用1-2天的时间来制定；
1周左右的项目，可考虑用几个小时制定；
1天左右的项目（敏捷story），在早上的站立会议上需要1个小时即可；
测试策略
测试策略的制定可大可小，依据测试策略制定者自己的经验和能力来把握。经验丰富的测试策略设计者可以制定整个项目的总体测试策略，此类测试策略甚至能指导和影响后续每个测试计划的制定，确立整个项目测试资源的投入重点，确立整个测试项目会拥有的各类测试阶段和测试活动，应该使用的测试技术，每个测试阶段的测试技术组合。经验稍少的测试策略设计者可以针对每个测试阶段来制定测试策略，确立在该测试活动中测试技术选取，测试资源投入的缘由。在测试策略设计时最重要的输入就是项目的质量风险预测，整个测试策略应该围绕如何充分利用现有测试资源来规避项目的重大质量风险来开展，可以这样来概括：质量风险是测试策略的指南针。而测试策略将会让项目经理明白项目的测试资源会被如何科学的利用，项目经理也可通过测试策略的清晰度，逻辑关联性，科学性了解测试团队是否为测试的明白人。
测试方案
常见的测试方案有性能测试方案，压力测试方案，自动化测试方案，安全性测试方案，XX场景测试方案，XX可靠性测试方案等。测试方案是测试计划和测试策略向测试用例转化过程中的重要测试设计中间件。一个测试方案至少应该包括：特定测试场景需求分析和场景风险分析，并从中提取出测试需求，在测试方案中考虑如何通过哪些测试工具或测试技术，测试用例来覆盖到这些测试需求。有时在时间非常紧急的情况下，甚至可以直接利用测试方案来进行测试需求的验证。
一个好的测试方案能很好的回答项目经理这样一个问题：“测试用例到底覆盖了多少测试需求？每条测试需求在哪个用例被覆盖了。”
测试用例
测试用例不仅仅只有功能测试用例，还有性能测试用例，压力测试用例，安全性测试用例，XX可靠性测试用例。测试用例是测试计划，测试策略，测试方案一系统测试分析和设计活动落地实施的最小测试设计单位。它们将是测试项目进度管理和资源管理的最小计算单元。好的测试用例集设计能够很好的回答哪些测试需求被覆盖到了。但是测试用例的设计不可能是一次性的，一次性设计的测试用例只能是用于基本verification的用例。如果希望能发现系统潜在的更多的深入缺陷，需要对测试用例进行多次补充，依据探索性测试活动或是随机测试活动来补充testing 测试用例。关于什么是好的测试用例，在互联网上已有足够多的资源了，大家尽可到网上获取。但在这里我仍要特别强调测试用例的设计一定要考虑避免出现用例理解的二义性，提高用例学习的易用性，这些将是保障后续测试用例执行质量和测试执行进度的重要支撑。
测试报告
所有的测试活动最终可交付的最重要的成果就是测试报告，无论是一批功能测试用例的测试报告，全版本的最终测试报告还是性能测试报告，压力测试报告，安全性测试报告，XX专项测试报告等，它们的价值都不应该仅仅只是用例通过数，发现bug的直接描述，而更应该包含测试人员从产品质量风险和产品质量评估的角度的分析语言，从发现的bug中分析出系统潜在的质量风险和测试活动本身还待改进的地方，从测试通过的测试项中得到哪些质量风险得到了验证，给出产品质量的正向反馈意见。在我心目中，一份只有bug类别和bug描述列表的测试报告最多只是一个勉强及格的测试报告。而从bug现象和测试项通过的数据中，得出项目在质量领域的结论性语言和对后续测试，开发，设计，需求分析活动的改进建议，对市场活动的建议的测试报告才是有质量，更能体现测试价值的报告。
项目经理，开发经理，市场代表，需求分析师都可以从测试报告中直接得到能指导他们改进后续活动的有依据的建议，才是测试报告的最终价值体现。
产品系统知识
测试人员进行了一系列的测试活动后，对组织还会有这样一个额外收获，即测试团队还能为公司输送产品经理，需求分析，售前，售后的人才。因为，测试人员有着比程序员更能在最短时间内最全面的熟悉产品系统业务知识的机会，经过几轮测试后，测试人员对产品系统的知识积累很多时候比公司其他岗位的同事更宽厚，无论是对产品的功能，性能，亮点，短板都有直观的感受，而且对产品的总体架构和主要设计技术都有一定的认识和知识。所以，这时的测试人员成长为了产品经理不仅仅具备了产品经理，需求分析人员的能力素质，而且还能对产品质量的改进有着更有力的支撑。同时测试人员具有的客户意识结合积累的产品体系知识，又足以使测试人员比现有公司的其他售前和售后技术人员，更熟悉产品业务，能在客户处树立起公司的业务专家形象。
四、测试工具
代码覆盖率
代码覆盖率最大的价值在于评估测试活动是否足够和充分，100％的代码覆盖率能证明测试活动基本验证了最初的产品设计，但是并不能证明产品不再有质量风险或没有bug了。因为代码覆盖的技术有多种：语句覆盖，分支覆盖，条件覆盖等。每种覆盖率达成目标的成本和技术难度都不一样，成本低和难度低的覆盖率，如语句覆盖率，只能说明测试验证了每行代码，能找到基本的编码错误，但是不能发现逻辑性设计错误。
虽然代码覆盖率不是一个可以100％衡量评估产品质量的工具，但是却是能衡量一定阶段测试活动质量的方法。如果产品连最基本的语句覆盖率都没有达到100％或90％，那就说明测试用例的设计还存在很基础的遗漏。
目前在互联网上已有一些代码覆盖率工具供大家自行下载，例如Gcov。代码覆盖率最好由测试人员通过黑盒测试用例结合部分单元测试来验证，而不应由开发人员全通过单元测试来验证，因为难免部分开发人员会为了达成代码覆盖率而刻意编写提高代码覆盖率的单元测试代码，“成为一个为了指标而做指标，忘了目标的活动”。
内存处理错误检测
内存处理错误检测工具的最大价值在于降低发现和定位代码内存处理错误bug的成本，尽早发现更多的此类bug。主要的内存处理错误检测工具有purify和valgrind，利用这些工具，我们甚至只需要执行一般的功能测试用例，就能发现代码中内存处理的错误，例如：未初始化，调用越界，开始出现未释放的错误。通过此类专项工具的告警信息，就能花很小的成本发现代码中潜在的内存处理错误的bug，而不用等此类问题积累到一定程度后，才能在产品层面暴露故障现象。
因此我建议：为了加快产品Time to Market的进度，减少产品研发成本，测试组无论是在功能测试阶段，性能测试阶段，压力测试阶段，自动化测试阶段，其他专项测试阶段，只要对系统进行任何黑盒测试，都在测试执行前先开启内存处理错误检测工具，在测试执行完成时，除了观察被测试目标是否达到预期目的，还要查看检测工具的测试告警报告，重视工具测试报告中的告警，并作为发现的系统bug一样进行跟踪定位。
Fuzzing工具
Fuzzing工具的最大价值是发现常规思维无法发现的一些系统边界值状态下的bug，其思想根源来自探索性测试。通过Fuzzing工具我们能在很短的时间内发现测试目标多个可靠性领域的bug。对于项目的商业目标，能提高系统的质量可靠性，同时降低发现此类可靠性bug的测试成本。但是Fuzzing工具最大的不足之处是无法对此测试活动进行定性的结论，不能证明系统不再有任何可靠性方面的缺陷，只能证明系统一直还存在Fuzzing工具所发现的这些bug。
而Fuzzing工具的最大缺陷是其经济性，它属于一次性使用就失效的产品，为什么呢？因为大多数Fuzzing工具只是异常穷举工具，当穷举的组合都在被测目标上验证完一遍后，该发现的bug都被发现了该工具的生命也就结束了。因此Fuzzing工具不像Loadrunner或winrunner之类的工具能有较广泛的应用范围和生命周期，所以，Fuzzing工具最好不要购买，要么自己开发一个简易版或租用商用工具，才是最佳的使用方式，也是降低研发成本，降低产品成本，提高商业竞争力的做法。
模拟器
通常在压力测试活动中需要使用一些模拟器来替代大量的真实用户数或真实的测试资源，应用于压力测试的模拟器的最大价值在于降低真实测试资源构建的成本，同时也能简化测试难度，有时还能提高自动化测试率。
但是模拟器的应用场合不仅仅只有压力测试，某些模拟器的应用还能加快产品研发进度，降低bug修改成本。其应用方式是在项目中，使用模拟器部件代替项目的某些模块，使得产品研发并行开展，测试尽早启动，能取得bug提早发现，减少bug定位难度和修复成本的效果。例如：我们要开发一款设备，通常的做法在硬件板没有做好之前，是无法开展黑盒软件测试活动的。但是如果我们购买硬件模拟器——实现虚拟的硬件板，我们所开发的上层业务软件能在虚拟硬件板上运行，那么我们则可以提前进行业务软件的调测，当硬件板被开发完成后，只需要做集成后的验证。这样相比传统的开发模式，不但加快了研发速度，而且也降低了bug修改成本，同时在进度和成本领域支撑了商业竞争力，这就是使用科技技术化解了进度与质量，进度与成本的矛盾的价值。所以，进度和质量，成本之间不是永远无法解开的矛盾，只要我们善于创新，应用科技技术就能让三者都能获得满足。
当然模拟器的开发也是需要成本和时间的，根据观察大部分成功应用模拟器的公司都是采用商用模拟器的方式，来获得更好的投入产出比。
自动化测试
自动化测试工具主要有两大类，一类是自动化测试平台类，它可以集成各类自动化测试工具，和进行自动化测试任务调度和管理。另一类则是一些自动化测试工具，例如AutoIt这类工具，它能很好的针对客户端软件进行录制回放的自动化测试。对于一个测试团队来说，自动化测试最好能有一个自动化测试平台，方便进行自动化测试任务的可视化管理和调度，执行。自动化测试平台能大大帮助提升自动化测试管理的效率，降低自动化测试用例的重复执行概率，有利于根据测试环境和测试任务的突发变化，及时调整自动化测试策略，其价值也是降低研发时间，有利于Time to market。
对于自动化测试工具的选取，我的建议是如果你的测试团队在20人以下，公司研发总共100人不到时，最好使用商用的自动化测试工具或开源工具，没有必要去自主开发，自动化测试工具的开发和维护也是要成本的，小公司或刚启动的项目的时间紧急度是非常高，如果这时还自行研发自动化测试工具，反而会分散现有的研发资源，既影响研发进度，还影响测试质量。除非你的测试用例质量都不断改进到了很高的质量，确实很难再提升时，同时又有富余的测试人力时，这时再投入自动化测试工具的开发或维护中也不晚。没有自研的自动化测试工具，我们的测试项目就一定不能前进了吗？在大多数的情况下——不是。现有的商用和开源自动化测试工具已非常丰富了，无论是基于命令行的，基于web页面的，基于windows客户端软件都有足够多的选择，你需要做的是先充分利用好现有的工具，我相信至少能满足你很大部分的应用。对于中国大部分的公司而言自研的自动化测试工具并不是你的核心竞争力，微软使用自研的自动化测试工具，是因为它的领先地位和丰富的研发资源，开发测试比1:2,1:3可以让他的测试人员来开发自研的工具。而中国基本是反过来的，更多地方的开发测试比为3:1，5:1, 甚至10:1都有，这种情况下，你再学微软搞自研自动化测试工具，你牺牲的必是你在测试设计上的质量，因为你减少了测试设计的人力投入了。
所以，最后我提出一个独特的观点，对大多数中国的公司用好外部自动化测试工具来解决自己的问题，不求100％解决所有自动化测试的问题，能基本满足自动化测试工作需要足也。持续在测试设计上投入人力和时间和利用自动化解放的人力一起把测试质量做得更好，才是保障商业竞争力的最大价值，而不是让自研自动化测试工具消耗掉我们宝贵的测试人力资源。
五、专项测试技术
提出专项测试技术的目的是为了与常规的功能性测试进行区分，突出我们在特定测试阶段测试工作的重点。并且作为测试技术的分支之一，专项测试技术的掌握和积累，对于一个组织而言，其重要性不亚于自动化测试。因此，我有必要使用简单的篇幅描述专项测试技术对商业成功的重要意义，希望各测试组织像重视自动化测试一样重视专项测试技术的投入。本文仅提及：可靠性测试；可测试性设计；兼容性测试；安全性测试；性能压力测试。对于其他专项测试例如：UCD测试，白盒测试，可服务性测试等则暂不进行阐述。
可靠性测试
提起专项测试，大多数人都知道性能测试，压力测试，安全性测试，可是在大多数测试组织中并未有专人专项进行可靠性测试的技术研究和积累。虽然在日常的测试活动中通过压力测试和异常测试能进行一定的可靠性测试保障，但是有专人专项研究的可靠性测试肯定会更系统，可靠性测试覆盖更全面，可靠性测试的难题解决效率也会更高。那么可靠性测试专项活动应该如何开展呢？首先，要建立测试项目相关的可靠性故障模式库；然后，根据故障模式库中的可靠性错误类型进行分类，根据分类准备相应的可靠性专项测试用例和可靠性测试工具。最后，在测试计划和测试策略中，把专项的可靠性测试用例应用起来。有条件的测试团队，还可以根据可靠性测试用例的测试通过情况进行可靠性模型的评估打分。这样产品在可靠性领域的工作才能做到心中有数，而不是完全处于无法跟踪和评判的状态。
可测试性设计
作为专项测试技术中，唯一1个对产品或项目进行正向构建的测试技术——可测试性设计技术，其重要性对于研发效率的提升，测试成本的降低，测试质量提升都非常直观。那么如何进行可测试性设计呢？大致思路可以这样参考，在项目需求分析阶段测试人员就参与分析，这时在可测试性领域测试人员可以做2件事，1、判断需求是否具有可测试性；2、在脑海中开始思考，如何才能用更低的成本来实现某个场景的测试。特别是第2件事，这时测试人员就开始进行可测试性设计的思考，通常情况下，可以考虑基于异常构造注入，内部压力构造，重要过程信息观察三个大的出发点来进行可测试性设计，输出可测试性设计的需求。需求分析结束后，测试人员和开发人员一起进行架构设计和系统设计，这时测试人员就可以把可测试性设计的需求在架构中进行落地，构建一个独立的可测试性模块来对所有可测试性设计进行统一的管理和调度。最后，在后续的测试活动中，包括测试设计阶段和测试执行阶段，想到任何有利于降低测试成本和难度的可测试性需求，都可以基于先前设计的可测试性架构进行添加补充。因此可见，可测试性设计对测试人员的要求一点不比自动化测试的要求低，它是一种产品设计活动，而不是质量保障活动，但它却只有由测试人员来主导才能真正发挥好价值，它也是测试人员参与产品架构活动时的主要职责和架构工作分工。
如果一个产品的可测试性设计做得好，不但测试构造测试环境的成本和难度大大下降，而且产品一些瞬息万变的故障隐患也能在可测试性设计的可观下被发现，从而提升产品质量，同时开发和测试定位问题的时间也会大大下降。甚至还可以把可测试性模块打包成产品的故障自诊断模块，仅可以提高产品在运行过程中的可靠性，而且也能提高产品的可维护性，例如：windows的任务管理器就是一个优秀的可测试性设计模块。所以，可测试性设计对于商业成功的价值，是全方位的提升竞争力，不但降低产品成本（研发成本，减少研发周期），提高产品质量，而且还能降低产品的维护成本。
兼容性测试
兼容性测试有必要进行技术积累吗？不就是让我的软件在各种其他软件的平台上运行看看是否会影响基本功能吗？这样的观点应该只是兼容性测试认识的最初阶段，兼容性测试不光是功能互通的验证，事实上某些性能需求也需要进行兼容性测试，甚至通过压力测试还能发现兼容性的缺陷。我记得有个案例是某个产品A的系统中集成了另一家公司的模块B，在平时的互通测试验证中所有功能都正常。可是在进入压力测试阶段后，虽然开始也没有出现任何兼容性的问题，但是随着压力测试的次数增加，在压力测试过程中开始出现让我们无法解释的奇异故障，最后才定位到模块B在整系统有压力情况下，会与我们系统中的自研模块产生兼容性的问题。从这个案例中获得的经验教训是兼容性测试验证不仅仅是互通了就认为没有问题，还需要在压力测试情况下进行验证。
兼容性测试中最大的挑战除了发现兼容性bug外，就是如何降低兼容性测试的成本。第一个问题是如果每次都人工进行互联互通兼容性验证，那么工作量和成本非常大；第二个问题是如果需要兼容性验证的第三方产品全购买的话，则不是一般的企业所能承受的成本。对于第一个问题，可以采用兼容性自动化测试的方式来解决，而兼容性自动化测试技术则比全自研产品的自动化测试技术要复杂的多，因为它需要应对更多种的第三方产品的特性环境，所以每个公司依据自己产品的应用场景需要积累和构建特有的兼容性自动化测试技术。对于第二个问题，则是完全需要创造性的思考解决方案来解决了，这类解决方案也是需要不断积累，不断改进，才能持续降低兼容性的物料成本，满足兼容性覆盖面的测试要求，难道解决兼容性物料的工作不属于有挑战的技术性工作吗？
所以为了减少公司产品的研发成本，加快研发进度，减少流向市场的兼容性bug，从而提高商业竞争力，我们需要抛弃那种在功能测试工作中顺带验证兼容性的不严谨的测试方式，而应采用专人专项投入的方式，来持续研究如何提高兼容性测试的质量，降低兼容性测试的成本。
安全性测试
安全性测试这些年很火，特别是搞互联网的项目的测试人员基本都知道，甚至成为了互联网产品的测试必经环节。回想起5，6年前，还很少听说有测试人员进行安全性测试，那时测试人员的关注点都是功能测试，性能压力测试，自动化测试。因此，过去认为只有黑客才具备的安全性知识，现在也成为了测试人员需要具备的知识。毕竟知识是需要系统积累才能发挥更好的效果，特别是安全性的知识面很广，所以，安全性测试安排专人专项准备和研究是必须的，否则安全性测试的质量会受到很大影响。不过，值得庆幸的是现在互联网上各种集成的安全性测试工具还是比较多，对于非专业安全性测试公司的测试人员，先学会如何直接使用现有的集成化安全性测试工具，比自己去学会某个安全攻击的原理，然后自己编写测试脚本或编写测试代码的方式，要更高效，产出更大。有所得就得有所失，为了组织在最短时间内完成安全性评估，只有先把安全性测试工具当成传统测试工具来应用，待测试任务完成后，再利用空闲时间来逐个了解学习每个安全性测试用例的原理。
对于有条件的组织，可以在安全性测试工具进行应用的基础上，从多个安全性测试工具的测试范围中抽取出安全性测试的共性进行分类，然后为每类进行专项的安全性测试用例开发，以后安全性专项测试的管理和工作规划就能基于自己的专项测试用例来开展，无论安全性测试工具如何变化，如何推陈出新，我们都是基于自己的测试用例来更新和维护，使得自己产品的安全性评估是基于系统化的测试用例，而不仅仅是1－2款工具。
性能压力测试
这个专项测试技术的资料是非常多的，大家可以自己google学习。我只从商业角度分享一些自己的特有观点稍做补充：性能测试与压力测试的测试报告需要分开来编写，正如性能测试和压力测试不能混为一谈一样，性能测试与压力测试选择的测试数据范围是不一样的，测试报告的关注点也是不同的。性能测试报告的商业价值更在于“务虚”，大多数时候都是最佳最优值，或有利于市场宣传，或为了内部汇报，但我们都知道最佳值不可能是平常值。而压力测试报告的商业价值更在于“务实”，是属于关上门在自己家里开展自我批判的材料，压力测试的结果是实实在在的发现产品中存在的可靠性问题，是证明我们的系统是否是可用的系统，压力测试报告在早期“越丑越难看”越是好事，才是对我们自己说实话，让我们知道还有哪些工作没做好。所以，为了支撑好商业成功，我们在做好性能测试获得漂亮的性能数据之后，还需要在压力测试领域持续投入，持续提升压力测试的质量，这才是我们真正能站稳市场长期获得商业成功的根基。
TAG:
