测试用例

本文以设计性能测试用例为示范，讲解在企业实际工作中，如何有效划分测试种类和编写对应的测试用例，使测试工作更加合理、高效率的开展。

其实，测试用例不是必须的。如果你是一个特别有想法的人，或者在软件测试方面很有天赋，每天都能找到其他人几天时间才能找到的Bug，那么你可以不用测试用例。但是不幸的是，你可能不是这样的人，或者你身上存在着几种情况，就最好使用测试用例。

经验而言，个人觉得，测试软件中最重要的因素还是要：设计和生成有效的测试用例。所以，作者在开章之处特别提及测试用例，我认为是很必要的。

测试用例是有一定的分类的。要是没有科学分类的用例，是不便于维护和阅读。

没有需求文档对于编写测试用例来说，确实很困难，做为测试人员，在没有测试需求文档情况下，我们不能等着开发人员输出，应该主动点，尽可能去多了解项目的一些情况，多知道一点，对测试用例就能多写点。

回归测试就是修改完bug之后对程序的新的一轮测试，据微软的统计，按照他们的经验，一般开发人员解决3~4个bug会衍生出一个新的bug，这就是必须作回归测试的原因。

刚看到每周一问中有对黑盒测试覆盖率的讨论，其实也就是对测试用例如何设计的讨论，现在谈一下我的观点（只针对功能测试）。

测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？

首先对需求说明书进行分析，整理出测试需求，其中包括需求说明书中的显性需求以及未涉及到的隐性需求，并对需求的重要程度进行划分。

写完代码后，你当然要测试它。有许多种方法来测试代码：你可以在你的代码中加些断点，或者观察实际发生的情况并和你预计的结果相比较，又或者写些测试程序等等。

功能测试用例的设计方法

在软件测试中，测试用例的设计是一件很难的事情。你可以拿任何一个公司的两个不同人员就同一功能点所写的测试用例来看，肯定会发现有所不同，这是为什么呢？一是着眼点不一样，二是经验不同，三是思维的问题了。其实你可以看到，有的人写的用例简单明了，有的人写的用例却是复杂冗长，出现这种情况并不奇怪，因为测试用例本身的设计方法与技巧很多都是从经验中来的，有些形成了理论，而有些还形成不了能够指导测试活动的理论。

在几家外企的测试理念带动下，软件测试，一夜之间突然变成了个香饽饽。但在许多中国的软件企业里，测试工作，似乎仍遭遇着某些尴尬。

回归测试就是修改完bug之后对程序的新的一轮测试，据微软的统计，按照他们的经验，一般开发人员解决3~4个bug会衍生出一个新的bug，这就是必须作回归测试的原因。

统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。

对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已,所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用,这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）.

本文介绍了一些自动化测试实现过程中可能碰到的问题，以及如何评估这些问题带来的工作量，为自动化测试团队开展自动化测试前对项目实现自动化测试的成本估算提供了一些参考。

能发现到目前为止没有发现的缺陷的用例是好的用例。首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。

高手过招，手中无需用剑，只要轻描淡写地以口代手，三两句话便高下立判，胜者胜得痛快，输者也输得潇洒。然而，除了在武侠小说之内，恐怕很难有地方让你感受到这种“会当凌绝顶”的痛快。本文根据作者在测试工作中的体会，提出了一种被称为“测试用例预演”的方法，用模拟的测试用例执行发现程序中潜在的问题，这种方法究竟有何神奇呢？请见内文。

本文的目的不是将软件测试流程优化的话题阐述的面面俱到，而是从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理流程的一些改进思路。