关于软件测试的问题我们在前几期的文章中讨论过很多次了,尤其是对于需求文档的结构与组成方面的内容更多。今天,我们就一起来了解一下,软件测试中的测试依据到底是指什么。希望通过对本文的阅读,大家对软件测试有更多的了解。
软件测试中的测试依据到底是指什么
软件测试基础理论中,我们提出了一个概念,叫做‘测试依据(test
basis)’。从字面意义上理解,测试依据就是就是我们测试可以依据它来进行测试分析,以及用例编写的文档或者信息;他被用来指导我们的测试,我们可以从中提炼出‘测什么’‘怎么测’这样测试根本性问题的答案。没有了测试依据,测试工作就将无从下手。
说到测试依据,我们直接会想到的就是需求文档了,根据项目特性的不同,他有可能呈现为不同的格式:比如需求规格说明书式,又比如原型图式等等。而根据需求文档内容分解和描述形式的区别,他又有可能呈现为用户故事型(User
Story)或者产品需求文档型(PRD)。
我们始终要明白一件重要的事情是,测试依据,其实指的并不仅仅只是需求文档。从本质上说,他应该包括所有可以指导我们测试的信息。下面我们就来一一探讨一下,都有哪些信息我们可以拿来用作测试依据,以及怎么来使用它们。
一个是开发部门的设计文档,包括我们在软件生命周期中提到的架构设计,详细设计阶段的产出。
开发部门在进行上述设计工作的时候,有可能会产出比需求阶段更丰富的文档,比如架构设计图,算法设计图,模块的详细设计说明书,接口定义文档,数据库设计说明书,界面设计线图等等等等。
实际工作中,你会发现,开发部门产出的设计文档往往会包含对产品更详尽,丰富的定义信息。基于这些文档提供的信息,我们就可以更进一步,深层次的确定我们测试所需要覆盖的范围和内容。
当然,理论上而言,这些设计文档只是开发部门为了实现需求而做出的分析性产出,他并不一定完全匹配初的产品需求甚至用户需求。我们使用这些设计文档的前提判断是:开发部门与需求部门有足够的沟通,他们的产品设计是符合需求的。为了确认这一事实,我们测试人员可能需要来回往返于开发团队和需求团队(或用户)之间来寻求肯定的答复(一个典型的状况是,需求团队对于用户需求的解读并不够细致详尽,事实上他可能根本没有思考到相应深刻的程度,而对于开发通过主观判断给出的设计,他也许并提不出什么意见,只能表示认可)。
还有一种状况是,对于某些细节性的处理,也许连设计文档都不曾包括,而是在开发团队与需求人员(或直接客户)的口头,会议交流中确定了某些做法。这些约定,一旦没有知会到我们测试团队,那么我们的测试就会走弯路甚至出错误。所以作为测试团队,我们应该尽可能要求参加进项目调研分析阶段的各项讨论活动和会议,并且要把这些口头约定的内容用文字记下来(比如用邮件,发给各与会方),从而形成我们的测试依据文档。相信我,在项目收尾阶段,我们去交付自己的测试成果时,有这些记录在案的约定处理会让你更有底气。
事实上,在当今的软件测试体系工程内,有一些领域大部分情况是没有需求支持,我们通常都会用现存的成熟标准来实现测试-一个典型的例子就是安全性测试。在我们去做安全性测试的时候,大部分情况下都不会有详尽需求来给我们指引,但是我们在这个领域内有着非常成熟的一套测试标准,比如说我们会测试Web项目的cookies安全性,防御XSS攻击的能力,数据库信息加密存储等等等等。
作者:Vincent
节选:软件测试网
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!