软件测试学习笔记

第1章 绪论

软件测试    

        本质上说，就是寻找软件的缺陷、错误，对其质量度量的方法与过程。软件测试的一切活动都围绕着两个目标（验证是否符合需求，识别差异）而行进。它是测试思维、策略方针、设计实施的基本出发点。

学习内容

        1.软件质量保证与测试的产生、发展；

        2 软件缺陷、软件错误、软件故障；

        3 软件质量保证与测试的意义、 原则和挑战。

1.1 软件质量保证与测试的产生、发展

 软件测试是伴随着软件的产生而产生的。  

        产生与发展的过程

        早期的软件规模小、复杂程度低，软件开发的过程相当随意，开发人员将软件测试等同于“ 调试”，常常由开发人员自己完成这部分工作。    

        总体而言， 跟软件测试相关的工作投入极少，测试工作介入也晚， 常常是等到代码编写出来， 产品已经基本完成时才进行测试。

        直到1957年，软件测试才开始与调试区别开来，成为一种专门致力于发现软件缺陷的活动。           由于当时人们对软件测试的目的理解为“使自己确信产品能工作”，所以软件测试通常在程序代码编写之后进行。  

        当时也缺乏有效的测试方法， 主要依靠“错误推测 Error Guessing”来寻找软件中的缺陷。             因此，大量软件交付后， 仍存在很多问题， 软件产品的质量无法保证。    

        1972年，软件测试领域的先驱BillHetzel（比尔黑则尔）博士在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。  

        1973年，他首先给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期的设想运行”。  

        核心观点：软件测试是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的。  

        这是以正向思维方式，针对软件系统的所有功能点，逐个验证其正确性。被称为第一类方法。软件测试第一类方法：验证软件是“工作的”。

        1975年约翰·古迪纳夫和苏珊·格哈特在IEEE上发表了“测试数据选择的原理”一文，软件测试才被确定为一种研究方向。    

        第一类方法受到很多业界权威的质疑和挑战，代表人物GlenfordJ.Myers（格伦福德·迈尔斯）。    

        1979年，他发表的代表性论著《软件测试艺术》可算是软件测试领域的第一本最重要的专著。    

        他认为测试不应该着眼于验证软件是工作的，而应该首先认为软件是有错误的，然后用逆向思维去发现软件中尽可能多的错误。    

        他还从人的心理学的角度论证，如果将“验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。

        GlenfordJ.Myers（格伦福德·迈尔斯）于1979年提出了他对软件测试的定义：“测试是为发现错误而执行一个程序或者系统的过程”。    

        Myers还给出了与测试相关的三个重要观点，那就是：      

        1、测试是为了证明程序有错，而不是证明程序无错误；      

        2、一个好的测试用例是在于它能发现至今未发现的错误；    

        3、一个成功的测试是发现了至今未发现的错误的测试。    

        这就是软件测试的第二类方法，简单地说就是测试是验证软件是“不工作的”，或者说是有错误的。    

        Myers认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。

        到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成。    

        软件测试定义发生了改变，测试不单纯是一个发现错误的过程。    

        人们将“质量”的概念融入其中，而且将测试作为软件质量保证的主要职能，包含软件质量评价的内容。

        1983年IEEE提出的定义：“使用人工或自动化的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求、弄清预期结果与实际结果之间的差别”。    

        软件测试总的来说是一种事后检查的方法，如果软件研发前期工作做得不好，完全依赖测试很难保障软件产品的质量，鉴于此，结合事先预防，过程监督和事后检查的软件质量保证就应运而生。

类比：    

        测试——>质量保证与测试    

        毕业考试——>日常督查与考试

        软件质量保证与测试观念变化的过程

基本概念

        软件测试（1983）    

        使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

        软件质量保证    

        软件质量保证是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动，它贯穿于整个软件过程。

软件质量保证活动

（1）质量管理方法；

（2）在各个软件过程中采用的正式技术评审；

（3）有效的软件工程技术（包括方法和工具）；

（4）多层次的测试策略；

（5）对软件文档及其修改的控制；

（6）保证软件遵从软件开发标准；

（7）度量和报告机制。

软件质量保证与测试

        软件测试是软件质量保证中重要的一项活动，但软件质量保证不仅仅包括软件测试，还包括检查、评审等其他很多活动。

        软件质量保证也不仅仅只是测试人员的工作，它需要专职的软件质量保证人员，也需要软件开发人员参与相关工作。

1.2 软件缺陷、软件错误、软件故障（失败）

（1）第一个bug

        英文的注解：臭虫、缺陷、损坏、窃听器、小虫等

        1945年9月9日， 下午三点。美国海军编程员、 编译器的发明者 格蕾斯·哈珀（ Grace Hopper） 正领着她的小组构造一个称为“ 马克二型”（又重又大，由继电器、转轴及离合器所构成，使用了近百万个原件及几百里长的电线，重达4.5吨，据推测，你买一台放家里玩一会纸牌，你家的小区估计就没电了）的计算机，盛夏时期，电脑散发的热量使机房里简直不能呆人，高温经常导致电路中断，造成工作故障。这天，马克二型像往常一样死机，技术人员测试了很多方法，最后定位到第70号继电器出错。哈勃观察出错的继电器，发现一只飞蛾躺在中间，它被继电器打死，她用镊子小心地将蛾子夹出来，用粘胶黏到了“事件记录本”中，并记下“第一个发现虫子的实验” 。

        于是后来， bug一词成了计算机领域的专业术语， 比喻那些系统中的缺陷或问题。

        程序员、bug相爱相杀    

        很多程序员：“在我不长的编程生涯中，一直都是bug陪我走过的”。    

        程序员的工作：开发项目写bug，解决bug。需求变动出现bug，解决bug。交给测试，测出bug，解决bug。项目上线出现bug，解决bug。

