软件测试理论

什么是软件

	（1）概念
			软件是一系列按照特定顺序组织的计算机数据和指令的集合
	（2）特点
			看的见摸不着

软件的分类

	（1）按照开发规模划分
			。小型
			。中型
			。大型
	（2）按照用户对象划分
			。产品软件（大众用户）
			。项目软件（特定用户）
	（3）按照技术架构划分
	 		。单机：计算机/画图工具
	 		。联机
	 		 	B/S架构：新浪/百度
	 		 	C/S架构：qq/LOL
	 		 	    （2）两种架构的比较
					  ①标准：B/S相对标准
					  ②效率 ：C/S相对高效率
					  ③安全 ：C/S相对安全
					  ④升级：B/S相对升级快
					  ⑤开发成本：B/S相对开发成本低	
	（4）按照功能划分
			。应用软件
			。系统软件：数据库管理系统、各种驱动软件、操作系统

浏览器

	（1）定义：
	  浏览器本质是一款软件，安装在操作系统上。一般给用户提供浏览网页的服务。
	（2）五大浏览器生产厂商
	  ①IE（微软）--thrident
	  ②Chrom（谷歌）--blink
	  ③Firefox（火狐）--gecko
	  ④Safari（苹果）--webkit
	  ⑤Opera（欧朋）--presto[现在已经放弃自己东西完全像Chrome]

常见图片类型

	（1）Jpg(Jpeg):高度保留图片色彩信息的格式
	（2）Png：该类的图片可以实现透明
	（3）Gif：图片所占体积小，可以实现动图
	（4）Psd：是一种分层的图片

软件调试与软件测试

	（1）调试：定位错误所在位置，并修改这些错误--由开发者完成--建设性的
	（2）测试：发现软件中的缺陷，提高软件质量--由测试人员完成--破坏性的

软件测试

（1）概念
		在规定的条件下对程序进行操作，以发现程序错误、衡量软件质量，并对其是否满足设计
		要求进行评估的过程
（2）软件测试的目的
		①证明软件能够运作
		②检测软件是否存在缺陷
		③预防软件可能出现问题（管理质量）
（3）测试对象
		①源程序
		②各阶段文档（需求文档、设计文档等）

开发过程模型

 （1）概念
 		软件开发包括需求、编码、测试等阶段，软件开发模型是规范化的软件开发流程
 （2）模型
		①瀑布模型
			制定计划-->需求分析-->软件设计-->编码-->软件测试-->运行维护								   
		②快速原型模型（了解）--》小样/原型
			快速分析-->需求说明-->构造原型-->原型-->运行原型-->评价原型-->修改意见
		③螺旋模型（了解）
			  制定计划-->风险分析-->实施开发-->客户评价（其实就是把瀑布模型执行N遍）
		④敏捷开发（重点）
			背景
			敏捷开发是一种从1990年代开始逐渐引起广发关注的一些新型软件开发方法。它们的具体名称、
			理念、过程、术语都不尽相同。相对于“非敏捷”，更强调团队协助、面对面沟通、频繁交付新的
			软件版本、能够很好地适应需求变化，也更注重软件开发中人的作用
			特点
				。一切从简（流程/文档/交流方式）
				。尽早交付
				。持续迭代，持续交付，周期越短越好
				。以人为本（相信自己的团队，规律的反省/调整/优化）
			基本原则
				。个体和交互胜过过程和工具
				。可以工作的软件胜过面面俱到的文档
				。客户合作胜过合同谈判
				。响应变化胜过遵循计划

迭代流程图

