（1）软件本身的兼容性：主要是软件的向后兼容，如软件升级，以前版本的功能也能使用

（2）不同平台下的兼容性：如在Linux系统下的ubuntu、openSUSE等，进行平台的兼容性测试

（3）对不同的设备的兼容性：如32位、64位、如小型机、PC等

（4）软件的互操作性：如和一些主流应用的兼容，也就是说和大众软件互通，比如和微信、微博、QQ能适用，有时是很多网站的登录。。。。

2-3 按测试模式来分类： 瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。 1、瀑布模型：项目计划->需求分析->软件设计->程序开发->软件测试->集成维护 2、V模型（最广泛） 需求分析->概要设计->详细设计->软件编码->单元测试->集成测试->系统测试->验收测试 3、W模型（双V模型） 开发与测试并行，可以尽早发现问题 4、X模型 解决交接和频繁集成周期的问题 5、H模型：把软件测试看成一个独立的流程，与其他流程并发进行，比如设计流程，并发流程 6、，甚至是测试流程

测试的分类： 按测试阶段来分类：单元测试、集成测试、系统测试、验收测试。 一、单元测试： 1、最小可测试单元（如函数、类）； 2、原则：（1）尽可能保证各个测试用例是相互独立的;（2）开发人员来实施； 3、益处：（1）能尽早的发现缺陷；（2）有利于重构；（3）简化集成；（4）文档（减少文档的存在）；（5）用于设计； 4、限制：（1）不可能覆盖所有的执行路径，不可能捕捉到所有错误； （2）存在投入和产出的平衡（一行代码需要3~5行代码）； 5、框架：Xunit、JUnit、nunit、PHPUnit、CppUnit； 二、集成测试： 1、定义：在单元测试的基础上，组装； 2、主要实施方案：（1）Big Bang；（2）自顶向下；（3）自底向上；（4）核心系统集成；（5）高频集成；（2、3最常用的） 单元测试&集成测试的区别： 1、测试对象不同；（单元，模块与模块） 2、测试的依据不同；（详细设计，概要设计） 3、测试的方法；（类，模块之间接口的关系） 三、系统测试 1、在集成测试的基础上（实际运行环境下）； 2、关注点：（1）系统本身的使用；（2）系统与其他相关系统间的连通；（3）系统在不同使用压力下的表现；（4）系统在真实使用环境下的表现； 系统测试&集成测试的区别： 1、测试对象（整个系统，模块与模块）； 2、测试时间（集成之后，单元测试和系统测试之间）； 3、测试内容（整个系统，各个模块之间的接口）； 4、测试角度（业务角度的验证，技术角度的验证）； 四、验收测试（交付测试） 1、由用户来决定是否合格； 2、细分：用户验收测试（交付之前）；运行验收测试（运维）；合同和规定验收测试；alpha测试（用户测试，开发者提供的环境）；Beta测试（完全脱离了开发者，用户提供的环境）；

测试阶段： 一、单元测试（针对代码的测试）：对软件中的最小可测试单元进行检查和验证，针对软件详细设计 原则：1、尽可能保证各个测试用例是互相独立的。2、一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。 优点：1、能尽早的发型缺陷 ；2、有利于重构 ；3、简化集成测试 ；4、减少文档的存在；5、验证设计； 缺点：1、不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误；2、每一行代码，一般需要3-5行测试代码才能完成，所有单元测试的投入较大； 测试工具：Junit 测试 JAVA ; Nunit 测试 .NET ; PHPUnit测试 PHP ; CppUnit测试 C++; 二、集成测试：是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或显示相应技术指标及要求的活动。 实施方案：1、Big Bang 2、自顶向下3、自底向上，从程序模块的最底层模块逐层向上测试，能够比较好的锁定软件故障的所在位置；4、核心系统集成测试；5、高频集成测试（持续集成）； 三、系统测试：是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，一发现软件潜在的问题，保证系统的正常运行。 关注点：1、系统本身的使用；2、关注系统与其他相关系统间的连通；3、关注系统在不同使用压力下的表现；4、关注系统在真实使用环境下的表现； 系统测试与集成测试的区别：1、测试对象：集成测试的测试对象是由通过了单元测试的各个模块所集成起来的构建；系统测试是除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统；2、测试内容：集成测试针对的是各个单元模块之间的接口，系统测试针对的是整个系统的功能和性能；测试人员介入是在系统测试 四、验收测试：也称交付测试；针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。 细分为：用户验收测试（开发方在移交之前） 运行验收测试（以运维的层面来进行测试） 合同和规范验收测试（参照约定的规范来进行验证） ALPHA测试（用户在开发者提供的环境中测试） BETA测试（在用户提供的环境中进行测试)

