软件测试相关知识_软件测试期末考试知识点

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

软件测试是软件生存周期中必不可少的环节，软件的典型生存周期可以用下图来形容：

                   

   软件测试的目的是尽可能早的发现软件缺陷并确保其得以修复，因此软件测试是提高软件质量的重要手段，大量的经验实践证明，软件测试越早参与到软件开发过程中，开发出来的软件质量相对越高，时间和物力也越经济。

    根据软件工程的基本理论，多模块程序的测试共包括以下4个层次：

  

   各阶段测试的具体内容会在以后章节具体介绍，下面介绍一下软件测试的经典技术。

 

   软件测试的经典技术分为黑盒测试和白盒测试技术。其中黑盒测试技术忽略程序内部结构，看不到程序的代码细节，只针对程序的功能进行测试，黑盒测试的方法有：

   具体方法会在以后章节中具体介绍，敬请期待。

        说完黑盒测试，就该介绍白盒测试了，白盒测试也称结构测试，白盒测试深入程序内部结构，分析程序代码结构，因此学好白盒测试，首先要掌握必要的编程语言，比如说Java或者C/C++/C#等。白盒测试的方法有：

 

   白盒测试的方法要涉及到程序图和流程图的设计，逻辑覆盖主要利用程序图，路径覆盖主要利用流程图，测试者必须能够根据程序的代码结构画出相应的程序图和流程图，白盒测试的方法也会在以后的章节中具体介绍。

 

 

 

本节主要介绍一下层次测试的第一步——单元测试。在了解单元测试之前先看一个简单的主程序树状模块图： 

 

  

 

   所谓模块测试就是在底层进行的测试，如上图，单元测试就是测试上图中紫色的模块。单元测试是整个测试的基础，单元测试中发现的错误约占程序总错误数2/3，单元测试的目标是通过对程序底层模块的静态和动态测试使底层模块达到模块说明的要求。

   单元测试主要测试5方面的的问题：

 

 

 

   模块的接口测试主要检查数据能否正确地通过模块；数据结构测试目的在于保持程序内部数据的完整性；重要路径测试是单元测试的一项基本任务，主要做好覆盖分析；程序最容易在边界上出错，因此边界条件测试是必不可少的；错误处理测试要点是在工作中发生了错误，其中的错误处理措施是否有效。

    单元测试的一般步骤：

 

  

   编译过程中主要检查对象就是代码中的语法错误；静态分析器检查使用专用工具来进行分析，代码审查主要依靠人工，第二步和第三步都是以检查结构性错误为主的静态分析；动态测试是单元测试的最后步骤，重点是发现单元的功能型错误，可采用白盒测试或者黑盒测试方法进行测试，白盒测试和黑盒测试会在以后进行详细介绍，这里知道有这两种方法即可。

   代码评审有两类组织形式：一、办公桌检查，由程序员自己审查自己的代码，仅适用于规模很小的程序。二、以小组会的方式进行，又分为走查和代码会审两种，适用于各种规模的程序。

   单元测试不是独立的程序，在多模块程序中，模块之间可以相互调用，单元测试时往往需要为被测模块编制若干模块替身，替身模块仅是真实模块的简化，仅需模拟与被测模块直接相关的一部分功能。

   根据经验总结，在单元级发现问题时，问题肯定就在那个单元中，如果在多个单元模块集成时发现缺陷，那么它一定与模块之间的交互有关。在实际情况中，有很少的例外。

好的，本节到此结束，下一节将详细介绍层次测试的第二步——集成测试。

 

 

本节主要介绍一下层次测试的第二步——集成测试。上一节我们已经在一定程度上了解了单元测试，这一节我们要讲解的集成测试就是建立在单元测试的基础上，将所有模块按照设计要求组装成一个完整的系统而进行的测试，也称为联合测试或组装测试。

   集成测试应由独立于开发人员的测试小组负责实施。集成测试重点测试所有模块的接口部分，需设计测试过程所使用的驱动模块和桩模块，在单元测试时为被测试模块做的上下级模块做的替身分别称为驱动模块和桩模块。测试方法以黑盒为主。集成测试的方案大致可分为有三种，分别是自顶而下、由底向上以及从两头逼近的混合模式。看下面程序模块：

                                                            

                                          

