今天完成的事情：巩固前面学习的测试用例模板还有bug
明天计划的事情：做项目的测试用例
遇到的问题：无
收获：

一、性能需求分析：

　　性能需求分析是整个性能测试工作开展的基础，如果连性能的需求都没弄清楚，后面的性能测试执行其实是没有任何意义的，而且性能需求分析做的好不好直接影响到性能测试的结果。

　　一些性能测试人员常犯的错误就是测试一开始就直接用工具对系统进行加压，没有弄清楚性能测试的目的，稀里糊涂做完了以后也不知道结果是否满足性能需求。市面上的书籍也大都是直接讲性能测试工具如LR，jmeter如何使用，导致很多新手一提到性能测试就直接拿工具来进行录制回放，使得很多人认为会使用性能测试工具就等于会性能测试了，殊不知工具其实只是性能测试过程中很小的一部分。

　在需求分析阶段，测试人员需要与项目相关的人员进行沟通，收集各种项目资料，对系统进行分析，建立性能测试数据模型，并将其转化为可衡量的具体性能指标，确认测试的目标。所以性能测试需求分析过程是繁杂的，需要测试人员有深厚的性能理论知识，除此之外还需要懂一些数学建模的知识来帮助我们建立性能测试模型。

首先，让我们来看看通过性能需求分析我们需要得出哪些结论或目标：

• 明确倒底要不要做性能测试？性能测试的目的是什么？
• 明确被测系统是什么？被测试系统的相关技术信息如：架构、平台、协议等
• 明确被测系统的基本业务、关键业务，用户行为
• 明确性能测试点是什么？哪些需要测，为什么？哪些不需要测，又是为什么？
• 明确被测系统未来的业务拓展规划以及性能需求？
• 明确性能测试策略，即应该怎么测试？

  3、性能需求评估：

  　　在实施性能测试之前，我们需要对被测系统做相应的评估，主要目的是明确是否需要做性能测试。如果确定需要做性能测试，需要进一步确立性能测试点和指标，明确该测什么、性能指标是多少，测试通过or不通过的标准？性能指标也会根据情况评估，要求被测系统能满足将来一定时间段的业务压力。

  　　判断是否进行性能测试主要从下面两个方面进行思考：

  • 业务角度:

  　　 系统是公司内部 or 对外？系统使用的人数的多少？如果一个系统上线后基本没几个人使用，无论系统多大，设计多么复杂，并发性的性能测试都是没必要的，前期可以否决。当然，除非在功能测试阶段发现非常明显的性能问题，使得用户体验较差的，此时可进行性能测试来排查问题。

   

  • 系统角度：系统又可以从以下3个方面进行分析

  　　a）系统架构：

  　　　　　如果一个系统采用的框架是老的系统框架（通常大公司都有自己的统一框架），只是在此框架上增加一些应用，其实是没有必要做性能测试，因为老框架的使用肯定是经过了验证的。如果一个系统采用的是一种新的框架，可以考虑做性能测试。

  　　b）数据库要求：

  　　　　　很多情况下，性能测试是大数据量的并发访问、修改数据库，而瓶颈在于连接数据库池的数量，而非数据库本身的负载、吞吐能力。这时，可以结合DBA的建议，来决定是否来做性能测试。

  　　c）系统特殊要求：

  　　　　　从实时性角度来分析，某些系统对响应时间要求比较，比如证券系统，系统的快慢直接影响客户的收益，这种情况就有作并发测试的必要，在大并发量的场景下，查看这个功能的响应时间。

  　　　　　从大数据量上传下载角度分析，某些系统经常需要进行较大数据量的上传和下载操作，虽然此种操作使用的人数不会太多，但是也有必要进行性能测试，确定系统能处理的最大容量，如果超过这个容量时系统需要进行相关控制，避免由于不人工误操作导致系统内存溢出或崩溃。

   

  4、确定性能测试点： 

  　　在上面第3点中，我们简单分析了如何确定一个系统是否需要做性能测试。下面简单总结下如果一个系统确定要做性能测试，我们如何确定被测系统的性能测试点？

  　　我们可以从下面几个方面进行分析：

  • 关键业务：

    　　确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如转账，扣款等接口。如果项目（或功能点）不属于关键业务（或关键业务点），则可转入下面。

  • 日请求量：

    　　确定被测项目各功能点的日请求量（可以统计不同时间粒度下的请求量如：小时，日，周，月）。如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试，而且关键业务点，可以被确定为性能点。

  • 逻辑复杂度：

    　　判定被测项目各功能点的逻辑复杂度。如果一个主要业务的日请求量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式方式的调用中，当某一个环节响应较慢，就会影响到其它环节，造成雪崩效应。

  • 运营推广活动：

    　　根据运营的推广计划来判定待测系统未来的压力。未雨绸缪、防患于未然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用。例如，运营计划做活动，要求系统每天能支撑多少 PV、多少 UV，或者一个季度后，需要能支撑多大的访问量等等数据。当新项目（或功能点）属于运营重点推广计划范畴之内，则该项目（或功能点）也需要做性能测试。

  　　以上 4 点，是相辅相成、环环相扣的。在实际工作中应该具体问题具体分析。例如，当一个功能点不满足以上 4 点，但又属于资源高消耗（内存、CPU），也可列入性能测试点行列。

   

  5、确定性能指标： 

  　　性能需求分析一个很重要的目标就是需要确定后期性能分析用的性能指标，性能指标有很多，可以根据具体项目选取和设定，而具体的指标值则需要根据业务特点进行设定，本文不详细进行阐述，后续可考虑就此单独写一篇。

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