测试架构支撑商业成功（第一部分）
上一篇 / 下一篇 2010-02-12 21:12:18 / 个人分类：测试架构师的必备能力
测试架构支撑商业成功（第一部分）
作者：架构师Jack
联系方式：TestArchitectJie@gmail.com
什么是测试架构？商业成功的关键是什么？测试仅仅是找bug吗？经过多年商业环境中测试工作的经验和实践，我将在本文分享心中的——测试架构支撑商业成功。
首先，请大家看图一，后续的内容将是对图一的一个全面阐述，告诉大家测试架构，测试活动的执行对商业成功的价值和意义。
图一
什么是商业成功？
以我这些年在工业界的经验和体会，我总结出一个机构的商业目标要成功必然要有两个阶段：第一阶段是吸引客户；第二阶段是留住客户。如果我们不能很好的吸引客户购买你的价值，那就没有任何商业价值了。但是吸引了客户后，为了让商业目标能持续下去，就需要你能继续留住客户，因为留住客户，才能吸引真正大部分的客户，你的商业价值才能越滚越大，才能基业长青。我们可以看2个案例：百度靠自己独特的功能，和较高质量的中文搜索结果，吸引了第一批客户，第一批客户又由于搜索结果的满意度，而口碑相传为百度创造了第二批，第三批客户。阿里巴巴依靠自己独特的功能和定位，以及配合营销的支持，吸引了第一批阿里巴巴的客户，在第一批客户得到满意的服务后，才能支持后续不断扩大着新的客户。倘若阿里巴巴的后台系统质量欠佳，例如：经常导致客户的网上业务中断，或是导致客户的数据丢失，或是客户的网页被黑客修改。那么可以肯定，阿里巴巴的现有客户会放弃阿里巴巴的服务，同时，质量差的口碑也会传播开，导致无法吸引新的客户。那么目前为止无论是百度还是阿里巴巴都在不断的扩大着自己的客户群，就证明了它们两家公司的测试质量还是令人满意的，没有因为质量拖累了商业目标的达成。
那么我们测试人员在这两个阶段如何发挥作用，体现自己的价值呢？
在“吸引客户”阶段：吸引客户的关键是产品的规划设计，规划的产品能解决客户的某些问题，这样自然会有客户愿意尝试产品，并成为第一批客户。在这一阶段，如果你不是一个刚进入工业界的新人，而是一个工业界的“老兵”测试人员那么你可以发挥你过去在其他项目中积累的对客户需求的理解，以一个代表“用户”的角色与老板，与开发负责人一起商讨产品应该具备哪些功能，如何才能满足用户的需求。对于能力很强，经验丰富的测试人员还可以参与产品的架构评审，设计方案质量的把关。确保产品的设计满足最初的需求规划，产品的设计缺陷不会留给用户。我把这个阶段的测试活动都定义为“测试驱动设计”。
在“留住客户”阶段：其实留住客户的贡献，测试人员从一个项目开始就在支持了。从代表“用户”来敲打需求的必要性和需求的正确性，到对产品进行的各种类型的测试，目的都是尽可能的保障产品的质量，不让产品缺陷伤害到客户。我把这个阶段的测试活动定义为“测试驱动开发”。
测试驱动设计——“吸引客户”
此处的测试驱动设计，不是写一段测试代码或一个工具来动态测试产品的设计方案。而是采用静态测试的方式，利用测试人员特有的产品系统经验，与开发人员一起完善产品的设计质量，需求质量。我把测试人员在产品设计阶段对开发人员的影响力，称为“测试驱动设计”。“测试驱动设计”解决的是产品设计质量的需求，确保产品的设计能“吸引客户”。在我的blog中有一篇文章，《测试架构师与产品架构师的合作》有更多的介绍。
http://www.51testing.com/index.php?uid-293557-action-viewspace-itemid-179482
这是测试人员未来发展的一个方向，更高价值的体现。成为产品设计的主导，而不只是在最后阶段发现一些程序员粗心大意的错误。
测试驱动开发——“留住客户”
测试驱动开发不仅仅是TDD的范畴，不只是测试人员先写好单元测试代码然后进行TDD活动，测试驱动开发还包含后期系统黑盒测试。大多数单元测试只能发现编程技术上或人为粗心的问题，很难发现产品需求和设计方案的问题。因此，我把单元测试和使用一些测试工具对产品进行的黑盒测试都定义为“测试驱动开发”。“测试驱动开发”解决的是开发质量的需求，确保客户不会因产品实现过程中的人为错误而受伤害，离开我们。
“测试驱动设计”如何实施？
需求/规划/设计/编码阶段的测试——“吸引客户”
需求阶段、规划阶段、设计阶段、编码阶段开展的测试在国际上有一个专业的词汇叫“early testing”，大家有兴趣可以在google上搜索“early testing”可以有更多的了解。早期测试与我们平时传统测试的区别更多在于测试在产品周期的哪个阶段介入。是开发人员做还是测试人员做更好呢？我依然认为还是专业的测试人员来做更有效，因为测试人员具有更好的发散思维和更严谨的思维，很适合在早期阶段进行测试。虽然欠缺一些产品代码编写的经验，但不影响早期测试的开展。最多在编码阶段的测试活动上效率低一些，但单元测试代码本身编写并不复杂。关于如何开展早期测试，欢迎大家关注我的blog文章之一《需求质量如何测试》http://www.51testing.com/?uid-293557-action-viewspace-itemid-197367
“早期测试的目的”就是要确保产品后续的活动是在一个正确的方向上。
“测试驱动开发”如何实施？
调测阶段的测试——“留住客户”
后期测试主要就是大部分测试人员日常所做的测试活动，这一阶段的测试活动基本都属于动态测试，测试技术的入门门槛并不高，但却是保障产品质量的最低底线。后期测试包含了平时我们所涉及的：性能测试，压力测试，可靠性测试，兼容性测试，测试方案，测试用例设计，等价类划分等活动。任何一个公司都必须把这些测试活动做扎实，才能守好最后的一道门。相对于早期测试活动的开展，对测试人员能力的要求相对较低，不存在是否测试活动能够有足够技术积累支撑开展的风险，所以成为了主流的测试活动。但是后期测试相对早期测试的不足就是：发现产品bug的成本高，发现产品bug后修复的成本大和难度大，而且发现一些产品设计缺陷的难度比早期测试大。因此，如果有条件，测试团队应该尽力抽精兵强将在早期测试阶段进行投入，能有多大能力就投入多大，不让“缺陷越早发现，成本越低”成为永远的不去努力的目标。
“后期测试的目的”就是要确保产品实现工作是在既定的方向上得到了无偏差的实现。
静态测试——“吸引客户”
早期测试的主要测试活动都属于静态测试，例如：需求评审，架构评审，代码静态检视，代码静态测试工具都是属于静态测试。静态测试是所有测试活动中发现缺陷时间最多，效率最高，缺陷定位时间最短（发现缺陷了就定位缺陷了），修改缺陷成本最低（只有一些图线或文字描述的修改）。但是静态测试对人能力的要求却更高了，因此目前在大部分中国的公司还无法开展起来。对于已开展静态测试的测试人员，要清楚你正在做的工作是“吸引客户”的第一步，这样会给你更大的责任感，让你更有动力做好静态测试的质量。静态测试的结果就是确保你们在做正确的产品，能满足新客户的需求，吸引到新客户。
动态测试——“留住客户”
动态测试顾名思义就是需要软件动起来，才能进行的测试。我们传统的黑盒测试都属于动态测试，一些动态测试工具能帮我们大大提升黑盒测试的效率，如：动态内存自动检测工具，压力测试工具等。采用动态测试基本都是在产品的后期阶段了，这时测试关注重心是产品得到了正确的实现，能留住老客户，而不会因为修改了一个bug，引入了新缺陷破坏了老客户原有功能。
目前为止，本文的上半部分结束了。从宏观层面给读者们分析了测试支撑商业目标的主要活动类型，以及各阶段测试活动的价值和意义。我们要在确立测试架构时，可以从以上大类划分测试活动的组合策略，清楚明白后续测试计划所解决的商业问题。
后面的内容将是本文的下半部分内容，从微观层面分解支撑测试架构的具体测试活动。
一、测试架构的国际通用标准和活动：
TMM（测试能力成熟度）：是类似于CMMI的一套评估体系，可以帮助我们了解当前所在的测试组织在国际标准中所处的成熟阶段。
ISO9126：是一个国际质量标准，它定义了很多非功能属性的内容。可以帮助我们完善产品非功能属性的设计，以及非功能测试所应该包含的内容。
TPI（Test Process Improvement）：是一个国际测试改进活动，没有唯一的国际标准，但是它提供了一种评估测试活动质量的维度矩阵，一种思想启发。目前国际上有一些测试顾问公司在使用TPI来进行测试咨询服务，识别出测试团队的短木板，给出改进建议。
以上内容在测试架构中的作用和价值是提升测试活动本身的质量。测试活动质量提升后的效果就是产品质量的提升。因此，测试活动的质量如何知道，测试团队提升的方向在哪，都可以参考这些国际通用的方法来帮助我们。
二、常见可用的测试工程方法
需求测试方法——（在产品需求阶段进行测试的方法）
首先，判断需求是否具有可测试性，这是需求测试的最低要求；
其次，对需求描述的完整性，二义性，前后一致性，可修改性，可行性进行评估；
最后，判断需求的必要性；
以上测试方法对人要求较低的是需求的可测试性判断，但也需要有经验的测试人员来实施。而其他内容，则视测试人员的项目经验多少和能力大小来实施。也许需求的测试方法还有许多，但我目前仅用以上方法进行实施，就足够我施展和发挥，而且也还处在不断改进，学习当中。
架构测试方法——（在产品设计阶段进行测试的方法）
借用SEI的经典方法：“质量属性决定架构设计”。测试人员在测试产品架构时，如能从质量属性入手，反推产品架构设计如何来支撑产品的质量属性，则可以发现产品设计上对质量属性支撑不足的缺陷。
同时，可以发挥测试人员积累的异常场景经验和负面场景经验，对架构中的每一个状态或算法进行异常假设和负面假设，则会发现开发人员的设计方案中有不少遗漏。
如能把以上两种方法很好的运用，则测试人员对产品架构质量的贡献已非常巨大了。
基于风险的测试——（在制定测试计划和测试策略之前的测试方法）
核心是测试人员与公司的项目经理，开发人员一起对项目在提交测试前进行风险分析，从风险发生的概率，风险产生的影响两个维度对风险进行打分评级。对于风险系数高的部分作为后期的测试重点，并配置针对性的测试资源和测试方法。基于风险的测试将帮助我们的测试策略能真正关注到产品质量的核心需求，可以大大提升整个测试计划，测试资源的准确性和有效性。
基于模型的测试——（提升测试设计和执行效率的测试方法）
该测试方法解决的问题是：如果需求发生改变，那么测试用例更新，自动化测试脚本更新将会是很大的工作量，而使用基于模型的测试，则几乎可以在瞬间完成用例和测试脚本的更新，用例维护将不再是恶梦。只是基于模型的测试方法对需求描述文字编写的质量要求非常高，且必须符合一定的描述规则，才能自动的将需求转化为模型，模型自动转化为测试用例。
这个大大提升测试设计和执行效率的测试方法目前仅在国外少数机构运用，我也只是看到过演示。如果你的组织能实施基于模型的测试，那么你的组织在需求把握的规范性和质量上已上升到了非常系统的阶段。
探索性测试——（测试执行阶段提升测试质量的测试方法）
探索性测试是测试艺术的体现，也是测试技术中最具有不确定性，也最有意思的活动，是最有创造性的测试活动。最原始的探索性测试就是简单的“Monkey Test”，但无论多高级的探索性测试都是从“Monkey Test”进化而来。一个测试组织只有“Monkey Test”那是很危险的，因为你的测试质量完全无依无靠，但是一个测试组织没有“Monkey Test”那么也是危险的，因为很多表层以下的问题都没有得到发现。所以，探索性测试应该作为测试用例执行完成后，提升质量的一个必备补充测试技术。它不但能确保系统不少表层下的问题被发现，而且还让测试人员的“发散思维”和“创造力”得到修炼。测试人员要相比开发人员的优势就应该是在“发散思维”和“创造力”上。
基于经验的测试设计——(提高测试经验重用性的测试方法)
业内有一种说法，基于经验的测试设计就是“Checklist”。是的，各种测试所用的checklist是基于经验测试设计的主要体现形式。对组织来说，让有对应测试经验的同事把需要测试的场景经验固化到“Checklist”中，让没有这些“测试场景和方法”的同事也能马上应用上这些测试经验。既为公司保留了宝贵的知识财富，又能让测试覆盖更全面，更系统，提升整体测试质量。
Fuzzing测试——（提升异常测试覆盖率质量的测试方法）
Fuzzing测试有些类似“Monkey Test”，但它与“Monkey Test”的最大区别在于Fuzzing测试的系统性和完整性。Fuzzing测试通常依赖测试工具对测试对象的所有正常场景和异常场景进行覆盖，由于依赖工具进行异常场景覆盖，就可以做到异常组合的全遍历，提升了产品异常测试覆盖率的质量。
等价类划分——（减少测试重复率，提升测试设计和执行效率的测试方法）
对于被测对象的所有场景和输入中，总有一些数据能用一个典型数据来代表，而不需要我们进行所有数据的全遍历。等价类划分技术不只是用于有数字的边界值范围，更可以用于测试用例的划分，测试场景的选取，测试步骤的等价选择。
正交分析——(提升测试设计覆盖率的测试方法)
简单理解就是要广泛应用功能交互，多个象限边界值交织的测试设计。因为往往某个模块在单一状态下没有问题，但是在多个状态同一时刻作用于一个点时则会暴露出模块设计考虑不足的问题。通常等价类划分和正交分析共同组合使用，使用正交分析可以保障产品应用场景的测试覆盖率，等价类划分则可以对正交分析的结果进行优化，减少重复的测试场景，提高测试效率。
基于场景的分析测试——（确保测试用例不遗漏，测试用例有效性的测试方法）
如何构建测试用例或测试环境？“凭空想象？” 肯定测试结果是不系统，不真实，甚至有时测试还是多余的。最好的方法是：利用需求进行用户场景的分析，分析用户在一定范围内可能的正常操作和期望，异常操作和期望。然后基于场景分析输出的测试场景，导出测试方案或测试用例。这样编写的测试用例才是真实的，不是多余的或无意义的。既可以保证每个测试用例真正代表了用户需求，证明了每个测试用例的有效性，又可以减少无意义测试用例的产生，或用户真实场景下测试需求的遗漏。
未完待续，下期继续测试架构支撑商业成功（第二部分）。。。。。。。。。。。。。。
本文收录于《51测试天地》电子杂志第十六期。
十六期杂志下载：
http://www.51testing.com/html/28/n-205128.html
版权声明：本文出自51Testing软件测试网电子杂志--《51测试天地》第十六期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
TAG:
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | |||||||
我的存档
数据统计
- 访问量: 1311122
- 日志数: 119
- 建立时间: 2009-10-12
- 更新时间: 2014-04-21