软件测试模型

	（1）概念
			规范化的测试流程
	（2）模型
			①V模型（适用于中小企业）
					流程：需求分析-->概要分析-->详细设计-->编码-->单元测试-->集成测试-->系统测试-->验收测试
					优点：①包含底层测试又包含高层测试；②清楚标识出软件开发的阶段；③采用自顶向下模式，每个阶段分工明确
					缺点：需求难以完全确定，变更需求时导致返工量非常大，模型灵活性比较低
		②W模型（适用于中大型企业（人员要求高））
				需求分析--> 概要设计-->  详细设计--> 编码实现-->模块集成-->系统构建-->系统安装
				    |           |            |           |          |          |        |
				需求测试->概要设计测试->详细设计测试->单元测试->集成测试-->系统测试->验收测试
		③H模型（了解）（对人员要求非常高，很少公司使用）
				测试准备-->测试就绪点-->测试执行（H模型中，软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行）

④最佳实践流程图

软件测试分类

	（1）按照测试阶段划分
			单元测试
				一般包括逻辑检查、结构检查、接口检查、出错处理、代码注释、输入校验、边界值检查。
			集成测试
				一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。
			系统测试
			 系统测试是将经过集成测试的软件，和操作系统/硬件看作一个整体，在实际运行环境下进行测试
					  ①功能测试
					  ②性能测试
					  ③兼容性测试（验证当前软件在不同环境下是否还可以使用）
					  ④安全测试（验证软件是否只是能授权用户提供功能使用）
					  ⑤接口测试
					  ⑥易用性测试
					  ⑦UI界面测试
					  ⑧文档测试……
			验收测试
					①α测试（主要是由一个用户在开发环境进行的测试，也可以
							是公司内部的用户在模拟实际操作环境下进行的测试）
					②β测试（在用户实际环境中进行测试）
					③γ测试（正式发布的候选版本）
					负责人（拓展）
						。客户（甲方）
						。委托第三方评测机构（中国软件测评中心）
						。乙方（软件实施方）
	（2）按照是否覆盖源代码划分
		白盒测试：必须检查程序的内部结构，从程序的逻辑着手，得出测试数据
			测试对象：源代码
		灰盒测试：介于黑盒测试和白盒测试之间，只关注一部分代码逻辑
			应用场景：集成测试，专项测试
		黑盒测试：以用户的角度，从输入数据与输出数据的对应关系出发进行测试
			测试依据：需求文档
			分类
				1）功能相关①功能测试②界面测试③易用性测试④专项测试⑤兼容性测试
				2）性能相关
					指标
					①QPS(TPS)：每秒request/事务数量
					②并发数：系统同时处理request/事务数
					③响应时间：一般取平均响应时间
					QPS(TPS)=并发数/平均响应时间
					④吞吐量：单位时间内系统处理用户的请求数
					分类
					①一般性能测试：
					②稳定性测试（连续运行被测试系统，检查系统运行时的稳定程度）
					③负载测试（不断增加负载，测试软件吞吐量上限，以验证系统的负
							载能力，目的获取最大用户数）
					④压力测试（也叫强度测试，在高压（高负载或者资源少）的情况下
							运行测试，目的是服务器资源处于极限状态和系统在极限状态长时间
							运行是否稳定）
					⑤配置测试（主要是在不同的软硬件配置环境下，进行测试以找到系
							统各项资源的最优分配原则的一种测试）

			缺点
				①不能测试程序内部特定部位
				②如果程序未执行的代码无法发现
				③不可能做到穷举测试
			优点
				①测试人员不需要了解细节，包括特定的编程语言
				②测试人员和编程人员是相互独立的
				③从用户的角度进行测试，很容易被接受和理解
				④有助于暴露任何与规格不一致或者歧义的地方
（3）按照是否运行划分
	静态测试（一般用工具扫描）
		概念：指不运行被测程序本身，仅通过分析或者检查源程序的语法、结构、
			过程、接口等来检查程序的正确性
		测试对象：
			。需求文档
			。各类设计文档
			。源程序做结构分析，流程图分析，代码走查
	动态测试
		概念：指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行
			效率、正确性和健壮性等性能
		测试对象:代码/系统/软件
（4）按照是否自动化划分
	人工测试
	自动化测试（需要借助工具或者代码去完成手工测试工作）
