当前位置: 主页 > 软件工程 > 测试技术 > 测试用例 > 测试用例设计方法:因果法(下)


时间:2009-10-30 01:05 点击:1652次 字体:[ ]

3. Cause-Effect Methodology

  3. 因果法

  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 "Conditions" in Decision Tables (e.g., "Date is Valid", "Amount > $5000", "Balance - Amount is within Overdraft Limit"). Effects are observable system behaviours triggered by specific combinations of Causes, expressed as imperatives (like "Actions" in Decision Tables, e.g., "Display ’Invalid Date’; "Subtract Amount from Balance").


  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.


  Convention of Test Case Description


  Presence of the cause or effect (“True”)

  ‘0’Absence of cause or effect (“False”)

  ‘ ‘Don’t care condition

  表1 因果法中的约定

  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.)


  Before filling in the Trues (1’s) and Falses (0’s), we rank the Causes in the table according to "masking" precedence. Here is how the “masking” precedence is achieved. If you regard each Cause as a question, a Cause can "mask" 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 "Causes" list in the table, computation rules in the middle, and output-generation rules at the bottom.


  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 "1" 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 "False", 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.)

  接着,从第一栏和第一个原因开始,我们发问:“哪个答案给出了最简单的结果,1还是0?”这么做的意图是为了找出哪个掩盖了最低级别的原因。假定答案是1,即第一列代表了1号原因为真所发生的事情,而在接下去的列中1号原因都为“假”或者“不必注意”(可对原因1涉及到的列立即做个等分)。在相同的列对产生的结果标记“1”或者“0”,而未触发的结果则保持空白。在第二列,1号原因现在就是“0”(或者“不必注意”),然后我们对2号原因像刚才那样问同样的问题。假设这次的答案是“假”,那么此列所有2号原因为假所发生的事情此时就被标记为“1”。表2显示了一个因果矩阵的例子(OMC-R Agent子系统测试CC%A8" target=_blank>平台文档的一小部分因果图和一个测试用例,分别是表3与图3)。

  表2 因果矩阵的简单例子


  [Help] button clicked


  Valid User ID entered

  01 1

  Valid Librarian ID entered

  1 1

  Valid Password Entered


  [OK] button clicked


  [Cancel] button clicked



  Go to User Desktop Screen


  Go to Librarian Desktop Screen


  Model Dialog box showing invalid userId


  Model Dialog box showing invalid password


  UserId Text Field and Password Text Field cleared.


  The help message will be displayed.1



  图4 表2中的一个测试用例

  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.


  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.


  4. Results

  4. 结果

  The benefits that have been achieved using this test case design technique on a pilot feature #1171 of OMC-R Agent are:

  在OMC-R Agent的首要特性1171中用到的测试用例设计方法取得了如下效果:

  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.


  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.).


  Easily understandable matrix format of test cases by reviewers/inspectors and quality assurance professionals.


  Helps gain a deeper understanding of the requirements.


  Helps to identify ambiguous requirements and to improve on requirement specifications.


  Ease of traceability to requirements.




  图5 表3中的测试用例

  5. Conclusion

  5. 结论

  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.


  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.


  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.


  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.

  测试工作的效率可以通过因果法配合合适的自动化测试工具,例如脚本执行测试工具(Script Execution Test Tool,SETT)和TestExpert,得到最大化。

  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




  6. 词汇表

  CE: Cause-Effect

  CLI: Command Line Interface

  CMIP: Common Management Information Protocol

  CTM: CMIP Test Manager

  GSD: Geographical Status Display

  ITU: International Telecommunication Union

  MIB: Management Information Base

  MIT: Management Information Tree

  OMC-R: Operational and Maintenance Centre-Radio

  scevmgr: SuperCell Event Manager

  SDC: System Data Collection

  SETT: Script Execution Test Tool

  SGI: Silicon Graphics Inc.

  SSC: Singapore Software Centre

  SST: Sub-System Testing

  UNO: Universal Network Operations

  7. 参考资料

  [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.

  [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.

  [3] IPL, Eveleigh House, Grove Street, Bath, BA1 5LR, UK, An Introduction to Software Testing, http:// www.teleport.com/~qcs/papers/p820.htm.

  [4] IPL, Eveleigh House, Grove Street, Bath, BA1 5LR, UK, Software Testing and Software Development Lifecycles, http://www.teleport.com/~qcs/papers/ p821.htm.

  [5] "Weak Mutation Testing and Completeness of Test Sets", IEEE Trans. Software Eng., Vol.SE-8, No.4, July 1982, pp.371-379.

本文地址 : http://www.fengfly.com/plus/view-145355-1.html
标签: 方法 功能 程序 设计 需求 中的
最新评论 查看所有评论
发表评论 查看所有评论