（2）软件缺陷

        软件缺陷的概念

        缺陷是存在于软件（ 文档、 数据、 程序） 之中的那些不希望或不可接受的偏差。 缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

        IEEE729-1983对缺陷有一个标准的定义： 从产品内部看， 缺陷是软件产品开发或维护过程中存在的错误、 毛病等各种问题，从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

        软件缺陷的外在表现

        软件出现了产品说明书指明不会出现的错误；

        软件未达到产品说明书的功能；

        软件功能超出产品说明书指明范围；

        软件未达到产品说明书虽未指出但应达到的目标；

        软件难以理解、 不易使用、 运行速度缓慢， 最终用户认为不好。

软件缺陷的产生的原因

        软件缺陷的产生， 主要是由软件产品的特点和开发过程决定的。 那么造成软件缺陷的主要原因有哪些？ 下面从软件自身的特点、 团队工作和技术问题等角度来分析软件缺陷产生的原因。

        1.软件自身的特点；

        2.团队合作

        3.设计和实现问题

        4.管理问题

        1.软件自身的特点

        1）软件本身的实际需求不清晰，导致设计目标偏离实际需求，从而引起功能或产品特征上的缺陷。    

        案例：某网上售票系统，一开始把系统的同时在线购票用户数量定位在十万数量级， 但在实际应用中，同时在线购票用户数量可能会达到百万甚至千万数量级， 这样就会引起负载或强度问题。系统过载会导致性能下降， 而如果负载超过其强度极限， 则可能会彻底瘫痪或崩溃。

        2）系统结构非常复杂， 而又无法设计成一个很好的层次结构或组件结构， 结果导致意想不到的问题或系统维护、 扩充上的困难； 即使设计成良好的面向对象的系统， 由于对象、 类太多， 很难完成对各种对象、 类相互作用的组合测试， 而隐藏着一些参数传递、 方法调用、 对象状态变化等方面问题。

        3）对一些实时应用， 需要进行精心设计和技术处理， 保证精确的时间同步， 否则容易引起时间上不协调、 不一致所带来的问题。

        4）系统运行环境的复杂， 不仅用户使用的计算机环境千变万化， 包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题。    

        案例：   美国迪斯尼公司狮子王游戏软件兼容性问题

        Windows系统兼容性问题：该游戏最初设计用于Windows 95系统，因此在较新的Windows系统上可能会出现兼容性问题。例如，在Windows XP上可能会出现命令提示符窗口打开但游戏无法启动的情况；在Windows 7上可能会提示应用程序与x86不兼容；在Windows 10上可能会提示目录损坏或无法读取。

        解决方法：

        兼容性模式：尝试以兼容模式运行游戏。例如，右键点击游戏的可执行文件，选择“属性”，在“兼容性”选项卡中选择“以兼容模式运行此程序”，并选择Windows 95或Windows 98。         禁用杀毒软件：某些杀毒软件可能会阻止游戏运行，尝试暂时禁用杀毒软件后再运行游戏。

        检查文件完整性：如果怀疑游戏文件损坏，可以尝试重新下载或安装。

        5）由于通信端口多、 存取和加密手段的矛盾性等， 会造成系统的安全性或适用性等问题。

        2.团队合作

        1）系统需求分析时对客户的需求理解不清楚， 或者和用户的沟通存在一些困难。

        2）不同阶段的开发人员相互理解不一致。    

        例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。

        3）对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。

        4）项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。           https://zhuanlan.zhihu.com/p/692369596

需要分析的关键点：

       你最终写出来的Prompt究竟是给谁用的？要识别到这个实际的用户。有的时候客户和用户不见得是一样的，客户可能是这个项目的推动者，或者是决策者，买单者，但是他推动完决策完，把单买了之后，使用提示词的人却不是他。

        对某个软件进行软件测试时：

        ① 包含缺陷fault的代码可能没有被执行到；

        ② 测试执行到了包含缺陷fault的代码， 但由于不满足特定的输入条件， 不一定会产生错误的中间状态error；

        ③ 产生了错误的中间状态， 但没有传播到最后输出， 我们从外部没有发现问题。

        以上情况都会导致测试工作不充分， 发现不了软件中存在的缺陷！

        PIE模型   案例