软件测试所遵循的原则：

一、测试显示缺陷的存在，但不能证明系统不存在缺陷；

二、穷尽测试是不可能的，应设定及时终止的条件；

三、软件测试应该尽早进行；

四、缺陷具备群集特性；（即测试当中发现的大部分缺陷和软件运行失败，往往是由少数的运行模块引起的。如果我们发现一个模块中有越多的缺陷，也意味着这个模块中有越多的缺陷没有被发现）

五、测试的杀虫剂悖论（如果在测试当中采用同样的测试用例，同样的测试方法，多次重复的测试某一个模块，最后我们就不能发现新的缺陷，所以我们的测试用例和测试方法应该不定期的评审和修改，并且应该增加不同的测试用例和测试方法来测试软件或系统的不同部分）

六、测试的二八原则（我们应该把80%的时间用在20%的重点模块上）

七、测试活动依赖于测试背景（比如电信软件可能对性能、大并发量会有更高的要求；而金融软件和银行系统可能对安全性要求更高一点）

                                    敏捷测试

Agile Testing--遵循敏捷宣言的一种测试实践

敏捷宣言（价值观）： 个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作   重于 合同谈判 响应变化   重于 遵循计划 ——在每对比较中，后者并非全无价值，但我们更看重前者

敏捷测试的特点：

敏捷测试强调从客户角度进行测试

重点关注迭代测试新功能，不在强调测试阶段

尽早测试，不间断测试，具备条件既测试

强调持续反馈

预防缺陷重于发现缺陷

基于脚本的测试-SBT

Script-based Testing

Scripted Testing(ST)

Exploratory Testing(ET) 逐渐开始非常流行的方式

探索式测试（ET）

完全抛开测试脚本的测试

它是一种测试风格、思维而不是一种测试技术

ST和ET是互补的

探索式测试的优点：

更能激发测试人员的创造性和工作乐趣

增加了发现新的或较深入Bug的可能性

在较短的时间内找到更多Bug以及对SUT做一个快速的评估

有利于更加有效地实施自动化

更加适用于敏捷项目

减少了在简单、繁复上用例的无谓编写时间

探索式测试的缺点：

测试管理上有局限性，较难协调和控制

对于Bug的重复利用和重现上作用有限

对测试人员的测试技能和业务知识深度依赖较大

只有在SUT已完全可用的前提下才更有作用

ET的生产率很难定义

ET本身较难进行自动化

局部探索式测试

输入、状态、代码路径、用户数据、执行环境（被测系统的五大要素）

    让测试人员像游客游览一样来测试，而且软件按照不同属性划分为各个区域。商业区是指软件启动到关闭之间用户会使用的功能。旅馆区是指软件休息没有实际运行时候的功能，例如后台进程和定时任务。历史区是指版本遗留代码或者说以前版本经常出现bug的功能模块。旅游区是指新手引导之类的功能。娱乐区是指主要功能之外的一些辅助特性。破旧区是指废弃或者已经隐藏的功能。

    konw you mession 了解测试重点，系统环境，有一个测试的总体思路     learning session 详细的学习探索被测系统了解系统的业务逻辑，具体功能，深入学习被测系统     coverage session 探索式测试的实施阶段，完成主要功能点的测试验收，完成测试点的覆盖     deep session 在上一个功能点的基础上，更深入的发散式的测试，挖掘深层次的问题，深入测试     close session 总结测试，整理测试信息，根据整理数据，分析有没有测试的遗漏 缺陷大扫除。

基于风险的测试-RBT

Risk-based Testing

一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型

那些是风险？

质量风险（软件功能，易用性，性能，软件代码缺失）；

管理风险（人员能力不足，环境风险，被测系统的需求不清晰，被测系统关联的第三方系统不能联调）

风险级别=风险可能性*风险严重度

分析要素分=Sum（单项权重*得分）

RBT的优点：参考图像（测试工作量-风险、测试完成率-质量信心）

基于模型的测试-MBT

https://blogs.msdn.microsoft.com/sechina/2009/11/18/123/            更偏向于借助MBT?工具的自动化测试

第三讲 软件测试手段笔记

黑白分明，一静一动，类似太极

根据对象可见度分为：黑盒测试、白盒测试