1. 自顶而下

      自顶而下的测试从顶模块开始，沿被测程序的结构图逐步向下测试，按照移动路线的差异，又可区分为两种不同的实施步骤，分别是先广后深和先深后广两种，以上图为例，先广后深的组装顺序：

M1——M2——M3——M4——M5——M6——M7——M8

      先深后广的组装顺序：

M1——M2——M5——M8——M6——M3——M4——M7

      自顶而下的测试要使用桩模块，如下图显示了先深后广的测试步骤：

 

                                                                                                                                             

             

  

 

                                                                                                                                              

                     

其中，S2、S3、S4、S5、S6和S8分别是M2、M3、M4、M5、M6和M8的替身。

 

1. 由底而上

    

   由底而上模式的典型步骤：

   1. 从下层找出一个没有下层模块作为开始模块，由下向上逐步添加新模块，组成程序中的一个子系统或模块群。
   2. 从另一子系统或模块群中选出另一个无下级模块开始，按步骤1进行组成一个新的子系统。
   3. 重复上一步，直到得出所有子系统，最后组装成完整的系统。

    

   例图程序模块可能的组装顺序：

   M8——M5——M6——M2

   M7——M4——M3——M1

 

1. 混合模式

     混合模式是以上两种模式的综合，其一般步骤：

1. 对上层模块采取自顶向下测试

2. 对关键模块或子系统采取由底向上测试

    

        此种模式兼有以上两种模式的优点，应用也最广泛。

 

    以上三种模式是从一个模块开始，测一次添一个模块，组装程序类似于滚雪球，所以统称为渐增式。三种模式都有各自的优缺点，综合起来，混合模式正在与扬长避短，综合了两种模式的优点，建议多采用混合模式进行总装。

 

    好的，本节到此结束，下一节将详细介绍层次测试的第三步——确认测试。

 

经过了单元测试和集成测试的学习，组装测试已经完成，接下来要进行的就是确认测试，那么本节就主要介绍确认测试。确认测试又称有效性测试或合格性测试，其任务是验证系统的功能、性能等特性是否符合需求规格说明。如下图：

 

 

   有效性测试和软件配置审查是确认测试最重要的两项工作。

   确认测试一般是在模拟的环境或者就是开发环境下运用黑盒测试法，按照需求说明书，验证软件功能、特性是否与用户需求一致。经过确认测试后，可能有以下两种情况：

1. 软件的功能、性能及其他要求均已经满足需求说明书，可能被认为是合格的软件。
2. 发现软件与需求说明书有较大的偏离，得到一个缺陷清单。这样的错误，工作量非常大，往往很难在交付期以前把发现的缺陷修复过来。此时需要开发部门和用户一起协商进行解决。

 

   软件配置审查也称配置审计，指软件工程过程中所产生的所有信息项：文档、报告、程序、表格、数据等。此阶段主要复查SCI是否齐全，检查软件的所有文档资料的完整性和正确性，然后对发现的缺陷，进行修复，最后编排好目录，以便后期维护顺利进行。

 

   确认测试继集成测试之后进行，其目的在于确认组装完毕的程序是否满足需求说明书。确认测试是由软件开发单位组织实施的最后一项开发活动，测试结束后，软件就交付验收了，因此开发单位必须十分重视这项工作，和集成测试一样，也应由独立测试小组负责实施。

 

好的，本节到此结束，下一节将详细介绍层次测试的第四步——系统测试。

 

