Web服务测试与传统的Web测试

liuyang0306

测试web service和测试一个传统的web应用的根本区别是什么?

Rami Jaamour：我想我们需要在头脑里保持以下这些意识：

       1) 不同于传统的应用(web开发，富客户端应用)，你正在构建和测试的services没有直接的用户

界面，所以你需要把它组合到一个界面中，让你能够和这些services轻松地进行交互(例如提供数据，构

建信息等等)。

       2) 类似于传统的应用，有些是要求你的services符合的功能性的要求，例如正确执行那些要求

和正确实行你的用例场景，但也有一些非功能性质的要求：

       1.符合标准(W3C，OASIS, WS-I等等)，以便当你维护供应商的独立性和避免专有插件的同时可以

成功地随时重用和访问那些services。

       2.遵循政策，其中包括标准以及设计和运行时的政策，还有的政策是确保services内部一致性，

使能够重用和加强信任，以便随着你的SOA的发展你能够真正重用services，并使他们的质量状况具有充

分的可见性(像信用报告)。

       3)在SOA中的功能和性能的考虑需要更多的关注和与传统的应用不同的方式，因为一旦你围绕你

的SOA中的services构建业务流程,你的services可能会以不易预测的方式被访问和消耗，这是因为它们

使用的范围不再受具体流程和约束于一个所谓的具体web应用的场景的控制，所以你需要注意负面测试，

并确保在突发状况(例如不良数据，数据丢失等等)下services功能是可靠的。

       4)安全。永远不要忘记安全考虑：内部外部都要考虑，即使你的services只是内部的。需要避免

一些专门针对XML的攻击，还有传统安全考虑，像要阻止对SQL的注入攻击。

       从流程角度看，一个连续的测试过程需要建立在你可以孤立的系统部分上(有时你需要清除或仿

真来实现)，并不断地(自动)对它进行回归测试。这有一些关键信息：

       1)把你的资源放进来构建测试，而不执行测试。这个执行应该是自动的。每当你发现自己在花费

时间做测试(发布XML信息并分析)，那么，你就是在做错误的事情。

       2)维护你的回归组件和你创建的测试，这是非常有价值的资源，因为一旦你需要做一新版本的

services，这些测试资源就会非常有用，所以你可以运行并确保从一个版本到另一个版本没有什么损坏。

       3)有一个基础结构来分享这些测试资源也是很关键的，这样不同的组、QA和开发人员等等可以访

问、改进和重用那些其他人创建的测试。这是web services被不同的团队重用和消耗的必然结果。