典型的測試錯誤有哪些？(19)

　　An alternative approach to capture/replay is scripting tests. (Most GUI capture/replay tools also allow scripting.) Some member of the testing team writes a "test API" (application programmer interface) that lets other members of the team express their tests in less GUI-dependent terms. Whereas a captured test might look like this:

　　捕獲/回放的一個替代方法是腳本化測試。(大多數GUI捕獲/回放工具都允許編寫腳本。)測試小組的某些成員編寫一個“測試API(應用編程接口)”，允許小組的其他成員以較少依賴GUI的方式表達他們的測試。一個捕獲的測試類似于這樣：

　　· text $main.accountField "12"

　　click $main.OK

　　menu $operations

　　menu $withdraw

　　click $withdrawDialog.all

　　...

　　文本 $main.accountField "12"

　　點擊 $main.OK

　　菜單 $operations

　　菜單 $withdraw

　　點擊 $withdrawDialog.all

　　a script might look like this:

　　而一個腳本類似于：

　　· select-account 12

　　withdraw all

　　...

　　select-account 12

　　withdraw all

　　The script commands are subroutines that perform the appropriate mouse clicks and key presses. If the API is well-designed, most GUI changes will require changes only to the implementation of functions like withdraw, not to all the tests that use them. Please note that well-designed test APIs are as hard to write as any other good API. That is, they're hard, and you shouldn't expect to get it right the first time.

　　腳本命令是執行適當的鼠標點擊和按鍵的子程序。如果API設計得好，大多數GUI變化僅需要對函數(例如withdraw)實現變化，而不是所有使用它們的測試。請注意設計精良的API和其他好API一樣難寫。也就是說，因為它們不容易寫，你也不要指望第一次就得到正確結果。

　　In a variant of this approach, the tests are data-driven. The tester provides a table describing key values. Some tool reads the table and converts it to the appropriate mouse clicks. The table is even less vulnerable to GUI changes because the sequence of operations has been abstracted away. It's also likely to be more understandable, especially to domain experts who are not programmers. See [Pettichord96] for an example of data-driven automated testing.

　　這個方法的一個變種，是數據驅動的測試。測試員提供一個表來描述鍵值。某些工具讀取表并將它轉換為特定的鼠標點擊。這個表即使在GUI變化時也不易受到損害，因為操作序列已經被抽象出來了。它也有可能是更易于理解，尤其是對于非程序員的領域專家。查看[Pettichord96]可以獲得數據驅動自動化測試的示例。

　　Note that these more abstract tests (whether scripted or data-driven) do not necessarily test the user interface thoroughly. If the Withdraw dialog can be reached via several routes (toolbar, menu item, hotkey), you don't know whether each route has been tried. You need a separate (most likely manual) effort to ensure that all the GUI components are connected correctly.

　　注意這些抽象測試(不論是腳本化的還是數據驅動的)不一定會完全測試用戶界面。如果“取款”對話框能夠通過幾個途徑(工具條、菜單項)達到，你無法知道是否嘗試了每個路線。你需要一個單獨的(很可能是手工的)的工作來確保所有的GUI部件都正確地連接。

　　Whatever approach you take, don't fall into the trap of expecting regression tests to find a high proportion of new bugs. Regression tests discover that new or changed code breaks what used to work. While that happens more often than any of us would like, most bugs are in the product's new or intentionally changed behavior. Those bugs have to be caught by new tests.

　　不論你采用的是什么方法，不要陷入期望回歸測試發現高比例的新 bug 的陷阱?；貧w測試是發現以前起作用、但新代碼或更改后的代碼不起作用的現象。雖然它比我們希望的發生的次數更多，但許多 bug 是產品的新的或故意更改的行為。那些 bug 必須通過新測試來捕捉。

　　Code coverage

　　代碼覆蓋率

　　GUI capture/replay testing is appealing because it's a quick fix for a difficult problem. Another class of tool has the same kind of attraction.

　　GUI捕獲/回放測試因為可以快速修復困難問題而具有吸引力。另一類工具也同樣具有吸引力。

　　The difficult problem is that it's so hard to know if you're doing a good job testing. You only really find out once the product has shipped. Understandably, this makes managers uncomfortable. Sometimes you find them embracing code coverage with the devotion that only simple numbers can inspire. Testers sometimes also become enamored of coverage, though their romance tends to be less fervent and ends sooner.

原文轉自：http://www.uml.org.cn/Test/200709289.asp