经过了前面的总结，今天该到层次测试的最后一步——系统测试了，系统测试是验收工作的一部分，应由用户单位组织实施。软件开发单位应该为系统测试创造良好的条件，负责回答和解决测试中可能发现的一切质量问题。

   系统测试是在更大范围内进行测试。除被测试程序外，系统还可能包括硬件和原有的其他软件。系统测试的目的在于把软件产品顺利安装到系统中以后，保证软件与系统其余部分协调工作，并且符合软件需求说明书的要求。

    下面说一下集成系统的测试，下图是集成系统测试的测试内容：

 

         其中：

   功能测试主要检查软件功能是否符合需求说明的要求，基本方法是构造一些合理的输入，检查是否得到期望的输出，假如输入范围是无限的，关键在于寻找等价区间，还有一种有效的测试方法就是边界值测试，会在以后具体介绍。

   性能测试是用来测试软件在集成系统中的运行性能，特别是针对实时系统和嵌入式系统，常常与强度测试结合起来进行。

   安全性测试是为了保证安装在系统内的保护机制能在实际运行中保护系统不受非法侵入等非法行为的干扰，测试过程中需要设置一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。

   恢复测试目的在于保证系统受到某些外部事故的破坏时能够重新恢复正常工作，可以通过各种手段，强制性地使软件出错而不能正常工作，进而检验系统恢复能力。

   强度测试主要是在一些极限条件下，检查软件系统的运行情况，例如一些超常数量的输入数据、超常数量的用户、超常数量的网络连接，这对于了解软件系统的性能和可靠性、健壮性具有十分重要的意义。

   文档测试主要检查文档的正确性、完整性和可理解性。正确性指不要把软件的功能和操作写错，也不允许文档内容前后矛盾；完整性是指文档不可以虎头蛇尾，更不允许漏掉关键内容；可理解性指文档内容让大众用户看得懂、能理解。

       

   到这里，层次测试的所有阶段都介绍完了，下一节将介绍软件测试的经典方法黑盒测试中的部分内容，最后介绍一下终止测试的标准。

   软件可以终止测试的标准有两个，一个标准是规定测试策略和应达目标，例如，在白盒测试中，可以规定完全覆盖为标准，即语句覆盖和分支覆盖率必须达到100%，满足了这些条件就可以停止测试；在黑盒测试中，可以规定设计各种方法来设计测试用例，当所有测试用例全部用完时即可停止测试。另一个标准是规定至少要查出的错误数量，例如根据以往的测试经验，估算系统中的缺陷数目，规定目标是消除95%的设计缺陷和98%的编码与结构缺陷，则可以停止错误。

前面总结了软件测试层次的各阶段目标和任务等相关内容，接下来将总结软件测试的经典方法，即黑盒测试和白盒测试。其中黑盒测试有等价分类、边界值分析、错误推测和因果图等经典分析方法，本节先介绍黑盒测试中的等价分类，也称等价分配或等价划分，即分步骤的把过多（无限）的测试案例减小到同样有效的小范围过程。

 

 

    其中，有效等价类中的任何一个测试测试用例都能代表同一等价类中的其他测试用例，即从某一个等价类中任意选出一个测试用例若未能发现程序的缺陷，就可以合理地认为使用程序中的其他测试用例也不会发现程序的缺陷；无效等价类中的每一个无效等价类至少要用一个测试用例，否则有可能漏掉某一类错误。

    划分等价类有其一般步骤，下面我们就一个具体的例子来讲解等价类划分的具体步骤。

    具体问题：某软件开发公司进行人员扩增，规定应聘人员的年龄在20周岁（1992年11月前出生）到35周岁（1977年11月后出生）之间，若出生年月不在以上范围内，则拒绝面试，并显示“年龄不合格”，请使用等价类划分方法对这一程序功能设计测试用例。

    第一步：划分等价类。现规定出生年月由6位数字字符表示，前4位代表年，后2位代表月份，则给出以下3个有效等价类和7个无效等价类，如下表:

 

    第二步：设计有效等价类的测试用例。在设计有效等价类测试用例前最好将所有等价类都先编号，如上图，然后根据编号设计测试用例，使其尽可能多的覆盖尚未被覆盖的等价类，下面是设计的测试用例表：

    让几个等价类公用一个测试用例，可以减少测试次数，有利而无弊。

    第三步：为每一无效等价类至少设计一个测试用例。本例有7个无效等价类，则至少设计7个测试用例，假如少设计测试用例，就有可能产生遗漏。下面是无效测试用例。

    本程序的等价类划分就算基本写完了，学习时注意划分的一般步骤，选择测试用例时也要仔细斟酌，看是否在所要测试的等价类中。

 

   等价类划分是一种典型的黑盒测试方法，也是一种非常实用的重要测试方法，作为一个合格的测试员，应具备划分等价类并为其设计合理的测试用例的基本能力。

 

   好的，本节结束，下一讲将总结黑盒测试的另一个经典方法——边界值分析法，敬请期待！谢谢！

