设计篇2

第20回 测试风险的管理

<script type="text/javascript"></script><script class="blogstory"></script>

        测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：

1. 质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；
2. 测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；
3. 需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；
4. 质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；
5. 测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等；
6. 测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；
7. 有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；
8. 回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。

       前面三种风险是可以避免的，而4）至7）的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。

       针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

• 测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查；
•  有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险；
•  有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险；

为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：

• 在做资源、时间、成本等估算时，要留有余地，不要用到100%；
• 在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中；
• 对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍能可以继续下去；
• 制定文档标准，并建立一种机制，保证文档及时产生；
•  对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换；
• 对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。

要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。


参考： 测试执行中非常有效的策略


补充材料： 关于风险管理的方法

风险管理，一般可以分成5个步骤，即风险识别、风险分析、风险计划、风险控制以及风险跟踪。

1. 风险识别
        风险识别是试图用系统化的方法来确定威胁项目计划的因素。识别方法包括风险检查表、头脑风暴会议、流程图分析以及与项目人员面谈等。前两种方法是比较常用的。风险检查表建立在以前开发类似的项目中曾经遇到的风险基础上，比如开发时利用了某种技术，那么有过这种技术开发经验的个人或者项目组就能指出他们在利用这种技术时遇到过的问题；头脑风暴会议可以围绕项目中有可能会出现哪些范围、进度、成本和质量方面的问题这一议题展开，讨论和列举出项目可能出现的风险。对不同的项目应该具体问题具体分析，识别出真正可能发生在该项目上的风险事件。

2. 风险分析
         风险分析可以分为定性风险分析和定量风险分析。定性风险分析是评估已识别风险的影响和可能性的过程，以根据风险对项目目标可能的影响对风险进行排序。它在明确特定风险和指导风险应对方面十分重要。定量风险分析是量化分析每一风险的概率及其对项目目标造成的后果，同时也要分析项目总体风险的程度。
不同的风险发生后对项目造成的影响各不相同，主要有以下3个方面需要考虑：

• 风险的性质，即风险发生时可能产生的问题；
• 风险的范围，即风险的严重性及其总的分布；
• 风险的时间，即何时能感受到风险及风险维持多长时间。

据此确定风险估计的加权系数，得到项目的风险估计。然后通过对风险进行量化、选择和排序，可以知道哪些风险是必须要应对，哪些是可以接受，哪些是可以忽略。进行风险管理应该把主要精力集中在那些影响力大、影响范围广、概率高以及可能发生的阶段性的风险上。

3. 风险计划
制定风险行动计划，应考虑以下部分：责任、资源、时间、活动、应对措施、结果、负责人。建立示警的阈值是风险计划过程中的主要活动之一，阈值与项目中的量化目标紧密结合，定义了该目标的警告级别。
该阶段涉及到参考计划、基准计划和应急计划等不同类型的计划。

• 参考计划是用来与当前建议进行比较的参考点。
• 基准计划是建议的计划编制基础，是提出的项目实施的起始位置。
• 应急计划是建立在基准计划基础上的建议补充计划，包括启动意外情况应对措施的触发点。

在这一阶段有巩固与解释、选择与细化、支持与说服等特定的任务。

4. 风险控制方法
主要采用的应对方法有风险避免、风险弱化、风险承担和风险转移等。

• 风险避免：通过变更软件项目计划消除风险或风险的触发条件，使目标免受影响。这是一种事前的风险应对策略。例如，采用更熟悉更成熟的技术、澄清不明确的需求、增加资源和时间、减少项目工作范围、避免不熟悉的分包商等。
• 风险弱化：将风险事件的概率或结果降低到一个可以接受的程度，当然降低概率更为有效。例如，选择更简单的开发流程、进行更多的系统测试、开发软件原型系统、增加备份设计等。
• 风险承担：表示接受风险，不改变项目计划(或没有合适的策略应付风险)，而考虑发生后如何应对。例如制定应急计划、风险应变程序，甚至仅仅进行应急储备和监控，发生紧急情况时随机应变。在实际中，如软件项目正在进行中，有一些人要离开项目组，可以制定应急计划，保障有后备人员可用，同时确定项目组成员离开的程序，以及交接的程序。
• 风险转移：不去消除风险，而是将软件项目风险的结果连同应对的权力转移给第三方(第三方应知晓有风险并有承受能力)。这也是一种事前的应对策略，例如签订不同种类的合同，或签订补偿性合同等。

5. 风险跟踪
     在风险受到控制以后，我们要及时进行跟踪，做好风险跟踪：

• 监视风险的状况，例如风险是已经发生、仍然存在还是已经消失；
• 检查风险的对策是否有效、跟踪机制是否在运行；
• 不断识别新的风险并制定对策。

可以通过以下几种方法进行有效的风险跟踪：

