第五章-执行测试PPT课件

.,1,执行测试,赵建华南京大学计算机系,.,2,主要活动,分配测试时间激发测试标识出现的失效,.,3,分配测试时间,按照三个步骤进行在要测试的系统之间分配测试时间在进行可靠性增长测试的每个系统的功能,回归,和负载测试之间分配时间。在进行负载测试的每个系统的操作模式之间分配测试时间。对于进行确认测试的系统，所有的测试时间都被分配给负载测试。,.,4,在被测试系统之间分配时间,对于系统的当前版本，首先根据估计的风险，将测试时间在超系统之间分配时间。对于其他的系统，时间的分配原则上按照分配新的测试案例的比例分配测试时间。分配案例的比率已经反映了被测试系统之间的相对重要性和新成分的多少。例如：FoneFollower中，总共计划320小时的测试，40小时分配给超系统。以前的测试案例的分配为0.714和0.286。所以各个系统得到的时间为，产品200小时，操作系统80小时。,.,5,不同测试方式之间的再分配,如果系统进行可靠性增长测试首先分配功能测试以及回归测试的时间。剩下的时间分配给负载测试。如果系统只进行确认测试，那么所有的时间都分配给了负载测试。例如：FoneFollower中，超系统的40小时和操作系统的80小时，都分配给负载测试。对于产品测试的200小时，预计进行10小时的功能测试，估计进行10次每次1小时的回归测试。这样负载测试的时间分配为180小时。,.,6,在操作模式之间分配测试时间,在操作模式之间分配测试时间的基本规则为：按照各种模式在实际使用中被使用的比例。对于FoneFollower，,.,7,激发测试（1）,SRE的测试需要在系统的单元经过了测试或Verification，并且被集成后使得系统的各个操作都可以完成。一般按照以下的顺序测试系统，主要的原因是：对于测试结果信息的需求的先后顺序。也可以采取其他的顺序。采办组件产品和变体超系统,.,8,激发测试（2）,对于单个系统的测试顺序：功能测试负载测试（程序有改动后）回归测试功能测试：从所有新测试案例和以前版本的回归测试案例集合中随机选择（包含了所有的关键性操作的测试案例）。负载测试：按所分配的时间比例，使用合适的测试过程，调用每个操作模式。回归测试：调用所有功能测试的测试案例，或从中选择一个子集（包括所有的关键操作）。,.,9,案例选择,总共执行的案例的数量是由允许的时间决定的。案例是按照测试操作剖面的概率，以随机的顺序，在随机时刻被激发的。对于负载测试，案例的选择是可重复的。一个案例被选择并执行之后，可能又被执行。原因在于：负载测试中，案例的执行数目远远大于允许的案例数目，且间接输入变量有一定的影响。对于功能测试或回归测试，案例的选择是不可重复的。一个案例只会被执行一次。原因在于：间接变量的影响被严格控制，同一个案例执行两次而出现不同的行为的可能性要远远小于两个不同案例的执行。,.,10,重复运行,运行重复的主要目的增加有关失效的信息。确认失效（错误）已经消除了。失效的重现是必要的。为了能够重现，我们必须纪录每个运行的相关信息案例，激发的时间，操作模式，环境变量，,.,11,操作选择,在执行测试的过程中，选择操作的时候需要的是稳定。稳定和不稳定的例子：操作A:0.7；操作B:0.3。顺序1：ABAABAAABA顺序2：AAAAAAABBB,.,12,找出系统失效,找出系统失效所需要做的事情分析测试输出，以找到行为偏离(deviation)确定哪些偏离是失效估计失效是什么时候发生的确认失效的严重程度等级,.,13,分析测试输出，确定偏离,偏离(deviation)是指系统的行为和原来预期的有偏差：通信失效，非法内存引用，死锁，可以通过自动化的方法来检测系统的失效行为。可以使用特定的工具来完成失效的自动检测。也可以在代码中插入断言来完成失效的自动检测。也可以设计内部状态审计程序或者外部结果检测器来检测失效行为。但是，一定程度的人工检测是必须的可能会有难以预先估计的错误出现。由于负载测试中，运行的数量很多，有些不能自动监测的失效会被忽略。,.,14,不算偏离的行为偏差,通常不计算程序行为在性能上的偏差。级联偏离不计算：一个偏离可能引起其他的偏差。此时只应该计算一个偏离。即使开始的时候多计算了，如果发现他们是相关的就应该合并。,.,15,判断哪些偏差是失效（1）,确定偏离是否失效需要人工的参与。但是，可以一些很严重的错误可以通过自动的方式检测到。Processcraches,incompletetransactions.需要根据不同的情况判断一个偏离是否失效。,.,16,判断哪些偏差是失效（2）,容错系统通常偏离不算失效。但是，如果容错系统不能够禁得起本来应该容忍的偏离，就是错误。故障，麻烦，修改和变更报告不一定是错误用户报告的故障，事件不一定是错误。可能是人为错误，希望有新的功能，或者文档不够清晰。,.,17,判断哪些偏差是失效（3）,当系统没有违反书面规范，但是用户不满意时大部分原因是因为规范没有描述好，或者书写不清晰。一般认为这样的东西是一种失效。除非承认失效会引起大的损失。一般不考虑单个用户的不满意。故意不解决的失效实际上可以看作是需求变化。如果失效没有引起用户不满意，并且解决这个失效的代价比较大，那么可以考虑不消除这个失效。这样的“失效”可以不算是失效。,.,18,判断哪些偏差是失败（4）,关于同一个错误引起的失效在确认测试中，一个错误引起的多个失效需要被分别计算失效个数。在可靠性增长测试中，这些失效应该被计算为一个失效。将一个错误引起的多个实效分别计算得到的失效强度表示的是客户的体验。而将多个失效合并为一个计算，得到的是修改后的FI，也可以认为是开发者的体验。,.,19,确定失效发生的时间（1）,使用当初确定FIO的度量方式来记录失效发生的“时间”。如果使用时间来表示FIO的话，那么我们需要用执行时间来记录失效何时发生。通常，我们记录错误发生时间是用的日历时间，因此我们需要将他们换算成为执行时间。最后还需要将他们重新换算成为日历时间。,.,20,纪录失效发生的时间（2）,对于确认测试，需要纪录失效发生的确切时间点。而在可靠性增长测试中，你应该尽量纪录失效发生的时间点，但是有时你也可以记录一个时间段中发生的失效个数。测试过程中，用于错误定位和改正确认的时间不计算在内。,.,21,时间之间的换算,一个软件的执行时间是非常难以准确计算的。但是我们可以通过某些指标来估计计算机的利用率：比如使用这个系统的用户数。通过估算利用率，我们就可以从时钟时间得到执行时间。考虑的执行时间是指执行被测试的软件的执行时间。对于分布式的软件，最好使用某种自然单位来度量可靠性。不得不选择时间时，可以考虑使用一个主要处理器的运行时间来估算。,.,22,时间换算的例子,从执行时间到时钟时间的转换,.,23,估算计算机利用率的例子,利用用户个数估算利用率10am发生的失效和2pm发生的失效之间的执行时间间隔是0.8+0.72+0.4+0.72=2.64小时,.,24,失效信息的记录,信息记录应该标准化，并且包含尽量多的信息，使得人员的变换不至于引起信息的丢失。信息可以包括：失效严重程度类；具体的失效发生时间（不是发现时间）失效现象，但是的运行环境是否可以重现，以及如何重现发现失效可能是在程序运行时刻，也可能是在1-2天后分析数据的时候。,.,25,特殊情况,对于多配置软件的测试。确认失效发生时间的不确定性。处理具有多个版本的系统。,.,26,对于多配置软件的测试,两种可能的多配置情况单机软件，但是可能运行在不同的计算机上。分布式系统，而硬件系统的平台可能不同。基本的方法是：运行多个版本，并且将这些版本运行时刻的失效排列起来。失效发生的时间时这些版本的时间的总和。如果不同的版本之间有不同的运行速度，那么可以以一个版本为基准，将其他版本的时间进行相应的转换。,.,27,处理多配置软件的测试例子,多配置软件的时间累加,.,28,不同版本处理速率不同时,ConfigureB的处理强度是ConfigureA的2倍,.,29,处理失效发生时间的不确定性的问题（1）,因为记录的数据太少，或者数据记录后保存，汇报的问题，我们难以确定某些失效发生的准确时刻。但是我们可以确定这些失效在某个时间段内发生。完全放弃这些数据将降低估算和预测的精确度。存在一个办法来利用这些数据（和其他精确的失效数据）进行比较精确的估算和预测。,.,30,处理失效发生时间的不确定性的问题（2）,假设失效数据记录中，有部分失效只记录了发生的时间段。使用随机数给这些失效确定一个假设的时刻。然后按照这样的数据进行数值估算。,.,31,例子,不确定性的例子,.,32,当多个失效被记录为同时发生,此时会使得对于系统FI的估算过于悲观：在零时间段内发生了多个错误。最好做出如下调整：假设在ti时刻与ti+k+1时刻有k个失效被记录为同一时刻发生的。在这两