// 定义一个公共的静态方法myave，该方法接收一个int类型的数组numbers作为参数，从方法名推测其功能可能是计算数组元素的平均值
public static void myave(int []numbers) {// 获取传入数组numbers的长度，并将其赋值给变量length，用于后续循环遍历和计算int length = numbers.length;// 声明两个double类型的变量，ave用于存储计算得到的平均值，sum用于存储数组元素的总和double ave, sum;// 将sum初始化为0.0，为后续累加数组元素做准备sum = 0.0;// for循环用于遍历数组，计算数组元素的总和。这里从索引1开始遍历存在逻辑问题，正常计算总和应从索引0开始for(int i = 1; i < length; i++) {// 将数组中索引为i的元素累加到sum中sum += numbers[i];}// 计算平均值，用累加得到的总和sum除以数组的长度lengthave = sum / length;// 尝试在控制台输出计算得到的平均值，但system拼写错误，正确的应该是System（Java中标准输出流的类名首字母大写）system.out.println("ave: " + ave);
}

        不看源代码， 通过执行软件， 能够发现的问题只有PIE 模型中外部层面的软件failure， 也就是表现出来的问题。 程序中处于内部静态层次的缺陷fault， 和内部中间状态层次的error， 是难以通过执行软件来直接检测出来的。

1.3 软件质量保证与测试的意义、 原则和挑战

        1.软件规模越来越大    

        KB → MB → GB    

        航天飞机： 软件代码4000万行

        空间站： 软件代码10亿行 缺陷与代码量正相关， 软件中的缺陷也越来越多！

        缺陷与代码量相关，软件中的缺陷也越来越多。

        2.软件数量越来越多  

        仅以苹果APP为例， 截止2016年3月31日， 全球共有190万款苹果APP应用。中国区每天新增大概是100-300之间。

        3.软件复杂度越来越高， 使得缺陷产生的概率增大

        4.软件应用越来越广泛和深入， 而新研发的软件往往缺陷较多。  

        新研发的软件可能会应用新的方法、技术、工具、采用新的形式，用于新的领域，由于缺少经验积累，缺陷往往会较多。  

        5.软件在事关国计民生重要领域的应用使得对软件质量要求越来越高，软件的质量风险起来载大。

软件质量保证与测试的重要性

        软件质量保证与软件测试已成为一项专业化要求越来越高的工作， 需要采用专门的方法和技术， 需要借助各种专业化的工具，需要专业人才甚至是专家来承担。    

        事关国计民生的重要软件， 没有严格的质量控制，不经过充分测试，就投入使用， 可能造成恶性事故！

        1.爱国者导弹防御系统失效    

        海湾战争中， 1991年2月25日， 一枚伊拉克飞毛腿导弹击中了沙特阿拉伯载赫蓝的一个军营， 炸死了美国陆军的28名士兵， 爱国者导弹防御系统未能拦截。    

        政府调查指出， 拦截失败归咎于导弹系统时钟内的一个软件错误。

        2.美国航天局火星登陆事故      

        1992年2月3日， 美国航天局的火星极地登陆飞船在试图登陆火星表面时逆向推进器意外关闭， 飞船坠毁。    

        这一事故的后果非常严重， 损失巨大， 而起因却是控制软件设计中的缺陷。 事后分析测试发现， 当飞船的支撑腿迅速打开准备着陆时， 机械震动很容易触发着地触电开关， 关闭登陆逆向推进器。

        3. 致命的辐射治疗      

        2000年， 巴拿马从美国Multidata公司引入的治疗规划软件， 其辐射剂量的预设值有误。        

        患者接受了高达100倍预定剂量的所谓治疗。 至少有5人死亡。 后续几年中， 又有21人死亡。        

软件质量保证与测试的意义：

        及早发现问题、 解决问题， 降低返工和修复缺陷的成本 ；

        防止事故， 降低失效成本；

        保证软件产品达到一定的质量标准；

        对软件质量进行客观评价 ；

        提高软件产品质量、 满足用户需求。

（1）预防成本

        是预防软件项目发生质量问题所产生的成本，规划质量与质量保证的成本都属于预防成本，如制定质量保证计划，制定质量标准、组成人员培训等。

（2）评估成本

        是检查软件产品或生产过程，确认它们是否符合要求而发生的成本，如评审和测试成本。对软件进行质量控制的成本属于评估成本。

（3）失败成本

        是纠正缺陷，弥补缺陷造成的损失所发生的成本，又分为内部失败成本或外部失败成本。    

        内部失败成本：在交给客户之前企业内部和处理缺陷所产生成本；    

        外部失败成本：指客户拿到或者使用软件产品之后出现质量问题而产生的处理成本。

        适当增加预防成本和评估成本，可以大幅度降低失败成本，从而使得总的软件质量成本得到降低。

        早期就存在的问题如果没有被发现和解决，随着开发过程的推进会被逐渐放大，越迟发现问题、解决问题，所要付出的成本就会越大。  

        假设一个问题在需求分析阶段被发现和解决的成本是1，那么到了后续阶段就会快速上升到数倍、数十倍、甚至成百上千倍。

        某企业有一个软件项目，在需求分析中对一项子功能的5行文字描述是错误的，但没有发现，在概要设计中这5行错误的文字描述变成了错误的4页概要设计文档，在详细设计中，变成了错误的20页详细文档，而编码阶段，就成了5000行错误的代码。

        学习软件质量保证与测试

        并不是只有将来专门从事软件质量保证与测试工作的人员， 才需要学习软件质量保证与测试。

        所有参与软件项目的人都应当树立软件质量保证与测试的理念。

        开发人员也必须学习和掌握软件质量保证与测试的基本知识、 方法、 技术和工具。

        一般而言软件开发人员需要对自己所开发的软件完成基本的测试， 只有懂测试的开发人员才能开发出高质量的软件， 软件质量保证与测试的理念、 知识和能力是对软件开发工程师的一项基本要求。  

