測試用例設計方法：因果法（下）

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

　　該方法從功能說明書——上至用戶需求說明書，下至子類子程序設計——抽取原因、結果以及它們之間的關系。一個原因是指在一個變量與另外某一個變量或變量屬性之間的輸入關系，它可以觸發目標系統的外部可觀測行為。原因與決策表中的“條件”表述相同。例如，“日期有效”，“總數大于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 aclearcase/" target="_blank" >ccording 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.

原文轉自：http://www.anti-gravitydesign.com