模板
教程
环境
性能
功能
管理
什么是好的测试用例(二)[1]
测试在于暴露缺陷
把我们关注的焦点局限在测试团队的两个主要目的上：
除了开发团队意外的人，会考虑寻找有关的(值得报告的)缺陷并修改这些缺陷。
即使在这些目的范围内，也有很多种不同的好的测试方法。例如，我们也许会说一个测试好于另一个测试，如果它：
更有力。
根据一般的统计学常识，我是这样理解有利的：如果存在缺陷就更可能暴露出来。注意，对一类缺陷来说，测试1比测试2更有力;对另一类缺陷来说，测试1不如测试2有力。
更可能产生重大(更有根据、更有说服力的结果)。
如果对一个重大问题有影响力的负责人拒绝修改这个问题。(负责人是指对产品有影响的人。对产品有影响力的负责人是指其喜好和观点会导致产品变更的人。)
更可靠。
可靠的测试更可能像是程序员或其他有影响力的负责人进行的真实的(或合理的)操作集合。“边角测试”是程序员惯用的一个例子，它是说测试或缺陷不可靠：“没有什么可以证明它。”如果有些(或所有)对产品有影响力的负责人同意测试用例的真实性，那么它就是可靠性。
更可能发现客户遇到的典型事件。
设计的很多测试都有很高的可信度。让你的人去影响真正的使用用途。
越经常出现的活动组就越可能被覆盖或完全覆盖。(我说的活动组是指很多特性同时被用，所以我们就追踪哪些特性集合体按照什么次序被使用了，并根据我们的分析反映这些信息。)更详细的请参阅Musa的(1998)关于软件可靠性工程。
更易于评价。
问题是程序是否通过了测试?为了易于进行评价，测试人员应该有能力快速、不费力地决定程序是否能通过测试。说程序可能是否会测试是不够的。较难进行评价的是，花费的时间越多，错误越可能在不经意间闪过。面对费时的评估，测试人员会用便捷的方法、另辟蹊径来减少程序是否完好的费时的评测。这些便捷的方法往往不完全精确(就是说，他们会发现不了明显的缺陷或把正确的代码标记为错误的。)
更有利于解决问题。
比如，在不能给有关测试条件提供大量信息以重现问题的情况下，大量的自动测试经常会搞毁系统。
他们对解决问题没有好处。越难重复的测试越不利于解决问题。
如果需要解决的问题是由这个测试发现的，那么这个测试就越难执行，下次测试也越难执行正确。
更有信息量。
测试的价值就是我们能从中学到东西。
大多数情况下，你从通过测试的程序中学到的东西比没通过测试的程序中学到的多，但有信息的测试会教你(减少不确定性)判定程序是否能通过测试。
比如，如果我们已经在多次构建之后运行了一个测试，并且程序每次都可靠地通过测试，那么我们就期望程序能再次通过这项测试。从重复测试中得到的另外的“通过”结果不会有助于我们对程序的认知。
等价类的观点是信息价值的另一个例子。任何测试背后都是一个测试集，他们之间有很高的相似度，我们认为其他测试实质上是这个测试的冗余。用口头的行话说，这就是“等价类”或者“等价部分”。如果这些测试充分的相似，那么第二次测试得到的附加信息会少于第一次测试。
这个标准很接近于Karl Popper的实验价值理论(参考Popper 1992)。优秀的实验涵盖了风险预测。这个理论预言人们期望的某些事物并不真实，你偏爱的理论是错的或者会令许多人感到惊讶。Popper分析认为优秀的实验(优秀的测试)是近似于科学哲理的主流核心理念。
或许，在这里真正要考虑的是，你希望从测试中学到的东西与测试设计、运行的机会成本是均衡的。你花费在测试上的时间就是你没有花费在其他测试或活动上的时间。
更加复杂。
一个复杂的测试包含被测软件的很多方面、或变量、或其他属性。
当程序有很多变更或一次测了很多特性时，不提倡用复杂测试。如果程序存在很多BUG，复杂测试很快就会失败，也就没必要再执行它了。测试组主要依靠复杂测试发现模块化的BUG。模块化的BUG使很多测试都无法通过，阻碍测试组了解测试应该暴露的信息。因此，测试初期，进行简单测试是合理的、有必要的。当程序更稳定时，或(在极限编程或任何开发生命周期)程序有了更稳定的特性时，更复杂的测试就会变得更有意义。
更可能帮助测试人员或编码人员洞察产品、客户或者外界环境的某些方面。
有时，我们通过测试了解产品，了解其如何运转以及存在的风险。随后，我们会设计测试来暴露产品的缺陷，但测试刚开始时，我们会对“是什么”和“怎么测”感兴趣。很多这样的测试不会重复进行。然而，在第一次测试环境中，期望(典型地，单元)测试集合警示编码人员实验上出现代码变更的副作用。在这种环境下，设计的测试会标记出性能变更、化整误差的差异、或者其他某些变更，这些都不是缺陷。程序中意想不到的变更会警示编码人员，她的代码或代码变更影响的原型是不完整或错误的，并引导她进行额外的测试或者解决问题。(感谢Ward Oummingham和Brain Marick提供的这个例子。)
