系统测试续一.docVIP

系统测试续一 8.8.4系统测试设计在系统测试需求确定后，可以开始测试设计工作。而测试设计又是整个测试过程中非常重要的一个环节，测试设计的输出结果是测试执行活动依赖的执行标准，测试设计的充分性决定了整个系统过程的测试质量。因此，为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。测试设计一般的流程是：首先理解软件和测试目标，然后设计测试用例，接着运行测试用例并处理测试结果，最后评估测试用例和测试策略。在确定测试设计流程时既强调目的性也强调计划性，目标是追求测试的高效率和测试的理想结果。当然，水能载舟，亦能覆舟。文档化和按部就班可以降低管理难度，增强计划性，但也可能扼杀测试人员的经验作用和灵感。1.理解软件和测试目标目的：建立软件故障模型，了解测试目标，来确定测试策略和测试计划。任务：了解软件的功能和业务背景、用户环境，了解软件的开发背景和系统结构、技术选型，了解软件的质量历史、版本变化，了解系统的测试目标和资源限制，确定测试策略和测试计划。方法：阅读软件使用手册，理解软件运行环境和用户行为，了解同类软件的功能和使用，了解软件要解决的问题域和解域(业务背景知识)；试运行软件，从中熟悉软件功能，确定软件基本可以测试；了解软件体系结构、技术选型、开发环境和工具；阅读早期版本测试报告，以及单元测试和集成测试报告；确定测试人员限制和时间限制，制定初步测试策略和测试计划，确定测试结束标准。结果：1)建立错误模型，指导回答该软件可能的错误会出现在哪里(用户环境与测试环境不一致会不会出问题，没有测试过的代码或功能里面会不会出问题，没有测试过的输入组合、极端环境或功能使用方法、使用顺序等会不会出问题)，如何做才能发现这些错误等问题.。2)在了解测试目标和资源限制之后，按照错误的性能价格比制定设计测试用例的优先级，并确定初步的测试策略和测试计划。3)确定测试结束标准或测试退出机制(已经解决的错误没有重现，所有缺陷报告已经关闭，所有测试用例全部执行完毕，通过错误播种、错误发生曲线分析、历史数据等相应方法统计出所遗留的未发现错误数量可以被接受，以及不属于技术层面且实际表明测试失败或者部分失败的市场和管理因素、预算和时间用完等因素)。2.设计测试用例目的：设计尽可能多、快、好、省发现错误的测试用例(即能够找到尽可能多的、以至于所有的BUG；能够尽可能快或早地发现最严重的BUG；找到的BUG是关键的、用户最关心的，且找到BUG后能够重现找到的BUG，并为修正BUG提供尽可能多的信息；能够用最少的时间、人力和资源发现BUG，且测试的过程和数据可以重用)。任务：理解故障模型、理解现有的测试用例库、设计具体的测试用例。方法：采用基于故障模型如经验、历史数据/错误、软件开发和运行环境的软件攻击法(这需要创造性思维，而且要注意保证满足测试多、快、好、省的要求，并要有以孙子兵法进行指导的战役思想，当然还要记住没有银弹的教诲)。结果：测试用例(IE4.0的测试用例数目：10万)。测试用例没有标准文档格式，对于特殊人或在特殊情况下可以在运行后再形成文档。测试用例文档由简介和测试用例两部分组成：简介部分描述了测试目的、测试范围、定义术语、参考文档、概述等；测试用例部分逐一列出各测试用例(包含的要素为标题和编号、版本号、修改记录等，针对目标和假设前提/可能发现的错误，输入和数据/代码，测试步骤，预期输出和错误发现方法)。表8-3是一个简单的测试用例设计表格。表8-3测试用例设计表测试用例ID输入预期结果实际结果测试统计利率贷款期限(年)贷款金额(元)月支付总支付总利息月支付总支付总利息通过/失败测试日期测试人员TC-001 8%30 80000 578.01 TC-002 8.5%30 80000 615.13 TC-003 8.5%15 80000 787.79 3.运行测试用例并处理测试结果目的：使用测试用例发现错误并关闭错误。任务：运行测试用例并记录结果，评估测试结果并记录缺陷，处理缺陷直至缺陷关闭(即修改、延迟处理、不修改、不是错误)。方法：选择测试用例库中的测试用例运行，选择新设计的测试用例运行，录制/回放或者笔录中间步骤和结果，记录下执行过程中的灵感(但不要轻易修改本次执行任务)，分析测试结果并尽量重现和优化错误步骤，详细填写缺陷报告并提供尽可能多的信息(如尽可能提供错误分析和修改建议)，认真审核错误处理结果并及时关闭缺陷报告。结果：记录下的运行结果，记录下的新的测试用例设计思路，提交并处理的缺陷报告。4.评估测试用例和测试策略目的：检验测试用例和测试策略的有效性，必要时对测试用例和测试策略进行完善和修改，增加测试经验。任务：根据测试结果完善、修改、合并测试用例，如果没有文档化测试用例，此时需要文档化；另外，对测试用例库进行维护。即增加新的测试用