（5）其他
	①回归测试
		概念:指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或者
			导致其他代码产生错误
		应用场景：
			BUG回归
			用例回归（更新版本时）
		回归原则：每一个版本都需要进行前一个版本的回归测试工作
		缺点：工作量大
		解决方案：自动化测试：自动回归测试将大幅度降低系统测试、维护升级等阶段的成本
	②冒烟测试（目的是确认软件基本的功能正常，保证软件系统能跑的起来，可以进行后续的正式测试工作）
	③随机测试（主要针对重要功能、软件更新和增加的功能、特殊情况点、特殊使用环境、之前中大BUG）
	④探索性测试（测试思维技术、具体问题具体分析、测试设计与测试执行同时执行）

测试用例

	（1）定义：一个为了特定目的而设计，包含测试输入、执行条件、预期结果的文档
	（2）测试用例的8大要素
			。编号	ID（唯一性）
			。项目/模块
			。标题（见名知意，简洁）
			。前置条件（外在环境：网络、系统服务是否正常；本模块的前置模块）
			。测试数据
			。测试步骤
			。预期结果
			。优先级
			注意：文档应该还有：实际结果，测试人员，测试实际，结果，备注等字段
	（3）方法
		①等价分类法（重点）
		②边界值（重点）
		③判定表法（重点）
		④场景法（重点）
		⑤流程图（重点）
		⑥因果图
		⑦测试大纲法
		⑧错误推断法
		⑨正交法
	（4）测试用例的完整写作过程
		基于需求规格说明分析测试需求-->设计测试用例-->写作测试用例-->评审测试用例
	（5）书写出好的测试用例
		①从三个维度分析
		  A.用例设计角度 B.用例写作角度 C.用例维护角度
		②对需求的覆盖
		③对被测试对象设计的了解
		④对具体的方法的使用
	（6）用例写作五项原则
		①正确：数据输入
		②清楚：操作步骤
		③简洁：标题
		④完整：预期结果检查完整
		⑤一致性：用例编号

用例优化

	（1）有效类（优化用例）
	  ①同一条用例中可以尽可能多的测试不同控件的一个有效等价类或者边界值
	  ②不同控件的有效数据可以组合在一起测试
	（2）无效类（加强破坏了查看极端的情况下程序的容错性）
	 前提：每个单个无效类都分别测试过才能组合一起强化
	 ①不同控件的无效等价类组合
	  ②同一控件的不同等价类组合

