6.2. 应用系统架构
　　【应用系统架构主要用来描述系统的各个服务之间的逻辑交互，例如redis缓存、mysql数据库、数据路由中间件、主备服务器等等之间的关系。侧重于服务之间的关系，需要画出系统架构图】
　　【具体参考如下图，该图是某某平台的应用系统架构，清晰的描述了消息中间件、nosql、redis等核心服务直接的关系。】

　　6.3. 应用系统风险点分析
　　【针对被测系统的网络拓扑图和系统架构，分析可能存在性能问题的地方，如某处可能会有大量的数据库IO操作、如果没有加redis缓存可能会导致数据库的处理能力瓶颈等】

　　6.4. 软硬件配置
　　【测试环境服务器的硬件具体信息】

　　【服务器上具体软件的具体核心参数配置，如数据库的连接池配置、tomcat的链接数配置、JVM参数配置，数据库的分库分表规则等】

　　7. 性能测试准备
　　7.1. 性能测试数据
　　【根据系统目标业务量估算出每个相关业务表的数据量，并扩大一定的倍数，准备测试数据；满足1、测试数据的总量；2、各个业务数据量的比例】
　　7.2. 测试工具
　　【根据被测系统的使用协议具体选择对应的性能压测工具；根据待测对象具体选择监控特定的参数】
　　【
　　1） 施压工具；
　　2） 监控工具；
　　3） 调优工具
　　】
　　8. 性能测试案例
　　8.1. 一般性能测试
　　【满足在规定的服务器资源性能指标范围内，模拟不同的用户数量的性能测试，以确定系统能够承受的大并发数。】
　　8.1.1. 单业务流程性能测试

　　8.1.2. 混合业务流程性能测试
　　【模板同单业务一样的模板】
　　8.2. 过载测试 （可选）
　　【加大系统负载，使服务器资源处于极限状态下，测试服务器能否稳定运行。强调的是在极端情况下的稳定性】
　　8.2.1. 单业务流程性能测试
　　【模板同上】
　　8.2.2. 混合业务流程性能测试
　　【模板同上】
　　8.3. 稳定性测试
　　【在混合业务场景下，在负载测试的并发数下，延长测试时长到至少3*24小时，考察系统的稳定性】
　　8.3.1. 混合业务流程稳定性测试
　　【模板同上】
　　8.4. 可靠性测试 （可选）
　　8.4.1. 服务进程可靠性测试
　　【进程可靠性测试，在进程被kill后，能够在5分钟内自动拉起，并逐步恢复原有的业务处理能力。如tomcat的进程被杀掉后，有监控脚本自动测试并重启tomcat，以及时保证系统的正常】
　　【模板同上】
　　8.4.2. 数据库可靠性测试
　　【高可用测试，例如主数据库出现异常时，备用数据库可以及时的成为主库，保证系统的高可用】
　　【模板同上】
　　8.4.3. 网络设备可靠性测试
　　【模板同上】
　　8.5. 基准测试 （可选）
　　8.5.1. 相同场景下的性能测试
　　【在相同业务场景，相同配置条件，相同负载压力下，新版本的性能测试和老版本的性能测试结果比对，以测试修改的或新增的功能对原有性能的影响】
　　9. 风险分析
　　【列出可能存在的风险】
　　10. 附件
　　以上是基本的此乃功能测试方案的样例，可以根据项目实际情况做出一些调整