软件测试论坛

 找回密码
 软件测试论坛注册页
查看: 394|回复: 1

战略性能探索性测试----数据分析探索之TPS与响应时间的藕断丝连(C系数)

[复制链接]
发表于 2013-5-9 10:49:49 | 显示全部楼层 |阅读模式
软件测试工程师就业班马上开班
     随记前言   
    越来越觉得使用的技术和分析手段没有本质的改变,都快把自己比作体力劳动者了,连销售都抱怨我们能给出的东西一成不变,作为一个高产量项目工作以及管理者,却一直无法写一些有趣的技术观点,一直都觉得惭愧,牛人太多,前辈太多,很多东西都总结的差不多而且一大部分都写的很有见地,也让我学习到很多。但是,真的就没有什么可以让总结发表观点的空间了么,当然不是,因为项目特别多,技术特别多,问题特别多。
        自己是个美剧迷,除了喜欢科幻、冒险、剧情类,唯一能让我对工作有所启发的就是《豪斯医生》,不仅迷恋他特立独行的性格,最让我着迷的是他的诊断科,一个团队利用一切手段和知识储备对病例进行诊断常规甚至暴力治疗。联想到我们丰富的项目库,其实每一份报告都是一份病历薄,有手段、有数据、有现象、有分析,因此,在今年初始,我尝试性的对以往项目报告进行整理总结,尝试发现一些规律性的现象,然后就后悔了,因为我发现这是一个巨大狂死脑细胞的行为,呵呵,架构不同,数据不同,实现方式不同造就的就是差异性太大,多么希望可以形成一份通用案例库,就像我感冒了知道吃什么药一样,不用每次都做个全身体检。一边缓慢的进行案例数据总结整理,另一方面重新研究之前的流程管理模型,发现一直用的模型太老套,性能测试是一个循环性的过程,这个没错,但是老绕着圈子做事,跟拉磨没区别了,不探索、不尝试思考新的东西,怎么进步。于是,更改了新的项目流程模型,如图1:

                                                                  
       这个流程模型是一个比较大的模型,不仅覆盖客户的各类项目,而且覆盖公司的人员培养,一直以来我们在工作模型中只是把业务和信息放在一个相对次要的位置,但是通过多年的性能诊断类项目和综合运维监控项目,我一直认为业务和信息是最重要的,业务了解的是否足够的透彻(此处的业务不仅仅是业务本身,还涉及业务的技术实现)以及各类信息是否了解透彻都会最终影响到数据的分析、瓶颈的分析乃至报告的准确性。另外这个模型中我最喜欢的是“战略性探索”,之所以叫战略性探索,是因为没想给这个探索限定一个框架,鼓励工程师进行“天马星空”式的探索,当然这个探索不能偏离性能诊断本身,这个概念我参考的是X模型,勉强算作一位科学类技术人员,我们对未知或者已有的现象和数据都越来越缺乏探索的主动性。当然这个模型还在尝试,它可能会给我们带来新的东西,也可能会因为其执行的风险导致流产,不管怎样,这个模型我们已经介入今年的项目中,从最不起眼的最常见的指标、数据、现象入手,一点点的去实践它,维护它。为了尽可能的覆盖其可使用的环境,采用雷达图模式展现,初次设计完善后,给team讲解顺便起名,懒到家的我们就暂时叫它,雷达模型,英文简写,R模型(Radar),希望的它能给我们带来一些新的有趣的东西。(待R模型可以按我的目标正确运作时,我会转为它写一篇说明,此处不累述)
        题外话,期间徒弟在对我的想法提出疑问,“这么多年了,国内国外的相关文章一大堆,我们探索可能都是别人研究烂的东西,何况各类技术模型都是都这么多年了,好多都现成的,未知的东西怎么探索”,我给他说了一个真实的故事,“高中时期,听身边的朋友说,他们学校出了一个牛人,该牛人在学习生物时,对蜜蜂筑巢现象着迷,潜心研究,写了一篇论文《蜂巢与液体表面张力》,该文章解释了蜂巢六棱形是怎么形成的,该论文改变了一直以来科学家们认为蜜蜂会建造六棱形的观点,并填补了该方面的知识。”蜜蜂、六棱形,建筑学,生物学这些研究的时间比性能诊断测试时间要长,甚至比计算机研究还长,我们不是技术牛人,这样做的是想,还在我们有精力和意愿的时候,多去钻研思考,使自己的本质工作更深刻更有深度更有思想更加科学。
       正文
       絮絮叨叨了半天,终于说明了下这篇文章要做什么,在刚尝试性的去做战略性探索性测试时,我决定从原有成熟的指标入手是一个很好的切入点,因为各类案例数据分析知识全面。TPS和响应时间是大家都快说烂了得两个指标,有的客户把TPS当做系统处理能力的主要评价指标,有的客户把响应时间当做主要评价指标,当然评测一个系统处理能力不能单看这两个指标,系统的处理能力需要的是一组综合性的考量指标。不过单从TPS和响应时间去思考,一直都有人问,这两个指标到底有没有关系,很多前辈老师,都做过形象的描述,这两个指标之间没有必要的关系。TPS是系统“娘胎里”带出来的,最简而易懂的就是高速路收费例子,收费站是既定的,不管来多少车,每秒通过的车数量的一定的,变化的是车辆的通过收费站的时间。从这个举例来看,这两的数据的确没有半毛钱关系。
        一直以来对数据的总结和整理,都会想这两个指标真的没有关系么,每次做项目,看到它们的出现,这个想法就会出现,后来我改变思路,与其说他们没有关系,不如所它们一起能反应出什么。于是,我把这个疑问带入到R模型中的“战略性探索测试”类别中的“数据分析探索”,尝试发现他们的可以反应什么。
       下面是一组真实的数据:
                                                