测试用例方法

	（1）等价分类法
		1）定义：
		  ①不需要考虑程序的内部结构，只需要考虑程序的输入规格
		  ②将不能穷举的测试过程进行分类，从而保证设计出来的测试用例具有完整性和代表性
		  注意：不做穷举测试是存在风险的，如果有时间，可以适当补充
		2）应用场景：有数据输入的地方即可
		3）分类
		  ①有效等价类（使得正常业务功能实现）
		  ②无效等价类（验证程序异常处理能力（健壮性））
		4）步骤
		  ①明确测试对象
		  ②分析需求，划分等价类
		  ③细化等价类
		  ④建立等价类表
		  ⑤根据等价类表，编写用例
	（2）边界值法
		1）定义：
		  ①边界是指对于输入等价类和输出等价类而言，稍高于其边界值及低于其边界值的一些特殊情况
		  ②常见的一种黑盒测试方法
		2）应用场景：有数据输入的地方即可 
		3）分类
		  ①有效边界值（有效次边界值）
		  ②无效边界值（无效次边界值）
		4）说明
		  边界值数据本质上就是属于等价类的范畴，但是应该单独测试，这种测试，实际上是一种
		  冗余，但在工程中是必须的
	（3）场景法
		1）基本概念 
		  ①基本流（有效流、正确流）-->软件的正确操作流程
		  ②备选流（无效流、错误流）-->软件的错误操作流程
		2）应用场景
		  ①适合使用场景法的软件的界面特点：很少填写项，一般都是通过鼠标单击、双击、拖拽操作完成
		  ②要求测试人员站在用户的角度，模拟用户的操作
		    A、模拟用户正确操作--验证程序的主要功能，业务逻辑是否正确
			B、模拟用户错误操作--验证程序处理错误的能力（健壮性）
		3）应用场景的两个层面
		  ①业务（需求）--层面：要求测试人员必须精通被测软件
		  ②技术层面（基于等价类）
		   A、模拟用户正确操作--有效等价类
		   B、模拟用户错误操作--无效等价类
		注意：根据场景编写用例，场景和用例不一定是一对一的关系（一个场景可能使用对条用
		例，一条用例可能测试多个场景）
	（4）因果图法
		1）核心概念
		  ①因--输入条件、用户所做的操作、原因
		  ②果--输出结果、用户做完操作的结果、结果使用画图的方式，表达因和果的关系
		2）应用场景
		 同一个窗口中有多个操作，操作和操作之间存在组合关系和限制关系，不同的操作
		 组合会产生不同的输出结果的组合
		3）图形符号
		  ①基本图形
		    A、恒等
			B、与（∧）
			C、或（∨）
			D、非（∽）
		  ②约束限制符号
		    A、互斥（E）
			B、唯一（O）
			C、要求（R）
			D、屏蔽（M）
			E、包含（I）
		4）步骤
		  ①找出所有输入条件
		  ②找出所有输出结果
		  ③在步骤①的基础上找到输入的限制关系和组合关系
		  ④在步骤②的基础上找出输出的限制关系和组合关系
		  ⑤画出输入和输出的关系
		  ⑥根据步骤③和步骤④找出输入组合和输出组合对应的关系
		  ⑦根据步骤⑥，列出判定表
		  ⑧根据判定表编写用例，把判定表的1列转化成1条用例，测试1种组合
		  
	（5）判定表法
		1）组合
		  ①条件桩
		  ②动作桩
		  ③条件项
		  ④动作项
		2）步骤
		  ①列出所有条件桩和动作桩
		  ②填入条件项
		  ③填入动作项。得到初始判定表
	（6）测试大纲法
		1）应用场景
		  一个程序有多个窗口，每个窗口中有多个操作，儿窗口之间又相互关联，弄清楚操作之间
		  的关系，可以使用测试大纲法
		2）使用步骤
		  ①分析需求（列大纲/提纲）--列出每一个窗口以及窗口上的操作（注意窗口顺序）
		  ②找到窗口之间的操作联系，生成一条路径，一条路径对应一条用例
    （7）错误推断法
		1）定义：
		  指利用直觉和经验猜测出错的可能类型，有针对性列举出程序中所有可能的错误
		  和容易发生错误的情况
		2）考虑方向
		  ①以前的BUG相关数据
		  ②异常情况
		  ③反面情况
		  ④特殊输入
	（8）正交排列法
		1）应用场景
		  有很多控件，每个控件有很多个取值，要考虑不同控件不同取值之间的组合。
	    2）核心思想
		  正交排列法核心思想是从大量的数据中挑选适量的、有代表性的点进行测试。
		3）公式Ln(m^k)
		  n：表示行数，即测试组合的次数
		  m：表示每个控件包含多少个值
		  k：表示列，即表示控件的个数
		4）步骤
		  ①分析需求--有多少个控件，每个控件的取值列出来
		  ②选择正确的正交表
		  ③设计编写用例--把正交表的每一行换成1条用例
		5）混合正交表使用Allpairs工具自动生成
		  步骤
		  ①制作取值表
		  ②复制取值表在一个记事本上,把数据粘贴在test1.txt保存
		  ③把test1.txt文档放在安装的allpairs文件夹目录下
		  ④WIN+R进入cmd控制台
		  ⑤在cmd控制台cd进入allpairs文件夹
		  ⑥输入allpairs test1.txt>test2.txt(其中test1是我们放进去的文件
		  ，test2.txt是要生成的新文件名)
	（9）流程图法
		1）应用场景：用于各种测试阶段，比如系统测试/验收测试阶段，
		模拟用户操作场景（测试多个功能组合）
		2）步骤
			①需求分析
			②绘制流程图
			 	常见符号：
			 		。开始或结束：椭圆
			 		。方向或路径：箭头
			 		。处理或操作：长方形
			 		。判断：菱形
			 		。输入或输出：平行四边形
		 3）设计测试用例（一条流程路径就是一条测试用例）

