《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjun.docx

《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjun.docx

《《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjun.docx》由会员分享，可在线阅读，更多相关《《软件测试》Software testing A Craftmans Approach学习第1章总结liuchuangjun.docx（11页珍藏版）》请在冰豆网上搜索。

《软件测试》SoftwaretestingACraftmansApproach学习第1章总结liuchuangjun

《软件测试》第1章学习总结

1.章节学习目标

1.1回答：

为什么要做测试？

1.2了解本书中的一些测试术语。

1.3通过维恩图理解测试。

1.4回答：

什么是测试用例？

测试用例的内容包含什么？

1.5回答：

标识测试用例的方法有哪些？

有什么异同？

优缺点对比。

1.6回答：

了解几种不同维度区分的错误与缺陷分类，为什么这样分？

1.7回答：

软件开发生命周期瀑布模型中的测试级别有哪些？

图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章的各个章节主要都是解释说明，关键在于本书搭建的测试理论的理解和记忆。