51CMM.COM编译 原著：James 翻译：李迅<br /><br /><br />  原题：Test Case Design Technique: Cause-Effect<br />  ABSTRACT - In order to perform full coverage on sub system testing, Cause and Effect (CE) Technique is being used to design test cases. In this technique, the functional specifications are transformed into cause and effect matrices. The matrix contains a row for each cause (inputs stimulus) and effect (output response). Each column of the matrix containing 0’s, 1’s and blanks specifies a test case which is a combination of the causes and effects. The CE technique is highly recommended as it traces the requirements to the test cases in a matrix form. This technique is suitable for black box testing, and as far as coverage is concerned, this technique will guarantee more than 80% coverage.<br />  摘要：<br />  为了使子系统测试能够完全被覆盖，可以使用因果法（Cause and Effect，CE）来设计测试用例。这种方法将功能说明书转换为因果矩阵。该矩阵中，每一行由原因（输入激励）和结果（输出应答）组成，而每一列则是由一些0、1或者空位组成，它们对应着由一系列原因和结果组合而来的测试用例。因果法之所以受到推崇，其原因是它以一种矩阵的形式跟踪着测试用例的需求。该方法十分适合于黑盒测试，并且在测试覆盖方面，它能保证80%以上的覆盖率。 <br />  1. Introduction<br />  1. 简介<br />  Software testing is part of software development process. The ultimate aim of the system testing on a deliverable product, is to achieve Motorola’s fundamental goals of six sigma quality, total customer satisfaction and 5NINES availability. One of the questions that has always been in the mind of software system test engineer is that whether he/she has thoroughly tested the software. One of the main factors that determine the coverage of system is the technique used in designing test cases.<br />  软件测试是软件开发工程的重要组成部分。对可交付产品的系统测试的最终目标就是要达到摩托罗拉公司（Motorola）提出的基本质量目标：6σ质量品质、完全顾客满意度以及5NINES有效性。在软件系统测试工程师心里总是存在着一个疑问，即他/她到底能否彻底地对软件进行测试。而决定系统的测试覆盖率的主要因素之一就是设计测试用例时所使用的方法。<br />  Even though there are numerous test case design techniques available in current software development world, the most important ingredients of any test design are experience and common sense. Test designers should not let any of the given techniques obstruct the application of experience and common sense. The design of the test cases has to be driven by the specification of the software.<br />  尽管现在的软件开发中正使用着众多的测试用例设计方法，然而最重要的测试用例设计因素却是经验和常识。测试用例设计不应该让任何给定的方法阻碍经验和常识的应用。因此，必须由软件说明书来驱动测试用例的开发。<br />  Traditionally , test cases are derived by studying the requirements. Most system testers approach this derivation based on their intuition and experiences. They normally do not follow any systematic process to derive test cases. These tests do not guarantee substantial coverage of requirements. At Singapore Software Centre (SSC), we used the Cause-Effect (CE) Technique to derive our test cases for sub-system testing of Network Management Agent software for Cellular Networks.<br />  传统上，测试用例生成于对需求的研究。大部分的系统测试者是基于他们的直觉和经验实践着这种做法。他们通常不会遵循任何条条框框来生成测试用例。这种测试无法确保对需求的完全覆盖。而在新加坡软件中心（Singapore Software Centre,，SSC），我们使用因果法为蜂窝网络的网络管理代理软件的子系统生成测试用例。<br />  This paper outlines the use of CE approach in test case design in order to achieve the required levels of coverage. The bottom line of this effort is to be able to investigate the most likely and costly types of defects on a risk priority basis so as to increase our confidence in system readiness for use. This test case design technique has been practiced in one of the on-going projects, called OMC-R Agent Release8.1, in SSC. The OMC-R Agent team has many new features added in each release and this technique has been applied to a case-study on one of the features (Feature 1171: GSD and Status Display) in the OMC-R Agent R8.1.<br />  本文论述了为到达所需的覆盖率而在测试用例设计中使用因果法的过程。其实，本次工作是为了研究基于风险优先级的情况下，可能性最大且成本最大的缺陷类型，进而增加我们对系统准备工作的信心。因果法已经在新加坡软件中心的一个正在进行的项目中得到应用，该项目名称是OMC-R Agent 发行版本号8.1。OMC-R Agent的团队在每个新的版本中都加入了很多新的内容，而因果法则是应用在OMC-R Agent R8.1其中一个新特性（特性1171: GSD及状态显示）的用例研究中。<br />  2. OMC-R Agent Sub-System Testing<br />  2. OMC-R Agent子系统测试<br />  2.1 Software Life Cycle<br />  2.1 软件生命周期<br />  The life-cycle for software development includes requirements gathering, requirements analysis, high/low level design, coding, unit testing, integration testing and sub-system testing (SST). Figure 1 shows the V-shaped software life-cycle which is used in the OMC-R Agent development work in SSC. After the component testing (Unit testing) and Integration testing the code is handed over for the sub-system testing.<br />  软件开发的生命周期包括需求搜集、需求分析、高/低端设计、编码、单元测试、集成测试以及子系统测试（sub-system testing ，SST）。图1显示了在SSC的OMC-R Agent开发工作中使用的V形软件开发模型。在组件测试（单元测试）和集成测试之后，代码便移交给子系统测试。<br /><br /><img src='http://www.51cmm.com/SoftTesting/images/No099-1.gif' border='0' alt='user posted image' /><br />图1：V形软件开发模型<br />  Our SST phase consists of a number of stages which progressively elaborates the design of tests from initial high level strategy to detailed test procedures. The stages involved in system testing done at SSC are test strategy, test planning, test case design and developing new test procedures. The SST performed on the OMC-R Agent products has always been a Black-box testing to make sure the software product meets the requirements. Full regression testing are performed whenever changes are made <br />  子系统测试阶段划分为一些更小的阶段。它们把测试设计逐步细化，使其从最初的高端测试策略演变成详细的测试程序。这些子系统测试涉及到的更小的阶段分别是测试策略、测试计划、测试用例设计以及开发新的测试程序。为OMC-R Agent的产品进行的子系统测试通常是黑盒测试，以此来保证软件产品符合软件需求。而不论何时，只要有变化产生，都要进行回归测试。<br />  Black-box test design treats the system as a &quot;black-box&quot;, so it doesn’t explicitly use knowledge of the internal structure. The black box is not an alternative to white box testing which is usually performed early in the software development process (unit testing). Black-box test design is usually focused on testing with sets of inputs that will fully exercise all the functional requirements of a system.<br />  黑盒测试把系统视为一个“黑盒子”，因此它就不会接触到内部结构。这个黑盒不能替代早期在软件开发过程的单元测试中经常使用的白盒测试。黑盒测试的设计往往集中用一组能完全启动系统功能的输入来测试。<br />  2.2 Network Management Overview<br />  2.2 网络管理概述<br />  In a cellular network, a managing system such as Universal Network Operations (UNO) manager, provides a single platform for centralized monitoring and control of devices. The ITU (X.730/X.740) defines the standard management function such as configuration management, fault management, security management, accounting management, and performance management.<br />  在蜂窝网络中，像通用网络系统（Universal Network Operations，UNO）管理者这样的管理系统为设备的集中监控提供了一个简单的平台。国际电信联盟（International Telecommunications Union，ITU）X.730/X.740定义了例如配置管理、错误管理、安全管理、计费管理以及性能管理这样的标准管理功能。<br />  Figure 2 shows the relationship between managing processes and managed processes. The managing system communicates with it’s managed objects to carry out the appropriate operation through CMIP agent. The CMIP protocol is an open standard interface that will allow applications to access managed objects in a common way. CMIP agent on OMC-R platform provides some functions namely:<br />  图2显示了管理过程与被管理过程之间的关系。管理系统与它管理着的对象进行交互，并通过CMIP代理执行适当的操作。CMIP协议是一个开放标准，它允许各种应用软件以一种公共的方式来访问被管理对象。OMC-R 平台的CMIP代理提供了如下一些功能：<br />  1. Notifications - events report, object creation/ object deletion, attributes value change, state change. <br />  1. 通知—事件报告、对象创建/销毁、属性值变更、状态变更<br />  2. Management Operation- m_set, m_create, m_delete, M-action (enable or disable all the devices).<br />  2. 管理操作—m_set, m_create, m_delete, M-action（所有设备可用或不可用） <br /><img src='http://www.51cmm.com/SoftTesting/images/No099-2.gif' border='0' alt='user posted image' /><br />图2 网络管理系统<br />  2.3 Test Environment/Test Bed<br />  2.3 测试环境/测试床<br />  Test software/simulators are required to execute the test cases. The two test simulators used are as shown in Figure . CTM is tool that will simulate a network manager which sends and receives messages to and from the CMIP Agent process on the OMC. And HARN is a tool to simulate the events from devices such as alarms, notifications and command responses. Perl scripts are written for automation during SST, automation is done in order to achieve Cycle Time Reduction.<br />  测试软件/模拟器都会执行一些测试用例。图3中显示了两个测试模拟器，CTM是一个模拟网络管理者的模拟器，它与OMC的CMIP代理程序相互发送信息。HARN模拟器则模拟了从设备发送来的事件，例如警报、通知、命令响应等。在子系统测试中，为使测试自动化我们编写了Perl代码，以到达周期时间缩短的目的。<br /><img src='http://www.51cmm.com/SoftTesting/images/No099-3.gif' border='0' alt='user posted image' /><br />图3 测试环境

