一. 工作背景
VEH平台在第二季度完成了平台数据库优化工作，为体现工作成效，公司安排对VEH平台进行性能测试。
二.工作配置
时间：7个工作日
人数：1人
设备：客户端1
二.工作回顾
2.1 计划通过接口压测的方式对平台性能进行测试，编写接口数据脚本 （4工日）
2.3 因需写入大量数据（百万级），在使用单线程执行脚本时，耗时长，且不易对数据库造成压力， 引入threading模块，使用多线程的方式执行写入sql脚本 （周末对threading线程进行了浅显的了解）
2.4 在被测服务器搭建监控工具，开始测试，执行写入sql脚本，发现线程应用出现问题。因未能了解线程的原理，使用在生产环境中时，出现了各种问题。 处理线程问题（1工日）
2.5 在编写报告的过程中发现，本报告为一份性能比较报告，因在本次测试以前，平台性能没有详细的性能表现文档。故无法与本次测试结果进行对比而证明性能提升。所以现在编写的报告是没有意义的。
2.6 通过与项目层面及测试领导沟通后，跳转了本次的测试目的，仅出具项目内当前版本的性能报告即可。【此时工作进度已经延误】
2.7 使用粒度较小的方式，对每个接口单独进行测试，每次测试记录接口性能表现及服务器表现，测试执行顺利，但因粒度较小，执行进度慢。
2.8 因在做2.7 工作时，向测试服务器内灌入了大量数据，导致测试环境的功能测试和联调工作受阻。与项目经理沟通，确认性能测试优先级较低，需向联调工作让路
2.9 在等待测试环境时，编写性能测试报告框架并完成项目的基准性能测试
2.10 在下班后，开始进行测试。 初始环节执行顺利，再执行业务中断接口时，出现因业务数据不批导致数据无法正常接入的情况。需多次对数据和缓存信息进行操作，调试测试脚本。 但仍有部分接口因数据原因未进行测试。且在本次测试时 并未启动服务器监控服务，无法获取服务器表现。
2.11 测试报告编写完成，发送测试报告，并发起评审。
三.问题总结
凡事预则立，不预则废
做任何事情，事前有准备就可以成功，没有准备就会失败。说话先有准备，就不会词穷理屈站不住脚；行事前计划先有定夺，就不会发生错误或后悔的事。
3.1 在测试工作启动前
（1）没有对测试背景和当前项目情况进行足够的了解。
因为没有对项目当前情况有足够的了解，所以在心中形成了一个错误的测试方案（即分别通过接口压测的方式对两套相同配置不同项目版本的服务进行测试。），但实际上测试环境仅有当前一套测试环境且部署的为新版本服务。
3.2 在测试工作启动初期
（1）没有搞清测试目标
因为没有搞清测试目标，所以没有明确测试方向，不明确测试所需着重记录的参数，就更不能有针对性的对其进行测试并获取目标参数。
（2）没有制定明确的测试计划
因为没有制定测试计划，所以在测试工作执行在执行时时间分配错乱，没有明确测试操作的方案导致方案多次变动，延误工期。
3.3 测试启动中期
（1）将工作重心放在了脚本编写
将过多的精力投入在了脚本编写中，为给调试和其他环节预留出时间。测试不只写完脚本即万事大吉，这只是众多环节中的一环，需环环相扣，每一环都顺利完成才能完成一次测试。
（2）测试脚本没有进行真实调试，对脚本所使用的模块不求甚解
每次测试脚本编写完成后，仅对脚本功能进行了验证。也就是只保证了功能可用，但忽略了应用在测试工作中的真实场景。类似于接口压测脚本没有顾虑到各接口传输速率的问题，导致下游接口所需数据不足；数据库sql写入脚本中的线程应用也不求甚解，只学会皮毛就照猫画虎，没能理解使用的逻辑方式，所以线程模块用的乱七八糟，直接导致脚本运行失败。因为没有对脚本进行真实场景调试，所以在测试执行后 就会出现各种问题。则需要一边修改 一边调试 一边执行。大大影响工作进度。调试工作应在非工作时间进行或再进度时间范围进行。不应占用测试执行时间。
（3）多次调整测试方案
我的初始方案是针对服务进行接口性能压测，后来开发建议直接对数据库进行测试，则又开始对数据库进行测试，再对数据库的测试出现断路后，又采取了小颗粒维度对接口进行性能测试，此测试方案可行但需要大量的时间。我再采取这种方案的时候并没有预见到这种风险，显然这种高耗时的方案并不适用于我当前已延误工期的情况。最终仍回归最初的单一接口性能压测方式，完成报告。
a、因为没有计划和方案，所以选取哪种方案自我并没有一个坚定的认知很容易动摇；
b、其次因为对性能测试相关知识掌握的不足，所以在面对开发提供的各种方案都容易被动摇，认为他们说的更合理，但实际并没有对这些方案进行认真的思考和评估。
（4）没有提前做性能基准测试
因为没有在压力测试正式开始前对业务进行基准测试，所以对各个接口的基本表现没有一个大致的了解，所以出现了脚本执行中权重比例错误的低级错误。
（5）在最后一次测试时，没有对服务器进行监控
a.对linux系统操作不熟练，操作监控服务的时间成本较高
b.没有设计好具体的监控方案，不知如何更高效的监控服务器
c.对自己降低了要求
3.4 测试收尾工作：
（1）出现工作冲突
应在测试工作开始前，明确测试执行时间区间，项目组内沟通，保证测试环境可正常使用。
四.错题改正
4.1 测试工作启动前：
（1）明确是什么人需要的性能测试报告，根据阅读人群大致确定测试方向，制定测试目标
如 本次测试报告由总师办提出，其目的为验证工作成效，所以需要出具数据对比报告。对比参数应为接口处理速率 qps 数据量承载拐点和数据库最大承载量。公司层级应会对项目的大体速率较为关注。对某接口的具体性能表现，更细粒度的性能表现内容则不会太过关注。
（2）明确当前项目状态，与开发沟通确认可提用于测试的环境真实情况
如： 在本次测试前，与开发沟通确认可提用于测试的环境真实情况，提前了解到当前仅有一套优化后的测试环境可用于测试。了解到该情况后就需与测试提出方即总师办进行沟通，协商可行的测试目标。
（3）制定测试计划，明确测试工期
根据测试目标，制定测试计划，预测测试工期，明确测试所需资源。
如：
（1）确定测试目标：与总师办沟通后测试目标调整为仅对项目进行性能测试，那么测试方向应为对项目内每个业务进行测试，出具一份项目的性能测试报告。
（2）确定测试内容：对每个业务进行轻负载基准测试，接口压力测试、业务压力测试 压测时关注目标为数据处理接口速率，接口qps 内存使用率 cpu使用率 I/O速率等。（以后可能还有其他各种性能测试，如强度测试、极限负载测试、极限在线时间测试等等，根据项目特性和需求方的关注点进行组合测试。）
（3）明确测试目标：明确所需测试项目的服务器地址，服务器配置，所依赖工具版本等等。。是否有影响性能的中间件，是否采用集群式部署等
（3）制定测试方案：然后确定每种测试的测试执行方式，也就是性能测试的测试用例，需像测试用例一样写清测试目标、前置条件、测试步骤、预期结果等用例内容。尤其是压力测试各种工具间的配合方式，采样频率，线程设置等测试参数应在此处明确。各种参数的设定对性能测试的结果都会造成影响，所以参数的设定要合理或符合实际生产场景。还需要在执行压力测试的时候，是否需要采用分布式方式 都需要纳入考虑的范围
（4）明确测试所需使用的工具：如 轻负载基准测试 需要浏览器开发者模块 压测则需要各种压测工具/脚本的支持 业务场景压测 也需要工具来完成。工具优先选择自己熟练使用的，最好不要临时学某一种工具使用，边学边用会学不好也用不好*（我是这样感觉的）。如果自己熟练使用的工具少，就会在这个时候很窘迫，因为没得选。有时不得不选择并不使用的工具来使用
（5）预测测试所需时间和资源
根据计划预估所需时间和所需外部配合的资源，确认必须资源到位时间。
包括测试环境可用时间，测试人员 或其他测试必须的条件等
（6）确定性能指标
可从项目组或需求方获取指标
常见业务场景可以市场平均指标为验证指标
罕见场景可项目内讨论根据生产环境的需求预估出一个指标
（7）风险评估
对于测试计划的内各个环节内存在的风险点进行记录，并在评审会上进行评估。
随记：
入行以来，这是我第二次接入真正的性能测试。
凭借这公司对文档要求并不规范，多个已上线项目的性能测试报告，均只出具了轻负载的基准性能表现记录，并没有真正意义上的性能报告。
在这以前，甚至更多的是用一些性能测试工具，run出一些自己也读不懂但看起来很高深的报表，拿来应付并不懂行的客户。
第一次出具性能测试报告，是吉利VEH的项目，吉利真不愧是国内的车企大厂，他们是第一个拿出性能指标要求的厂商。
那是一年前了，当时我刚刚接触python，没有写脚本的能力，Jmeter也只能搞一些简单的登录demo，完全搞不定业务所需的数据加解密传输的问题。
还是靠其他部门同事的支援，才搞出了几个接口的Jmeter脚本，我只要一键执行就行了。终于再开发和其他测试同事的帮助下，完成了这次性能测试。
虽说完成了，但毫无成就感可言，我做的最多的只有文案的工作而已。
这次是我第二次接触性能测试了，测试的还是上次的系统平台。
一年的时间过去了，我觉得自己有所进步，现在的我应该可以搞定了，所以我信心满满的准备完美的完成这次测试。
但结果却不尽人意，总之我自己对这次测试工作的表现不是很满意。虽然工作已经完成，但仍需对工作进行回顾。
通过上面的复盘，我总结出了一个在网上烂大街的测试计划大纲，以前这种东西我只知其然，现在自己总结出来 也算是知其所以然了。
在这次工作过程中还涉及到很多性能测试相关的专业知识，也让我认识到自己的浅显。道阻且长！
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