用户数
TPS
90%响应时间(秒)
1
10
0.107
10
65
0.175
20
85
0.334
40
84
0.684
80
86
1.176
100
90
1.319
140
89
1.886
220
91
2.881
380
87
5.025


              TPS变化图:
                                                               

         响应时间变化图
                                                  

        当我们看到这组数据时,很直观的看的到,TPS在20u并发开始就趋于一个稳定值,如果不考虑响应时间,单从TPS来看,没错该系统处理该业务在20u时就趋于达到了其的处理能力最大值,这样说没有错,因为数据是这么反应的。但是,这个是真的反应系统的处理能力么,这里可能会对系统的处理能力的概念存有差异,这样的一种评估理论忽略了系统可以良好的支撑用户的能力,因为从响应时间看,及时TPS到了最大值,响应时间在220u并发时,为2.8s,这个响应时间依然在优良范围内。如果为该系统抱不平的话,也可以分析为该在220u是处理能力依然保持良好,然后反对意见又出来了,TPS在20u时就不增加了。
        这样的异议,在不同的项目和客户都有反应,于是出现,以开发为主导的客户会以TPS为主参考响应时间为依据,因为他们的更关注的是娘胎里带出的指标,以业务为主导的客户会以响应时间为主参考TPS为依据,因为他们更关注用户体验。这两种评估方式单从评估来讲都没问题,但是个人更偏向以TPS为主参考响应时间,毕竟正常情况下响应时间的增加时因为TPS所限制,而且是否要对系统进行开刀调优理应要以更能体现系统本质内在的指标为参考依据。
         那么TPS和响应时间存在这样一种藕断丝连的隐晦联系就不能反映出什么吗?它们之间的联系会不会体现出一种规律,并且可以以数据或者曲线的形式直接表现出来来说明什么?于是,根据真实项目搜集回来的数据来观测,我发现可以根据这两个指标的计算,可以得出一个系数,这个系数的分布是存在各个场景中,它们的曲线图的走向是相似。其实计算过程很简单,通常我们认为TPS高,响应时间低,说明系统处理能力很好,这个类似我们买东西时说的“性价比”这个概念,于是把TPS当做这个功能,响应时间当做价格,做除法,于是根据上面举例的书得出下面的计算结果和曲线1:

探索性数据
数据统计
用户数
C系数
1
93.458
10
371.43
20
254.49
40
122.81
80
73.129
100
68.234
140
47.19
220
31.586
380
17.313
              
                                                                                          曲线一
         
         在其他的场景中也可以计算出这样的曲线:


          其实这是个显而易见的规律,在性能没有出现异常情况时,TPS趋于稳定时,随用户数增加,响应时间增长,这个系数值曲线肯定会出现一个拐点。
          有意思的情况出来了,仔细观察曲线一以及它的系数结果,发现曲线拐点所对应的支撑用户数是10u,而不是根据TPS曲线图得出来的20u。

          那么这样一个拐点或者现象可以反应出什么,系统的处理能力?我想不能这么简单的看,因为TPS还能增加,而且响应时间也很小。看做这个系统的“性价比”,也不能,因为测试里没这个概念,呵呵。
          在思考这个现象或者系数曲线能作为什么参考标准的过程中,我发现,一直以来,我们通常会把TPS当做是面向系统的一个指标,而响应时间当做是面向用户的一个指标。那么TPS与响应时间的计算得到的系数能否是可以作为同时面向系统和客户的双向评估指标,我认为是可以的,因为在这个拐点系数下,不仅系统可以赢有余力的处理事务,同时用户也可以得到很快的响应。于是,我给这个系数起名为“舒适度系数”,英文comfort,简称“C系数”。
          “C系数”一眼看上去,很容易会产生它可以评价系统的处理能力的错觉,因为随着用户数的增加,曲线一直上升,拐点越靠后出现,所能反应的是TPS增加的幅度要大于响应时间增加的幅度,这样的确可以间接反应系统处理能力,但是正如上面真实数据中体现的,显然不能简单认为10u时,系统达到最大处理能力或者最佳处理能力。
          所以,我个人认为“C系数”可以作为类似于“最佳用户体验”这样感性方面的指标来反应在拐点所对应的用户数时,既能保证系统可以赢有余力的轻松处理事务,用户也可以最佳的用户体验,于是暂且认为“C系数”可以反应“最佳服务能力”吧。
           结束语          至于“C系数”是否可以作为一个参考依据可进入性能评估范围内,它所反映的现象能为系统的评测调优带来多少帮助,有待于后续的验证和判断。
         当然 如果我的思考出发点是错误的,欢迎大家来喷!呵呵

ISTQB
发表于 2014-12-16 17:51:22 | 显示全部楼层
软件测试工程师就业班马上开班
学习.. 支持楼主
ISTQB

本版积分规则

Archiver|手机版|小黑屋|领测软件测试网 ( 京ICP备10010545号-5 )

GMT+8, 2020-1-22 14:05 , Processed in 0.174945 second(s), 16 queries , Xcache On.

Powered by Discuz! X3

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表