【2月9日更新】性能测试过程手记

trapezia

最近刚做完一个不大的但是比较完整的性能测试项目，趁热打铁想总结一下，因为本身也很菜，怕总结的不全，所以帖出来供大家讨论。我也好收集一些好的建议和知识。我会持续更新这个帖子的。希望大家支持。
先从性能测试的过程开始说起吧：
性能测试组成
1.测试策划
被测系统概述、测试目标、测试范围、定义需要测试/不需要测试的特性；分析测试设备、人员、时间等资源情况；最后生成《测试计划》。
从待测试系统提交到开始着手进行测试，需要面对测试需求\范围不明确，测试资源不明确，测试目的不明确等问题，而测试策划的阶段主要就是来应对这几个问题。其中对测试需求不明确要尤其加以重视，越来越多的信息系统使用方开始关注性能，但是由于性能测试处于初级阶段，许多系统只是要做性能测试，但是对于性能测试的目的、方法、重点等考虑的不到位。这就可能导致在花费时间、金钱进行了性能测试后发现得到的和预期的不同，或者性能测试没有有效避免后期的性能故障。
性能测试是在功能性测试完成后进行的，在进行性能测试设计时，需要分析哪些功能点要测试，哪些不测试。9

[ 本帖最后由 trapezia 于 2009-2-9 19:41 编辑 ]

jiang860718

能不能把完整的测试计划发上来看看啊？学习一下！

trapezia

回楼上的，因为目前项目还没有结项，所以暂时资料还不能发布，过一段时间我会发的。
另：如果关注测试计划，可以参考国际标准IEEE829，这个对测试计划的文档规范有很详细的描述。虽然事无巨细，但是确实有用。
************************************************************************************
我继续：
-->测试策划阶段分析哪些要测试哪些不要测试？
这个很重要，例如：一些功能，只有管理员在用，而系统管理员总共只有2个，且权限划分不同（其实很多系统的管理功能都是这样的）。还有必要测50用户并发操作吗？显然是没必要。这类功能可能对系统长时间稳定运行更关注（疲劳度测试）。
在策划阶段，需要对每个功能点进行分析。回答下列问题：需要进行性能测试吗？进行哪一类（疲劳的？并发的？大数据量的？速度的？）性能测试？关注哪些性能指标？不关心哪些性能指标？有没有潜在的测试风险（例如测试不完整？测试失败？）。
进行良好的取舍分析，可以有效的避免测试过程中的不必要劳动和目的性不明确的劳动。同时，这种分析也是一个对被测系统加深了解的过程。
-->应对需求不明确。
一个系统来做性能测试，对于PM，什么最可怕？我认为是甲方需求不明确。这有可能造成所得非所想，工期延误，纠纷甚至项目失败。还记得那个经典的“奥运售票系统”第一天崩溃和“欧洲图书馆”第一天崩溃的例子吧。其实说白了都是需求不明确造成的。用户会问：性能测试人员为什么不测试一下800万人并发访问时的服务器负载情况呢？实际情况是：没人让性能测试人员去测试800万人并发访问时的服务器负载情况，因为他们“认为”系统只会有800个人访问。
如何拿到合适的需求信息，是一个集合了管理、技术、文档、人性的复合型问题。需要PM，需求方，相关人员的配合。

[ 本帖最后由 trapezia 于 2009-1-16 11:15 编辑 ]

yetties2005

帮顶下。

星驰

直播中~~~顶！

trapezia

