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").
该方法从功能说明书——上至用户需求说明书，下至子类子程序设计——抽取原因、结果以及它们之间的关系。一个原因是指在一个变量与另外某一个变量或变量属性之间的输入关系，它可以触发目标系统的外部可观测行为。原因与决策表中的“条件”表述相同。例如，“日期有效”，“总数大于5000美元”，“余额总数在透支限度内”。结果则是由原因以特定方式组合而产生的系统的外部可观测行为，和决策表中的“行为”类似。例如，“显示‘无效日期’”，“从余额中减去总量”。
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.
这种方法中，功能性需求被转换为一些因果矩阵。矩阵中，每一行由原因(输入刺激)和结果(输出应答)组成，而每一列则是由一些0、1或者空位组成，它们对应着由一系列原因和结果组合而成的测试用例。
Convention of Test Case Description
‘1’
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.)
测试用例的数目由一组具有上下限的指定原因确定。表中的原因数确定了真假条件的可能组合，作为测试上限(2**n，其中n表示原因数)。而覆盖集的近似大小则被作为下限(n+1，等价于某个图的环复杂性)。在下限方面，某些位置每个原因都为“真”，某些位置每个原因都为“假”，某些位置每种结果都可能发生，每列都有意义且都集中于一个特定原因。而在那些原因相互依赖的情况下，我们必须做一些折中(例如，在那些相互排斥的地方)。
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.
在填入真(1)和假(0)之前，我们根据掩盖优先原则对表中的原因进行排列。下面论述什么是掩盖优先。假如你把每个原因都看作一个问题，那么当答案再不需询问其他原因就可以得到时，一个原因即掩盖了其他的原因。通常，该掩盖优先技术会把输入数据的确定规则放置在表中的原因一拦的顶部，运算规则放置在中部，而输出规则则在底部。
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 因果矩阵的简单例子
Cause1234567
[Help] button clicked
1
Valid User ID entered
01 1
Valid Librarian ID entered
1 1
Valid Password Entered
1100
[OK] button clicked
111110
[Cancel] button clicked
1
Effect
Go to User Desktop Screen
1
Go to Librarian Desktop Screen
1
Model Dialog box showing invalid userId
1
Model Dialog box showing invalid password
11
UserId Text Field and Password Text Field cleared.
1
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.
像这样处理表中所有其他的原因和结果。最后，不会多于n+1个列，最少每个原因要对应一个“1”或者一个“0”。但是这样依然会有未触发的结果，需要为它们创建新的列。所以，测试者需要为测试需求构建一个最小集，好让每列都与系统中潜在BUG的位置一一对应。然后，测试者再考虑是否要用新的测试来扩展该集合以开发某些不同的未涉及到的因果组合。
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.
因果法又被称为测试需求定义方法(控制流图，状态转换分析等等)，而并非测试设计。在操作步骤结尾，每列都通过由原因和结果确定的目标为潜在的测试用例描述了需求。测试者依然需要设计实际的测试数据来支持这些目标。同时，他们还必须十分注意那些依然可以是“1”或“0”的被掩盖的原因，并设计一些测试来执行测试用例。由于文章篇幅所限，这里就不再讨论辅助表(用来处理复杂的输入或者输出)、迭代和反馈环等技术了。
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.
得到了更好的测试覆盖率。通过在1171特性中的因果法的应用，到达了“6σ”的质量品质，使得该特性不存在后发缺陷。请参考图6中的Q数据，其中只有很少缺陷被报告，但没有一个存在于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
使用因果法带来的结果将提升产品质量并降低成本，这对于ABC软件开发周期是很有益的。它能帮助ABC提升产品质量。
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.
文章来源于领测软件测试网 https://www.ltesting.net/