根据状态分为：静态测试、动态测试

根据侧测试执行的方式分为：手工测试、自动化测试

【黑盒测试】

更偏向用户的角度出发涉及测试用例

优点：

1、容易实施，不需要关注内部的实现

2、更贴近用户的使用角度

缺点：

1、测试覆盖率低，一般只能覆盖到代码量的不到40%

2、针对黑盒的自动化测试，复用率较低，维护成本较高

测试/关注什么：

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

阶段：

系统测试阶段更多接入黑盒测试，实施软件测试

黑盒测试的主要设计方法：

1、等价类划分法：所有等价输入归为一类，典型代表输入划分

2、边界值分析法：关注各样边界条件，开发易出现失误的地方

3、错误推测法：基于经验、直觉来判断可能出现错误的地方设计用例的方法

4、因果图法：程序需求规格说明书画出因果图和判定条件

5、正交试验分析法：筛选输入数据

6、状态迁移图法：功能点的状态迁移关系

7、流程分析法：梳理逻辑执行的用例

【白盒测试】

定义：

结构化测试，透明盒测试，强调逻辑（主要逻辑单位：语句，条件，条件组合，分支，路径）

优点：

1、迫使测试人员去仔细思考软件的实现，理解原理

2、可以检测代码中的媒体哦啊分支和路径

3、揭示隐藏在代码中的错误

4、对代码的测试比较彻底

缺点：

1、昂贵、较高的覆盖率工作量大

2、无法检测代码中一楼的路径和数据敏感性的错误

3、不能直接验证需求的正确性

白盒测试的主要测试方法

1、代码检测法：桌面检查、代码走查/审查

2、静态结构分析法：使用测试工具分析内部结构

3、静态质量度量法：根据标准的质量模型为基准，制造度量模型进行评估

4、逻辑覆盖法：语句、条件、条件组合、分支、判定、路径、条件和判定的组合覆盖

5、基本路径测试法：分析圈复杂度

【灰盒测试】

定义：

介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现

【静态测试】

定义：

静态测试是指无需执行检测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率

方式：

互审(不正式)<-走查->会议（正式）

【动态测试】

定义：

动态测试是指通过运行检查程序，检查运行结果与预期结果的差异，并分析运行效率，正确性和健壮性等，黑盒测试的主要测试方法，主要是动态测试。白盒测试的主要测试方法，是静态测试。

【手工测试】

定义：

由专门的测试人员从用户视角来验证软件是否满足设计要求的行为，更实用针对深度的测试和强调主观判断的测试。比如众包和探索式测试

【自动化测试】

定义：

使用单独的测试工具软件控制测试的自动化执行以及对预期的结果进行自动检查，比如单元、接口和性能测试等

手工测试vs自动化测试：

1、易发现缺陷 高效率、速度快

2、容易实施 高复用性

3、创造性、灵活性 覆盖丰富易度量

4、覆盖量化难 准确、可靠

5、重复测试率低 不知疲劳

6、不一致性，可靠性低 机械，发现缺陷率低

7、人力资源依赖 一次性投入较大

按阶段分类：

1.单元测试（认为规定的最小的测试模块，可以是c语言的一个函数，可以JAVA中的每个类，可以看做一个登陆功能）

单元测试是对代码进行测试

测试框架：junit针对JAVA nunit针对.net phpunit针对PHP CppUnit针对C++

2.集成测试：偏于技术角度验证

3.系统测试（功能测试，性能测试，稳定性测试）企业针对系统测试这个阶段

包括外围设备，偏于业务角度验证

4.验收测试（交付测试）

alpa测试，开发人员提供场景环境，用户测试

Beta测试，完全脱离开发人员，在用户提供的场所和环境下进行测试

学容易，学好难，加油吧