既然版主都来捧个人场，那我今天就多写一点。
2.测试设计
根据测试策划中对人员、设备、测试点、指标分析都的结果，相关人员就可以开始进行测试设计。测试设计的结果是《测试用例、记录》，《测试环境和配置》，《测试脚本和场景》，这些可以是独立的文档，也可以是一个文档。
-->测试脚本和测试场景
我在前面说了测试策划中对测试范围等的选择的重要性，现在，如果进行了良好的测试筛选，哪些部分需要进行哪种类型的测试，就可以直接生成测试用例和场景了。如果在写测试用例的过程中，你还在不断的问自己：“这部分到底还tmd需不需要测试啊？测多久？”那你应该反思第一部分的工作是否到位了。
还有一个需要重视的问题就是测试脚本和测试场景的区别。
测试脚本是录制或者编辑的，用于实现某个功能的脚本。而测试场景则是一些测试脚本通过特定方式组合在一起用于模拟大量用户实际行为的。
这两个有本质的不同，技术人员由于天性，在脚本录制和回放上经常投入大量的时间，对场景考虑的一般都不多，这就导致
--有可能脚本和场景之间有冲突（单独的脚本可以跑，几个脚本一起就跑不了。跑10分钟可以，跑10小时不行。）
--也可能导致脚本录制不全（等到执行的时候才发现某个功能没有录制）。
--更可能导致多余劳动（考虑了半天复杂的技术实现，后来发现场景中根本就没有相应要求。）
作为PM，应该在全局上对项目实际进展进行把握，及时的追踪每个技术人员执行的进度，防范技术人员在过多细节技术问题上纠缠而耽误了整体进度。定期组织小组讨论，对技术问题进行收集，对于影响进度的要及时处理。
测试脚本应该在设计阶段录制还是在执行过程中录制，这个有争议，我倾向于在设计阶段录制，但是确实在实际中执行过程中的修改也无法避免，但是设计阶段脚本考虑的多一些，可以避免时间和进度上的风险。

Zee

继续。

★星の金币

搬个板凳 坐着看~

trapezia

继续更新
*******************
在设计和计划阶段，除了基础的工作，还需要对一些细节进行规定。比如关心的哪些事务和哪些指标，关心的事务的命名。事务的命名很重要，在设计阶段搞定命名可以避免一些麻烦。据个例子：一个网站的10个页面中可能有7个检索，如果这些检索的业务都叫做“search”，那在整理报告的时候就很难分清哪个是哪个。对于事务的命名，放置的位置，一些规约性的东西，要提前约定好，因为脚本不一定是一个人开发的。需要保持团队之间的一致。一些大家都要使用的共性的东西，比如服务器IP，参数，公共函数，文件，数据文件等，PM要在项目的早期就开发好并编制使用方法文档，作为项目资源约定和规范下来，这个和开发项目有相似性。
如果项目需要进行配置管理和文档规范化，PM也要在计划和设计阶段搞定。
>从总体上来说，测试计划应包含哪些内容（欢迎大家指正，这只是我的看法）？
-概述 包含项目名称、编号、背景、系统概要说明。
-测试目标 包含 测试目标列表和相关术语解释
-测试范围 包含测试对象（软件）的功能分解和指标筛选，不需要测试的内容
-测试依据 测试的标准、文档依据
-测试环境 测试的概要环境介绍和资源需求
-其他技术和场景细节 例如关注指标的分析和解释
-进度计划 谁在什么时间完成什么工作，生成何种内容，有谁负责内容审查。
-关于进度和计划的其他细节

[ 本帖最后由 trapezia 于 2009-1-22 09:39 编辑 ]

archonwang

ipkh840122

学习学习

kevin_swpi

期待完结篇
上最终相关文档

spook2008

trapezia