上一节讲到了黑盒测试中的等价分类，这一节继续总结黑盒测试又一经典测试方法——边界值分析法，其实边界值测试不是专属于黑盒测试，在白盒测试中也会用到边界值测试。

   

    边界值测试其实就是测试程序的各种边界值，边界值测试是等价分类的推广，在实际测试中，在测试程序的边界时，往往可以测试出很多缺陷，所以两种方法要结合使用，才能更好的满足程序的测试需求。边界值测试分为两部分：

 

 

      

        对于输入测试，大家也许可以理解，但是对于输出测试，大家可能理解起来有点困难了，说再多的道理不如举几个例子来说明道理，下面就和大家一起看下面的具体实例。

 

    问题一：某超市出售某品牌的高级盒装酸奶，现就元旦佳节开展促销活动，该超市将按照顾客购买量进行不同力度的促销，具体促销方案如下：

 

 

 

    分析：我们能够考虑到的边界值是1，10，20，30，因为问题中已经详细给出了边界条件，其实我们应该还要考虑的边界值还有0，9，19，29，31和无限大，具体测试用例如下：

 

 

 

    问题二：某保险公司人寿保险的保费计算方式为：

    1.保险费=投保额*保险费

    2.其中，保险费率根据投保人年龄、性别、婚姻状况和抚养人数的不同而有所不用，体现在不同的上述条件下对应的点数设定不同，10点及10点以上保险费率为0.6%，10点以下保险费率为0.1，具体规则见下表：

 

 

 

    分析：本例需要考虑的边界值比较多。不仅需要考虑输入边界，还要考虑输出边界。其中输入边界有可以分为年龄边界和抚养人数边界，点数可以作为输出边界。

 

    其中，年龄边界有：0  1  19  20  39  40  59  60  90  100  无穷大

        抚养人数边界：0  1  6  7  9  10  无穷大

                点数：9  10  11 

 

    下面是一位老师总结的边界值分析的原则：

    1.如果输入条件规定了值的范围，则应取刚达到这个范围的边界值以及刚刚超过这个范围边界的值作为测试输入数据。

    2.如果输入条件规定了值的个数，则用最大个数，最小个数和比最大个数多一个，比最小个数少一个的数作为测试数据。

    3.如果程序的规格说明给出输入域或输出域是有序集合，则应选取集合中的第一个和最后一个元素作为测试用例。

    4.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。

 

   当然原则还有好多，边界值分析的最根本的理论就是刚好大于最大值，或者刚好小于最小值。抓住这个基本点，将问题逐个分类，才是做好边界值测试的基本出发点。

 

   这一节结束，下一节将总结错误推测法，敬请关注！谢谢！

 

 

 

三国中的诸葛亮能看破天象，对敌军的破绽之处也更是了如指掌，死孔明吓跑活仲达的笑话无人不知，无人不晓。作为软件测试员就应该有孔明先生这样的本领，测试员能该把软件当作自己的敌人，兵法云知己知彼方能百战不殆。本节将总结黑盒测试中的又一常用方法——错误推测法。

    

    在错误推测法中，测试员的角色就相当于三国中孔明的角色，测试员要根据自己的经验，预测出软件中哪些地方容易出现缺陷，我们应该怎样发现缺陷，确保缺陷得以修复。

 

    常见的输入与输出错误推测情况：

 

 

      以下是一个软件测试教师总结的经验，现分享给大家。

 

经验分享一：时间性测试

          1.提交操作时限

          2.未到达的日期是否可选择

          3.前后时间限制问题

          4.系统时间的调整是否影响软件的使用权限

 

经验分享二：密码输入框

          1.密码明文显示（超级用户）

          2.复制密码，明文显示

          3.截断（字符长度限制）：Ctrl+V，鼠标

          4.限制

 

经验分享三：配置文件安全性

          

经验分享四：密宽窄屏缺陷

          

经验分享五：同时操作问题

          1.在不同机器上同时登陆同一用户

          2.对一条记录在不同机器上进行不同操作（修改、删除）

          解决方法一：锁定记录 解决方法二：给出提示信息

          3.一人审核，一人退回

          4.两个人修改同一张工单

 

经验分享六：删除为空时缺陷

          

经验分享七：自动刷新问题

          1.是否具有自动刷新

          2.局部刷新与全部刷新

          3.刷新过程中出现分辨率下降等问题

          

