第五章执行测试

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,第五章执行测试,主要活动,分配测试时间,激发测试,标识出现的失效,2,分配测试时间,按照三个步骤进展,在要测试的系统之间分配测试时间,在进展可靠性增长测试的每个系统的功能,回归,和负载测试之间分配时间。,在进展负载测试的每个系统的操作模式之间分配测试时间。,对于进展确认测试的系统，所有的测试时间都被分配给负载测试。,3,在被测试系统之间分配时间,对于系统的当前版本，首先根据估计的风险，将测试时间在超系统之间分配时间。,对于其他的系统，时间的分配原那么上按照分配新的测试案例的比例分配测试时间。,分配案例的比率已经反映了被测试系统之间的相对重要性和新成分的多少。,例如：Fone Follower中，总共方案320小时的测试，40小时分配给超系统。以前的测试案例的分配为0.714和0.286。所以各个系统得到的时间为，产品200小时，操作系统80小时。,4,不同测试方式之间的再分配,如果系统进展可靠性增长测试,首先分配功能测试以与回归测试的时间。,剩下的时间分配给负载测试。,如果系统只进展确认测试，那么所有的时间都分配给了负载测试。,例如：Fone Follower中，超系统的40小时和操作系统的80小时，都分配给负载测试。对于产品测试的200小时，预计进展10小时的功能测试，估计进展10次每次1小时的回归测试。这样负载测试的时间分配为180小时。,5,在操作模式之间分配测试时间,在操作模式之间分配测试时间的根本规那么为：按照各种模式在实际使用中被使用的比例。,对于Fone Follower，,mode,Proportion,Super system,Product time,OS time,Peak hours,0.1,4,18,8,Primehours,0.7,28,126,56,Off hours,0.2,8,36,16,6,激发测试1,SRE,的测试需要在系统的单元经过了测试或,Verification，,并且被集成后使得系统的各个操作都可以完成。,一般按照以下的顺序测试系统，主要的原因是：对于测试结果信息的需求的先后顺序。也可以采取其他的顺序。,采办组件,产品和变体,超系统,7,激发测试2,对于单个系统的测试顺序：,功能测试负载测试程序有改动后回归测试,功能测试：从所有新测试案例和以前版本的回归测试案例集合中随机选择包含了所有的关键性操作的测试案例。,负载测试：按所分配的时间比例，使用适宜的测试过程，调用每个操作模式。,回归测试：调用所有功能测试的测试案例，或从中选择一个子集包括所有的关键操作。,8,案例选择,总共执行的案例的数量是由允许的时间决定的。,案例是按照测试操作剖面的概率，以随机的顺序，在随机时刻被激发的。,对于负载测试，案例的选择是可重复的。,一个案例被选择并执行之后，可能又被执行。原因在于：负载测试中，案例的执行数目远远大于允许的案例数目，且间接输入变量有一定的影响。,对于功能测试或回归测试，案例的选择是不可重复的。,一个案例只会被执行一次。原因在于：间接变量的影响被严格控制，同一个案例执行两次而出现不同的行为的可能性要远远小于两个不同案例的执行。,9,重复运行,运行重复的主要目的,增加有关失效的信息。,确认失效错误已经消除了。,失效的重现是必要的。为了能够重现，我们必须纪录每个运行的相关信息,案例，激发的时间，操作模式，环境变量，,10,操作选择,在执行测试的过程中，选择操作的时候需要的是,稳定,。,稳定和不稳定的例子：,操作,A:0.7；,操作,B:0.3。,顺序1：,ABAABAAABA,顺序2：,AAAAAAABBB,顺序,稳定(1),不稳定(2),1,1,1,2,0.5,1,3,0.67,1,4,0.75,1,5,0.6,1,6,0.67,1,7,0.71,1,8,0.75,0.88,9,0.67,0.78,10,0.7,0.7,11,找出系统失效,找出系统失效所需要做的事情,分析测试输出，以找到行为偏离(,deviation),确定哪些偏离是失效,估计失效是什么时候发生的,确认失效的严重程度等级,12,分析测试输出，确定偏离,偏离(,deviation),是指系统的行为和原来预期的有偏差：通信失效，非法内存引用，死锁，,可以通过自动化的方法来检测系统的失效行为。,可以使用特定的工具来完成失效的自动检测。,也可以在代码中插入断言来完成失效的自动检测。,也可以设计内部状态审计程序或者外部结果检测器来检测失效行为。,但是，一定程度的人工检测是必须的,可能会有难以预先估计的错误出现。,由于负载测试中，运行的数量很多，有些不能自动监测的失效会被忽略。,13,不算偏离的行为偏差,通常不计算程序行为在性能上的偏差。,级联偏离不计算：一个偏离可能引起其他的偏差。此时只应该计算一个偏离。,即使开场的时候多计算了，如果发现他们是相关的就应该合并。,14,判断哪些偏差是失效1,确定偏离是否失效需要人工的参与。,但是，可以一些很严重的错误可以通过自动的方式检测到。,Process craches,incomplete transactions.,需要根据不同的情况判断一个偏离是否失效。,15,判断哪些偏差是失效2,容错系统,通常偏离不算失效。但是，如果容错系统不能够禁得起本来应该容忍的偏离，就是错误。,故障，麻烦，修改和变更报告不一定是错误,用户报告的故障，事件不一定是错误。,可能是人为错误，希望有新的功能，或者文档不够清晰。,16,判断哪些偏差是失效3,当系统没有违反书面标准，但是用户不满意时,大局部原因是因为标准没有描述好，或者书写不清晰。一般认为这样的东西是一种失效。除非成认失效会引起大的损失。,一般不考虑单个用户的不满意。,成心不解决的失效实际上可以看作是需求变化。,如果失效没有引起用户不满意，并且解决这个失效的代价比较大，那么可以考虑不消除这个失效。,这样的“失效可以不算是失效。,17,判断哪些偏差是失败4,关于同一个错误引起的失效,在确认测试中，一个错误引起的多个失效需要被分别计算失效个数。,在可靠性增长测试中，这些失效应该被计算为一个失效。,将一个错误引起的多个实效分别计算得到的失效强度表示的是客户的体验。而将多个失效合并为一个计算，得到的是修改后的,FI，,也可以认为是开发者的体验。,18,确定失效发生的时间1,使用当初确定FIO的度量方式来记录失效发生的“时间。,如果使用时间来表示FIO的话，那么我们需要用执行时间来记录失效何时发生。,通常，我们记录错误发生时间是用的日历时间，因此我们需要将他们换算成为执行时间。最后还需要将他们重新换算成为日历时间。,19,纪录失效发生的时间2,对于确认测试，需要纪录失效发生确实切时间点。,而在可靠性增长测试中，你应该尽量纪录失效发生的时间点，但是有时你也可以记录一个时间段中发生的失效个数。,测试过程中，用于错误定位和改正确认的时间不计算在内。,20,时间之间的换算,一个软件的执行时间是非常难以准确计算的。但是我们可以通过某些指标来估计计算机的利用率：比方使用这个系统的用户数。,通过估算利用率，我们就可以从时钟时间得到执行时间。,考虑的执行时间是指执行被测试的软件的执行时间。,对于分布式的软件，最好使用某种自然单位来度量可靠性。不得不选择时间时，可以考虑使用一个主要处理器的运行时间来估算。,21,时间换算的例子,从执行时间到时钟时间的转换,Failure,Execution,Aputer utilization,Adjusted time,1,0.2,0.4,0.5,2,0.6,0.4,1.5,3,1.2,0.4,3,22,估算计算机利用率的例子,利用用户个数估算利用率,10,am,发生的失效和2,pm,Hour,Number of User,utilization,Hour,Number of user,utilization,8-9,am,16,0.32,1-2,pm,36,0.72,9-10,am,36,0.72,2-3,pm,40,0.8,10-11,am,40,0.8,3-4,pm,40,0.8,11-12,am,36,0.72,4-5,pm,36,0.72,12-1,pm,20,0.4,5-6,pm,24,0.48,23,失效信息的记录,信息记录应该标准化，并且包含尽量多的信息，使得人员的变换不至于引起信息的丧失。信息可以包括：,失效严重程度类；,具体的失效发生时间不是发现时间,失效现象，但是的运行环境,是否可以重现，以与如何重现,发现失效可能是在程序运行时刻，也可能是在1-2天后分析数据的时候。,24,特殊情况,对于多配置软件的测试。,确认失效发生时间的不确定性。,处理具有多个版本的系统。,25,对于多配置软件的测试,两种可能的多配置情况,单机软件，但是可能运行在不同的计算机上。,分布式系统，而硬件系统的平台可能不同。,根本的方法是：,运行多个版本，并且将这些版本运行时刻的失效排列起来。失效发生的时间时这些版本的时间的总和。,如果不同的版本之间有不同的运行速度，那么可以以一个版本为基准，将其他版本的时间进展相应的转换。,26,处理多配置软件的测试例子,多配置软件的时间累加,time,Event,Config.A,Config.B,Failure times,8:00,Start A,0,8:30,Start B,30,0,9:00,Failure 1,60,30,90,9:20,Failure 2,80,50,130,27,不同版本处理速率不同时,Configure B,的处理强度是,Configure A,的2倍,time,Event,Config.A,Config.B,调整后的,Config.B,Failure times,8:00,Start A,0,8:30,Start B,30,0,0,30,9:00,Failure 1,60,30,60,120,9:20,Failure 2,80,50,100,180,28,处理失效发生时间的不确定性的问题1,因为记录的数据太少，或者数据记录后保存，汇报的问题，我们难以确定某些失效发生的准确时刻。但是我们可以确定这些失效在某个时间段内发生。,完全放弃这些数据将降低估算和预测的准确度。存在一个方法来利用这些数据和其他准确的失效数据进展比较准确的估算和预测。,29,处理失效发生时间的不确定性的问题2,假设失效数据记录中，有局部失效只记录了发生的时间段。使用随机数给这些失效确定一个假设的时刻。然后按照这样的数据进展数值估算。,30,例子,不确定性的例子,Event,Time,Random Number,Adj.Factor,Assigned time,Time Interval,Start,0,0,Fail 1,30,30,30,Fail 2,90-140,67557,0.0005,123.8,93.8,Fail 3,180,180,86.2,Stop,240,240,Start,240,240,Fail 4,240-440,26,446,0.0002,292.9,112.9,Fail 5,240-440,97,159,0.0002,434.3,141.4,Stop,480,480,31,当多个失效被记录为同时发生,此时会使得对于系统,FI,的估算过于悲观：在零时