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

　　盡早測試的作用不僅僅是防止編碼錯誤。像我們將在下一個主題中所討論的那樣，許多測試代表的是用戶任務。設計它們的過程可以在昂貴的重新工作之前發現用戶界面和可用性問題。我發現過的問題包括：錯誤消息不能顯示在用戶可以看到的地方，插件不能放到一起，兩個必須同時使用的屏幕不能同時顯示，一個“很明顯” 的功能不能執行。測試設計作為一個發現規格說明書 bug 的方法，很好地與可用性工程工作相適應([Nielsen93])。

　　I should note that involving testing early feels unnatural to many programmers and development managers. There may be feelings that you are intruding on their turf or not giving them the chance to make the mistakes that are an essential part of design. Take care, especially at first, not to increase their workload or slow them down. It may take one or two entire projects to establish your credibility and usefulness.

　　我應當說明早期介入測試對于許多程序員和開發經理來說不自然?？赡苡幸环N感覺是你干擾了他們，沒有給他們在設計的基礎部分犯錯誤的機會。小心些，尤其是在開始的時候，不要增加他們的工作量或減慢了他們的速度?？赡苄枰恢羶蓚€完整的項目才能建立你們的可信度并顯示出作用。

　　主題二：計劃測試工作

　　I'll first discuss specific planning mistakes, then relate test planning to the role of testing.

　　我將首先討論特定的計劃錯誤，然后將測試計劃與測試作用關聯起來。

　　It's not unusual to see test plans biased toward functional testing. In functional testing, particular features are tested in isolation. In a word processor, all the options for printing would be applied, one after the other. Editing options would later get their own set of tests.

　　將測試計劃偏重于功能測試的情況的并不少見。在功能測試中，某個功能部件是孤立測試的。在字處理軟件中，所有打印選項都將一個接一個地應用。編輯選項在后面將得到它們自己的測試集。

　　But there are often interactions between features, and functional testing tends to miss them. For example, you might never notice that the sequence of operations open a document, edit the document, print the whole document, edit one page, print that page doesn't work. But customers surely will, because they don't use products functionally. They have a task orientation. To find the bugs that customers see - that are important to customers - you need to write tests that cross functional areas by mimicking typical user tasks. This type of testing is called scenario testing, task-based testing, or use-case testing.

　　但是，在各個功能部件中常常有交互作用，功能測試很容易遺漏它們。例如，你可能從未注意到一系列的操作：打開文檔、編輯文檔、打印整個文檔、編輯一頁、打印該頁不能工作。但是客戶一定會注意到，因為他們不會按功能使用產品。他們是面向任務的。如果要找到客戶看到的 bug——這些 bug 對于客戶來說是很重要的——你需要編寫模仿典型用戶任務的跨功能區的測試用例。這類測試稱為場景測試、基于任務的測試，或使用用例測試。

　　A bias toward functional testing also underemphasizes configuration testing. Configuration testing checks how the product works on different hardware and when combined with different third party software. There are typically many combinations that need to be tried, requiring expensive labs stocked with hardware and much time spent setting up tests, so configuration testing isn't cheap. But, it's worth it when you discover that your standard in-house platform which "entirely conforms to industry standards" actually behaves differently from most of the machines on the market.

　　偏重于功能測試也會低估配置測試的重要性。配置測試檢查產品在不同硬件上、以及在與不同的第三方軟件組合使用時如何工作。通常有不同的典型組合需要嘗試，需要有裝備了硬件的昂貴實驗室，并花費很多時間設置測試，所以配置測試成本不低。但是，當你發現你的“完全符合業界標準”的標準機構內部平臺實際上在市場上不同的機器上表現不同的時候，這樣做就值了。

　　Both configuration testing and scenario testing test global, cross-functional aspects of the product. Another type of testing that spans the product checks how it behaves under stress (a large number of transactions, very large transactions, a large number of simultaneous transactions). Putting stress and load testing off to the last minute is common, but it leaves you little time to do anything substantive when you discover your product doesn't scale up to more than 12 users.

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