《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx

上传人:b****5 文档编号:21494216 上传时间:2023-01-30 格式:DOCX 页数:11 大小:340.32KB
下载 相关 举报
《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx_第1页
第1页 / 共11页
《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx_第2页
第2页 / 共11页
《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx_第3页
第3页 / 共11页
《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx_第4页
第4页 / 共11页
《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx_第5页
第5页 / 共11页
点击查看更多>>
下载资源
资源描述

《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx

《《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx》由会员分享,可在线阅读,更多相关《《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx(11页珍藏版)》请在冰豆网上搜索。

《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjunWord文档格式.docx

图1测试概述目录结构

2.测试目的

因为人类会犯错,软件中经常有错误,错误的程序会得出一些不是预期的结果,导致用户会感觉到不悦、无法接受、影响使用或者非常严重的经济损失等等,所以为了减少这样的现象,以及在软件投入生产使用之前,对软件质量有一个了解,或者是演示正确的操作,就需要做软件测试。

书中对软件测试目的总结是:

对质量或可接受性做出一个判断,以及发现问题。

图2测试目的

3.测试术语

当我们想要了解测试是什么?

怎么做测试?

我们先了解一下其它大多数人在测试这个主题中都有些什么研究,都有哪些可参考的术语或者总结,这样有助于我们了解和学习测试知识。

测试是一个需要协作和沟通的工作,建立一些共识(名词的基本定义),才能有效沟通和协作。

本书所有的术语都是参照IEEE标准。

一些基本定义:

错误:

人类会犯错误。

同义词是过错,在程序中被成为bug。

缺陷:

缺陷是错误的结果,更确切的说缺陷是错误的表现。

失效:

当缺陷执行时会产生失效。

事故:

当出现失效时,可能会也可能不会呈现给用户(或客户或测试人员)。

事故说明出现了失效类似的形式,警告用户注意出现的失效。

测试:

测试显然要处理错误、缺陷、失效和事故,测试是采用测试用例执行软件的活动。

测试有两个显著目标:

查找失效,演示正确的操作。

测试用例:

测试用例有一个标识,并且与程序行为有关,测试用例还有一组输入和一个预期输出表。

如图是错误、缺陷、失效和事故之间的关系:

图3错误、缺陷、失效之间的关系

测试用例与测试之间的关系:

测试是采用测试用例执行软件的活动,测试目的是找出失效或演示正确的操作。

这里又给了测试目的,如图:

图4测试定义

如下是测试的详细过程:

图5测试过程

4.测试用例

软件测试的本质是针对要测试的内容制定一组测试用例。

那么测试用例包含的什么信息?

如图:

图6测试用例信息

测试用例内容项说明:

测试用例ID:

测试用例首先要有ID,测试集合中会有很多测试用例,那么怎么区分测试用例呢?

测试用例ID作为主键信息,测试用例的开发、评审、使用、管理和保存都是通过测试用例ID作为标识的。

确定一组有效的测试用例,最终的表现就是一组测试用例ID集合。

测试目的:

该测试用例测试目的,需要验证的内容。

前提:

测试用例执行的环境。

输入:

测试用例特定的输入信息,例如:

输入字符,点击按钮。

预期输出:

期望的输出结果。

后果:

执行测试用例后实际输出结果。

日期:

测试用例执行记录日期。

结果:

测试是否通过。

版本:

被测程序的版本号。

执行人:

测试用例执行人。

开发测试用例填写内容:

1首先确定测试用例编号,不能与其它测试用例编号重复。

2填写测试目的,描述该测试用例验证的功能点。

3填写测试用例运行的环境。

4填写输入信息。

5填写预期输出结果。

执行测试用例填写内容:

1确定单个测试用例ID,准备执行。

2按照测试用例输入操作。

3填写后果(实际输出结果)。

4填写执行历史记录:

结果。

对比预期结果和实际输出结果,填写测试结果(是否通过)。

5填写执行历史记录:

日期

6填写执行历史记录:

版本

7填写执行历史记录:

执行人

5.通过维恩图理解测试

现实的开发过程中,大部分图都是由开发人员编写的组织结构图,组织结构图只是来说明程序或者产品是什么,然而测试其实关注的是它做什么,所以在测试过程中,只通过组织结构图,不能很好理解测试,作者引进了维恩图来理解测试,举例行为之间的集合关系:

如图是标注了你想要的是什么(集合S)和程序实现(集合P)之间的关系,从图中明显看出S与P之间存在不完全重叠的现象(S不等于P),说明需求规格和程序实现之间是有差异的,并且这样的差异是客观存在的,测试要做的就是检查这些差异。

图7所描述的行为与所实现的程序行为

图7说明了需求规格与开发程序之间的关系。

如果特定的需求描述行为没有程序实现、或者程序实现了需求规格说明没有描述的部分,作为一个测试人员,我们所关注的就是这些都是问题。

增加测试用例T的集合,从而出现如下情况:

图8已描述、已实现和经过测试的行为

图8,已描述行为与程序行为交集是区域1和2,是程序行为按照已描述行为正确实现的部分;

测试用例与程序行为的交集是1和3,是测试用例和程序行为一致的区域;

已描述行为与测试用例之间的交集是1和4,此区域是已描述行为与测试用例一致的区域。

图中,区域1是需求规格说明、程序和测试用例都覆盖的部分,这部分就是我们所期望的范围,测试有一种很好的观点是,测试就是确定既被描述又被实现的程序范围。

利用集合关系研究图8,区域2和5,是没有测试到的已描述行为;

区域3和7是没有描述的测试行为;

区域2和6是没有测试的程序行为;

区域4和5,是程序未实现的已描述行为。

区域3和6,是未描述的程序行为。