4）举例：#需求：根据生活ATM取款功能，画出业务流程图

测试用例设计报告总结

	原则
	1.具有输入功能，但输入之间没有组合关系--》推荐等价类划分法
	2.输入有边界如长度、类型--》用边界值法补充测试用例
	3.多输入、多输出、输入与输入之间存在组合关系，输入和输出之间存在依赖和制约关系--》判定表
	4.用最少的测试用例获取做大测试覆盖率时--》正交法
	5.多个功能的组合测试--》流程图与场景法
	6.最后推荐使用错误推测法来进一步补充测试用例

阶段测试文档

	（1）单元测试：软件设计文档
	（2）集成测试：软件结构设计文档
	（3）配置项测试：需求规格说明书（接口需求规格说明）
	（4）系统测试：用户需求（研制合同或系统需求）
	（5）验收测试：软件研制合同（用户需求或者系统需求）

软件测试流程

	（1）需求分析
	（2）设计用例
	（3）用例评审
	（4）配置环境（操作系统+服务器软件+数据库+软件底层代码的执行环境）
	（5）执行用例
	（6）回归测试及缺陷跟踪
	（7）输出测试报告
	（8）测试结束

主要的测试文档

	（1）测试计划：测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档；
	（2）测试方案：为完成软件集成特性的测试而进行的设计测试方法的细节文档；
	（3）测试用例：为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档；
	（4）测试规程：执行测试时测试活动序列的文档；
	（5）测试报告：执行测试结果的文档；
	（6）测试日报：每天测试执行情况的记录和总结。

测试的七大原则

	（1）通过测试可以显示缺陷的存在
	（2）穷尽测试是不可能的
	（3）测试要尽早介入
	（4）缺陷的集群效应（对于软件功能来说，核心功能占20%，非核心功能占80%，在实际工作
	中我们会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%，缺陷都集中
	在20%的功能模块里）
	（5）杀虫剂的悖论（同样的一个测试用例不能重复的执行多次，因为软件会对它产生免疫）
	（6）测试依赖于特殊的环境
	（7）没有缺陷的系统并不代表有用的系统

软件内部质量六大特性

	（1）功能性：当软件在指定条件下使用时，软件产品提供满足明确的和隐含的能力，包括是适合性、
	准确性、互操作性、安全保密性、依赖性
	（2）可靠性：在指定条件下使用时，软件产品维持规定的性能级别能力，包括成熟性、容错性、易
	恢复性、依从性
	（3）易用性：在指定条件下使用软件产品被理解被学习使用和吸引用户的能力，包括易学性、易操
	作性、吸引性和依从性
	（4）效率性：在规定条件下软件产品执行其功能时使用包括资源利用性和效率依赖性合适数量和类
	别资源的能力，
	（5）维护性：软件产品可以被修改的能力可能包括纠正、改进、软件对环境的需求 和功能规格说明
	变化的适应，包括易分析性、易改变性、稳定性、易测试性和依从性
	（6）可移植性：软件产品从一种环境迁移到另一种环境的能力，包括适应性、易安装性、共存性、
	易替换性和可移植性的依从性