3-1 软件测试类型 软件测试分类: 按测试类型: 功能测试、性能测试、兼容性测试、部署测试、易用性测试、文档测试、本地化测试、安全测试、无障碍测试、可靠性测试 功能测试: 根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。 针对的问题: 功能错误或遗漏、界面问题、性能错误、数据及访问错误、初始化及终止错误。 功能测试工具: 商用: QTP(web)、winrunner(桌面)、silkTest、Rational robot 开源: selenium、Watir、Sikuli(基于屏幕截图) 性能测试: 负载测试:在测试过程中，逐步加入负载，最后确认最大负载; 压力测试:在极限情况的压力情况; 稳定性测试:稍大于正常业务量的情况下持续长时间的测试。 性能指标: 并发用户数VU、每秒事务数TPS、系统响应时间、设备性能。 性能测试工具: LoadRunner、Silkperformer、Jmeter、WebLoad、Apache Bench、LoadUI。 静态性能评估: 开发Web应用时，基于一系列Web应用页面性能优化的最佳实践对Web应用的页面进行静态分析，并给出评估结果的性能分析方法。 应用性能管理(APM): 提供对系统的实时监控以实现性能管理、故障管理的解决方案 按测试类型分类： 功能测试：主要的类型，根据产品特性、操作描述和用户方案，测试一个产品特性和可操作 行为以确定他们满足设计需求。 针对的问题：功能错误或遗漏、界面问题、性能错误、数据及访问错误、初始化及终止错误 功能测试工具：QTP，silkiest,Rational

1.软件测试的分类： a.按软件测试阶段分类：单元测试、集成测试、系统测试、验收测试 单元测试：对软件中的最小可测试单元进行检查和验证。 单元测试原则：1.尽可能保证各个测试用例是相互独立的。2.一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。 单元测试的益处：1.尽早发现缺陷； 2.有利于重构 3简化集成 4.文档 5.用于设计 单元测试限制：1.不可能覆盖所有的执行路径，发现所有路径的错误 2.每一行代码 一般需要3~5行测试代码才能完成单元测试，存在投入和产出的一个平衡 集成测试：在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动 集成测试的主要实施方案：Bigbang、自顶向下、自底向上（常用）、核心系统集成、高频集成 单元和集成区别：测试对象不同（单元：软件基本单元；集成：模块与子系统） 测试依据不同（单元：软件详细设计；集成：概要设计） 测试方法不同 （集成：接口；单元：单元的类） 系统测试：是将经过集成测试的软件，作为计算机系统的一个部分与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件的问题 关注点：关注系统本身的使用、关注系统与其他系统间的连通、关注系统在不同压力下的表现、关注系统在真实环境下的表现 系统测试和集成测试 1.测试对象不同：集成：由通过了单元测试的各个模块集成起来的构件； 系统：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统。 2.测试时间：集成测试介于单元测试和系统测试之间，系统测试在集成测试之后 3.测试内容：集成：各个单元模块之间的接口 系统：整个系统完整的功能 4.测试角度：集成：偏于技术；系统：偏于业务 验收测试：确定系统是否满足验收标准 用户验收测试和运行验收测试、合同和规范验收、alpha测试（开发者环境）、beta测试（用户环境）

按测试模式来分类： 瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。 1、瀑布模型：项目计划->需求分析->软件设计->程序开发->软件测试->集成维护 2、V模型（最广泛） 需求分析->概要设计->详细设计->软件编码->单元测试->集成测试->系统测试->验收测试 3、W模型（双V模型） 开发与测试并行，可以尽早发现问题 4、X模型 解决交接和频繁集成周期的问题 5、H模型：把软件测试看成一个独立的流程，与其他流程并发进行，比如设计流程，并发流程，甚至是测试流程

3、系统测试：是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，一发现软件潜在的问题，保证系统的正常运行。一般需要做：功能测试、性能测试、稳定性测试等； 关注点：1、系统本身的使用；2、关注系统与其他相关系统间的连通；3、关注系统在不同使用压力下的表现；4、关注系统在真实使用环境下的表现； 系统测试与集成测试的区别：1、测试对象：集成测试的测试对象是由通过了单元测试的各个模块所集成起来的构建；系统测试是除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统； 2、测试时间：集成测试介于单元测试和系统测试之间，系统测试在集成测试之后； 3、测试内容：集成测试针对的是各个单元模块之间的接口，系统测试针对的是整个系统的功能和性能；

软件测试的对象 答：软件需求、软件设计概要、软件详细设计、软件源代码、可运行程序、软件运行环境 什么是软件测试： （1）测试是为发现错误而执行程序的过程； （2）使用人工或自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异； 软件测试的五大要素和两个目标 答：五大要素是指软件质量、人员、资源、流程、技术 软件测试两大目标： 答：为了更好的测试出软件中存在的缺陷与bug，提升测试股概率、提高测试效率 4.软件测试所遵循的原则 （1）测试显示软件的存在，但不能证明系统不存在缺陷 （2）穷极测试是不可能的，应设定及时终止的条件 （3）测试应该尽早进行 （4）缺陷具备群集特性 （5）测试的杀虫剂悖论（用相同的用例多次测试时发现不了bug的，应该更新测试方法和用例） （6）测试的二八原则 （7）测试活动依赖于测试背景 （8）即针对不同的软件的测试方法是不同的，比如电信软件看中性能、大批量；银行看中安全性；

