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

　　5. When beta users report a bug, the bug report is often unusable. It costs much more time and effort to handle a user bug report than one generated internally.

　　當β用戶報告錯誤時，錯誤報告常常無法使用。處理一個用戶的錯誤報告比一個內部產生的錯誤報告要花費多得多的時間和精力。

　　Beta programs can be useful, but they require careful planning and monitoring if they are to do more than give a warm fuzzy feeling that at least some customers have used the product before it's inflicted on all of them. See [Kaner93] for a brief description.

　　β程序可能是有用的，但是需要仔細的計劃和監督，否則它們在激怒所有β客戶之前，除了帶來一種模糊的、興奮的感覺，認為至少有一些客戶在使用產品之外，不會后其他收獲。參見[kaner93]以獲取一個簡要描述。

　　The one situation in which beta programs are unequivocally useful is in configuration testing. For any possible screwy configuration, you can find a beta user who has it. You can do much more configuration testing than would be possible in an in-house lab (or even perhaps an outsourced testing agency). Beta users won't do as thorough a job as a trained tester, but they'll catch gross errors of the "BackupBuster doesn't work on this brand of 'compatible' floppy tape drive" sort.

　　β測試有用的一種情況是配置測試。對于任何古怪的配置，你都可以找到一個使用此配置的β用戶。你可以做比機構內部實驗室(或者甚至是外包給測試機構)多的配置測試。β用戶不會象一個訓練有素的測試員一樣做完整的測試，但他們可以捕捉到大致錯誤，像“BackupBuster在這個品牌的兼容磁帶驅動器上不能工作”。

　　Beta programs are also useful for building word of mouth advertising, getting "first glance" reviews in magazines, supporting third-party vendors who will build their product on top of yours, and so on. Those are properly marketing activities, not testing.

　　β程序也有助于建立口頭的廣告，獲得雜志的“第一印象”評論，支持第三方供應商在你的產品上構建他們的產品等等。這些都是正常的市場營銷活動，不是測試。

　　Planning and replanning in support of the role of testing

　　計劃和重新計劃測試的支持作用

　　Each of the types of testing described above, including functional testing, reduces uncertainty about a particular aspect of the product. When done, you have confidence that some functional areas are less buggy, others more. The product either usually works on new configurations, or it doesn't.

　　上面所描述的包括功能測試在內的各種類型的測試，減少了產品某一方面的不確定性。在執行完畢后，你可以確信某些功能領域的錯誤較少了，其他的還比較多。產品通常將在新配置中起作用，或者是不起作用。

　　There's a natural tendency toward finishing one testing task before moving on to the next, but that may lead you to discover bad news too late. It's better to know something about all areas than everything about a few. When you've discovered where the problem areas lie, you can test them to greater depth as a way of helping the developers raise the quality by finding the important bugs.

　　有一種很自然的傾向，就是在進行到下一個測試任務之前先完成一個任務，但這可能導致你過晚地發現壞消息。對所有領域都了解一些比深入了解幾個領域更重要。如果你發現了問題在哪個地方，你可以更深入地測試它們，通過發現重要 bug來幫助開發人員提高質量。

　　Strictly, I've been over-simplistic in describing testing's role as reducing uncertainty. It would be better to say "risk-weighted uncertainty". Some areas in the product are riskier than others, perhaps because they're used by more customers or because failures in that area would be particularly severe. Riskier areas require more certainty. Failing to correctly identify risky areas is a common mistake, and it leads to misallocated testing effort. There are two sound approaches for identifying risky areas:

　　嚴格地說，我對將測試的作用描述為減少不確定性是太簡單了。更恰當的說法是“風險加權”的不確定性。產品中某些領域比其他領域更有風險，也許是因為它們由更多客戶使用或是因為那個領域的故障更嚴重。危險性高的區域需要更好的穩定性。不能正確地識別危險區域是一個常犯的錯誤，它導致測試工作的不恰當分配。

　　1. Ask everyone you can for their opinion. Gather data from developers, marketers, technical writers, customer support people, and whatever customer representatives you can find. See [Kaner96a] for a good description of this kind of collaborative test planning.

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