经验分享八：网页安全缺陷

          已登陆用户地址复制给其他用户，其他用户连接时是否显示欢迎界面

          

经验分享九：判断顺序/逻辑缺陷

          

经验分享十：用户管理

          1.超级用户，忘记删除

          2.超级用户，回收权限

          

经验分享十一：聊天窗口功能

          1.输入特殊字符后，窗口是否能够正常显示

          2.输入空格，是否能够过滤，是否会算入长度计算

          3.输入html字符

          4.输入脚本语言函数

          5.图片头像显示

          6.在需要密码验证，或者需要二次输入确认的地方，通过复制粘贴第一次的输入内容是否能             够通过

 

经验分享十二：查询功能

          1.无条件查询

          2.是否支持模糊查询

          3.查询的关键字之间是否可用连接符

          4.是否支持空格

          5.是否支持各类字符

 

经验分享十三：翻页功能

          1.首页、上一页、下一页、尾页

          2.总页数、当前页数

          3.指定跳转页

          4.指定每页显示条数

 

经验分享十四：删除功能

          1.不选择记录，进行删除，验证提示信息“请选择记录”

          2.删除记录权限验证

          3.删除结果检查

          4.删除成功后，再次添加相同记录，应可成功添加

 

经验分享十五：导入/导出/打印问题

     

    导入：

          1.模版内容是否与系统一致

          2.模版中是否有必填项、字段长度等限制

          3.导入时格式不匹配的校验，提示信息是否准确

          4.导入两条相同数据是否提示重复导入

          5.导入后验证系统中内容是否正确

          6.批量导入时，容量上限的验证、个数验证

 

    导出：

          1.表头、图标是否显示正确

          2.文件名显示有规则和实际意义

          3.导出后信息验证

 

这一节开始总结黑盒测试中的最后一种方法——因果图法，说到因果图法，就不能不说决策表法（也称判定表法），因为这两种方法经常联用，经验丰富的测试员有时跳过因果图的设计，直接设计决策表，决策表法也是最严格也最具有逻辑性的测试方法。下面先介绍一下因果图的基础知识。

 

 

   如果输入输出比较多，输入之间和输出之间相互制约的条件比较多，在这种情况下应用因果图法设计决策表很合适。因果图是一种形式化语言，是一种组合逻辑网络图，它把输入条件视为因，把输入或程序状态的改变视为果，将黑盒看成是从因到果的网络图，采用逻辑图的形式来表达功能说明书中输入条件的各种组合与输出的关系，最终生成决策表，写出相应的测试用例。   

 

 

 

    因果图的基本符号：

 

 

 

 

 

 

 

 

 

 

                  因果图的一些限制符号：

 

 

 

 

 

 

 

 

 

 

 

 

 

 

     因果图绘制的一般步骤：

 

         1.提取因果，赋予标识符

 

         2.提取因果关系，表示因果图

 

         3.标明约束条件

 

 

 

    做完因果图就要转换成判定表，做判定表的一般步骤：

 

         1.抽象出所有的条件类和动作类

 

         2.确定规则的个数

 

         3.填入条件项

 

         4.简化（合并类似规则或相同动作）

 

     

 

     绘制决策表的一般步骤不固定，假如测试员经验丰富，可以提前简化。下面是一个简单的具体实例，建议读者先根据以上知识先自行设计因果图和决策表，然后再与下面的对比，你可能设计的会更好。

 

 

 

    问题：某公司要求，对功率大于50马力且维修记录不全或已运行10年以上的机器，应给予优先的维修处理，请根据需求运用因果图法设计测试用例。

 

 

 

    因果图：

 

        a：功率大于50马力      b：维修记录不全    c：运行10年以上  

 

                 d：优先维修                 e:其他处理

 

     

 

     最初决策表：

 

 

      简化后决策表：

 

  

  
     测试用例也就是简化后的决策表用例，由于本例比较简单，所以要想全面了解因果图法，就必须多做例子，并且每个条件的情况可能数有时不一定是只有真假，有时候会很复杂，建议多做些生活中的例子，尽管很复杂，但是绘制步骤和简化思想大多是一样。

 

     到目前为止，黑盒测试的方法就总结完了，当然黑盒测试的方法还有很多，不只是只有这四种，在这里介绍的是最常用的四种。下一节将总结白盒测试，语言多以C++为主，敬请期待，谢谢。

 

