软件测试学习总结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.总结
每个章节的总结都能对应学习目标中的问题点。
概述章节学习之后，我理解测试的目的，以及怎么做测试（理论知识基础），并且测试是一个技术含量的工作，在测试理解、测试经验、测试思路上都是有优劣之分的，也为后续章节展开说明提供了理论框架。
升级会员 