6.标识测试用例

有两种基本方法标识测试用例:

功能性测试和结构性测试。

如果有测试基础的人,可能听说过黑盒测试或者白盒测试,功能性测试用例对应的就是黑盒测试,结构性测试对应的就是白盒测试。

黑盒测试(功能性测试)通俗的理解就是不关心实现方法和原理,把功能看作未知的黑盒子,只需要对其做输入输出验证,从而标识测试用例。

白盒测试是按照功能实际实现的方式来标识测试用例,用什么方法来实现这个功能,然后就按照这个方法来验证是不是使用了这个方法,这个方法有没有漏洞等等。

图9测试用例标识方法

功能性测试只利用规格说明标识测试用例,而结构性测试以程序源代码为根据标识测试用例。

假如有程序没有按照需求说明来开发,遗漏了某个需求点,只用结构性测试是发现不了的;

另外如果程序实现了需求之外的功能,功能性测试也不会发现。

两种方法单独使用都是不充分的。

通过维恩图来理解功能测试和结构性测试标识测试用例的关系,如图:

S:

功能性测试

P:

结构性测试

图10功能性测试与结构性测试标识测试用例的方法

当我们做一件事情,达到某个目标有两个或者两个以上的方法时,自然会想到哪个方法更好,什么情况下使用什么方法,那么先了解功能性测试和结构性测试标识测试用例优缺点,如图:

图11功能性测试和结构性测试优缺点对比

7.错误与缺陷分类

书中描述错误和缺陷是过程与产品之间的关系,按照缺陷的定义:

缺陷是错误的表现。

个人理解,因为犯错或者产生了错误,导致产品有缺陷。

也就是做了不应该做的,没有按照规则做,所以产品(程序源代码、结构图或者流程图等)有了缺陷。

此处举例了一个按照缺陷后果严重程度来划分等级,根据后果严重程度的方式能合理化调整开发资源,并且不阻碍测试进度。

图12根据后果严重程度的错误与缺陷分类

该小节提到了SQA(软件质量保证),该职位或者组织一直是努力改进过程,从而改进产品,怎么理解?

比如,小明经常在组织结构图和程序代码的注释中写错别字。

那么SQA首先是要按照错误与缺陷分类指标对“结构图和程序注释有错别字”进行分类,假如根据后果的严重程度进行分类,该错误属于“轻微”,对于轻微的错误与缺陷,SQA会制定一个流程,从过程上要求来减少同类型问题发生,例如编写的结构图和注释,需要有人评审,并且由直接领导确认,生成checklist对错误别字进行检查。

对应的错误与缺陷有一系列的流程,努力改进流程,从而让产出的产品减少次类型的错误与缺陷。

流程中,也就是SQA努力改进的过程,过程中莫一项可以是测试,测试也是一项活动,是过程中的一项活动。

测试级别

测试级别反应软件开发生命周期瀑布模型中的抽象级别。

其中测试级别与功能性和结构性测试存在现实的关系。

大多数实践者认为单元测试适合结构性测试,系统测试适合功能性测试。

图13瀑布模型中抽象与测试级别

9.总结

每个小节的总结都能对应学习目标中的问题点。

测试概述章节学习之后,我理解了测试的目的,以及怎么做测试(理论知识基础),并且测试是一个有技术含量的工作,在测试理解、测试经验、测试思路上都是有优劣之分的,也为后续章节展开说明提供了理论框架。

各章节之间的关系,开篇就对测试目的的阐述,回答了我们为什么要测试,之后就需要建立一个测试理论的基本框架。

第1小节,就是测试相关的基本定义,全篇中的术语都是按照IEEE标准。

测试是采用测试用例执行软件的活动。

从测试的定义,我们发现测试用例占据了测试的中心地位。

然后第2小节就讲了测试用例的内容和测试用例中各项内容的代表含义。

同时也说明了测试详细步骤:

测试计划、开发测试用例、执行测试用例和评估测试结果。

为了理解需求规格说明和程序实现之间的关系,加深测试理解,作者在第3小节就通过维恩图对测试进行了说明,测试是已描述行为(需求规格说明)S、程序行为P和测试用例T,此3个集合之间的关系,3个集合的交集、并集、补集关系都是在测试中需要验证的结果,由于此3个行为之间存在S不等于P不等于T,那么S\P\T之间的共同重叠区域是什么样的?

这部分就是期望的区域,测试就要验证这个重叠区域范围。

测试用例的内容说明之后,如何标识测试用例,有哪些基本方法标识测试用例?

第4小节就说明了功能性测试(黑盒测试)和结构性测试(白盒测试),有两种标识测试用例方法。

两种方法的优点、缺点分析,以及标识测试用例参考的依据说明,最后两种方法的关系,都是第4小节的主要内容。

测试是为了处理错误、缺陷、失效和事故。

那么第5小节就对错误与缺陷举例说明,错误和缺陷可以通过不同的维度进行区分,并且良好的区分,有助于软件质量保证和测试获益。

假如对缺陷进行后果的严重程度划分,那么就可以针对后果严重程度制定处理解决方案。

书中还对缺陷从IEEE中摘取和作者常见的异常做了列表。

开篇的基本定义中就对错误、缺陷做了定义说明。

最后小节说明了测试级别,测试级别反映了软件开发生命周期瀑布模型中的抽象级别。

测试级别分了单元测试、集成测试和系统测试,测试级别与功能性测试和结构性测试存在现实的依赖关系。

单元测试适合结构性测试,系统测试适合功能性测试,从而测试级别需要使用第4章说明的标识测试用例方法。

总体来说,第1章的各个章节主要都是解释说明,关键在于本书搭建的测试理论的理解和记忆。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 人文社科 > 广告传媒

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1