软件技术架构对性能测试的影响

以前跟人讨论有关软件开发中业务或技术方面问题的时候，总会说技术向来不是软件开发的难点，而且一直都很认同。但现在在**，随着性能测试工作的深入、DBA新鲜血液的加入、标准版逐步暴露出来的各类问题等的进展，这种观点逐步被打破，因为在目前的**，技术难点逐步被一 一暴露了出来。不是技术出身，也不是架构师，对于**系统架构了解很浅，所以，对于这块只能谈些**系统架构对于性能测试方面的影响之类的浅薄理解。

1、多层加密和数据压缩以及非标准协议引起的第三方性能测试工作应用困难的问题：

加密的目的为了安全，压缩的目的为了效率，B/S是为了与时俱进，很多业界ERP或其他管理类软件的的产品性能测试用的是LR等专业性能测试工具，业界此类产品应该也考虑到了安全性、效率等各方面，人家能用起来，如果我们的系统架构提供支持，也是应该可以用起来的，这个支持意味着重构或方案重新选定，挑战不小。

2、不支持数据库升级导致分析用户数据后通过脚本来实现构库困难重重：

目前之所以无法把**或以前**里面的数据导过来或者通过升级来实现，除了业务变更的影响外，还有就是**系统架构或者数据库以及表结构在变，导致无法处理升级；因为**比较年轻，以后的路还很长，用户的需求也会一直在变，系统架构随着业务变是不可避免的。这块对性能测试的直接影响就是数据怎么来？写脚本和构库花费大量的工作，不过这个目前倒是有方案，只是投入会比较多。以后**如果重构或新产品上线，在技术层面上这些应该都要纳入考虑范围的。

3、**工具的继续开发维护被搁浅：

**是当初解决问题1的一个很好的东东，测试这个阶段也完善了一些对此工具的需求，如：

目前这块的需求被搁浅，其实这是个很好用的工具，借用业界第三方专业的性能测试工具的功能，当易用性及相关功能完善后，可以针对这段时间发生的各类问题设计一些测试场景，快速的发现一些问题，部分问题的复现有时比**要快捷多了，浪费了就可惜了。

**系统技术架构对于性能测试的影响分析跟业务架构相同，都需要经历逐步积累的过程，不经历不知道，经历之后才能改进，测试人员会跟上产品的步伐，与时俱进。