缺陷报告

	（1）软件缺陷
	  错误，毛病，异常，功能的失效与违背，使用中的错误
	（2）缺陷报告
	  当测试人员发现了一个缺陷，需要填写一份“缺陷报告”来记录这个缺陷，并通过这个缺陷
	  报告告知开发人员所发生的问题-----缺陷报告是测试人员与开发人员交流沟通的重要工具。
	（3）缺陷报告重要组成
		。编号ID（唯一性）
		。模块
		。标题
		。严重程度
			。严重：主功能不可用，Crash问题、闪退、不能启动等
			。一般：次要功能不可用，边界、异常未进行处理等
			。微小：易用性问题、界面展示、小的性能问题
			。建议
		。优先级
			。高：阻塞性问题，影响继续测试
			。中：正常流程，本次迭代上线修复即可
			。低：可以延期到下个版本解决
		。复现步骤
		。预期结果
		。实际结果
		。缺陷类型：代码错误、界面错误、兼容性错误、性能问题、安全问题、易用性问题
		。缺陷状态
			。新建
			。指派/未指派（这个是操作，不是状态）
			。打开
			。修复/拒绝/延期
			。关闭/再次打开
	（4）缺陷报告的用途
		1.记录缺陷
		2.对缺陷进行分类（发现者，日期，模块，版本，状态，严重程度，优先级）
		3.对缺陷进行跟踪（new--->closed）
		4.对缺陷进行分析统计总结
	（5）如何识别一个缺陷
		1.参考测试用例的预期结果
		2.参考相关文档（需求，开发，用户手册）
		3.讨论
		4.参考缺陷的5点定义
	（6）缺陷起源
		1.Requirement:在需求阶段发现的缺陷
		2.Architecture：在架构阶段发现的缺陷
		3.Design：在设计阶段发现的缺陷
		4.Code：在编码阶段发现的缺陷
		5.Test：在测试阶段发现的缺陷
	（7）缺陷来源
		1.Requirement:由于需求的问题引起的缺陷
		2.Architecture：由于架构的问题引起的缺陷
		3.Design：由于设计的问题引起的缺陷
		4.Code：由于编码的问题引起的缺陷
		5.Test：由于测试问题引起的缺陷
		6.Integration:由于集成问题引起的缺陷
	（8）缺陷类型分类
		1.业务逻辑
		2.数据处理
		3.接口
		4.UI
		5.性能
		6.安全性
		7.兼容性
		8.配置
		9.文档等
	（9）注意：
		1.一个报告只能提交一个缺陷
		2.缺陷描述清晰易读，准确，使用最少，必须的步骤，保证缺陷重现
		3.提交缺陷报告之前一定要认真审核，确保提交的缺陷是有效缺陷，而不是因自己
		疏忽或操作不当造成的“假缺陷”
		4.不要为了引起开发人员注意夸大缺陷
		5.小bug也要报告
		6.及时报告缺陷
		7.对于不可重现的bug也要报告
		8.不做任何评价   

BUG的分类

	（1）三种无效bug
	   ①By design设计本该这样
	   ②Duplicat重复提交的bug
	   ③Not Repro无法重现的bug
	（2）四种有效bug
		①Externa,因为外部因素导致的问题（浏览器操作系统，第三方）
		②Fixed,问题已修复
		③Postponed,延迟处理后续版本
		④won't fix是个bug,太过于细小，不值得修改

Buglist

作用①用于统计②了解隐患③绩效考核

基线

	已经正式通过审核批准的软件阶段性产品，是一个阶段性的开发版本，是一个具有里程碑意义
	的阶段性版本，可以作为下一步开发的基础

缺陷管理工具–禅道

（1）禅道是项目管理工具，用于测试用例管理和BUG管理
	1）编写用例
		测试-》用例-》“+建用例”
	2）提交BUG
		测试-》Bug-》“+提Bug”

版本控制系统–SVN

	（1）SVN是一个开源版本控制系统，用于多个人共同开发同一个项目时，实现资源共享，实现集中式管理
	（2）管理对象
		。需求、设计等文档
		。代码（源程序）
	（3）服务端
	（4）客户端