如何考核性能测试的成果？（2014.6.3）(获奖名单已公布)
本周的问题为“本周的问题为：如何考核性能测试的成果？”此话题由会员DPCQ_COCO提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单
奖项获奖名单奖励答案链接
一等奖土土的豆豆50元京东礼品卡#8
看看 1，搜集性能测试中发现并解决的问题列表，这是性能测试最直观的成功。
2，审核性能测试的各种产出物（测试计划，测试报告，各种图标结果分析），判断测试做的是否深入、充分。
2，跟踪上线后产品的性能表现，经过测试的模块有没有发生严重的性能问题。 首先，还是汇合业务经理、产品经理、开发经理等检查性能测试执行的业务场景是否完全跟真实运行业务场景有什么差别；
其次，执行的结果中各个指标，是否已经可以满足之前提出的性能需求； 1、性能测试结束后的文档类的输出，eg：性能测试计划、性能测试方案、性能测试报告等。
2、之前的性能是可承受xx并发，cpu、mem的占用率是多少，经过性能测试后，在原来的基础上可多负载并发xx用户，cpu、mem的占用率在原来的基础上降低了多少等。
3、通过这次性能测试，发现的现有工作流程 或 项目上存在的问题，并提出合理化的建议。
4、对整个性能测试团队的成长、以及 在这个过程中自身学到的内容，进行总结。
个人观点，仅供参考，谢谢！ 1，前期计划是否合理、充分，针对性能需求设计的测试策略是否合理、充分；
2，测试环境的设计与搭建是否合理，是否具有可代表性；
3，测试执行是否按照步骤执行，对于测试过程中发现的性能问题是否有详实的记录
4，测试文档及报告是否完备，对遗留的性能问题是否给出了合理化建议，整体评估是否满足了客户对软件性能的要求。 1、文档类的检查（测试计划、方案、用例、报告）；
2、性能问题的汇总及解决方案；
3、重点模块性能的抽查测试；
4、性能测试的总结； 与其说考核成果，不如我们来称之为对测试结果的分析更为准确。
主要可以考虑以下几个方面：
1、性能测试需求是否覆盖完整
业务不仅是功能测试的根本，也是性能测试的前置条件。一个成果性能测试肯定是最大最优化覆盖了业务路径，包括核心业务功能模块和逻辑。
2、性能测试计划是否合理
a）测试前计划所需的软、硬件环境配置
包括服务器CPU/Mem/HD等，还有网络带宽和路由/交换机等网络拓扑。其对整个测试结果起到决定性作用，也对测试代理机和工具等给予支持。
b）测试进度安排是否充分
这里主要指对于测试方案制定、测试脚本开发、测试执行、测试结果分析总结等一系列时间节点是否满足整个项目测试计划和进度。我们知道性能测试比较依赖环境、工具等，若该阶段花费太多时间成本，对整个测试项目会有严重影响。
3、性能测试方案是否有效
测试方案及策略是整个性能测试的指导性纲要，对于测试方法、技术、选择的业务脚本，都得在性能测试方案中体现。
4、性能测试脚本是否高效
这里已经默认选择了充分的业务场景进行测试。对于整个性能测试结果来说，核心部分就是开发的测试脚本，能够用最高效的代码来执行每一个业务功能，充分、完整的覆盖所有路径，则可以保障测试结果的有效和整个性能测试的质量。另外，脚本本身如开发之代码，过多调用进程和不释放内存等低质量语句，会使得测试执行变本加厉，从而影响到整个测试，甚至产生的结果会有严重差异。
5、性能测试执行日志是否加载
这里注意不是整个测试结果数据，是执行测试时每个细节、步骤的日志信息。若性能测试执行时不开启或开发产生日志信息，则丢失了第一时间的问题列表数据，对于日后分析带来不便。
6、性能测试结果分析是否到位
对于完成的性能测试结果，我们基本会使用图表形式来直观查看测试情况，并通过结果数据如CPU/MEM占用率，吞吐量，响应时间等来量化服务器资源消耗和系统性能。但我们更加需要去把握几个峰值或异常数据的节点，分析其产生的原因和当时的状况，然后给出自己建言和想法，帮助开发去进行性能调优。
7、性能测试问题发现和总结
其实不仅仅是性能测试，每次完成测试后对测试整个过程和产生的问题进行整理，并作总结，帮助下次测试时避免再发生相同的问题，是必须进行的步骤，也是成功测试的有效手段。
8、所有过程是否文档化
这个其实也不仅仅是性能测试，对于每次测试过程，无论功能、性能或者安全，都得文档化，通过产生记录、各阶段的测试准入、准出等，来辅助相关测试人员等进行工作。若有体系标准，如CMMI/ISO9001等，则更佳。
以上大致列举了下性能测试及其成果度量时需要考虑的部分，通过周而复始的操作，比对前后性能测试过程与结果，这样就可以不断改进和提高性能测试的质量。说大点可就能考评自己性能测试是否高效、系统功能更优化的那些成果了。
纯个人想法，请不吝指正。 1、测试过程中，是否充分发现了系统内的性能问题
2、对发现的问题有没有提出很好的优化方案
3、系统上线后，有没有出现的性能缺陷
就是一个发现问题—解决问题—最后验证的过程 不仅仅看发现的问题，还得看过程 光衡量测试结果,那首先应该明确哪些成果是属于性能测试的成果。
我个人认为至少应该包含两个方面:
1.测试文档:测试场景、测试报告等
2.测试之后的调优成果。
那么衡量性能测试的成果也应该从这两个层面来进行。
做的好还是不好,标准最重要,几楼的弟兄说的我比较赞同,基于长时间统计分析后得出的结论比较贴近客观现实。
但是同时也不能忽略过程结果的度量。
首先是基本指标：
是否发现了性能的瓶颈,并根据这个发现进行了性能调优。
场景设计是否合理。
脚本编写是否合乎规范。
测试分析后的结论是否正确。
其次是项目指标:
计划进度安排是否合理。
第三方面 是关于过程改进方面的指标
流程是否合理,是否有需要改进的地方 如何考核性能测试的成果？
1.建立考核的标准？（需求，计划，用例，环境，场景，脚本，数据采集，分析结果，定位问题等）
2.花费了多少资源和时间？
3.预期结果和实际结果？
从开始到结束，我们要什么，最终我们得到的是否是我们最初想要的即可？ 性能成果的检查，还是在数据量割接及大数据量导入时，看现网的真实成功。
重要的是：性能模型是否与真实场景一致。如果模型本身就是错误的，那么再好的计划、报告也是不靠谱的。
当然，短期的性能结果考评，还是性能报告的输出。长期的性能结果考评，是现网的运营情况。 1、进行性能测试后是否发现了性能提升点
2、是否找到了性能提升点的应对策略
3、策略是否有效落实并比对结果后确实提高了性能
个人愚见 略片面 回复 1# lsekfe
主意看客户可接受与承受的结果；性能结果是相对的，还的看是什么人使用 关于如何考核性能测试的成果这个话题，截止目前我还未亲自实践过，基于此，我就说说我对这个问题的思考：
1.首先，性能测试的成果鉴定有个大前提，就是看当前的项目性质（也是看客户对当前项目的态度如何）；
2.根据客户对项目的要求及潜在要求，需求负责人要整理好客户的反馈需求，包括描述项目的初步性能需求，这个文档（可以叫用户需求）可以作为考核成果之一保留；
3.通过需求人员反复与客户沟通需求，以及协调相关项目经理、测试经理、开发、测试人员对需求的深入理解加分析，出炉了最终的项目需求文档，此时，对项目的性能描述会更加清晰，这个文档可以作为考核成果之二保留；
4.等到开发阶段，由项目开发负责人协调各方项目参与者，通过沟通、讨论，最后确定出来的需求详细设计说明书，此时对项目的性能描述就更加深入透彻，这个文档可以作为考核成果之三保留；
5.进入项目的系统测试阶段且性能测试还未开始之前，由项目测试负责人搜集前期准备的测试用例，在此基础上整理一份当前的性能测试预估报告文档，这个文档可以作为考核成果之四保留；
6.由项目经理、技术经理、测试经理根据以上四个文档，通过沟通讨论之后，正式整理出一份性能测试评估报告（包括对数据的分析及预期结果，以及存在的风险预估及建议的解决方案等），然后邀请客户方代表一起参加该报告的最后的讨论定夺，这份文档可以作为考核成果之五保留；
7.等性能测试阶段完成，由测试负责人整理实际性能测试结果，并出一份最终性能测试结果报告，这个报告文档作为考核成果之六保留；
8.最后由测试经理组织项目经理、技术经理依据“性能测试评估报告文档、最终性能测试结果报告”两份文档，通过沟通协调解决后，出一版“最终性能测试结果报告之项目版”（测试经理负责整理），然后三方责任人再次联系客户方代表，通过沟通协调解决并出一版“最终性能测试结果报告之用户版”；
9.考核标准就是参考“最终性能测试结果报告之项目版”和“最终性能测试结果报告之用户版”的文档执行情况来定夺，看执行率(按数字标注每一个性能测试点，完成的测试点数除以总测试点数)，以百分比来计量！ 性能测试的目的：1、验证系统是否能够达到用户提出的性能指标，2、发现软件系统存在的性能瓶颈，3、根据性能瓶颈优化系统，提高系统可靠性。
因此性能测试的成果可从以下几方面进行考核：
1、系统能力是否得到充分评估：通过测试，了解在不同状态下的系统业务响应时间和可接受的并发用户最大数，即系统负载和响应时间。
2、系统中的弱点是否被充分识别出来：网络的分布式系统涉及到客户端、网络、web服务器、数据库服务器等诸多方面，因此就会产生很多藏有性能瓶颈的位点，这时候通过充分的性能测试，使得系统的负荷被增加到极端的水平，从而发现并修复系统的薄弱地方。
3、系统是否得到充分的调优：这个依赖与第二点的充分性，知悉了性能瓶颈后，最重要的就是能够根据测试结果调整系统代码和配置，验证调整后的系统能达到预期的改进目标，从而达到提高系统性能。
4、是否解决了长时间的测试执行所发生的内存泄露问题：这个属于程序中的隐含的问题，是潜藏的，比较难以发现，在长时间的测试执行中暴露出来，还需测试人员特别注意。
5、系统的稳定性和可靠性经过调优后是否达到需求目标：这点与第一和第二点类似，也是需要长时间的运行，以及在一定压力或极端负载下进行测试，才能发现，这点是否充分检测过也计入性能测试成果的考核中。
总体来说，性能测试的成果考核，包括了负载测试、并发测试、压力测试、疲劳测试、容量测试等，各种方法根据系统的性能需要进行选择性执行，可以有效保证系统交付用户使用后，最大程度上保证用户对性能的满意度。
当然，我觉得真正的性能测试成果的最终考核是在用户的手中，因为系统是为了满足用户使用研发的，再专业的需求分析和测试可能都无法完全覆盖用户对系统性能的需求，因此，收取用户使用体验反馈就显得很重要，这应该也可以列入考核中。 题目是：如何考核性能测试的成果？
上面有TX对问题的理解是：如何考核性能测试工作的效果，从计划、策略、准确率、环境等方面，评估了性能测试这个工作是否达到了预期结果。
我的理解可能不一样，我对此问题的问题点理解是：进行性能测试后，如何从结果上评估产品的性能结果？
之前负责制定过APP的相关性能方案，在制定了相应的CASE后，发现指标的制定真的很头疼，如果明确某条具体CASE的值，以此判定是否合格或达标？
以下是我们经过讨论的一些定义指标的方向：
1、比较法
通过比较，判定此项CASE是否满足要求，比较的依据可以是竞品，也可以是上次迭代的值。
2、PO(Project Owner,项目经理或需求定义人员)定义
这种方法是指，由项目经理（或需求人员、设计人员等）给出期望值（或预期的设计目标）。
3、竞品评估值
这种方法是指由专门的小组（在我们公司是用户体验小组）在收集了多款竞品后，通过数据统计给出的产品定位性能指标。这个方法需要涉及到专门的小组来实现。
以上只是定义了性能的指标，对于测试而言，这只是解决了提BUG的问题，但是，产品的性能到底如何，还需要测试人员对于性能报告进行分析解读：
1、测试的准确性？我们是通过一个简单的离散度指标定义每项的准确性，其算法为：max|Xn-X|/X*100%（X为3次测试均值），我们定义离散度在10%以内说明此CASE数据有效。
2、CASE的总体达标率是多少？用户关注重要级别高的CASE是否全部通过？
3、没有通过的CASE主要集中在哪些功能模块上？
等等。 看覆盖率了，性能测试的结果在成本、项目进度的压迫下性能测试，质量很难做到尽善尽美，我们只能在此基础上做到最好就行，尽到力了，覆盖到主要性能的方面时对的。 一个能从别人的观念来看事情，能了解别人心灵活动的人永远不必为自己的前途担心。
页:
[1]
2
