在前面已经分析了SOA架构设计师与开发人员。下面我将对测试人员进行分析并指出一个成功的SOA测试人员的特征。
或许我应该在讨论架构设计师的时候加入一个重要的职位:测试设计师。正如《建立SOA测试团队前考虑六大问题》里所说,SOA测试对技术能力(包括开发技能)有更高的要求。也许要求测试团队拥有全面的技能不太现实,但是测试设计师和主管必须了解诸如状态、分布式计算和数据服务等概念才能正确地验证底层的架构。他们还要能够使用开发人员的测试工具并用他们自己的测试脚本进行改写。
一个成功的SOA测试策略是从测试架构开始的。因此,这个职位需要一个对SOA有很深造诣并且能与EA团队紧密合作的人来担当。我推荐直接让EA团队里的人担任。当然各企业都有自己的情况。测试架构的目标是建立一个框架和一套核心策略与程序(IT治理的一部分),这样测试团队才能有合适的工具和指导以对SOA进行测试。如果没有测试架构,那么测试团队的专业技能可能就会面临很大挑战。我个人曾经亲自遇到过三种情况。
场景1:低估SOA
第一个场景就是直接由缺乏工具和知识导致的失败。这是由于公司没有认识到他们当前的方法和内部的人事并不适合测试SOA。这些公司没有在工具、培训和治理上做出足够的投资,并且通常只能测试呈现层和接口。由于对SOA的概念缺乏了解,他们无法对架构进行验证,直接导致了性能的低下和服务的脆弱。
场景2:付出太高的代价
我所见过的第二种情况是测试时过于依赖“专家”咨询公司。公司可能把所有的资产都赌在有经验的SOA咨询公司上,支付超过100美元每小时的费用。这种模式是无法持续太长时间的,除非公司真的很喜欢烧钱(这可不是什么时髦的做法)。
场景3:取得内外技术的平衡
一种更好的情况是培训或者聘用一位SOA测试设计师,根据企业需求建立一个稳定的测试平台,然后一边培训团队里的其他成员一边对过程进行测试。公司应该聘用一名以上的有经验的SOA测试人员,寻找一两名有经验的顾问,或者培训一个有经验的可靠的候选人来引导架构测试。同时,测试专家还要肩负向团队其它成员传输知识的责任。这是很关键的。因为非常有经验的SOA测试人员现在还是稀有品种,随时可能会飞掉的。所以很有必要对内部知识库进行补充。
测试需求
可以把需求分解成三个部分:人力、工具与治理。那么一个成功的SOA测试人员应该具备哪些特征呢?答案是取决于所部署的架构。而这个架构又与工具和已决定的策略有关。
在讨论开发人员时,我提到过有必须在各层进行专业的细分化。这对测试人员也一样。对于开发人员各层之间的工作是同时进行的。我建议采用迭代开发和测试方式,而这也意味着各层的测试工作会同时进行。
我认为下面是一些具有相当高存在必要性的职位。当然某些人可以同时完成多个职位的任务。
SOA测试设计师
他是一个有胆量的领导角色,对SOA、分布式计算等有广泛的了解,有集成测试和代码/脚本编写经验,了解业务。你可能需要亲自出马才能找到这样的人,或者也可以请一位咨询师来协助你的高层测试人员。
SOA测试主管
他或他们必须了解架构的所有层(请别忘记安全性),并且能够设计可以同时验证架构和治理模型的测试方案。他们应该了解如何进行黑盒、白盒和灰盒测试。抽象的服务需要在安全性、性能和回归等方面进行广泛的测试。再加上服务的版本要求和服务消费者能以意想不到方式预先体验服务,测试用例的组合也在飞速的增长。测试主管需要根据测试推测风险,并在风险、时间和成本之间取得平衡点。这比传统的多层架构的情况要棘手得多。
业务过程测试人员
应该对业务过程进行建模并调用几个服务。根据变量与常量,这个流程需要一系列的决策点。并且它还可能引发像通知、警告、其它过程、错误处理机制、服务等一系列事件。测试人员要将业务过程作为一个独立的个体进行验证。比如,如果这个业务过程是”验证信用卡”,那么测试人员需要确定这个过程正确地对输入进行了处理、准确地运行了验证程序、并生成了合适的结果。在这一点上,测试人员不需要关心其它的过程或服务。这些测试人员必须与业务部门和/或业务分析员紧密合作,但不需要有像主管或架构师那么宽的知识面(当然有的话也会很有用)。这就叫从业务的角度进行测试。
集成测试
这些测试人员必须是非常技术性的,了解XML、SOAP、WSDL、网络与电信概念、状态,以及各种平台与技术(Java与.Net、Windows、Unix/Linux与大型机等)。
用户界面测试人员
公司可能已经有足够的人可以测试UI了。如果你的公司使用了混合应用、无线设备或者面向消费者的UI,那么测试的复杂性也会极大地增长。这些测试人员可能还需要了解AJAX、RIA、门户技术、RSS以及一系列社会性软件。
数据服务测试人员
这些测试人员必须了解数据建模、数据库CRUD操作、转换、安全性和功能、验证等还有许多方面的概念。一切的一切都起源于数据,如果这一层出现了错误,那么其它的任何结果都必须是失败。你必须有一个强有力的测试主管工作在这个数据服务层,因为数据是任何成功部署的基础。
其它需要关注的领域
成功的关键还是加速上市,而测试自动化则是促成这一点的关键。性能测试是非常非常重要的,企业应该进行对所有服务进行模拟测试以预测将来的性能。安全模型与治理模型的验证也应该成为完整的测试策略的一部分。每一位负责设计安全性测试方案的人都应该阅读并充分理解这本书。
结束语
根据我的个人经验来看,做架构和开发工作需要先在测试与安全上投入尽可能多的精力,要保证企业在测试培训与工具方面有足够的资金。在几年前的一个项目中,由于初期研究阶段过于注重开发和开发人员,而没有为测试拔出足够的资金,而导致失败。千万不要再犯同样的错误。开始SOA相关的业务已经很困难,但是想退回去更是难上加难——特别是在还没有实现任何商业价值的时候。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突