IT (Information Technology): 信息科技和产业
称呼：IT男/IT女 IT 民工 码农 搬砖
软件：一系列按照特定顺序组织的计算机数据和指令的集合程序+数据+文件
产品：能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。
项目：指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。
什么是软件测试？
分为功能测试和性能测试
使用人工和自动手段来运行或测试某个系统的过程， 其目的在于
检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
软件测试发展史
早期特点 等同于“调试”
1957年 与调试区别开来
20世纪70年代 被确定为一种研究方向
20世纪80年代早期 质量
20世纪90年代 工具盛行
近20年 测试模型
为什么做软件测试？
• 一个糟糕的测试程序可能导致任务的失败，
影响操作的性能和可靠性，导致维护阶段的成本提高。
• 一个好的测试程序是项目的主要成本。
• 一个好的测试程序可以极大地帮助你定义需求和设计。
• 一个好的测试可以迫使你在工作时必须面对和处理问题，使得修改缺陷成本降低。
• 一个好的测试不能弥补一个糟糕的软件项目，但是的确有助于发现许多问题并且至少使得你尽早知道你处在问题当中。
软件测试任职要求
硬实力：
学历、专业、经验、测试技术、开发技能、业务知识
软实力：
责任心、沟通能力、团队合作精神、耐心、细心、信心、风险防
范意识、持续学习能力
二． 软件生命周期
软件生命周期：软件从无到有的过程
1.需求调研：需不需要开发这样一款软件
2.需求分析：具体要实现哪些功能，做需求调研和分析
3.设计阶段：从计算机角度，根据《需求规格说明书》，针对不同的需求，采用相对应的设计模式，规划出概要设计文档和详细设计文档。说明具体使用什么框架，具体格局的分配，实现什么样的功能，开发程序使用什么语言来编码
4.开发阶段—用代码实现软件功能。
5.测试阶段。
6.发布上线，客户验收
7.运营/运维/产品支持：提供产品支持和维护，解决产品使用过程中发现的问题
8.合同到期终止维护
三．项目组成员
四.测试基本原则
1.测试是上下文相关的：不同软件测试强度不同
2.穷尽测试是不可能的：不可能测试所有软件的所有操作
3.测试尽早介入：从需求阶段开始测试，测试人员尽早介入降低测试成本
4.杀虫剂悖论：测试用例不能只用同一种，发现不了新的BUG
5.缺陷群集性：一个模块有问题，开发做出改动修复BUG可能会导致别的部分也有问题
6.测试证明存在缺陷；测试是为了证明软件存在缺陷，而不是为了证明不存在缺陷
7.无错谬误；已经发现的问题已经解决不代表没有缺陷了，只是还没有被发现
软件测试对象
五.软件开发模型
研发模型—瀑布型
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
优点：有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。
缺点：（1）开发过程一般不能逆转，否则代价太大；（2）实际的项目开发很难严格按该模型进行；（3）客户往往很难清楚地给出所有的需求，而该模型却要求如此。（4）软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。
研发模型—原型
在需求分析阶段输出了原型设计，把该设计图交予客户，客户确定没有问题后才能开始后续工作。
优点：（1）可以得到比较良好的需求定义，容易适应需求的变化；（2）有利于开发与培训的同步；（3）开发费用低、开发周期短且对用户更友好。
缺点：（1）客户与开发者对原型理解不同；（2） 准确的原型设计比较困难；（3） 不利于开发人员的创新。
研发模型—敏捷模型
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。先是根据软件中重要的需求在2-4周发布一个原始的版本，在制定版本迭代的计划，进行版本的迭代，这种开发模型，可以使软件尽早地占据市场。而瀑布模型和原型都是一次性完成之后在进行发布，进入市场比较慢。
其它研发模型：
• 螺旋模型：适合于大型复杂软件系统
• RUP模型（Rational Unified Process）：模型过于复
杂，难于掌握，耦合度高不适合
六.软件测试模型
测试模型--- V模型
优点：既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。
局限性：把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，不能体现“尽早地和不断地进行软件测试”的原则。
测试模型--W模型
优点：
1.如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。
2.测试者可以在项目中尽可能早地面的规格说明书中的挑战。
3.测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。
局限性：无法支持迭代、自发性以及变更调整。
测试模型--H模型
优点：
1.软件测试不仅仅指测试的执行，还包括很多其他的活动。
2.软件测试是一个独立的过程，贯穿产品整个生命周期，与其他流程并发地进行。
3.软件测试要尽早准备，尽早执行。
4.软件测试是根据被测物的不同而分层次进行的。
5.不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
6.软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发的进行
测试模型—前置模型
优点：
1.体现开发和测试相结合
2.对每一个交付内容进行测试
3.在设计阶段进行测试计划和测试设计
4.测试和开发结合在一起
5.让验收测试和技术测试保持相对独立
七.软件测试阶段
需求测试
返工：70%~85%由于需求
重点：检查需求规格说明书 SRS
1）完整性
2）正确性
3）一致性
4）可行性
软件测试阶段
5）无二义性
6）健壮性
7）必要性
8）可测试性
9）可修改性
1.单元测试
单元：函数、类
单元测试是针对软件基本组成单元（软件设计的最小单
位）来进行正确性检验的测试工作
单元测试的目的是检测软件模块对《详细设计说明书》
LLD的符合程度
2.集成测试
集成测试是对单元之间及单元与第三方接口之间的测试，目的
是验证接口是否与设计相符，是否与需求相符。（即检测软
件模块对《概要设计说明书》的符合程度）
集成策略：自底向上或自顶向下 渐增式
3.系统测试
系统测试是将已经集成好的软件系统，作为整个基于计算机系
统的一个元素，与计算机硬件、外设、某些支持软件、数据和
人员等其他系统元素结合在一起，在实际运行（使用）环境下，
对计算机系统进行一系列的测试工作
系统测试的目的在于通过与《需求规格说明书》作比较，发现
软件与系统需求定义不符合或与之矛盾的地方
4.确认测试
又称有效性测试，它的任务是验证软件的有效性，即验证软件的功
能和性能及其它特性是否与用户的要求一致。
若能达到这一要求，则表明开发的软件是合格的。
5.验收测试
交付用户部署前，进行验收测试
以用户为主，验收组：项目组成员、用户代表或者系统的其它利益
相关者。
根据合同、《需求规格说明书》或《验收测试计划》对成品进行验
收测试。
6.Alpha测试和Beta测试
Alpha：内部，模拟/真实
Beta：外部，真实
7.UAT测试
User Acceptance Test 用户接受度测试
验证系统的可用性
8.回归测试
回归测试（ Regression Testing ）：软件在测试或其他活动中发现的缺陷经过
修改后进行的测试。目的是验证缺陷得到了正确的修复，同时对系统的变更没
有影响以前的功能。
回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试。
回归测试策略
1.完全重复测试：
重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性
2.选择性重复测试：
即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序
选择性重复测试
• 覆盖修改法
即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。
• 周边影响法：
该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。该方法比覆盖修改法更充分一点。
• 指标达成方法：
这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。
回归测试流程
以下流程适合于单元测试、集成测试和系统测试
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
回归测试自动化
1.回归测试是一个重用以前成果的测试，很难预料到要经过多少次回归系统才能达
到满意的水平，结果，这种回归测试将可能演变成一种重复的、令人心烦意乱的工作，效果与人员的积极性将大打折扣，因此，在回归测试道路上的自动化便是我们工作的追求
2.回归测试的自动化法包括测试程序的自动运行、自动配置，测试用例的管理和自动输入，测试的自动执行，测试信息与结果的自动采集，测试结果的自动比较和结论的自动输出
3.对系统测试功能比较简单、测试界面相对稳定并且测试用例良好组织的测试来说，采用“捕捉回放”工具是比较合适的，这类工具有Selenium等
八.软件测试类型
功能测试
概念：
功能测试是根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格
目标：
功能测试主要是为了发现以下几类错误：
• 是否有不正确或遗漏了的功能？
• 功能实现是否满足用户需求和系统设计的隐藏需求？
• 输入能否正确接受？能否正确输出结果？
性能测试
• 性能测试(Performance Testing)就是用来测试软件在集成系统中的运行性能的。
• 性能测试的目标是度量系统相对于预定义目标的差距。
• 性能测试必须要有工具支持，市面上有一些专门用于GUI或Web的性能测试工具，如Loadrunner, Jmeter, SilkPerformer, WebLoad。
性能测试收集的信息
• CPU使用情况
• IO使用情况
• 内存使用情况
• 信道使用情况
• 每个模块执行时间百分比
• 一个模块等待IO完工的百分比
• 指令随时间的跟踪路径
• 每一组指令页换入和换出的次数
• 系统反应时间
• 系统吞吐量，即每个时间单元的处理数量
• 所有主要指令的单元执行时间
负载测试
负载测试是超过被测对象标准性能负荷指标下，验证系统的负载承受能力。并要求超负荷情况下，依然正常实现业务功能。负载测试是通过不断对被测对象施加负荷，观察被测对象在不同负载下的性能表现。
压力测试
压力测试（Stress Testing）的目的是调查系统在其资源超负荷的情况下的表现。尤其感兴趣的是这些对系统的处理时间有什么影响。这类测试在一种需要反常数量、频率或资源的方式下执行系统。
目标：
通过极限测试方法，发现系统在极限或恶劣环境中自我保护能力。主要验证系统的可靠性，找到系统薄弱环节。
容量测试
容量测试(Volume Testing)的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
安全性测试
安全测试(Security Testing)用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。 用来保证系统本身数据的完整性和保密性。如当受到恶意攻击时，设备的自我保护能力，病毒防护能力，自定义通信协议安全性等。广义的还包括物理安全性测试、业务安全性测试。
安全性测试内容：
一般可以从以下方面考虑安全性测试
• 系统的登录
• 用户管理
• 防火墙
• 系统数据
• WEB安全性，如WEB的加密，解密，数字签名等
• 数据库的安全性
• 内部通信协议
• 系统防病毒测试
GUI测试
• GUI测试是针对软件系统GUI界面进行的测试
• GUI测试主要包括两方面的内容：
界面实现与界面设计的吻合情况；
确认界面处理的正确性。
• 一般业界常用的GUI自动化工具有QTP, SilkTest, QARun、QuickTestProfessional,selenium等。
GUI测试对象：
• 简单界面元素：指功能和属性相对比较单一的界面区域，即通常所指的各种控件
• 组合类界面元素：主要指一些复杂的界面元素，比如工具栏，组合框，表格，菜单栏等
• 完整界面（窗口）：由一系列界面元素通过适当的形式组合而成的界面形式，最为常见的为各种窗口。包括各种对话框、单文档窗口、多文档父窗口，多文档子窗口等
可用性测试
可用性测试(Usability Testing)是为了检测用户在理解和使用系统方面到底有多好。主要考虑产品是否符合实际应用情况，是否符合用户习惯或特殊要求，操作方式是否方便合理、设备和用户间的交互信息是否准确易于理解、是否遵从行业习惯、外观/界面是否美观等。应涉及到所有和用户有交互的功能或子系统。这包括系统功能、系统发布、帮助文本和过程，以保证用户能够舒适地和系统交互。
一些测试人员应当关注的可用性问题：
• 过分复杂的功能或者指令；
• 困难的安装过程；
• 错误信息不准确或者过于简单；
• 用户被迫去记住太多的信息；
• 语法、格式和定义不一致
安装卸载测试
定义：
系统的可安装性测试，主要是根据软件的测试特性列表、软件安装、配置文档，设计安装过程的测试用例，发现软件在安装过程中的错误
目的：
• 系统可安装性测试的目的不仅是找安装软件本身的错误，而且还要找安装文档的错误。在安装软件系统时，会有多种选择，要分配和装入文件与程序，布置适当的配置，进行程序的联结。而安装测试就要找出这些安装过程中出现的错误
异常测试
概念：
系统异常测试又叫系统容错和可恢复性测试，它是通过人工干预手段使系统产生软、硬件异常，通过验证系统异常前后的功能和运行状态，达到检验系统的容错、排错和恢复的能力。它是系统可靠性评价的重要手段
容错处理：
系统自动处理
人工干预处理
注意：
系统异常测试还与系统的指标测试有关系，当系统需要提供的服务能力大于系统的设计指标时，也属于系统异常的情况，因此应该结合起来加以考虑
系统的可靠性是设计出来的，而不是测试出来的。测试出来的数据有助于为我们进行进一步的系统优化设计积累经验，设计和测试是一个互为反馈的过程
文档测试
文档测试(Documentation Testing)的目标是验证用户文档是正确的并且保证操作手册的过程能够正确工作。
网络测试（接口测试）
概念：
网络测试是在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常
内容：
网络测试考察系统的处理能力、系统兼容性、系统稳定可靠性及用户使用等方面。
如通信产品，主要进行协议测试：
• 一致性测试：检测所实现的系统与协议规范符合程度
• 性能测试：检测协议实体或系统的性能指标（数据传输率、联接时间，执行速度、吞吐量、并发数等）
• 互操作性测试：检测同一协议不同实现厂商之间，同一协议不同实现版本之间、或同一类协议不同实现版本之间互通能力和互连操作能力
• 坚固性测试：检测协议实体或系统在各种恶劣环境下运行的能力（信道被切断、通信设备掉电、注入干扰报文等）
稳定性测试
系统稳定性测试目的是评价系统在一定负荷情况下、长时间的运行情况。包括系统在一定负荷下，再增加新的业务，原有的业务是否受影响，新的业务是否能正常工作，系统资源有无泄漏，数据有无不一致的情况，系统性能是否会降下来，关键点是长时间的运行后，系统的状况如何，系统平均无故障时间MTBF是否满足系统设计要求。
兼容性测试
兼容性测试验证被测对象与硬件、其他软件之间的兼容情况
软件测试方法
测试活动从不同的角度出发，可以有不同的分类。
• 黑盒测试和白盒测试、灰盒测试
• 静态测试和动态测试
• 人工测试和自动化测试
软件测试两种极端情况
系统的任何软件产品都可以使用以下的两种方法之一进行测试：
• 已知产品的需求规格，但不知道其内部实现，可以进行测试证明每个需求是否实现。
• 已知产品的内部实现过程，可以通过测试证明每种内部操作是否符合设计规格的要求，所有内部成分是否已经过检查。状况如何，系统平均无故障时间MTBF是否满足系统设计要求。
计算器例子
• 参照SRS直接测试计算器的加法功能。这就是黑盒测试。
• 参照LLD根据加法主函数的伪码或者流程图测试该主函数的结构。这就是白盒测试。
什么是白盒测试
• 白盒测试是依据被测软件分析程序内部构造，并根据内部构造设计用例，来对
内部控制流程进行测试，可完全不顾程序的整体功能实现情况。
• 白盒测试是基于程序结构的逻辑驱动测试。
• 白盒测试又可以被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、
逻辑驱动测试。
特点：
• 白盒测试一般在测试前期进行，通过达到一定的逻辑覆盖率指标，使得软件内部逻辑控制结构上的问题能基本得到消除
• 白盒测试能保证内部逻辑结构达到一定的覆盖程度，能够给予软件代码质量更大的保证
• 白盒测试发现问题后解决问题的成本较低
白盒测试一般会用到静态分析和动态分析两类技术。
常用的有：
• 静态分析：控制流分析、数据流分析、信息流分析等
• 动态分析：逻辑覆盖测试（分支测试、路径测试等）、程序插装等
什么是黑盒测试？
• 黑盒测试把被测对象看成一个黑盒，只考虑其整体特性，不考虑其内部具体实现。
• 黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块、一个函数等。
• 黑盒测试又可以被称为基于规格的测试。
常见的黑盒测试类型
• 功能性测试，一种是顺序测试每个程序特性或功能，另一种途径是一个模块一个模块的测试，即每个功能在其最先调用的地方被测试；
• 容量测试，检测软件在处理海量数据时的局限性，能发现系统效率方面的问题；
• 负载测试，检测系统在一个很短时间内处理一个巨大的数据量或执行许多功能调用上的能力；
• 恢复性测试，主要保证系统在崩溃后能够恢复外部数据的能力
黑盒测试的特点
• 对于更大的代码单元来说（子系统甚至系统级）比白盒测试效率要高；
• 测试人员不需要了解实现的细节，包括特定的编程语言；
• 从用户的视角进行测试，很容易被大家理解和接受；
• 有助于暴露任何规格不一致或有歧义的问题；
灰盒测试
• 根据利用的被测对象信息的不同，会采用不同的方法进行测试。
• 利用被测对象的整体特性信息，采用黑盒测试方法
• 利用被测对象的内部具体实现信息，采用白盒测试方法
• 如果既利用被测对象的整体特性信息，又利用被测对象的内部具体实现信息，采用的就是灰盒测试方法。两种信息占的比例不同，相应的灰度就不同。完全是整体特性信息，就是黑盒测试，完全是内部具体实现信息，就是白盒测试
• 典型的灰盒测试比如集成测试和系统测试时借助log信息
静态测试和动态测试
• 静态测试：不运行被测试的软件系统，而是采用其他手段和技术对被测试软件进行检测的一种测试技术。例如：代码走读、文档评审、程序分析等都是静态测试的范畴。常用技术有静态分析技术。
• 动态测试： 按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件系统进行检测的一种测试技术。常用技术有动态分析技术。
静态分析技术
• 定义：静态分析是一种不通过执行程序而分析程序执行的技术
• 功能：检查软件的表示和描述是否一致，没有冲突或者没有歧义，
它瞄准的是纠正软件系统在描述、表示和规格上的错误，因此是任
何进一步测试执行的前提。
主要有三种不同的程序测试可能性：
• 考虑程序是否满足编码规则，语法上是否具有一致性和完整性；
• 考虑文档描述是否规范、准确、便于查阅；
• 考虑程序和文档之间的一致性。
定义：静态分析是一种不通过执行程序而分析程序执行的技术
功能：检查软件的表示和描述是否一致，没有冲突或者没有歧义，它瞄准的是纠正软件系统在描述、表示和规格上的错误，因此是任何进一步测试执行的前提。
主要有三种不同的程序测试可能性：
考虑程序是否满足编码规则，语法上是否具有一致性和完整性
考虑文档描述是否规范、准确、便于查阅；
考虑程序和文档之间的一致性。
人工和自动化测试
人工测试：测试活动（如评审、测试设计、测试执行等）由人来完成，狭义上是指测试执行由人工完成，这是最基本的测试形式
自动化测试：一般是指通过计算机模拟人的测试行为，替代人的测试活动，狭义上是指测试执行由计算机来完成
自动化测试的意义
对程序新版本运行前一版本执行的测试，提高回归测试效率
可以运行更多更频繁的测试，比如冒烟测试
可以执行手工测试困难或不可能做的测试，比如大量的重复操作或者集成测试
更好地利用资源，比如测试仪
例子：路由器
增加路由
删除路由
查看路由
自动化测试的限制
不能取代手工测试，自动化测试只能提高测试效率，不能提高测试有效性，即
不可能发现更多缺陷
• 手工测试比自动测试发现的缺陷更多
• 对测试设计依赖性极大，测试设计的不好会遗漏问题
• 自动化测试对软件开发具有很大的依赖性，开发上出现变更可能导致前面的自
动化测试完全失效
• 工具本身并不具备想象力，工具不具有智能
九.软件测试流程
测试计划阶段 – 测试计划
测试设计阶段 – 测试方案
测试实现阶段 – 测试用例、测试规程
测试执行阶段 – 测试报告
主要的测试文档
1. 测试计划：指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。
2. 测试方案：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。
3. 测试用例：指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。
4. 测试规程：指明执行测试时测试活动序列的文档。
5. 测试报告：指明执行测试结果的文档。
6. 测试日报：每天测试执行情况的记录和总结。
系统测试过程与开发阶段
测试工程师系统测试各阶段任务
软件需求阶段：评审软件需求规格说明书
软件设计阶段：评审软件概要设计说明书、软件详细设计说明书、协助编写系统测试计划
软件编码阶段：设计系统测试用例、准备测试资源（测试工具、测试环境等）、开发测试脚本、开发测试工具、准备测试数据
软件测试阶段：执行测试用例、提交缺陷单、跟踪缺陷、回归测试、提交测试报告
十.软件测试质量
软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量。
软件质量模型
质量模型：一组特性及特性之间的关系，它提供规定质量需求和评价质量的基础
软件测试与QA的区别
1. 从性质上看：
测试属于技术的工作
QA属于管理的工作
2. 从对象上看：
测试的对象是软件研发产品，大多数工作是对研发领域的检验
QA的对象是整个软件过程，覆盖各个领域
3. 从手段上看：
测试以事后检查为主
QA强调的是缺陷预防
质量保证活动与软件测试的关系