软件质量保证与测试的基本原则

        软件质量保证与测试要贯穿于整个软件生存期

        软件质量保证与测试要预防为主， 发现为辅;

        软件质量保证与测试需要客观性;

        软件质量保证与测试需要独立性;

        软件质量保证与测试的最终标准都应追溯到用户需求;

        软件质量保证与测试应妥善保存一切过程文档 。    

        不对软件不做充分测试是不负责任的。

        过度的测试也是一种严重浪费。

        关于软件质量保证与测试的一些错误认识

        软件质量保证与测试由专人负责， 与开发人员无关；      （×）

        软件质量保证与测试与开发、测试等所有参与软件项目的人都有关，人人关注质量，保证质量才能生产出高质量的软件。

软件质量保证与测试面临的挑战

1.软件质量保证理念还没有深入人心  

        理想状态： 所有软件研发人员都把软件质量保证当成是一种自觉的约束 (mental discipline)，不用太多的测试投入就可产生低风险的软件，目前距离这一理想状态，还有很长的路要走。    

        实际情况： 重产品轻质量； 重开发轻测试； 赶进度降成本。

2.软件测试技术发展滞后  

        软件测试技术的发展也很快， 但是其发展速度仍落后于软件开发技术的发展速度。  

3.如何通过软件质量保证与测试保证重要、关键软件不出问题这是一个挑战。      

        例如武器控制系统、航空航天软件，银行证券软件等，这样的软件如果出现质量问题则后果可能非常严重。  

4.对于实时系统来说，缺乏有效的测试手段。

5.随着安全问题的日益突出，信息系统的安全性如何进行有效的测试与评估，是世界性的难题。

6.新的软件应用对软件质量保证与测试提出了新的挑战，如移动应用软件、嵌入式软件等。 7.软件的规模越来越大，由此产生的测试任务越来越繁重。

8.随着软件变得越来越复杂，研发过程中出现各种问题的概率在增大，相关的软件质量保证工作难度在增大，如何进行充分而有效的测试成为了难题。

9.面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步。  

10.对于分布式系统整体性能还不能进行很好的测试。  

第 2 章 软件测试的策略

1.软件测试模型、 阶段和生命周期

2.软件测试方法和技术概述

2.1 软件测试模型、 阶段和生命周期

1.软件测试模型

我们应当怎样来进行软件测试？

        软件测试过程模型是对测试过程的一种抽象。      

        软件测试专家总结出了很多测试模型。    

        这些模型将测试活动进行了抽象，并与开发活动有机的进行结合，划分了不同的测试阶段，是进行测试过程管理的重要参考依据。

        单元和集成测试应检测程序的执行是否满足软件设计的要求；      

        系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标。      

        验收测试确定软件的实现是否满足用户需求或合同的要求。

不足：        

        开发与测试是先后关系， 先开发后测试。    

        忽视了对需求分析， 系统设计的验证和确认， 需求的满足情况一直到后期的验收测试才被验证。    

        如果开发阶段没有有效的质量控制措施， 到软件编码完成之后， 通过测试发现大量缺陷和错误， 再想提高软件质量， 则成本会非常高， 有时甚至已经不可能。

        相对于V模型， W模型增加了软件开发各阶段中同步进行的验证和确认活动。    

        W模型由两个V字型模型组成， 分别代表软件质量验证、 确认、 测试过程 和 软件开发过程。      

        W = V + V

        W模型强调： 软件需求分析、 软件设计等同样需要质量控制， 应当及时进行验证和确认。

        软件需求、 软件设计阶段需要为后续的软件测试工作做准备、 测试与开发是同步进行的。

        验证、 确认和测试等软件质量控制活动伴随着整个软件开发周期。

优点：

        有利于尽早、 全面的发现问题。 例如， 需求分析完成后， 质量保证与测试人员就应该参与到对需求分析文档的验证和确认活动中， 并尽早的发现问题。

        有利于降低软件开发的总成本。 因为越早发现问题，解决问题的成本就会越小。  

        有利于提前做好测试准备和测试设计。 例如在需求分析阶段就可以及早进行验收测试设计， 这将显著减少测试工作所产生的时延， 加快项目进度。  

总结

        W模型通过测试早期介入和全生命周期覆盖，能够显著降低项目风险，提高交付质量。 而V模型的串行流程导致测试滞后，无法应对需求变更和复杂系统的挑战。 在实际项目中，W模型尤其适用于需求变化频繁、系统复杂度高的场景，如电商平台、金融系统等。验收测试：        

        从用户的角度对软件产品进行检验和测试，看是否符合用户的要求。验收测试可以分成两类， 针对具有大量用户的通用软件， 可以采用Alpha测试 + Beta测试， Alpha测试是由用户在开发环境下完成的测试， Beta测试是由用户在用户环境下完成的测试； 而针对只有特定用户的专用软件， 可以采用用户正式验收测试。软件测试的生命周期  