3. Cause-Effect Methodology<br />  3. 因果法<br />  This method extracts Causes, Effects, and their relationships from a functional specification at any levels from User Requirements specification down to subclass or program subroutine. A Cause is an input relationship between a variable and either some other variable or some property of the variable that triggers externally-observable behaviours in the target system. Causes are expressed the same way as &quot;Conditions&quot; in Decision Tables (e.g., &quot;Date is Valid&quot;, &quot;Amount &gt; $5000&quot;, &quot;Balance - Amount is within Overdraft Limit&quot;). Effects are observable system behaviours triggered by specific combinations of Causes, expressed as imperatives (like &quot;Actions&quot; in Decision Tables, e.g., &quot;Display ’Invalid Date’; &quot;Subtract Amount from Balance&quot;).<br />  该方法从功能说明书——上至用户需求说明书，下至子类子程序设计——抽取原因、结果以及它们之间的关系。一个原因是指在一个变量与另外某一个变量或变量属性之间的输入关系，它可以触发目标系统的外部可观测行为。原因与决策表中的“条件”表述相同。例如，“日期有效”，“总数大于5000美元”，“余额总数在透支限度内”。结果则是由原因以特定方式组合而产生的系统的外部可观测行为，和决策表中的“行为”类似。例如，“显示‘无效日期’”，“从余额中减去总量”。<br />  In this technique, the functional requirements are transformed into cause and effect matrices. The matrix contains a row for each cause (input stimulus) and effect (output responses). Each column of the matrix contains 0’s, 1’s and blanks specifies a test case which is a combination of the causes and effects.<br />  这种方法中，功能性需求被转换为一些因果矩阵。矩阵中，每一行由原因（输入刺激）和结果（输出应答）组成，而每一列则是由一些0、1或者空位组成，它们对应着由一系列原因和结果组合而成的测试用例。<br />Convention of Test Case     Description  <br />‘1’                       Presence of the cause or effect (“True”) <br />‘0’                       Absence of cause or effect (“False”) <br />‘ ‘                       Don’t care condition <br />表1 因果法中的约定<br />  The number of test cases that can be derived from a set of identified Causes has upper and lower limits. The number of Causes in a table identifies both the number of possible combinations of true or false as an upper limit on testing (2**n, where n is the number of Causes). The approximate size of a covering set as a lower limit (n+1, equivalent to cyclomatic complexity of a graph). In the case of lower limit, every Cause is “True” somewhere, every Cause is “False” somewhere, every Effect is generated somewhere, every column makes sense, and each column concentrates on one specific Cause. Some compromises have to be taken on a situation where Causes are interdependent (e.g., where they’re mutually exclusive.)<br />  测试用例的数目由一组具有上下限的指定原因确定。表中的原因数确定了真假条件的可能组合，作为测试上限（2**n，其中n表示原因数）。而覆盖集的近似大小则被作为下限（n+1，等价于某个图的环复杂性）。在下限方面，某些位置每个原因都为“真”，某些位置每个原因都为“假”，某些位置每种结果都可能发生，每列都有意义且都集中于一个特定原因。而在那些原因相互依赖的情况下，我们必须做一些折中（例如，在那些相互排斥的地方）。<br />  Before filling in the Trues (1’s) and Falses (0’s), we rank the Causes in the table according to &quot;masking&quot; precedence. Here is how the “masking” precedence is achieved. If you regard each Cause as a question, a Cause can &quot;mask&quot; others if the answer (“True” or “False”, as appropriate) removes the need to even ask the others. Usually, this “masking” precedence technique will put input data validation rules at the top of the &quot;Causes&quot; list in the table, computation rules in the middle, and output-generation rules at the bottom.<br />  在填入真（1）和假（0）之前，我们根据掩盖优先原则对表中的原因进行排列。下面论述什么是掩盖优先。假如你把每个原因都看作一个问题，那么当答案再不需询问其他原因就可以得到时，一个原因即掩盖了其他的原因。通常，该掩盖优先技术会把输入数据的确定规则放置在表中的原因一拦的顶部，运算规则放置在中部，而输出规则则在底部。<br />  Then, starting with the first column and first Cause, we ask: Which answer gives the simplest result, “1” or “0”? The intension of the above question is to find out which masks the most lower Causes. Assume that &quot;1&quot; is the answer: Column 1 now represents all occurrences of “True” for Cause 1, which will now be “False” or “Don’t Care” in all subsequent columns (an immediate halving in the potential number of columns which involve Cause 1). Generated Effects are identified with “1” (or “0”) in the same column. The untriggered Effects are left blank. In Column 2, Cause 1 is now “0” (or it can also be “Don’t Care”), and we ask the same question as before about Cause 2. Assuming the answer this time is &quot;False&quot;, this column represents all occurrences of False for Cause 2, which will be “1” from now on. A text book example on the CE matrix is shown in Table 2. The test case corresponding to the column 3 of the Table 2 is shown Figure 4.(For, a small portion CE matrix and a test case, from the OMC-R Agent Sub-System Test Plan document, are shown in Table 3 and Figure 3 respectively.)<br />  接着，从第一栏和第一个原因开始，我们发问：“哪个答案给出了最简单的结果，1还是0？”这么做的意图是为了找出哪个掩盖了最低级别的原因。假定答案是1，即第一列代表了1号原因为真所发生的事情，而在接下去的列中1号原因都为“假”或者“不必注意”（可对原因1涉及到的列立即做个等分）。在相同的列对产生的结果标记“1”或者“0”，而未触发的结果则保持空白。在第二列，1号原因现在就是“0”（或者“不必注意”），然后我们对2号原因像刚才那样问同样的问题。假设这次的答案是“假”，那么此列所有2号原因为假所发生的事情此时就被标记为“1”。表2显示了一个因果矩阵的例子（OMC-R Agent子系统测试平台文档的一小部分因果图和一个测试用例，分别是表3与图3）。<br />  表2 因果矩阵的简单例子

