软件测试学习总结3教学内容Word文档格式.docx
- 文档编号:7021289
- 上传时间:2023-05-07
- 格式:DOCX
- 页数:9
- 大小:273.48KB
软件测试学习总结3教学内容Word文档格式.docx
《软件测试学习总结3教学内容Word文档格式.docx》由会员分享,可在线阅读,更多相关《软件测试学习总结3教学内容Word文档格式.docx(9页珍藏版)》请在冰点文库上搜索。
有什么异同?
优缺点对比。
1.6回答:
有哪些常见的错误\缺陷举例?
了解这些错误\缺陷有什么益处?
1.7回答:
软件开发生命周期瀑布模型中的测试级别有哪些?
图1测试概述目录结构
2.测试目的
因为人类会犯错,软件中经常有错误,错误的程序会得出一些不是预期的结果,用户会感觉到不悦、无法接受、影响使用等等,所以为了减少这样的现象,对我们的软件质量有一个了解,或者是演示正确的操作,就需要做软件测试。
书中对软件测试目的总结是:
对质量或可接受性做出一个判断,以及发现问题。
图2测试目的
3.测试术语
当我们想要了解测试是什么?
怎么做测试?
我们先了解一下其它大多数人在测试这个主题中都有些什么研究,都认可的一些术语或者总结,这样有助于我们了解和学习测试知识。
测试是一个需要协作和沟通的工作,建立一些共识(基本定义),才能有效沟通和协作。
本书所有的术语都是参照IEEE所指定的标准。
一些基本定义:
错误:
人类会犯错误。
同义词是过错,在程序中被成为bug。
缺陷:
缺陷是错误的结果,更确切的说缺陷是错误的表现。
失效:
当缺陷执行时会产生失效。
事故:
当出现失效时,可能会也可能不会呈现给用户(或客户或测试人员)。
事故说明出现了失效类似的形式,警告用户注意出现的失效。
测试:
测试显然要处理错误、缺陷、失效和事故,测试是采用测试用例执行软件的活动。
测试有两个显著目标:
查找失效,演示正确的操作。
测试用例:
测试用例有一个标识,并且与程序行为有关,测试用例还有一组输入和一个预期输出表。
本书通篇都是使用的是IEEE制定的标准,如图是错误、缺陷、失效和事故之间的关系:
图3错误、缺陷、失效之间的关系
测试用例与测试之间的关系:
测试用例是测试的工具,测试是采用测试用例执行软件的活动。
这里又重新定义了测试的目的,与之前的定义不同,其实是不矛盾的,此处是测试实际活动想要达到的结果,这个结果是有理论框架支持并且实际的衡量刻度标准的。
之前给出的测试定义是一个高度浓缩的术语。
图4测试定义
测试过程如图:
图5测试过程
4.测试用例
测试用例是测试的工具,此处我们研究测试包含的内容。
图6测试用例信息
说明:
测试用例ID:
测试用例首先要有ID,测试集合中会有很多测试用例,那么怎么区分测试用例呢?
测试用例ID作为主键信息,测试用例的开发、评审、使用、管理和保存都是通过测试用例ID来作为标识的。
测试目的:
该测试用例测试目的,需要验证的内容。
前提:
测试用例执行的环境。
输入:
测试用例特定的输入信息,例如:
输入框中输入字符,点击按钮。
预期输出:
期望的输出结果。
后果:
除了预期输出之外的影响。
日期:
测试用例执行记录日期。
结果:
测试是否通过。
版本:
程序的版本号,测试用例执行时的对应关系。
执行人:
测试用例执行人。
总结:
根据测试用例的内容,首先要确定此次执行测试用例的范围,是一系列的测试用例编号,根据编号,我们找到对应的测试用例,根据前提和版本号确定测试用例执行环境。
按照测试用例内容输入,执行测试用例得到输出结果,对比预期输出和输出结果,判断测试用例是否通过。
执行历史记录测试用例执行的日期、结果、版本和执行人。
5.通过维恩图理解测试
现实的开发过程中,大部分图都是由开发人员来编写的组织结构图,组织结构图只是来说明程序或者产品是什么,然而测试其实关注的是他做什么,所以在测试过程中,只通过组织结构图,不能很好理解测试,作者引进了维恩图来理解测试,举例行为之间的集合关系:
如图是标注了你想要的是什么(集合S)和程序实现(集合P)之间的关系,从图中明显看出S与P之间存在不完全重叠的现象,说明需求规格和程序之间是有差异的,并且这样的差异是客观存在的,测试要做的就是检查这些差异,因此需要通过测试来实现。
S
P
需求规格
(预期的)说明
程序
(观察的)
程序行为
图7所描述的行为与所实现的程序行为
图7说明了需求规格与开发程序之间的关系。
如果特定的需求描述行为没有程序实现、或者程序实现了需求规格说明没有描述的部分,作为一个测试人员,我们所关注的就是这些都是问题。
增加测试用例T的集合,从而出现如下情况:
图8已描述、已实现和经过测试的行为
图8,已描述行为与程序行为交集是区域1和2,是程序行为按照已描述行为正确实现的部分;
测试用例与程序行为的交集是1和3,是测试用例和程序行为一致的区域;
已描述行为与测试用例之间文档交集是1和4,此区域是已描述行为与测试用例一致的区域。
图中,1是需求规格说明、程序和测试用例都覆盖的部分,这部分就是我们所期望。
利用集合的关系研究图8,区域2和5,是没有测试到的已描述行为;
区域1和4,是经过测试的已描述行为;
区域3和7是没有描述的测试行为;
区域2和6是没有测试的已描述行为;
区域4和5,是程序未实现的已描述行为。
区域3和6,是程序实现的未描述行为。
6.标识测试用例
有两种基本方法标识测试用例:
功能性测试和结构性测试。
如果有测试基础的人,可能会听说过黑盒测试或者白盒测试,功能性测试用例对应的就是黑盒测试,结构性测试对应的就是白盒测试。
黑盒测试(功能性测试)通俗的理解就是不管实现方法和原理,把功能当做未知的黑盒子,只需要对其做输入输出验证,从而标识测试用例。
白盒测试是按照功能实际实现的方式来标识测试用例,用什么方法来实现这个功能,然后就按照这个方法来验证是不是使用了这个方法,这个方法有没有漏洞等等。
图9测试用例标识方法
功能性测试参考需求规格说明,而结构性测试以程序源代码为根据。
假如有程序没有按照需求说明来开发,遗漏了某个需求点,只用结构性测试是发现不了的;
另外如果程序实现了需求之外的功能,功能性测试也不会发现。
两种方法单独使用都是不充分的。
通过维恩图来理解功能测试和结构性测试标识测试用例的关系,如图:
S:
功能性测试
P:
结构性测试
图10功能性测试与结构性测试标识测试用例的方法
当我们做一件事情,或者需要达到某个目标有两个或者两个以上的方法时,自然会想到哪个方法更好,什么情况下使用什么方法,那么先了解功能性测试和结构性测试标识测试用例优缺点,如图:
图11功能性测试和结构性测试优缺点对比
7.错误与缺陷分类
书中描述错误和缺陷是过程与产品之间的关系,按照缺陷的定义:
缺陷是错误的表现。
个人理解,因为犯错或者产生了错误,导致产品有缺陷。
也就是做了不应该做的,没有按照规则做,所以产品(程序源代码、结构图或者流程图等)有了缺陷。
此处举例了一个按照缺陷后果严重程度来划分等级,根据后果严重程度的方式能合理化调整开发资源,并且不阻碍测试进度。
图12根据后果严重程度的错误与缺陷分类
如果我们能够了解可能在哪些地方容易犯错误,或者是程序有哪些类型缺陷,我们可以根据这些知识点来明确使用哪种标识测试用例的方法。
集中测试力量来对可能发现的缺陷的地方进行测试,避免盲目和地毯式检查,没有侧重点,从而浪费了测试精力。
8.测试级别
测试级别反应软件开发生命周期瀑布模型中的抽象级别。
其中测试级别与功能性和结构性测试存在现实的关系。
大多数实践者认为单元测试适合结构性测试,系统测试适合功能性测试。
图13瀑布模型中抽象与测试级别
9.总结
每个章节的总结都能对应学习目标中的问题点。
概述章节学习之后,我理解测试的目的,以及怎么做测试(理论知识基础),并且测试是一个技术含量的工作,在测试理解、测试经验、测试思路上都是有优劣之分的,也为后续章节展开说明提供了理论框架。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 学习 总结 教学内容