1. 测试需求分析      

        明确需要完成的测试任务、 测试内容和要达到的测试要求。简单地说，所谓测试需求就是明确要测试哪些内容。  

        测试需求可以由软件文档获取， 例如软件的规格说明书中明确了软件具有某项功能， 那么就需要测试这项功能是否实现。    

        测试需求除了有功能测试需求之外还可以有非功能测试需求， 如性能测试需求、 安全性测试需求。

2. 测试计划            

        描述所有要完成的测试工作， 包括被测试项目的背景、 目标、 范围、 方式、 资源、 进度安排、 测试组织，以及与测试有关的风险等方面。

        制定软件测试计划可以从以下几方面促进测试工作的开展：    

        1．软件测试工作有据可依， 按部就班， 进行更顺利;    

        2．使软件测试工作有章可循，更易于管理;    

        3．促进项目参与人员彼此的沟通交流，分工合作;    

        4．及时发现测试工作中的问题和不足，适时调整进度、资源投入和人员安排等。

3. 测试设计            

        如何合理运用测试原则、 方法、 策略， 设计测试方案和数据， 尽可能降低测试成本， 并尽可能多的发现软件中的缺陷和问题。    

        测试设计要兼顾测试的充分性和成本节约原则， 综合运用多种测试方法、 策略， 合理设计测试数据， 用尽可能少的测试数据发现尽可能多的软件缺陷和问题， 减少测试工作量， 提高测试效率。

4. 测试开发            

        主要指开发测试脚本， 有时也包括自动生成测试数据等。    

        软件测试需要重复执行软件， 以便发现软件中的问题， 测试开发的重要工作就是编写得到用于自动执行测试过程的代码， 一般称之为测试脚本。        

        有时在需要大量测试数据的情况下， 也可以编写程序或者通过其他工具自动生成一些测试数据。

5. 测试执行与记录            

        执行测试过程， 包括执行程序， 输入测试数据， 记录测试结果等。    

        目前采用自动化的方法来执行测试过程用的越来越多。

6. 测试总结            

        包括统计分析测试结果， 报告缺陷， 评估软件质量等。

2.2 软件测试方法和技术概述

静态测试

        静态测试是指不需要执行被测程序， 而是人工检查或者借助专用的软件测试工具来检查、评审软件文档或程序， 度量程序静态复杂度， 检查软件是否符合编程标准， 寻找程序的不足之处， 降低错误出现的概率。

        静态测试包括：

        代码检查

        静态结构分析

        代码质量度量等    

        它可以由手工进行， 充分发挥人的逻辑思维优势；也可以借助软件工具自动进行。

        代码检查在编译和动态测试之间进行，在检查前：

        需求描述文档；

        程序设计文档；

        源代码清单；

        代码编码标准；

        代码缺陷检查表。动态测试

        动态测试是指通过运行被测程序， 输入测试用例，检查运行结果与预期结果的差异， 并分析运行效率、 正确性和健壮性等性能是否符合要求。                测试用例应该详细给出完成该项测试任务、执行该次测试用例过程所需要的所有信息，因为设计测试用例和执行测试用例的可能不是同一个人，对照测试文档，应当能让一个没有参加测试设计，对被测软件也并不熟悉的人员也能完成测试执行的任务。        代码检查比动态测试更有效率，能快速找到缺陷，发现30%~70%的逻辑设计和编码缺陷。    

        代码检查看到的是问题本身，而不是外部的征兆            白盒测试要求对程序的结构特性做到一定程序的覆盖，或者说是“基于覆盖的测试”，覆盖程序越高，则测试工作做得越彻底，但测试成本也会越高。3.动态测试：可能是黑盒测试，也可能是白盒测试。

        如根据软件规格说明书进行测试，属于黑盒测试；也有可能是白盒测试，如针对源程序做逻辑覆盖测试。

4.静态测试→白盒测试。

5.灰盒测试介于白盒测试与黑盒测试之间。既关注在给定输入的情况下输出是否正确，同时也关注内部表现，但这种关注不像白盒那样详细、完整。只是通过一些表征性的现象、事件、标志来判断程序内部的运行状态是否正确。

需要灰盒测试的原因：    

        在做黑盒测试时，有时候输出是正确的，但内部其实已经出错了。这样的情况很多，如果每次都采用白盒测试效率会很低，因此，需要采用黑盒测试与白盒测试相结合的灰盒测试。

灰盒测试的应用：    

        主要用于集成测试。

手工测试

          是指由测试人员手工执行测试活动， 并记录测试结果，观察分析结果是否正确或者符合要求。

          手工测试有很多弊端，当测试任务很重，需要执行非常多的测试数据时，手工测试是难以满足实际需要的。

自动化测试     

        自动化测试是把人为驱动的测试行为转化为机器执行的一种过程。

        通过开发和使用软件分析和测试工具、测试脚本等来实现软件分析和测试过程的自动化，具有良好的可操作性、可重性和高效率等特点。     

