军规18 尽量减少依赖
大家都知道，如果App的依赖越多，出现问题和错误的可能性也就越大，要解决问题付出的成本也越多。所以摆在眼前的问题是，如何尽量减少App的依赖。
从笔者的经验来说，减少依赖主要是从App的系统架构入手，尽量减少依赖。
18.1 对于既有Web版本又有App版本的App要减少依赖
很多App开发时都已经先有了Web的版本，而App只是把Web的内容展示在移动设备上，这就会让App的很多功能依赖于Web事先实现的方式（如图18.1所示）。
图18.1 常见的先开发Web，后开发App的系统架构
这样的系统架构，目的在于让App使用的service能够更多地重用已有的Web版本，实际上，App只是在移动设备上做展示，和Web没有本质的区别。
但是由于App所运行的移动设备的特殊性，比如其屏幕大小、设备性能、网络环境等和Web所使用的桌面环境差别很大，所以如果单纯在App上使用Web的service，很有可能造成App性能和样式出现问题。
那是不是必须为Web和App都开发独立的service呢？（如图18.2所示）。
图18.2 为Web和App单独开发独立的service
其实也没必要这么做，因为重新把Web所有的service再为App实现一遍的开发和测试成本很高，后期的维护成本也很高。
所以，笔者的经验是，首先分析，如果已有的Web的service使用在App上，App中会有哪些场景使用到这些service，哪些service会有性能和样式的问题；其次，选择在App上直接使用可能会出现问题的那些Web service来实现独立的service（如图18.3所示）。
图18.3 只针对App与Web不同之处单独开发独立的service
也许读者会问，App的系统架构确实对测试有影响，不过系统架构的设计并不是测试人员负责的，那和具体测试没什么关系吧？其实不尽然，在做service分析的时候，对于App使用的场景和需要用到的具体service，没有人比测试人员更熟悉了，这也正是测试人员可以为App贡献的关键时刻。
本文选自《移动App测试的22条军规》第十八章，本站经人民邮电出版社和作者的授权。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
