3、设计测试用例

　　测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约(或设计规格说明书)，根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达。
　
　　设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。 　

　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

　　四、测试用例在软件测试中的作用

　　1、指导测试的实施

　　测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。 　

　　根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

　　2、规划测试数据的准备

　　在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

　　除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

　　3、编写测试脚本的"设计规格说明书"

　　为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书是测试用例。

　　4、评估测试结果的度量基准

　　完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

　　5、分析缺陷的标准

　　通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

　　五、相关问题

　　1、测试用例的评审

　　测试用例是软件测试的准则，但它并不是一经编制完成成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

　　2、测试用例的修改更新

　　测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

　　一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

　　3、测试用例的管理软件

　　运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。

　　有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

　　开发一个软件产品，会发布多个版本，伴随着测试用例（Test case）的不断维护， 使测试用例不断完善并与产品功能、特性(features)的变化保持一致，所以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品，多个版本常常共存，为客户提供服务，这时多个版本的测试用例也是并存的，所以在新建、修改、删除测试用例时要十分小心，并有相应的规则。

　　根据产品特性和test case一致性，分下面几种情况分别处理：

　　1. 产品特性没变，只是根据Late Discovery Bug 或 Remedy Ticket 来完善 test case，只有这时候可以修改Test case， 也意味着当前修改的test case，对目前和以前的版本都有效。

　　2. 原有产品特性发生了变化，不是new feature， 而是enhanced features（功能增强）， 这时候原有的 test case 只对先前版本（如version 1.0、2.0) 有效，而对新的版本（如 version 3.0)无效，这时绝不能修改 test case ，只能增加新的 test case，这一点很重要。原有的 test case 依然对原有版本有效（如version 1.0、2.0)。

　　3. 原有功能取消了，这时只要在新版本上使之对应的test case置为inactive（无效）。

　　4. 完全新增加的特性，大家比较清楚，增加对应的、新的测试用例。

　　这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几、十几倍的增加，可以真正保证 test case 的完整性、有效性！