今天完成的事情：
上午听了俱到网二七的需求讲解，下午任务七提交，看了关于任务八的一点文章，看了一期和三期的原型图
明天计划的事情：
写下测试用例
遇到的问题：
没有
收获：
一.性能需求分析：
   性能需求分析结论和目标：

•    明确倒底要不要做性能测试？性能测试的目的是什么？

•    明确被测系统是什么？被测试系统的相关技术信息如：架构、平台、协议等

•    明确被测系统的基本业务、关键业务，用户行为

•    明确性能测试点是什么？哪些需要测，为什么？哪些不需要测，又是为什么？

•    明确被测系统未来的业务拓展规划以及性能需求？

•    明确性能测试策略，即应该怎么测试？

•    明确性能测试的指标，知道测试出来的结果怎么算通过？

1. 二.需求分析的几个方面

1.   1、系统信息调研

1.   2、业务信息调研

1.   3、性能需求评估

1.   4、确定性能测试点

1.   5、确定性能指标

三、性能测试准备
  1、测试环境准备：
　　系统运行环境：这个通常就是我们的测试环境，有些时候需求比较多，做性能测试担心把环境搞跨了影响其它的功能测试，可能需要重新搭建一套专门用来做性能测试的环境。
　执行机环境：这个就是用来生成负载的执行机，通常需要在物理机上运行，而物理机又是稀缺资源，所以我们每次做性能测试都需要提前准备好执行机环境。
  2、测试场景设计：根据性能需求分析来设计符合用户使用习惯的场景，场景设计的好不好直接影响到性能测试的效果。
  3、性能工具准备：
　　负载工具：根据需求分析和系统特点选择合适的负载工具，比如LR、Jmeter或galting等
　　监控工具：准备性能测试时的服务器资源、JVM、数据库监控工具，以便进行后续的性能测试分析与调优。
  4、测试脚本准备：如果性能测试工具不能满足被测系统的要求或只能满足部分要求时，需要我们自己开发脚本配合工具进行性能测试。
  5、测试数据准备：
　  负载测试数据：并发测试时需要多少数据？比如登录场景？
　　DB数据量大小：为了尽量符合生产场景，需要模拟线上大量数据情况，那么要往数据库里提前插入一定的数据量。这可能需要花费一些时间，特点是关联系统较多，逻辑复杂的业务可能同时涉及多张表。
  6、其它：如果需要其它其它关联系统或专业人士如DBA配合的，也需要提前进行沟通。
四、性能测试执行
   1、人工边执行边分析
　　通常我们做性能测试都是人工执行并随时观察系统运行的情况、资源的使用率等指标。性能测试的吸引力之一就在于它的不可预知性。当我们在做性能测试的时候遇到跟预期不符的情况很正常，这个时候需要冷静的分析。但这个过程可能会很慢长，需要不断的调整系统配置或程序代码来定位问题，耗时耗人力。特别是在当前敏捷开发模式比较流行的大环境下，版本发布非常频繁且版本周期短（通常1~2周一个版本），没有那么长的时间来做性能测试。
   2、无人值守执行性能测试
　　无人值守是最理想化的目标，目前我们也朝着这个方向努力。无人值守不是说没有人力介入，而是把人为的分析和执行过程分离，执行过程只是机器服从指令的运行而已。通常测试环境在白天比较繁忙，出现性能问题及定位难度较大且会影响功能测试。所以一般性能测试最好在晚上或周末进行，在相对较安静的条件有利于测试结果的稳定性。这种方法也相对比较适合敏捷的模式，不需要人工一直守着。只需要在拿到结果后进行分析就好了。同进，这种方式对测试人员能力的要求比较高，需要我们能进行自动化的收集各种监控数据、生成报表便于后续分析。
 
五、结果分析与调优
 关于性能分析与调优这是一个比较大的话题，后续会单独进行总结和分析。
 
六、测试报告与总结
 　　性能测试报告是性能测试的里程碑，通过报告能展示出性能测试的最终成果，展示系统性能是否符合需求，是否有性能隐患。性能测试报告中需要阐明性能测试目标、性能测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能测试调优说明、性能测试过程中遇到的问题和解决办法等。
　　性能测试工程师完成该次性能测试后，需要将测试结果进行备案，并做为下次性能测试的基线标准，具体包括性能测试结果数据、性能测试瓶颈和调优方案等。同时需要将测试过程中遇到的问题，包括代码瓶颈、配置项问题、数据问题和沟通问题，以及解决办法或解决方案，进行知识沉淀。