200602271215442.html

软件工程的红包书

<P>&nbsp; ·编制软件测试大纲</P>
<P>&nbsp; ·设计和生成测试用例</P>
<P>&nbsp; ·实施测试</P>
<P>&nbsp; ·生成软件问题报告</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;对整个测试过程进行有效的管理实际上,软件测试过程与整个软件开发过程基本上是平行进行的。测试计划早在需求分析阶段即应开始制定,其它相关工作,包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等也应在测试阶段之前进行。充分的准备工作可以有效地克服测试的盲目性,缩短测试周期,提高测试效率,并且起到测试文档与开发文档互查的作用。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 此外,软件测试的实施阶段是由一系列的测试周期(Test Cycle)组成的。在每个测试周期中,软件测试工程师将依据预先编制好的测试大纲和准备好的测试用例,对被测软件进行完整的测试。测试与纠错通常是反复交替进行的。当使用专业测试人员时,测试与纠错甚至是平行进行的,从而压缩总的开发时间。更重要的是,由于专业测试人员丰富的测试经验、所采用的系统化的测试方法、全时的投入,特别是独立于开发人员的思维,使得他们能够更有效地发现许多单靠开发人员很难发现的错误和问题。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 软件测试大纲是软件测试的依据。它明确详尽地规定了在测试中针对系统的每一项功能或特性所必须完成的基本测试项目和测试完成的标准。无论是自动测试还是手动测试,都必须满足测试大纲的要求。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 一般而言,测试用例是指为实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。测试用例控制着软件测试的执行过程,它是对测试大纲中每个测试项目的进一步实例化。已有许多著名的论著总结了设计测试用例的各种规则和策略。从工程实践的角度讲有几条基本准则:</P>
<P>&nbsp; 1.测试用例的代表性:能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等;</P>
<P>&nbsp; 2.测试结果的可判定性:即测试执行结果的正确性是可判定的或可评估的;</P>
<P>&nbsp; 3.测试结果的可再现性:即对同样的测试用例,系统的执行结果应当是相同的。</P>
<P><STRONG>八、制定成功的测试计划</STRONG></P>
<P><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; “工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到<a href="200603061723295.html" tppabs="http://www.itisedu.com/phrase/200603061723295.html" target="_new">框架</a>结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 产品基本情况调研：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 具体的要点有：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置， 粗略的估计测试大致需要的周期和最终测试报告递交的时间。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;产品规格：就是制造商和产品版本号的说明。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 测试需求说明：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 测试的策略和记录：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 经验判断：对以往的测试中，经常出现的问题加以考虑。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;测试资源配置：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 计划表：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 问题跟踪报告：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。</P>
<P>&nbsp;&nbsp;&nbsp; &nbsp; 问题描述尽可能是定量的，分门别类的列举，问题有几种：</P>
<P>&nbsp; 1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。</P>
<P>&nbsp; 2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。</P>
<P>&nbsp; 3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 测试计划的评审：</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 结果：</P>