以自动化黑盒测试为例:      

        某软件总共需要执行5万组测试数据，每次手工输入测试数据需要30秒，每组测试数据实际执行需要1秒，记录和对比执行结果需要30秒，手工完成这一测试任务总共需要（30+1+30）*5万秒，大约为847个工时。

以自动化黑盒测试为例:    

        每组测试数据实际执行需要1秒，但每次输入自动化测试数据只需要0.1秒，记录和对比执行结果也只需要0.1秒，自动化完成这一测试任务总共需要(0.1+1+0.1)*5万秒，大约为17个工时。

        随着技术和工具的发展：

        软件测试工作中，自动化的程度会越来越高，但并不是所有测试工作都可以自动化的来完成， 也不是所有情况自动化测试都适用。

软件测试的基本策略

        针对不同的软件项目，软件测试的策略不尽相同，软件测试的基本策略如下：

        1、为提高软件质量，缩短软件项目总的工期，软件测试应当和软件开发同步进行；

        2、应对软件需求、软件设计等进行验证和确认；

        3、一个软件项目中，测试可分为单元测试、集成测试、系统测试和验收测试四个阶段分步实施；

        4、多种软件测试方法和技术应当综合运用，并针对不同的软件，合理选用没同的软件测试方法和技术。

        5、应运用自动化测试技术，采用软件测试工具，提高软件测试的效率；

        6、一项软件测试任务，它的生命周期包括测试需求分析、测试计划、测试设计、测试开发、测试执行、测试总结6大环节，软件测试荐可以按照这样的环节来组织实施。

结合案例说明桌面检查、代码审查、代码走查的区别。

1.桌面检查（Desk Checking）

定义：开发者自行检查代码的过程，通常通过人工模拟代码执行或检查逻辑错误。

特点：    

        个体行为：由代码作者独立完成。    

        非正式：没有固定流程，可能依赖开发者的经验。    

        快速但局限：容易遗漏团队协作或业务逻辑问题。

案例：    

        场景：开发者小王完成登录模块的代码后，自行检查代码。    

        过程：          

        小王逐行阅读自己编写的代码，模拟输入用户名和密码的流程。          

        发现密码加密函数中有一个拼写错误（如 encryptPassord 应为 encryptPassword）。           修正错误后，继续检查边界条件（如空密码、超长用户名）。    

        结果：发现局部错误（如拼写、语法），但未发现业务逻辑问题（例如未验证用户是否已锁定）。

2. 代码审查（Code Review）

定义：通过团队协作的方式，系统性地检查代码是否符合规范、是否存在潜在缺陷。

特点：    

        团队参与：由开发者、测试人员或架构师共同参与。    

        结构化：通常基于检查表（Checklist）或规范（如代码风格、安全要求）。    

        聚焦细节：关注代码质量、性能、可维护性等。

案例：    

        场景：团队通过 Git 提交代码后，发起 Pull Request（PR）进行审查。    

        过程：      

        开发者提交代码，并描述修改内容（例如“修复密码加密逻辑”）。      

        团队成员小李审查代码，发现以下问题：          

        安全性：密码加密未使用加盐哈希（不符合安全规范）。          

        冗余代码：存在未使用的变量 userStatus。          

        团队讨论后，要求开发者重构加密逻辑并删除冗余代码。    

        结果：发现设计缺陷和代码冗余，提升代码安全性和可维护性。

3. 代码走查（Code Walkthrough

定义：通过会议形式，由开发者讲解代码逻辑，参与者提问并验证代码的正确性。

特点：    

        协作与沟通：强调团队对代码逻辑的理解。    

        模拟执行：通过测试用例或场景推演代码行为。    

        聚焦逻辑：关注业务逻辑是否符合需求，而非代码细节。

案例：      

        场景：团队召开代码走查会议，验证登录模块的业务逻辑。      

过程：            

        开发者小王展示代码结构，并解释登录流程（如验证用户名、密码、用户状态）。                测试人员小张提出疑问：“如果用户连续输错密码 5 次，是否会触发账户锁定？”      

        团队发现代码中缺少对错误次数的累计判断，导致账户锁定逻辑未生效。            

        架构师指出：用户会话管理未考虑并发场景（如同一账号多设备登录）。    

结果：发现业务逻辑缺失和设计漏洞，推动代码重构。实际应用建议

桌面检查：适合开发过程中快速自查，但需结合其他方法确保质量。

代码审查：在提交代码前强制执行，确保符合团队规范。

代码走查：针对核心模块或复杂逻辑，提前发现需求层面的问题。

通过结合这三种方法，团队可以兼顾代码细节与业务逻辑，全面提升软件质量。

第 ３ 章 黑盒测试

３.1 黑盒测试概述

1.什么是黑盒测试

        把被测试软件看做一个打不开的黑盒子， 完全不考虑软件的逻辑结构和内部特性， 只是依据软件的规格说明书，运行软件， 输入测试数据， 根据运行结果， 检验该软件的功能是否实现并符合要求、 性能等其它特性是否满足用户需要

        黑盒测试是一种从用户观点出发， 基于规格说明的测试。  

        黑盒测试又叫功能测试、 数据驱动测试、基于规格说明的测试。

