基于用户业务应用模式的性能测试分析

软件即服务，注定软件的开发过程是围绕所服务行业、公司或部门业务来转的；无论是需求分析、编码还是测试，任何一项脱离了业务，都是没有意义的。对于测试，脱离业务的测试，无论是功能还是性能都没有徒劳无功的。测试讲究Good-Enough原则，或者叫做适用性原则，过少的测试是不负责任的表现，过多的测试也是一种资源的浪费，在**，如何做到Good-Enough，关键点仍然在基于用户业务应用模式或者叫用户应用场景的分析。

功能测试我们已经做了很多年，从**到**，我们基于用户应用场景的分析尽量想做到覆盖全且精，测试人员通过与需求、产品、实施、运维人员沟通、直接去现场或电话、远程处理用户反馈问题等各种方式了解业务，这里的业务不仅包含需求文档里面能找到的东西，更多的是对于用户究竟如何应用以及可能如何应用的思考。但当**逐步需要支撑规模化应用，需要像业界ERP/CRM系统那样支撑大、中、小型企业级应用的时候，我们又有些迷茫，因为没有人，需求？产品？实施？销售，甚至即使是现有客户能够直接告诉我们：

要做更合理的性能测试，针对不同规模的企业级应用：

（1）   如何构造合理的数据库？

（2）   如何区分大/中/小型企业？如何区分大/中/小型项目？分别是什么样规模？分别如何管理及应用？不同规模的项目如何在系统中分布？不同的应用规模，对于业务的应用有哪些不同，或不同侧重点？

（3）   一个**系统，不同应用的规模，每天甚至每小时会多少个用户同时在线？分别在做哪些操作？每天或每小时一个人最多可以干多少活？（录入多少数据）

（4）   对于现有用户还没有应用起来或不稳定的业务，如生产，数据如何构造？

（5）   集团、公司、项目同时使用系统的角色比例情况如何？

（6）   哪些业务或模块、操作会被用户会经常使用？哪些是已经熟透的需求哪些还处于探索阶段？

…..

一系列的问题，均为**业务应用的范畴，对这些问题的解答来自于对客户应用模式的真正了解，不了解的情况下所做的猜测都是徒劳的，想不到要了解这些对管理类软件的长远发展的影响是可悲的。

对于**测试，接下来对业务的理解范畴，对于用户业务场景的分析，需要加入这些，这些不仅是对性能测试场景设计有用的逻辑，对于功能测试场景设计以及版本质量标准的定义，做到Good-Enough的测试，制定版本质量标准等等也是极具有指导意义的。

**还很年轻，我们逐步从分析用户应用日志、尽量找能了解一些的人沟通，找寻业界管理类软件测试等种种方式期望能发现一些马脚，相信后续的**，**业务，**测试，均会具有极其广阔的发展空间。

**业务分析与了解，我们，任重道远。