What is a test design?
什么是測試設計?
A test design should contain a description of the setup (including machine configuration for a configuration test), inputs given to the product, and a description of expected results. One common mistake is being too specific about test inputs and procedures.
測試設計應當包含設置描述(包括配置測試的機器配置),對產品的輸入和預期結果的描述。一個常見錯誤是對測試輸入和過程過于注重細節。
Let's assume manual test implementation for the moment. A related argument for automated tests will be discussed in the next section. Suppose you're testing a banking application. Here are two possible test designs:
讓我們先假設一個手工測試實施。相關的自動化測試將在下一節討論。假設你在測試銀行應用程序。這里有兩個可能的測試設計:
Design 1
設計1
Setup: initialize the balance in account 12 with $100.
設置:將帳戶12的余額初始化為$100。
Procedure:
過程:
Start the program.
Type 12 in the Account window.
Press OK.
Click on the 'Withdraw' toolbar button.
In the withdraw popup dialog, click on the 'all' button.
Press OK.
Expect to see a confirmation popup that says "You are about to withdraw all the money from this account. Continue?"
Press OK.
Expect to see a 0 balance in the account window.
Separately query the database to check that the zero balance has been posted.
Exit the program with File->Exit.
啟動程序。
在帳戶窗口中輸入12。
按“確定”按鈕。
點擊“取款”工具條按鈕。
在彈出的取款對話框中,點擊“所有”按鈕。
按“確定”按鈕。
預期會看到一個確認消息:“您將從此帳戶中取出所有的錢,是否繼續?”
按“確定”按鈕。
在帳戶窗口中預期會看到余額為0。
單獨查詢數據庫,檢查余額為0。
通過“文件->退出” 退出程序。
Design 2
設計2
Setup: initialize the balance with a positive value.
設置:將帳戶余額初始化為一個正值。
Procedure:
過程:
Start the program on that account.
Withdraw all the money from the account using the 'all' button.
It's an error if the transaction happens without a confirmation popup.
Immediately thereafter:
- Expect a $0 balance to be displayed.
- Independently query the database to check that the zero balance has been posted.
啟動該帳戶的程序。
用“所有”按鈕從帳戶中取出所有的錢。
如果在事務發生時沒有彈出確認消息,則是一個錯誤。
其后立即:
- 預期余額會顯示$0。
- 單獨查詢數據庫,檢查余額為0。
The first design style has these advantages:
第一種設計風格有以下優點:
· The test will always be run the same way. You are more likely to be able to reproduce the bug. So will the programmer.
· 測試總是以相同方式運行。重現錯誤的可能性更大。程序員也一樣。
· It details all the important expected results to check. Imprecise expected results make failures harder to notice. For example, a tester using the second style would find it easier to overlook a spelling error in the confirmation popup, or even that it was the wrong popup.
· 它將所有要檢查的預期結果的細節都描述出來。不精確的預期結果使得錯誤更難注意到。例如,使用第二種風格的測試員將會發現更容易忽略確認對話框中的錯誤拼寫,甚至是錯誤的對話框。
· Unlike the second style, you always know exactly what you've tested. In the second style, you couldn't be sure that you'd ever gotten to the Withdraw dialog via the toolbar. Maybe the menu was always used. Maybe the toolbar button doesn't work at all!
· 不像第二種測試風格,你總是能明確地知道你在測試什么。在第二種風格中,你不能確定可以通過工具條得到“取款”對話框。也許總是使用菜單。也許工具條根本不起作用!
原文轉自:http://www.uml.org.cn/Test/200709289.asp