2. 黑盒测试的优缺点

优点：

        不需要源代码； 测试简单易行；

        能够发现软件设计中的问题；

        除了功能之外， 还可以测试性能、 安全性等其他特性。    

缺点：

        无法对代码进行有针对性的测试， 某些代码可能得不到；黑盒测试只是在软件的接口处进行，并不深入到软件的内部，

        有时输出的结果可能碰巧正确， 但软件内部在执行过程中可能已经出错了；

        黑盒测试以规格说明书为测试依据， 如果规格说明书有误， 黑盒测试是发现不了的。设计黑盒测试用例可以和软件需求分析、软件设计同时进行，这样可以缩短整个软件项目所需要的时间。  

        例如：    

        在对软件做需求分析时就可以为验收测试做准备，编写验收测试所需要的黑盒测试用例，

黑盒测试主要可以发现以下几类错误

1.接口错误    

        程序A包括A1， A2两段， A2是一个函数， 有三个参数，x,y,z， 在程序段A1中调用了函数A2， 但调用时只给了两个参数， 这样执行程序A时会出错， 原因是程序段A1对函数A2的调用接口有问题

2.初始化或终止性错误    

        对程序B进行黑盒测试， 执行后， 程序B始终处于运行之中， 不再对用户的键盘鼠标操作给出响应， 没有提示，也不能关闭或者退出。 这是终止性错误， 一般情况是程序存在死循环， 不能终止。

3. 功能遗漏或者不正确             

        程序C的规格说明书中说明该程序可以根据给定的多个成绩计算平均成绩， 并且成绩可以是百分制， 也可以是五级计分制， 但执行程序C， 对其进行黑盒测试发现该程序只能对百分制的成绩计算平均成绩， 而不能对五级计分制的成绩计算平均成绩， 这是该程序功能不全， 有遗漏。

4. 界面错误    

        对某成绩管理系统D进行黑盒测试， 执行后主界面显示：“ 欢迎进入网上商城” ， 这是界面上有提示信息错误。

5. 性能不符合要求    

        某网上售票系统E的规格说明书要求该系统能满足1000个客户端同时在线买票， 但对其进行黑盒测试时发现， 500个客户端同时在线买票时该系统就瘫痪了， 该系统性能不符合要求。

6. 数据库或其它外部数据结构访问错误    

        某销售管理系统F有一个后台数据库， 对销售管理系统F进行黑盒测试时发现， 当需要访问数据库时系统就会报错，这是数据库访问错误， 错误的原因很可能是连接字符串中的参数不正确。

７.安全性问题等    

        某学生管理系统 G， 对其进行黑盒测试时发现， 用户登录时输入正确的用户名后， 密码什么都不输入， 也可以登录成功， 这是系统在对用户进行身份认证时存在安全性问题。

黑盒测试的依据

        对软件进行黑盒测试的主要依据是软件规格说明书，因此， 在进行黑盒测试之前应确保软件规格说明书是经过评审的， 其质量达到了既定的要求。  

        如果没有规格说明书的话， 可以采用探索式测试。  

        黑盒测试思想不仅可以用于测试软件的功能， 同时，也可用于测试软件的非功能特性， 如性能、 安全性等。        在面对实际的软件测试任务时， 如果仅仅采用一种黑盒测试用例设计方法， 是无法获得理想的测试用例集、高质量的解决复杂软件测试问题的。    

        比较实用的方法是， 综合运用多种设计技术来设计测试用例， 取长补短， 只有这样才能有效提高测试的效率和测试覆盖率。 这就需要我们认真掌握这些方法的原理， 积累一定的软件测试经验， 才能有效地提高软件测试水平。

        综合运用黑盒测试方法的策略

① 可以首先进行等价类划分， 包括对输入条件和输出结果的等价划分， 将无限测试变成有限测试， 这是减少工作量和提高测试效率最有效的方法。

② 在任何情况下都推荐使用边界值分析法， 经验表明，用这种方法设计出的测试用例发现程序错误的能力最强,发现缺陷的概率也最高， 因为问题往往容易出现在边界上。

③ 对于业务流清晰的系统， 可以采用场景法对测试任务进行分解， 以便于实施。

④ 如果程序的规格说明中含有输入条件的组合情况， 则一开始就可选用因果图法和判定表驱动法。

⑤ 对于参数配置类软件， 可用正交实验法选择较少的数据组合达到较好的测试效果。

⑥ 在其它方法的基础上， 可以采用错误推测法追加一些测试用例， 用错误猜测法补充通过其它测试用例设计方法无法获得的测试用例， 这需要依靠测试工程师的智慧和经验。