按测试手段分类

可见度分类

黑盒测试：不考虑程序内部结构和内部特性，通过内部相关暴露出来的接口对程序进行测试，只检测程序的功能是否能够按照需求规格说明的规定正常的使用，是否能适当的接受输入数据并产生正确的输出，针对软件外部可见的部位，如界面及可见的功能来进行测试。更多是从用户的需求通过不同的数据或事件来驱动系统，并通过输出结果来进行判断

优点：

1. 容易实施，不需要关注内部的实现

2. 更贴近用户的使用角度
   

缺点：

1. 测试覆盖率较低，一般只能覆盖到代码量的不到40%

2. 针对黑盒的自动化测试，复用率较低，维护成本较高。

关注点：

1. 是否有不正确或遗漏的功能

2. 在接口上，输入是否能正确的接受？能否输出正确的结果？

3. 是否有数据结构错误或外部信息（例如数据文件）访问错误？

4. 性能上是否能够满足要求

设计方法

1. 等价类划分法，将所有的输入等价的划分若干典型输入，并将这些典型的输入设计为测试用例（有效等价类和无效等价类）

2. 边界值分析法，特殊等价类划分法，测试各种边界条件，如数据区间，开发在边界值上是很容易出现失误的地方，在边界上加一减一进行测试

3. 错误推测法，基于经验或直觉来判断程序中可能出现错误的原因，从而针对性的设计用例，如在登录时考虑格式，在输入文件时考虑文件大小

4. 因果图法，拿到需求说明书，针对每一种输入和输出，看作原因和结果，对输入和输出赋予特殊的标识符，然后将这些情况形成因果图，最终根据规格语义的说明形成一个判定表，根据判定表来设计测试用例

5. 正交试验分析法，利用正交法从一组数据中筛选出典型的代表性数据的测试方法，主要用于筛选我们的输入数据，然后在设计用例输入输出

6. 状态迁移图法，通过梳理软件功能点里面的状态迁移关系来设置测试用例，状态迁移如软件审批的功能，提交审批到待审批到审批，审批有具结，通过退回这样的状态，那退回到提交者，他也会修改再重新提交然后审批通过这样各种各样的状态，通过画出这些状态之间的一个关系图来设置用例

7. 流程分析法，通过梳理整个程序的逻辑执行的路径来设置测试用例，
   

白盒测试：又称结构化测试和透明测试，通过程序逻辑结构来设计测试用例，通过覆盖率来衡量测试的完整性，逻辑单位为：语句、条件、条件组合、分支、路径，其覆盖为每条测试

优点：

1. 迫使测试人员去仔细思考软件的实现，理解原理

2. 可以检测代码中的每条分支和路径

3. 揭示隐藏在代码中的错误

4. 对代码的测试比较彻底

缺点

1. 昂贵，（要求覆盖，工作量大）

2. 无法检测代码总遗漏的路径和数据敏感性错误

3. 不能直接验证需求的正确性

测试方法：

1. 代码检测法：主要包括多面检查、代码审查和走查，主要代码

2. 静态结构分析法：测试者主要通过测试工具分析源代码的数据结构，逻辑结构、内部的控制逻辑这样内部结构的分析来设计测试用例

3. 静态质量度量法：根据标准的质量模型，比如ISO的质量标准来构造质量的度量模型，用于软件的各个方面的测试

4. 逻辑覆盖法：逻辑、语句、条件、分支、条件组合、判定覆盖、笃定覆盖、条件和判定的组合覆盖

5. 基本路径测试法：（白盒测试中主要的测试方法），是在程序控制流图的方法下通过分析、控制构造的圈复杂度，导出基本可执行的路径的集合，设计测试用例的方法
   

状态分类

静态测试：无须执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检测软件是否符合编辑标准，借以发现编写的程序的不足之处，减少错误出现的概率（方法与白盒相似）

方式有：互审（程序员相互检测代码）、走查（一个小组一起集体走查程序或文档）、会议（会议相应记录、结果文档）。不正式到正式

动态测试：通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等。（方法与黑盒相似）

执行方式分类

手工测试：由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用针对深度的测试和强调主观判断的测试。（众包测试、探索式测试）

自动化测试；使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。（单元测试、接口测试、性能测试等）