本文我们主要讨论测试系统及用例设计开发等方面的问题。在掌握了软件测试的重点内容并建立、批准了测试计划之后，接下来就是按照测试计划的安排组织测试项目实施。面向软件开发的软件测试与只作为最后确认验收过程的测试过程的管理是不一样的，这里我们主要以面向软件开发的软件测试为主说明这种反复循环的管理过程。

　　首先为了应对开发过程的程序反复修改，需要按照软件生命周期过程理论对阶段成果进行确认，在用户需求规格说明确定之后，开发和测试团队可以同时开展各自的工作，开发团队按照需求进行系统设计、数据库设计、数据流程设计、概要设计、详细设计等工作（该系统简称为应用软件），测试团队以用户需求规格说明及开发团队的各种设计输出为基础对用于测试应用软件而需要开发的测试软件系统（简称测试系统或测试件）及测试用例进行设计。所不同的是测试系统是测试团队自己使用，下面讨论相关内容。

　　1、测试系统设计

　　测试系统也需要根据应用软件、测试环境和自身的需要进行体系结构设计，测试系统体系结构与测试计划结合决定测试过程，被设计出来的测试系统也是一种测试工具，并且测试软件时可能需要与其他测试工具配合使用来完成测试工作，所以下面混称测试工具或测试系统，不指明它们的差别。

　　通过使用测试工具按条件选择测试用例库中的测试用例，由它们组成测试包，执行测试，获得结果？D？D测试报告。

　　测试系统本身也有质量风险问题，需要参考一般软件的质量管理进行设计和控制。

　　测试用例和活动应具有低耦合性，才易于保证测试系统本身的可靠性。由于测试资源和进度紧张，所以效率很重要，测试系统的自动程度以及灵活性、容量等影响效率和扩展。比如初始版本要求模拟每秒60个事务，软件升级后要求模拟每秒600甚至6000个事务，在测试系统设计初期是否能考虑到这种扩展？测试系统应可以随被测软件一样可以移植，否则改变环境将不能进行自动测试。测试系统与其他工具应易于交换或者使用相关数据，易于集成和维护。

　　系统增加的特性会导致测试系统对特殊操作系统甚至硬件环境的紧耦合，并可能引起用例之间相互依赖。需要权衡可移植性与功能性。

　　发现问题后，可以通过手工再现异常，通过实验隔离错误，如果测试工具设计不合理，可能导致测试异常假象，测试工具也是软件，可能同样存在多种缺陷。

　　测试系统形成的文档、数据和日志要易读，否则人员更替会导致培训、理解、更新维护困难。同时要避免测试系统产生不易识别的垃圾文件。

　　2、测试系统的基本构件：测试用例

　　行为、数据、期望结果的集合是测试发生和测试条件创建的三个因素。

　　测试用例按一定的模板（规定的项目、问题）建立，选择执行测试包中的测试用例，标识执行情况：通过、警告（有问题）、失败、阻塞（不可能执行）、跳过，对警告/失败编号，用于后面的跟踪。还应对测试用例整体进行评价。

　　测试用例模板一般包括：测试用例规格说明标识符，测试项：描述被测试的特性和条件，输入规格说明：数据名、排序、值（带有容差或生成过程）、状态、时间限制，输出规格说明：数据名、排序、值（带有容差或生成过程）、状态、时间限制，环境需要：硬件、软件、其他。特殊过程需求，用例之间依赖关系。

　　探索性测试（文档很少或没有）、文档化的用例测试都有成功和失败的例子，但探索性测试更容易落入遗漏和浮浅，文档化的用例要防止用例失效和浪费太多的时间用于编写文档化的用例，因而应平衡准确性和细节，采用两者结合的方法进行测试。

　　3、测试覆盖

　　测试覆盖的策略不是一成不变的，需要反复地考虑和调整。开发过程的测试一定要覆盖所有的功能，不一定覆盖所有的用例，但至少应覆盖所有的等价类区间。

　　测试深浅程度应从质量风险相关人员获取有价值的信息，评价并使用这些信息确定质量风险优先级数，质量风险相关人员包括顾客、最终用户、在这个领域的同事，以及诸如市场、技术支持、销售、业务分析、顾问组和其他与用户接近的人（即关键测试相关人员）。

　　把质量风险与测试用例联系起来列表，说明测试覆盖程度，高风险应对应于高覆盖程度。

　　质量风险与测试用例的关系有三种情况：无关系0、间接覆盖1、直接覆盖2。

　　交叉引用需求和设计规格说明，也可以评审对其覆盖情况。分配权值后利于统计比较。

　　配置覆盖要力求避免N维矩阵组合，要简化配置。第一要选择关键配置，有代表性的配置方式。第二随机分布N维矩阵组合中的几种，可以使用优选法。第三循环改变配置覆盖，接近完全覆盖。