怎样才算是一个好的测试用例

今日花了数小时的时间仔细的阅读了一下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.

怎样才算是一个好的测试用例相关推荐

毕业设计计算机画册怎么做,问题：我们的毕业设计是制作一个宣传画册，那怎样才算是一个好的宣传画册呢...
问题:我们的毕业设计是制作一个宣传画册,那怎样才算是一个好的宣传画册呢发表日期:2016-03-29 20:45:02 浏览:338 分享给朋友: 导语专业顾问回答:热心朋友回答:宣传画册设计基本原 ...
怎么才算是一个合格的coder
十一假期过后,疫情反复.有一个问题,怎么才算是一个合格的coder?我认为能独立从头完成一个功能模块的开发时,才算是一个合格的coder~ 我们做程序员的面试经常被关注的几个问题:毕业几年.项目经历. ...
怎样才算是一个合格的网页设计师？
随着互联网的盛行,市场上各行各业的企业对于网站的更新换代都有着不等级别的需求,然而网页设计师这个专业便是一个赤手可热职位.在上海建站行业里面什么样的网页设计师才算是合格的,对于企业网站设计理念,设计思 ...
怎样的项目才算是一个成功的项目于病视神，未有形而除之
http://www.nowamagic.net/librarys/veda/detail/2466参与各种项目已经好几年了,大大小小的项目也做过了很多.经历了很多,也明白了很多.现在反思下,什么样的 ...
io操作 mysql_怎样的操作才算是一个IO操作？
你好. 关于如何才算一个IO的问题,我可以在这里简要讲解,IO在不同层次有不同的概念和单位.一次IO就是一次请求,对于磁盘来说,一个IO就是读或者写磁盘的某个或者某段扇区,读写完了,这个IO也就结束了 ...
怎样才算是一个好的老师？？？
个人觉得,老师至少可以分四类: 第一类,带你入门的老师: 第二类,带你升级的老师: 第三类,给你指方向的老师: 第四类,被称为"老师"的教书匠: 要成为一个合格的第一类老师,个人觉 ...
什么才是一个好的团队？
无聊的时候经常在想,怎么样的团队才算是一个好的团队?从一开始工作到现在其实经历的的团队不多,但也不算少,随便总结总结. 先说是领导,往往什么样的领导决定了会产生什么样的团队,团队中领导经常是资历最老的 ...
什么才算是“好的”测试用例？
什么才算是"好的"测试用例? 通常,你的第一反应很可能会是"发现了软件缺陷的测试用例就是好的用例",我可能会反问你"如果说测试用例发现了缺陷就是好用例 ...
02.如何设计一个“好的”测试用例？
文章目录什么才算是"好的"测试用例? "好的"测试用例必须具备哪些特征? 三种最常用的测试用例设计方法第一,等价类划分方法第二,边界值分析方法第三,错误 ...

怎样才算是一个好的测试用例

怎样才算是一个好的测试用例相关推荐

最新文章

热门文章