３.2 等价类划分

        黑盒测试只有对一个程序穷举所有可能的输入来进行测试，才能发现程序中所有的错误。        

        不仅要测试所有合法的输入，而且还要对那些不合法但有可能出现的输入进行测试。        从软件测试的角度来说， 由于等价类中的各个元素具有相同的特性， 所以对于发现或者揭露程序中的缺陷， 它们的作用是等价的， 或者说效果是相同的。

        等价类划分法就合理地假定：对于某个等价类而言， 只需要测试其中的某个代表数据， 就等于对这一等价类中所有数据的测试。

        使用等价类方法时，把所有可能的输入数据， 划分成若干个等价类， 然后从每一个等价类中选取1个或者少量数据， 作为测试数据去测试程序。

        各个等价类之间不应存在相同的元素，即等价的交集为空；

        所有等价类的并集应当是被划分集合的全集，即所有等价的并集为全集。        通常针对输入数据而进行，通过等价类划分，把可能无限的输入，变成有限的等价类， 然后从中选出代表作为测试用例，以期达到在测试工作尽可能完备的同时又尽可能避免测试冗余， 降低测试成本， 提高测试的有效性。

        等价类划分是最基本和最常用的黑盒测试方法。

        等价类可以分为有效等价类和无效等价类。

        有效等价类： 是指对于程序规格说明来说， 合理的、有意义的输入数据构成的集合。 利用它， 可以检验程序是否实现了规格说明预先规定的功能和性能等特性。

        无效等价类： 是指对于程序规格说明来说， 不合理的、 无意义的输入数据构成的集合。 利用它， 可以检验程序能否正确应对异常的输入， 而不至于产生不希望出现的后果。  

        设计测试用例时，要同时考虑这两种等价类， 因为软件不仅要能接收并处理合理的数据， 也要能经受意外的考验。

        在遇到不合理的、 无意义的数据输入时， 程序应能妥善处理， 而不至于无法应对， 出现意外的结果， 只有通过这样的测试， 才能确保软件具有更高的可靠性。划分等价类的建议

        到目前为止， 还没有高质量划分等价类的标准方法， 对软件不同的规格说明可能使用不同的等价类划分方法。 不同的等价类划分得到的测试用例的质量不同。  等价类划分

        为什么设计一个测试用例可覆盖多个有效等价类，而一般只能覆盖一个无效等价类？    等价类组合的相关概念       

        弱等价类：至少覆盖一次即可    

        强等价类：覆盖组合    

        一般等价类：只覆盖有效等价类    

        健壮等价类：覆盖有效和无效等价类      

        4类等价类技术：弱一般等价类测试、强一般等价类测试、弱健壮等价类测试和强健壮等价类测试；    

等价类测试分类

        是否考虑无效等价类

        单缺陷假设还是多缺陷假设

        分类：

        弱一般等价类测试

        强一般等价类测试         

        弱健壮等价类测试

        强健壮等价类测试

等价类的组合

        弱一般等价类：      

        设计若干测试用例， 每个测试用例应尽可能多地覆盖尚未覆盖的被测变量的有效等价类并且每个被测变量的有效等价类应至少出现一次。    

        测试用例个数为： 各个被测变量中的最大有效等价类个数。

实例：    

        函数y = f (x1,x2) 输入变量的取值范围分别为: x1∈ [a,d],  x2 ∈ [e,g]。    

        根据函数的规格说明划分得到相应的等价类      

        X1：有效等价类 [a,b)  [b, c)  [c, d]          

                无效等价类 (-∞, a), (d, + ∞)          

        X2：有效等价类 [e,f) [f, g]          

                无效等价类 (-∞, e), (g, + ∞)边界值分析   

        边界值分析法就是对输入或输出数据的边界值进行测试的一种黑盒测试方法。 边界值分析法可以和等价类划分法结合起来使用， 在划分等价类的基础之上，选取输入等价类、 输出等价类的边界数据来进行测试。    

        边界值分析法与等价类划分法的区别是， 边界值分析不是从等价类中随便挑一个作为代表， 而是把等价类的边界作为测试条件。

        使用边界值分析方法设计测试用例， 首先应确定等价类的边界， 然后选取正好等于， 略大于， 略小于边界的值作为测试数据。    

        需要注意的是， 边界值不仅仅可以是数据取值的边界， 还可以是数据的个数， 文件的个数， 记录的条数等边界值。

        通常情况下，软件测试可能针对的边界有如下多种类型：     数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。    

        以上类型的边界值应该考虑：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况。

边界的不同类型

        数据取值范围的最大值、 最小值

        屏幕上光标在最左上、 最右下位置

        报表的第一行和最后一行

        数组元素的第一个和最后一个

        循环 1 次、 循环最大次

        数据表中的第一条记录， 最后一条记录

        字符串的第一符号， 最后一个符号

        第一个文件， 最后一个文件   

        还应考虑略大于和略小于边界端点的情况。    

        实际中，对于一个取值范围选取边界值的个数常见的有4点法和6点法边界值的组合

        如果有多个变量， 边界值的组合可分为多种情况：分类：        

        一般情况：只考虑在有效区间上的边界值    

        健壮情况：同时考虑有效和无效区间上的边界值。    

        最坏情况：考虑边界值的组合

1、 一般边界值：    

        仅考虑单个变量在有效取值区间上的边界值， 包括最小值， 略高于最小值， 略低于最大值和最大值， 如果被测变量个数为n， 则总的边界值有4n个。    

        设计测试用例时每次只覆盖一个变量的边界值， 其它变量应当用正常值， 所以可以为每个变量再选取一个正常值， 这样的话边界值和等价类划分相结合， 总的测试用例个数为4n+1个。