外部评审主要工作方式是用文档直接记录评审结果，测试人员根据评审结果对用例进行升级修改。
测试部门内部评审––部门内部同行对测试策略的评审，评审的核心内容是测试策略和用例编制思路是否正确，以此来保证测试用例的有效性。可以组织正式的评审，由用例的设计人员进行讲解，然后大家共同评审;也可以把文档发给部门的同事进行评审。内部评审有些象开发人员在单元测试中的交叉测试。
内部评审的主要工作方式是项目会议，大家可以进行激烈的讨论，共同探讨用例编写、交流经验，这样用例的编写水平才能提高，同时可以进行一些创新。
评审方式中的外部评审最为重要。因为开发人员很容易发现用例中遗漏了什么内容，同时还可以发现错误的用例––因为存在对需求理解的偏差。用例外部评审可以理解为开发人员在查找测试人员编写的“程序”缺陷。
通常情况下先执行内部评审，然后执行外部评审。很多时候，内部评审会被忽略，建议要进行内部评审。这样至少有两个好处：集思广益和提高测试小组输出文档的质量。
3.2 管理方案
国内大多数IT公司在测试用例的发展经历了以下几个阶段：
无用例而执行测试：测试的初级阶段，完全手工测试，测试执行工程中没有测试用例作为执行依据，可能会按照需求进行测试;
有用例而不使用用例执行测试：已经编写测试用例，但是受各种环境的影响，例如需求变动频繁、编写的用例过于简单等，测试用例编写后在实际工作中不能使用;
按照部分用例执行测试：随着用例编写水平的提高，部分测试用例可以在测试中发挥作用;
完全按照用例执行测试：组织建立了规范的项目管理过程，对测试用例进行规范的管理，执行测试用例以用例为准则来执行测试。
完全按照测试用例执行测试是一个公司测试水平的体现，测试用例管理成为这一阶段的主要内容。测试用例管理的核心内容是版本管理。如果测试用例是采用文字编辑软件例如word编写，建议采用工具(例如Visual SourceSafe)对用例进行控制。可以参照图2进行。
编写用例
用例评审
进入版本控制库
用例修改
使用用例&维护&升级
图2 测试用例管理示意图
1、 编写用例：测试工程师根据需求分析、概要设计、详细设计等文档编写测试用例。
2、 用例评审：3.1小结说明了用例的评审。原则上用例像程序一样，要经过多次的修改才可以通过，而实际工作中只进行一到两次。
3、 用例修改：评审结束后，需要根据评审意见进行修改，修改后通常不再进行评审。建议在时间和人力资源比较充裕的情况下，对用例的评审要像测试开发部门的产品一样，经过反复的评审和修改，然后正式投入使用，因为每次评审可能都有新的发现。
4、 使用用例：在执行任务时，从版本控制库取出用例，执行时建议直接在用例上记录测试结果。这样做会带来两个好处：首先是下次测试时可以看见上次测试的结果记录，可以起一个提醒的作用;其次可以一次性的把发现的缺陷输入到缺陷跟踪数据库中，在输入时可以进行综合统计，避免输入重复的缺陷。每次使用后送入版本控制库中，进行版本的管理。
5、 用例升级/维护：随着软件产品的不断修改、升级，对应的用例也需要升级和维护。针对同一个项目，可以根据需求的变更不断进行维护;如果是产品，用例的维护则更加重要，要达到用例和产品的版本一一对应。
测试用例的管理还可以采用专门的测试软件例如TestDirector等来进行管理，测试工具通常会具备上面的功能。如果有条件，建议采用集成华的测试工具，这样更容易对测试执行全程进行监控，可以把测试需求、测试用例、缺陷管理统一起来，大大提高测试效率。
在测试用例管理规范化并成为测试的执行准则后，管理测试用例带来的巨大好处开始逐渐显现出来，测试用例成为评估测试和改进测试工作的主要依据，可以给工具带来巨大的方便。例如可以通过测试用例的执行情况来统计分析执行结果，编写测试报告，判断软件测试是否完成，通过统计测试覆盖率、测试合格率、重要测试对象的合格率是多少来完成对软件质量的评估;尤其是新员工到岗后，可以更容易介入工作。
总之，不管是性能测试还是其它测试都要本着“一切从实际出发”的原则，根据不同产品的特性进行用例编写，最后按照要求完成测试，达到提高产品质量的目的。在测试用例的编写过程中，尤其要记得“创新”，如果长期依靠某一测试用例编写模式、采用某些固定的模板，测试用例编写工作肯定会停滞在某一层次上不再发展，一定要跟着测试对象的不断变化来调整策略，在具体的工作中改进和提高，才能“开发”出优秀的测试用例!
文章来源于领测软件测试网 https://www.ltesting.net/