从这一节开始即将总结白盒测试的常用经典技术。前面详细总结了黑盒测试和一些常用的黑盒测试技术，但是都没有打开软件的代码进行测试，黑盒测试的概念就是针对白盒测试技术命名的，那么什么是白盒测试呢？白盒测试也称结构测试，白盒测试是针对被测单元内部是如何工作进行的测试，深入程序代码细节，它根据程序的控制结构设计测试用例，主要用于软件程序验证。

               白盒测试又分为静态白盒测试和动态白盒测试。其中静态测试主要涉及代码走查和审查，就不在这里总结了，动态测试包括逻辑覆盖测试、路径覆盖测试和边界值测试等，当然分法还有好多，这里主要总结逻辑覆盖测试和路径覆盖测试。覆盖测试要以程序图和流程图辅助工具，所以在学习覆盖测试前要熟练掌握程序图和流程图的画法。

      本节主要介绍流程图和流程图到程序图之间的转化。程序流程图是描述和分析软件控制流向的通用工具，利用程序流程图设计测试用例有助于分离程序的路径，进行覆盖统计，程序流程图的主要符号：

      顺序：

     条件判断：

     先判断后循环：

     先执行后判断循环：

 

    下面看一段程序的代码，并分析画出其流程图：

    #include <iostream.h>

   void main()

  {

   inti,a[5];              //定义循环变量i，数列项n

   longsum=0;      //定义数列的和及临时变量

   cout<<“请输入5个数，作为数列每项的值:”<<endl;

   for(i=1;i<=5;i++)

   {

     cout<<“请输入第”<<i<<“个值:”;

     cin>>a[i];

   }

   for(i=1;i<=5;i++)

   {

     sum+=a[i];

   }

   cout<<a[1]<<“+”<<a[2]<<“+…+”<<a[5]<<“=”<<sum<<endl;

  }

 

 

      流程图：

 

 

 

      程序图：

 

      由于程序流程图的知识很简单，所以本节就介绍这么一个非常简单的实例，图都可以对比画出来的，程序流程图在逻辑覆盖测试中非常重要，所以以后章节的总结中也会渗透程序流程图的实例。

、

 

快世界末日了，不知道这软件测试在传说中的末日来临之前还能总结完不，不管末日来不来，软件测试的总结还得进行下去。好了今天开始总结逻辑覆盖中的语句覆盖。

 

    什么是语句覆盖呢？从字面上理解，就是把程序代码每条语句都覆盖了，至少都要执行一遍，其实意思也差不多。语句覆盖是一个比较弱的测试标准，意在选择足够的测试用例，使得程序中每条语句至少都能被执行一次，下面举一个小程序作为实例，希望大家能够在这个例子中领会其中的思想。

 

    程序的代码：

#include <iostream.h>

void main()

{

    //声明变量

    int A,B,C,a,b,c;

   //提示并存储用户输入

 

    cout<<“请输入一个整数A:”;

 

    cin>>A;

 

    cout<<“请输入一个整数B:”;

 

    cin>>B;

 

    cout<<“请输入一个整数C:”;

 

    cin>>C;

 

    //条件选择

    if(A>5)

    {

       a=A*A;

       cout<<“A>5,所以a=A*A=”<<a<<endl;

    }

    else

    {

       a=A;

       cout<<“A<=5,所以a=A=”<<a<<endl;

    }

    if(B>10)

    {

      b=B*B;

      cout<<“B>10,所以b=B*B=”<<b<<endl;

    }

    else

    {

       b=B;

       cout<<“B<=10,所以b=B=”<<b<<endl;

    }

    if(C>15)

    {

       c=C*C;

       cout<<“C>15,所以c=C*C=”<<c<<endl;

    }

    else

    {

       c=C;

       cout<<“C<=15,所以c=C=”<<c<<endl;

    }

}

 

   程序流程图如下：

 

   这段代码很简单，思路也很清晰，看到程序流程图后，思路就更清晰了，两幅图中用红色标出的路径表示E、H、K三个条件均取真时，程序执行的路径；土黄色的路径表示E、H、K三个条件均取假时，程序执行的路径。那么根据图可以看出只要走了这两条路径就可以把这段代码的所有语句执行一遍，所以测试用例也就可以相应的设计了，在这里给出了一对测试样例：

 

   测试用例1：A=6，B=11, C=16

   测试结果：

 

   测试用例2：A=5,  B=10, C=15

   测试结果：

 

    可以看出，测试结果符合题意。

    好了，语句覆盖就总结到这，过多了就不多说了，因为说多可能会和以后的覆盖分析混淆，学一种覆盖就牢牢掌握一种。

 

 