很久没有更新了，过了一个很忙的年，给顶帖子送花的筒子们也拜个年吧。
******************************************************************************
3.测试执行
测试执行阶段，就是一干性能测试工程师在PM带领下，辛勤劳动，不顾白天黑夜的把测试设计内容转化为测试结果的阶段。
曾经有测试同仁跟我抱怨：“黑盒真是枯燥，还是白盒和性能测试好...”我的回答都是：“好个p。”黑盒测试枯燥可能不假，但是性能测试绝对更枯燥。比如说：黑盒测试可能1个礼拜就能见个新面孔，性能测试经常数周都和同一个功能在较劲；黑盒测试关心输入、步骤、输出，性能测试就要和很多个变态公司的产品的变态指标打交道，天天都是看着一堆枯燥的123456...；黑盒测试经常可以学到软件设计思想和业务流程，性能测试能学到的大多都是如果解决编号为XXXX的lr错误，如何从乱七八糟的数据中判断性能故障；最后也是最关键的一点，黑盒测试组经常有mm，性能测试组不提也罢...
综上，性能测试的枯燥指数和BT指数绝对在功能性测试之上，而测试执行阶段就是性能测试枯燥之最了。
经常在网上看到某大公司测试人员说：我们的测试都是自动化地，我们的PM又帅英语又好，我们用英语开着快乐的小组会议，愉快的写着脚本，一杯咖啡过后，结果出来啦...某些网络写手就是这样一边犯贱一边给大家传授错误思想。
以上这些论调哪些是错误的呢？
1.测试不需要都自动化，也不是所有功能[感谢yzylion的提醒，我查过了，你说的是对的]都要进行性能测试，资本家只关心成本和收益（别告诉我bill gates不是资本家）。真正要用性能测试一遍一遍折腾的功能也就那么一小部分，如果大老板让你把所有的功能不加设计都搞一遍性能，先戳他汽车轮胎然后辞职回家。
2.英语好就nb？如果是国内项目，能用中文命名事务就用中文，搞一堆乱七八糟命名方式弄出来的中英文混杂的报告，从又红又专年代过来的领导没有几个喜欢的。
3.小组会议很重要，但是肯定不愉快。如果每个人都按时保质完成任务，那PM搞定设计以后就可以回家休假，该种地的种地，该打渔的打渔。小组会议干什么？提问回答。哪几个问题呢？How？Why？When？
4.写脚本一点也不愉快。这拜如下几点所赐，①lr的易用性差②lr不开源③定位问题耗时太长④其他工具还不如lr⑤51testing的众牛人要么太忙，要么太抠...
5.一杯咖啡的时间什么也干不了，没有几个性能测试能在分钟级别的时间搞定。数小时、数十小时、数天更常见。跑5分钟出来的性能数据没什么价值。

[ 本帖最后由 trapezia 于 2009-2-8 20:49 编辑 ]

trapezia

在家更新一小段。
******************
测试执行确实是非常非常枯燥，同时也极其重要的阶段。再好的蓝图，只有经过建筑才能称为大厦；再好的方案，只有正确执行了才能得到结果。所以，执行性能测试的筒子要有泥瓦匠那样的吃苦耐劳品质和体力。
lr的执行路线是【脚本】--【场景】--【结果】--【分析报告】
脚本是技术人员开发的，但是由于智商过高的原因，很多大侠写的都是不可读代码，他们基本认为其他人不会再读和修改代码了，同时呢自己的代码也不会有错误。不过呢，多花点时间写写注释，改改结构，可以减少你在和mm约会的途中被叫回单位改代码的概率。
从脚本到场景的过程，执行人员需要按照设计文档要求对脚本进行组合，对监控指标进行添加。执行大仙们一般不重视保存场景，因为他们认为不会再第二次执行场景了，准保一次通过，再说再加一次windows啊网络啊was资源什么的也是学习过程。不过如果不想在夜里1点lr controller死机以后，头晕眼花的加那些指标的话，还是烦劳花1分钟保存一下场景并取个好名字。
场景设置完毕，很多人就开始兴高采烈的跑测试了，不过作为PM或者其他执行人员，最好还是再次确认一下场景监控指标的正确性和完整性，如果跑了72小时以后才发现有几个细小的指标忘加了，迎接大家的绝对是免费加班的好日子。
还有，lr8.1的中文版报告模块无法获取windows监控资源，知道的就算了，不知道的加以注意。

[ 本帖最后由 trapezia 于 2009-2-4 20:24 编辑 ]

AJan1000

LZ有才

Gray

情不自禁的顶一个

tester_ran250

很久没在论坛中溜达了，今天无意中在坛子中看到了楼主的大作，一口气看完，很赞

creatysun

顶一下，跟楼主颇有同感啊

小肥羊

刚接触性能测试和LoadRunner，LZ的这番总结给人的压力很大啊
很大