课程目标（总体框架见文末）
了解软件测试的含义
软件测试遵循的准则
软件测试有哪些分类是什么概念
何时开始测试方案如何设计p>
测试流程是怎样的提bug写 告p>
为什么要做自动化做p>
1-1软件测试概要
什么是软件测试strong>
IEEE定义：使用人工或自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。
软件测试的测试对象
软件需求、软件概要设计、软件详细设计、软件运行环境、可运行程序、软件源代码（涵盖软件开发整个过程）
五大要素和两个目标
4、缺陷具备群集特性（发现问题多的模块可能存在更多的问题）
5、测试的杀虫剂悖论（测试用例和测试方法应该定期修改/增加，从而能发现更多缺陷）
6、测试的二八原则（80%的时间和资源用在20%的重点模块上，来达到高测试效率和最佳的资源配置比例）
7、测试活动依赖于测试背景
2-1软件测试阶段
软件测试的分类
按测试阶段来分：单元测试集成测试 系统测试 验收测试
单元测试
1、定义
对软件中的最小可测试单元进行检查和验证。（如C中的函数，Java中的类，有界面的功能软件中的菜单项或者说功能项）
2、单元测试的原则
1）尽可能保证各个测试用例是相互独立的。（即不要在测试用例中调用外部依赖的函数或类，因为这样无法判断是调用的依赖有问题还是函数本身有问题）
2）一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。
3、单元测试的益处
1）能尽早发现缺陷（例如TDD是测试驱动开发（Test-DrivenDevelopment）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。）
2）有利于重构
3）简化集成（保证最小单元模块的稳定性和正确性，为集成测试奠定基础。）
4）文档（减少代码对应的文档的修改）
5）用于设计（设计本身可以用来验证设计）
4、单元测试的限制
1）不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误。
2）每一行代码，一般需要3-5行测试代码才能完成单元测试，所以存在投入和产出的一个平衡。
5、单元测试框架
Xunit：Junit（针对java）、Nunit（针对.NET）、PHP Unit（针对PHP）、CPPUnit（针对c++）。
例如：
在Eclipse中使用JUnit4进行单元测试（初级篇）
http://blog.csdn.net/andycpp/article/details/1327147/
集成测试
1、定义
是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。
2、集成测试的主要实施方案
1）Big Bang（所有东西组装好，然后一起做测试）
2）自顶向下（递增组装软件，从控制层逐层向下）
3）自底向上（传统最常用，从下向上组装，容易锁定故障所在位置）
4）核心系统集成（先对核心部分测试，再逐步扩展到外围）
5）高频集成（每隔一段时间开发团队就进行一次集成测试）（4、5是敏捷开发中常用的）
集成测试&单元测试
1、测试的对象不同
集成测试：模块与子系统，模块之间接口关系
单元测试：最小单元
2、测试的依据不同
集成测试：概要设计
单元测试：详细设计
3、测试的方法不同
系统测试
1、定义
是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。（企业的岗位一般是针对系统测试，如功能测试、性能测试、稳定性测试）
2、关注点
关注系统本身的使用
关注系统与其他相关系统间的连通
关注系统在不同使用压力下的表现
关注系统在真实使用环境下的表现
系统测试&集成测试
1、测试对象
系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统
集成测试：由通过了单元测试的各个模块所集成起来的构件
2、测试时间
集成测试介于单元测试和系统测试之间
系统测试在集成测试之后
3、测试内容
集成测试：各个单元模块之间的接口
系统测试：整个系统的功能和性能
4、测试角度
集成测试：偏于技术角度的验证
系统测试：偏于业务角度的验证
验收测试
1、定义
也称交付测试。针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。（强调用户角度）
2、细分
1）
用户验收测试（开发方自己验收）
运行验收测试（运维角度，如系统备份、容灾、灾难恢复）
合同和规范验收测试（参照合同规范，针对政府法律法规验证）
2）
Alpha测试（开发者提供的场所和环境中，由用户执行）
Beta测试（完全脱离开发者，在用户提供的场所和环境中测试）
3、应用
在敏捷开发中，有验收测试驱动开发ATDD，是TDD的延伸。也有叫BDD行为驱动开发的。ATDD与BDD概念类似。
2-2 软件测试手段
软件测试的分类
按测试手段来分类
测试时对象的可见度：黑盒测试、白盒测试
状态：静态测试、动态测试
测试执行方式：手工测试、自动化测试
黑盒测试
1、定义
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是事件驱动的，是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。（在系统测试阶段用的最多）
2、优点
1）容易实施，不需要关注内部的实现
2）更贴近用户的使用角度
3、缺点
1）测试覆盖率较低，一般只能覆盖到代码量的不到40%
2）针对黑盒的自动化测试，复用率较低，维护成本较高
4、主要测试什么p>
1）是否有不正确或遗漏的功能p>
2）在接口上，输入是否能正确的接受输出正确的结果p>
3）是否有数据结构错误或外部信息（例如数据文件）访问错误p>
4）性能上是否能够满足要求p>
5、主要设计方法
1）等价类划分法：把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。
2）边界值分析法：是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。
3）错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
4）因果图法：分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。根据这些关系，画出因果图。再根据规格的语义说明，把因果图转换为判定表。最后根据判定表编写测试用例。
5）正交试验分析法：通过正交性从一组数据中筛选出典型的代表性数据的设计方法。主要用于筛选输入数据，然后设计测试用例。
6）状态迁移图法：通过梳理软件功能点里的状态迁移关系来设计测试用例。
7）流程分析法：通过梳理程序的逻辑执行路径来设计测试用例。
白盒测试
1、定义
测试人员全面了解程序内部逻辑结构、对所有逻辑路径进行测试。又称为结构测试、透明盒测试。针对逻辑结构来设计测试用例。用逻辑的覆盖率衡量测试的完整性。
2、主要的逻辑单位
语句、条件、条件组合、分支、路径。
不同的逻辑单位有不同的覆盖方法。逻辑覆盖包括语句覆盖（保证程序的每条语句至少执行一次）、条件覆盖（所有条件的表达式至少计算一次）、条件组合覆盖（覆盖所有各种条件的组合情况）、判定/分支覆盖（保证每个分支至少执行一次）、判定和条件组合覆盖和路径覆盖（每条可能的路径至少执行一次，分支是路径的一部分）。
3、优点
1）迫使测试人员去仔细思考软件的实现，理解原理
2）可以检测代码中的每条分支和路径
3）揭示隐藏在代码中的错误
4）对代码的测试比较彻底
4、缺点
1）昂贵
2）无法检测代码中遗漏的路径（代码中少写的）和数据敏感性错误（数据处理有问题）
3）不能直接验证需求的正确性
5、主要测试方法
1）代码检测法：主要包括多面检查、代码审查、走查。主要检查代码和设计的一致性。对代码本身进行检查。
2）静态结构分析法：测试者通过使用测试工具，分析源代码的系统结构、数据结构、内部的控制逻辑，通过内部结构的分析设计测试用例。
3）静态质量度量法：根据标准的质量模型（如ISO），构造质量的度量模型，用于评估软件各方面要素。
4）逻辑覆盖法：见2
5）基本路径测试法（主要）：在程序控制流图的基础上，通过分析控制构造的圈复杂度，导出基本可执行路径的集合，进而设计测试用例。
灰盒测试
介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现。更多是在系统组件这层评价应用软件的设计符合需求的情况。
静态测试
1、定义
静态测试是指无须执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率。
2、方式
互审（两个程序员，不正式）、走查（小组）、会议（正式）
动态测试
动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等。
手工测试
由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用针对深度的测试和强调主观判断的测试。
如众包测试、探索式测试
自动化测试
使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。
如单元测试、接口测试、性能测试等。
手工测试vs自动化测试
手工测试：
优点：易发现缺陷；容易实施；创造性、灵活性
缺点：覆盖量化难；重复测试效率低；不一致性、可靠性低；人力资源依赖
自动化测试：
优点：高效率、速度快；高复用性；覆盖率容易度量；准确、可靠；不知疲劳
缺点：机械、发现缺陷率低；一次性投入较大
2-3 软件测试模式
软件测试的分类
按测试模式来分类
瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等
传统的瀑布模型
V模型明确界定测试过程存在不同阶段，明确测试不同阶段和研发不同阶段的对应关系。
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
W模型
X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。
H模型
2、ST VS ET
ST：系统性强；容易管理、控制；设计在先，执行在后；主要是验证自己的思路；可预见性
ET：自由灵活；和ST互补；执行和设计（思考）并行；不断和系统交互，带着问题测试；学习的过程
3、探索式测试的优点
更能激发测试人员的创造性和工作乐趣
增加了发现新的或较深入BUG的可能性
在较短时间内找到更多BUG以及对SUT（被测系统）作一个快速的评估
有利于更加有效地实施自动化
更加适用于敏捷项目
减少了在简单、繁复用例上的无谓编写时间
4、探索式测试的缺点
测试管理上有局限性，较难协调和控制
对于BUG的重复利用和重现上作用有限
对测试人员的测试技能和业务知识深度依赖较大
只有在SUT已完全可用的前提下才更有作用
ET的生产率很难定义
ET本身较难进行自动化
5、局部探索式测试
从被测系统的五大要素入手：
（1）输入
任务：接受输入、产生输出、存储路径、进行运算；
测试角度：输入顺序、输出内容、输出异常。
（2）状态
临时状态：运行时有效、阶段有效
永久状态：数据库保存、文件保存
（3）代码路径
对代码的覆盖
（4）用户数据
采用真实的用户数据，或构造合理的数据
（5）执行环境
操作系统、系统组 的 络拓扑、和系统交互的第三方系统、系统的配置数据、运行系统的硬件设备
6、全局探索式测试
漫游测试法：测试人员像游客游览一样，把被测系统按照不同属性分成不同区域，进行针对性测试。
（1）商业区：软件从启动到关闭之间，用户主要可能使用的软件特性和功能。（指南测试法、麻烦测试法）
（2）旅馆区：软件在休息或没有在实际运行时的功能，一般指运行在后台的一些进程或定时任务。（懒汉测试法）
（3）历史区：版本的历史遗留代码中的一些功能，或在以前的测试中发现较多问题的功能。（恶邻测试法）
（4）旅游区：新用户会使用或比较关注的一些功能，如新手指引，新用户注册等。
（5）娱乐区：主要功能之外的辅助特性和功能。（深巷测试法）
（6）破旧区：系统废弃或隐藏的、用户看不到的一些功能，一般在用户手册中提及。（破坏测试法）
7、执行探索式测试
基于模型的测试-MBT
测试用例是从一个模型中完整或部分导出得到的，而该模型描述了被测系统的某些（通常是功能）方面。 此处的“模型”指对需求功能点建模。
https://blogs.msdn.microsoft.com/sechina/2009/11/18/123/
1、主要的MBT工具
Spec Explorer（Microsoft）
GraphWalker（OpenSource）
http://graphwalker.github.io/
Tcases（OpenSource）
https://github.com/Cornutum/tcases
modeljunit（OpenSource）
http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/
3-1 软件测试类型
软件测试的分类
按测试类型来分类
3、性能测试工具
兼容性测试
1、内容
软件本身的兼容性（新版本对旧功能的兼容）
不同平台下的兼容性（如Linux下有各种不同版本）
软件对运行设备的兼容性（32位/64位，PC、Pad、手机、电视盒子等）
软件互操作性（不同软件之间的兼容性）
2、浏览器内核的兼容性
内核
文档测试
针对软件产品的交付品，配套的文档类部件的测试。如用户手册、使用说明、用户帮助文档等。
1、关注要点
完整性、正确性、一致性、易理解性、易浏览性。
可靠性测试
1、软件可靠性：软件系统在规定时间内，规定环境下能完成规定功能的能力。
2、硬件可靠性（更多）：硬件产品在设计应用过程中受气候环境、机械环境的影响，能否正常工作。
易用性测试
易用性测试是指测试用户使用软件时是否感觉方便，是否能保证用户使用体验的测试类型。比如是否最多点击鼠标三次就可以达到用户的目的。
易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用。
本地化测试
针对软件的本地化版本实施的针对性测试。（如中文版、英文版）
主要测试内容：语言、书写习惯；时区、日期格式、货币；当地风俗、法律法规；政治敏感内容。
部署测试
也称安装测试，主要验证系统部署过程，并确保软件经过安装测试后可以正常使用。
主要测试内容：在不同环境下的部署验证；参照部署文档执行，过程的合理、正确性；基础数据。
无障碍测试
Accessibility Test.也称可访问性测试。是指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试。
4-1 其他测试分类
软件测试的分类
其他的一些测试类型概念
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！