•  风险审计：项目管理员应帮助项目组检查监控机制是否得到执行。项目经理应定期进行风险审核，尤其在项目关键处进行事件跟踪和主要风险因素跟踪．以进行
• 风险的再评估；对没有预计到的风险制定新的应对计划。
•  偏差分析：项目经理应定期与基准计划比较，分析成本和时间上的偏差。例如，未能按期完工、超出预算等都是潜在的问题。
• 技术指标分析：技术指标分析主要是比较原定技术指标和实际技术指标差异，例如，测试未能达到性能要求等。

第21回 测试用例设计方法的综合运用

<script type="text/javascript"></script><script class="blogstory"></script>

测试用例是按一定的顺序执行的与测试目标相关的测试活动的描述，是确定“怎样”测试。测试用例被看作是有效发现软件缺陷

的最小测试执行单元，也被视为软件的测试规格说明书。在测试工作中，测试用例的设计是非常重要的，是测试执行的正确性、有效性的基础。如何有效地设计测试用例，一直是测试人员所关注的问题；设计好测试用例，也是保证测试工作的最关键的因素之一。

设计测试用例，也分为白盒设计方法和黑盒设计方法。白盒设计方法又分为逻辑覆盖法和基本路径覆盖法，或者分为语句覆盖、判定覆盖、条件覆盖方法，而黑盒设计方法分为等价类划分法、边界值划分法、错误推测法、因果图法等。在实际测试用例设计过程中，不仅根据需要、场合单独使用这些方法，常常综合运用多个方法，使测试用例的设计更为有效。

 

1．判定-条件覆盖方法

判定-条件覆盖方法就是将两种白盒设计方法“判定覆盖”和“条件覆盖”结合起来的一种设计方法，它所设计的测试用例是判定覆盖的设计的测试用例和条件覆盖设计的设计的测试用例的交集，即设计足够精巧的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果也至少执行一次。

举个例子，源程序是：

Dim a,b as Integer

Dim c as Double

If （a > 0 and b > 0） Then

c = c/ a

End If

If （a>1 or c>1） Then

c=c+1

End If

c=b+c

则用两个测试用例（如表1）来覆盖了两个判定“P1=（a > 0 and b > 0）”和“P2 =（a>1 or c>1）”和四个条件“C1= a > 0”、“C2= b > 0”、“C3= a>1”和“C4= c>1”。

表1 判定-条件覆盖的测试用例

测试用例	具体取值条件	取值条件	判定条件
输入：a=2，b=1，c=6 输出：a=2，b=1，c=5	a>0，b>0，a>1，c>1	C1, C2, C3, C4 = True	P1, P2= True
输入：a=-1，b=-2，c=-3 输出：a=-1，b=-2，c=-5	a<=0，b<=0，a<=1，c<=1	C1, C2, C3, C4 = False	P1, P2= False

 

2．条件组合覆盖

条件组合覆盖的基本思想是：设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次，条件覆盖是简单地要求每个条件出现“真”与“假”两种结果，而条件组合覆盖是让这些结果的所有可能组合都至少出现一次。

按照条件组合覆盖的基本思想，针对8种组合条件，来设计所有能覆盖这些组合的设计用例，如表2所示。即使我们用四个测试用例覆盖了所有8种组合条件，但还不能保证所有的路径被执行，如这个例子少了一种路径，即P1= True, P2= false。

  表2 条件组合覆盖的测试用例

测试用例	覆盖条件	覆盖组合
输入：a=2，b=1，c=6 输出：a=2，b=1，c=5	① C1=True, C2=True, ⑤ C3=True，C4=True	P1=True, P2=True
输入：a=2，b=-1，c=-2 输出：a=2，b=-1，c=-3	② C1=True, C2=false, ⑥ C3=True，C4=false	P1=false, P2=True
输入：a=-1，b=2，c=3 输出：a=-1，b=2，c=6	③ C1=false, C2=True, ⑦ C3=false，C4=True	P1=false, P2=True
输入：a=-1，b=-2，c=-3 输出：a=-1，b=-2，c=-5	④ C1=false, C2=false, ⑧ C3=false，C4=false	P1=false, P2=false

 

3. 等价类划分法和边界值分析法的组合

数据测试是功能测试的主要内容，或者说功能测试最主要手段之一就是借助数据的输入/输出来判断功能能否正常运行。所以在测试用例的黑盒设计方法中，最常用的方法是等价类划分法、边界值分析法。

等价类划分方法的基本思想是设想用一组有限的数据去代表近似无限的数据，就是基于对输入或输出数据的评估将数据划分为两个或更多子集（如有效的和无效的数据集），从每个等价类中选择一定的代表值进行测试，来代表整个数据集的输入/输出。

边界值分析法就是在某个变量范围的边界上，验证独立的输入/输出是否正确的测试方法。因为实践证明，程序往往在输入/输出数据边界更容易发生错误，所以检查边界情况的测试用例是比较高效的，可以更快地查出错误。

