今日花了數小時的時間仔細的閱讀了一下Cem Kaner教授的《What Is a Good Test Case?》一文。起初看到文章的標題原以為是一篇講述編寫測試用例所應該採用的步驟和注意事項的文章，讀完才發現原來是一篇講述評判測試用例”good”的文章。文中提出的測試用例應該更傾向於向被測程式索求資訊(不僅僅包含缺陷資訊)，以及建議在軟體測試的開始階段應該秉著以合法的資料來驗證程式是否實現了規定的功能，這兩點還是頗受啟發的。另外文章對索求的資訊目標和怎樣判斷一個測試比另一個測試（可以理解為是測試用例，也可以理解為一次測試行為）更好的判斷標準做了詳細的分類與羅列。這裡選擇其中個人認為的精華部分予以摘錄如下。

Designing good test cases is a complex art. The complexity comes from three sources:

·Test cases help us discover information. Different types of tests are more effective for different classes of information.

·Test cases can be “good” in a variety of ways. No test case will be good in all of them.

·People tend to create test cases according to certain testing styles, such as domain testing or risk-based testing. Good domain tests are different from good risk-based tests.

What’s a Test Case?

In my view, a test case is a question that you ask of the program. The point of running the test is to gain information, for example whether the program will pass or fail the test.

An important implication of defining a test case as a question is that a test case must be reasonably capable of revealing information.

Under this definition, the scope of test cases changes as the program gets more stable. Early in testing, when anything in the program can be broken, trying the largest “legal” value in a numeric input field is a sensible test. But weeks later, after the program has passed this test several times over several builds, a standalone test of this one field is no longer a test case because there is only a miniscule probability of failure.

Another implication of the definition is that a test is not necessarily designed to expose a defect. The goal is information. Very often, the information sought involves defects, but not always. (I owe this insight to Marick, 1997.) To assess the value of a test, we should ask how well it provides the information we’re looking for.

Information Objectives

So what are we trying to learn or achieve when we run tests? Here are some examples:

Find defects. This is the classic objective of testing. A test is run in order to trigger failures that expose defects. Generally, we look for defects in all interesting parts of the product.

Maximize bug count. We might focus narrowly, on only a few high-risk features, if this is the way to find the most bugs in the time available.

Block premature product releases. This tester stops premature shipment by finding bugs so serious that no one would ship the product until they are fixed.

Help managers make ship / no-ship decisions. Managers are typically concerned with risk in the field. They want to know about coverage (maybe not the simplistic code coverage statistics, but some indicators of how much of the product has been addressed and how much is left), and how important the known problems are. Problems that appear significant on paper but will not lead to customer dissatisfaction are probably not relevant to the ship decision.

Minimize technical support costs. Working in conjunction with a technical support or help desk group, the test team identifies the issues that lead to calls for support.

Assess conformance to specification.：Any claim made in the specification is checked. Program characteristics not addressed in the specification are not checked.

Conform to regulations. The test group is focusing on anything covered by regulation and nothing that is not covered by regulation

Minimize safety-related lawsuit risk. Any error that could lead to an accident or injury is of primary interest. Errors that lead to loss of time or data or corrupt data, but that don’t carry a risk of injury or damage to physical things is out of scope.

Find safe scenarios for use of the product (find ways to get it to work, in spite of the bugs). Sometimes, all that you’re looking for is one way to do a task that will consistently work. In this case, the tester is not looking for bugs. He is trying out, empirically refining and documenting, a way to do a task.

Assess quality. This is a tricky objective because quality is multi-dimensional. To assess quality -- to measure and report back on the level of quality -- you probably need a clear definition of the most important quality criteria for this product, and then you need a theory that relates test results to the definition.

Verify correctness of the product. It is impossible to do this by testing. You can prove that the product is not correct or you can demonstrate that you didn’t find any errors in a given period of time using a given testing strategy. However, you can’t test exhaustively, and the product might fail under conditions that you did not test.

Assure quality. You can’t assure quality by testing. Quality assurance involves building a high quality product and for that, you need skilled people throughout development who have time and motivation and an appropriate balance of direction and creative freedom. This is out of scope for a test organization. It is within scope for the project manager and associated executives.

Tests Intended to Expose Defects

We might say that one test is better than another if it is:

More powerful. I define power in the usual statistical sense as more likely to expose a bug if it the bug is there. Note that Test 1 can be more powerful than Test 2 for one type of bug and less powerful than Test 2 for a different type of bug.

More likely to yield significant (more motivating, more persuasive) results. A problem is significant if a stakeholder with influence would protest if the problem is not fixed.

More credible. non-credible means “No one would do that.”

Representative of events more likely to be encountered by the customer.

Easier to evaluate. The question is, did the program pass or fail the test? Ease of Evaluation. The tester should be able to determine, quickly and easily, whether the program passed or failed the test

More useful for troubleshooting. Tests that are harder to repeat are less useful for troubleshooting.

More informative. A test provides value to the extent that we learn from it.

Appropriately complex. A complex test involves many features, or variables, or other attributes of the software under test.

More likely to help the tester or the programmer develop insight into some aspect of the product, the customer, or the environment.