丁～～ 这个有点复杂，考下来慢慢看～

<img src='http://www.51cmm.com/SoftTesting/images/No100-1.gif' border='0' alt='user posted image' /><br /><br /> 图4 表2中的一个测试用例<br />  Again, all the other Causes and Effects in the table are dealt with as appropriate. Eventually, not more than n+1 columns, there’s at least one “1” and at least one “0” for each Cause. But there may still be untriggered Effects, for which additional columns may have to be created. So, the tester will then have a minimum set of test requirements, such that each column specifically targets one, and only one, potential bug location in the system. Now tester can consider whether to expand the set with additional tests to explore some otherwise untouched combinations.<br />  像这样处理表中所有其他的原因和结果。最后，不会多于n+1个列，最少每个原因要对应一个“1”或者一个“0”。但是这样依然会有未触发的结果，需要为它们创建新的列。所以，测试者需要为测试需求构建一个最小集，好让每列都与系统中潜在BUG的位置一一对应。然后，测试者再考虑是否要用新的测试来扩展该集合以开发某些不同的未涉及到的因果组合。<br />  This technique is also known as Test Requirements Definition technique (as are Control Flow graphing, State Transition Analysis, etc.), rather than test design. At the end of the process, each column expresses the requirements for a potential test case with a specific objective identified by the Cause(s) and Effect(s). The tester still has to design the actual test data values so that each supports the objective. The tester must also take special care with masked Causes, which must still be “1” or “0”, and design a test or tests to best execute the test cases. Due to restriction of paper length there isn’t scope to tell more, or to discuss topics such as subsidiary tables (for handling complicated input validation or output generation), iterations, and feedback loops.<br />  因果法又被称为测试需求定义方法（控制流图，状态转换分析等等），而并非测试设计。在操作步骤结尾，每列都通过由原因和结果确定的目标为潜在的测试用例描述了需求。测试者依然需要设计实际的测试数据来支持这些目标。同时，他们还必须十分注意那些依然可以是“1”或“0”的被掩盖的原因，并设计一些测试来执行测试用例。由于文章篇幅所限，这里就不再讨论辅助表（用来处理复杂的输入或者输出）、迭代和反馈环等技术了。<br />  4. Results<br />  4. 结果<br />  The benefits that have been achieved using this test case design technique on a pilot feature #1171 of OMC-R Agent are:<br />  在OMC-R Agent的首要特性1171中用到的测试用例设计方法取得了如下效果：<br />  Helps to achieve a better test coverage of the testing. A chived “six sigma” quality for the Feature #1171 on which this CE technique has been piloted. There is no post-release defects have been found for this feature. Please refer to the Q-data (Figure 6), and there are few reported defects. But none of them are from Feature# 1171.<br />  得到了更好的测试覆盖率。通过在1171特性中的因果法的应用，到达了“6σ”的质量品质，使得该特性不存在后发缺陷。请参考图6中的Q数据，其中只有很少缺陷被报告，但没有一个存在于1171特性中。<br />  Optimization in developing test cases (i.e., it is easy to avoid any duplication of test cases in a CE table by identifying the “masking” precedece as explained in Section 3.).<br />  测试用例的优化。（例如，根据经过掩盖优先处理过的因果图设计的测试用例很容易避免测试用例的重复）<br />  Easily understandable matrix format of test cases by reviewers/inspectors and quality assurance professionals.<br />  复查/审核人员及质量保证专家更容易理解矩阵形式的测试用例。<br />  Helps gain a deeper understanding of the requirements.<br />  对需求有更深刻的理解。<br />  Helps to identify ambiguous requirements and to improve on requirement specifications.<br />  更好的确定不明确的需求并且改进需求说明书<br />  Ease of traceability to requirements.<br />  容易对需求进行跟踪<br /><img src='http://www.51cmm.com/SoftTesting/images/No100-2.gif' border='0' alt='user posted image' /><br />  图5 表3中的测试用例<br />  5. Conclusion<br />  5. 结论<br />  Software should be tested against what it is specified to do, not against what it actually observed to do. Software can be tested at various stages of the development cycle and with various degrees of rigor. <br />  软件需要被测试它被指定做的事情，而不是实际上看到的做的事情。软件能够基于各种不同严格程度在开发周期的不同阶段被测试。<br />  In practice, using CE technique, the design of each level of system testing has been developed through a number of layers, each adding more detail to the tests. This technique in some cases will also help clear the ambiguity in requirements while extracting the “Causes” and “Effects” from requirements for the matrix. <br />  实际上，通过因果法，每一层次的系统测试设计可以若干级来开发，每一级增加新的测试内容。这种方法在一些情况下还能帮助理清不明确的需求，因为它从需求中把抽取“原因”与“结果”的放置到矩阵中。<br />  During the review/inspection of the system test cases, the matrix can also be used to trace the requirement/ specification of the product to the test cases.<br />  在系统测试用例的复查/审核过程中，矩阵还能用来检查产品的需求说明书与测试用例的一致性。<br />  The effectiveness of testing effort can be maximized by using CE technique together with appropriate use of automated test execution tools such as Script Execution Test Tool (SETT) and TestExpert. <br />  测试工作的效率可以通过因果法配合合适的自动化测试工具，例如脚本执行测试工具（Script Execution Test Tool，SETT）和TestExpert，得到最大化。 <br />  The net result of the CE technique will be an increase in quality and a decrease in costs, both of which can be beneficial to ABC’s software development cycle. This will help ABC to meet quality <br />  使用因果法带来的结果将提升产品质量并降低成本，这对于ABC软件开发周期是很有益的。它能帮助ABC提升产品质量。<br /><img src='http://www.51cmm.com/SoftTesting/images/No100-3.gif' border='0' alt='user posted image' /><br /> 6. 词汇表<br />  CE: Cause-Effect<br />  CLI: Command Line Interface<br />  CMIP: Common Management Information Protocol<br />  CTM: CMIP Test Manager<br />  GSD: Geographical Status Display<br />  ITU: International Telecommunication Union<br />  MIB: Management Information Base<br />  MIT: Management Information Tree<br />  OMC-R: Operational and Maintenance Centre-Radio<br />  scevmgr: SuperCell Event Manager<br />  SDC: System Data Collection<br />  SETT: Script Execution Test Tool<br />  SGI: Silicon Graphics Inc.<br />  SSC: Singapore Software Centre<br />  SST: Sub-System Testing<br />  UNO: Universal Network Operations<br />  7. 参考资料<br />  [1] Krish T. Krishnakumar and Ng Orr Thiak, UNO2.1/ R8.1 OMC-R Agent Features:#1171, GSD and Status Display Software System Test Plan , SCELL-COM-OMC-SSTP-004, Version 2.0.0, May 20, 1998. <br />[2] Dan Lewis, Debbie Stackis, Ron Weddige, Ravishankar H.S, Huei-Ying Ong, Supercell OMC-R CMIP Agent Software Functional Specification, SCELL-COM-GEN-SFS-004, Version 11.2, May 30, 1998. <br />[3] IPL, Eveleigh House, Grove Street, Bath, BA1 5LR, UK, An Introduction to Software Testing, http:// www.teleport.com/~qcs/papers/p820.htm. <br />[4] IPL, Eveleigh House, Grove Street, Bath, BA1 5LR, UK, Software Testing and Software Development Lifecycles, <a href='http://www.teleport.com/~qcs/papers/' target='_blank'>http://www.teleport.com/~qcs/papers/</a> p821.htm. <br />[5] &quot;Weak Mutation Testing and Completeness of Test Sets&quot;, IEEE Trans. Software Eng., Vol.SE-8, No.4, July 1982, pp.371-379.

ding <!--emo&:huh:--><img src='style_emoticons/default/huh.gif' border='0' style='vertical-align:middle' alt='huh.gif' /><!--endemo-->