但是，仅仅测试边界数据是不够的，正常区域内的数据也是需要测试的，而且对于那些非法的、无效的数据也需要测试，以测试系统的容错性。所以，必须采用等价类划分方法来对边界值分析法的补充。从另一个方面看，要划分数据的等价类，首先是要确定数据边界，也就是找出数据等价类的边界。所以，在实际测试用例设计工作中，将边界值分析法和等价类划分方法结合起来，先用边界值分析法确定数据边界，再用等价类划分方法得到等价的数据类，从而有效地设计出精而少的测试用例。

让我们看一个简单的例子。假如一个输入数据是一个有限范围的整数，如学生成绩管理系统中的学生分数的输入（不计小数点）。这时，我们可以确定输入数据的最小值N_min和最大值N_Max，则有效的数据范围是N_min≦N≦N_Max ,如学生分数的输入范围是0≦N≦100，这个范围就是有效数据区域。除此之外，就是无效数据区域，即N <N_min或N>N_Max，如N <0或N>100。这时测试的数据从近乎无限的数据简化为5个输入数据，就是：

• 边界值两个：Nmin和NMax，如0和100
• 有效数据的等价输入值 Ni, 如75
• 无效数据的等价输入值两个：NLm1和NLm2, 如 -999和 999

为了得到更好的覆盖率，可以在最靠近边界取一些值，共四个，即：

 N_min +1，N_min -1，N_Max +1，N_Max -1，如 -1，1，99，101

所以一个有效的测试数据集合是{-1，0，1，99，100，101}；更完整的测试数据集合是{-999，-1，0，1，75，99，100，101，999}。

4．因果图法和组合分析法

因果图法和组合分析可以看作测试用例黑盒设计方法的综合方法。因果图法就是一种利用图解法分析输入的各种组合情况，生成判定表，从而设计测试用例的方法，它适合于检查程序输入条件的各种情况的组合。我们知道，即使各种单个输入条件可能出错的情况已经被排除了，但多个输入情况组合起来还是可能会出错。检验各种输入条件的组合并非一件很容易的事情，因为即使将所有的输入条件划分成等价类，它们之间的组合情况也相当多，因此，必须需要考虑采用一种适合于多种条件的组合，相应能产生多个动作的形式来进行测试用例的设计，这就是因果图法。

而组合分析是一种基于每对参数组合的测试技术，主要考虑参数之间的影响是主要的错误来源和大多数的错误起源于简单的参数组合。

 

5．功能图法

    功能图法是一种黑盒和白盒混合用例设计方法，在功能图方法中，要用到逻辑覆盖和路径测试的概念和方法，这属于白盒设计方法；而确定输入数据序列以及相应的输出数据，则是黑盒设计方法。

    我们知道，每个程序的功能通常由静态说明和动态说明组成，动态说明描述了输入数据的次序或者转移的次序；静态说明描述了输入条件和输出条件之间的对应关系。对于比较复杂的程序，由于大量的组合情况的存在，如果我们仅仅使用静态说明来组织测试往往是不够的，必须还要动态说明来补充。功能图法就是因此而产生的一种测试用例设计方法。

    功能图法就是使用功能图形式化地表示程序地功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型组成。其中，状态迁移图用于表示输入数据序列以及相应的输出数据，由输入和当前的状态决定输出数据和后续状态； 逻辑功能模型用于表示再状态输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅仅由输入数据决定。测试用例测试由测试中经过的一系列的状态以及在每个状态中必须依靠输入/输出数据满足的一对条件组成。

第22回 测试用例的复审

<script type="text/javascript"></script><script class="blogstory"></script>   

   测试用例的设计是整个软件测试工作的核心，测试用例反映对被测对象的质量要求和评估范围，决定测试的效率和测试自身的质量。

所以对测试用例的评审，就显得非常重要。测试用例设计完之后，要经过非正式和正式的复审和评审。在测试用例审查、评审过程中，主要检查下列内容：

• 测试用例设计的整体思路是否清晰，是否清楚系统的结构和逻辑从而使测试用例的结构或层次清晰，测试的优先级或先后次序是否合理；
• 测试用例设计的有效性，测试的重点是否突出，即是否抓住修改较大的地方、程序或系统的薄弱环节等；
• 测试用例的覆盖面，有没有考虑到产品使用中一些特别场景（scenario）、考虑到一些边界和接口的地方；
• 测试用例的描述，前提条件是否存在、步骤是否简明清楚、期望结果(Criteria)是否符合产品规格说明书或客户需要；
• 测试环境是否准确，测试用例有没有正确定义测试所需要的条件或环境；
• 测试用例的复用性和可维护性，良好的测试用例将会具有重复使用的功能, 保证测试的稳定性；
• 测试用例是否符合其他要求，如可管理性、易于自动化测试的转化等。

 
       测试用例在评审后，根据评审意见做出修改，继续评审，直至通过评审。在以后的测试中，如果有些被发现的缺陷，没有测试用例，应及时添加新的测试用例或修改相应的测试用例。和软件缺陷相关的测试用例是更有效的测试用例，其执行的优先级也高。通过测试用例所发现的缺陷占所有软件缺陷的比值，是衡量测试用例质量和有效性的方法之一。