学好软件测试，必须对软件的开发有足够的了解。软件的开发过程这章主要讲解一下内容：

 

 

 

 

 

         软件产品的组成部分：            

 

 

                软件项目成员部分：

 

 

           软件的开发模式部分：

 

     

         图片上写的够详细的了，我就不再罗嗦了。

学好软件测试，必须对软件的开发有足够的了解。软件的开发过程这章主要讲解一下内容：

 

 

 

 

         软件产品的组成部分：            

 

 

                软件项目成员部分：

 

 

           软件的开发模式部分：

 

     

         图片上写的够详细的了，我就不再罗嗦了。

这一章我们要了解一些软件测试的基本常识，下面请看内容提要。

 

 

                  测试需要遵循一定的原则，原则如下图：

 

 

                   作为软件测试员必须要知道一定的常识，测试的常识也如下图：

 

 

                  测试界的术语和定义。还是如下图：

 

 

 

            了解了软件测试的实质之后，就进入了软件测试的基础知识学习阶段，在以后的几章中我会介绍一些关于软件测试的基础知识，敬请关注，谢谢。

从本章开始，将介绍软件测试的基础知识。说道软件大多都有软件产品说明书，那么怎么测试说明书以便在产品出厂之前发现缺陷呢？下面我将介绍一下测试软件产品说明书的方法。

 

        本章共分以下三部分：

 

 

              其中开始测试介绍如下：

 

 

             对产品说明书进行高级审查的介绍如下：

 

 

             产品说明书的低级测试技术介绍：

 

 

 

          读完本章，读者可能会认为测试产品说明书是一个相当主管的过程、高级审查技术可以查出遗漏和丢失之处，低级测试技术用于保证所有细节都被定义，但是这些技术不是真正的按步操作过程。

            如果读者有兴趣了解更高级的审查产品说明书技术，那么就研究一下Michel Fagan的工作，Fagan先生在IBM公司任职时，率先采用一种称为软件检测的有序方法。许多公司，尤其是生产要求严格软件的公司用它正式审查软件说明书和代码。

 

 

闭着眼睛测试软件其实就是指动态黑盒子测试。它是动态的，因为程序正在运行——软件测试员充当客户使用它；它是黑盒子，因为测试时不知道程序如何工作——闭上眼睛。   

      对于软件测试新手应聘软件测试职位，主考人一定会问如何测试新程序或者新特性，本章就将介绍最常用、最有效的软件测试技术，无论是何种类型的程序——公司的客户账目软件包、工业自动化程序还是市场流行的射击游戏，这些技术都适用。

 

        下面先看一下本章内容的概述：

 

 

           初识动态黑盒子测试：

 

 

            通过测试和失败测试：

 

 

          等价分配：

 

 

             数据测试：

 

 

             状态测试：

 

 

                     

 

           其他黑盒子测试技术：

 

 

       对于测试新手，这章是最重要的一章，这好比是面试或者上岗第一天接到软件进行测试。运用本章所讲的技术是快速找出缺陷行之有效的方法。

        本章的黑盒子测试技术是一套行之有效的测试技术，但是要用到新技术来完善。

进行到现在，已经是第六章了。本章主要讲解检查代码——静态白盒子测试——被证实是早期发现软件缺陷最有效的方法。虽然这是一项需要大量准备工作才能有成效的任务，但是许多研究表明花费的时间与得到的好处相比是值得的。

 

        下面先来看一下本章的内容概述：

           静态白盒子测试：

 

 

          正式审查：

 

 

                编码标准和规范：

 

 

          通用代码审查清单：

 

 

      

           目前，静态白盒子测试正在受到重视，而在某些开发过程中，没有它，项目就无法得到可靠的软件。