测试知识学习1

软件测试的目的：

验证程序是否满足用户的需求
###什么是测试用例？
向被测程序输入的一组集合，包括：测试环境，操作步骤输入数据，预期结果，前置条件……

认识不同的测试方法：

按测试时间阶段分类：单元测试、集成测试、系统测试、验收测试

单元测试：

含义：对软件中的最小可测试单元进行检查和验证
单元就是人为规定的可测试的模块
1、单元测试的原则：

• 尽可能保证各个测试用力是相互独立的（如果当前函数失败很难判断是调用其他函数失败还是其他的原因）
• 一般有开发人员来实施，所以要对代码有一定的了解
  2、单元测试的好处和局限：
  |好处|局限|
  |--------
  |尽早发现缺陷（测试要尽早的进行，减少损失）敏捷开发(TDD)就要求先写单元测试然后再开发|不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径下的错误。（由于测试本来就是不可能覆盖所有错误）
  | 有利于重构（完善的单元测试后面就可以识别出重构的错误）|每一行的功能代码需要3-5行的测试代码才能完成单元测试，所以存在投入和产出的一个平衡。
  |简化集成|
  |文档（尽可能减少文档，就是不要在维护代码的同时维护文档）|
  |设计的本身可以用于验证设计|

单元测试框架：eclipse中就有JUnit(java)、nunit、CppUnit(C++)、PHPUnit(PHP)

集成测试

含义：在单元测试完成的基础上，针对完成单元测试的模块在组装。
【集成测试的两个策略：深度优先集成和广度优先集成】
集成测试的主要实施的方案：
1、自顶向下集成（比如说从个人中心才能到充值模块，这里叫做主控模块到存根模块 ）：从主控模块开始，沿着程序的控制层次向下延伸，逐步增加新的模块。
2、自底向上集成（传统瀑布式软件研发常用）从程序模块的最底层逐渐向上组装，可以比较好的锁定软件故障，但是只能在最后才能看到结果。

对比单元测试和集成测试：

• 集成测试和单元测试的对象不同

测试依据不同（单元依据详细文档集成测试依据概要）

• 测试方法不同（单元测试关注单元内部，集成测试模块之间接口的集成）

认识架构：C/S架构和B/S架构（浏览器服务器模式，人人网，淘宝网等）IT黑洞：没有了解用户的需求，盲目的开发然后就投资，开发出来之后就会发现没有人需要，那么就产生了IT黑洞，解决方法就是迭代，例如一个淘宝我们可以先实现购买的功能，然后发现用户需要一个购物车，这时候再去更新就不会产生黑洞，减少投资开销，所以说C/S需要用户同意才能用到后面研发的好的功能，例如QQ就会一段时间发布新的版本，如果不的话就只能使用旧的版本。B/S就不会，他的更新不需要经过用户的同意就是不断的迭代。
从安全性来比较：
B/S用户是不可知的，但是C/S架构就在安装的时候知道地址，所以用户就会暴露，那么想做非法的事情就会被发现

系统测试

含义：将经过了集成测试的软件作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境中对计算机系统进行一系列的严格有效的测试，来发现软件潜在的问题，保证系统正常进行。

系统测试的关注点：关注系统本身的使用、关注系统和其他相关系统间的连通、关注系统在不同使用压力下的表现（在CPU等达到极限看软件如何表现）。

系统测试和集成测试的不同：

1、从根本上来看：
集成测试：由通过了单元测试的各个模块所集成起来的构建
系统测试：除了涉及软件还有硬件以及相关外围设备等。
2、从时间上来看：
集成测试介于单元测试和系统测试之间，系统测试在集成测试之后
3、从测试内容上来看：
集成测试：各个单元模块间的接口
系统测试：整个系统的功能和性能
4、从测试角度来看;
集成测试：偏于技术角度的验证
系统测试：偏于业务角度的验证

验收测试

含义：又叫交付测试，针对用户需求业务流程的正式测试，确定系统是否满足验收标准，由用户、客户和其他授权机构决定是否接收系统。
细分：用户验收测试（开发方来做的）、运行验收测试（从运维角度来看）、合同和规范验收测试、alpha测试（由用户执行，环境由开发者提供）、Beta测试（脱离开发者与用户相关环境由用户测试）
release版本就是可交付的版本。
TDD（测试驱动开发）BDD（行为驱动开发）ITDD（验收测试驱动开发）：针对用户故事的验收条件在开发功能代码
总结：
单元测试：各个阶段测试的基础，测试的是最小的可测试单元
集成测试：关注小单元模块间接口以及子系统的集成
系统测试：将系统组装后放在真实运行环境对系统进行全面的评估
验收测试：从用户角度是对系统软件认可的验收

***********************class 2: 按测试手段分类：黑盒白盒（对象的可见度）、静态测试和动态测试（状态）、手工测试和自动化测试（测试执行方式）

按对象可见度来分类：

黑盒测试

含义：不考虑内部逻辑，通过暴露的接口来测试，看是否适当接收输入输出数据符合功能规范。

1. 

优点：（1）容易实施，怒需要关注内部的实现。（2）更贴近用户的使用角度。
2.
缺点：（1）测试覆盖率低（40%）。（2）针对黑盒的自动化测试，复用率较低，维护成本高。
3.

黑盒测试关注：

（1）是否有不正确或者遗漏的功能
（2）在接口上，输入是否正确接收？是否能正确接收？
（3）是否有数据结构错误或外部信息（例如数据文件访问错误）
（4）性能上是否能够满足要求？

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

等价类划分法:举个例子就是根据学生层次不同分层次的制定不同的学习计划，使用的情景就是输入比较多的时候我们使用等价类划分法可以用一个来代表一类，这种方式就是等价类。
例如登录时用户名规定是6至15位，然后是字母（大小写不区分）：
这个案例在划分等价类的时候就是先测试用户名的长度：
（1）在小于6的一类中选择测试5
（2）边界值6
（3）6-15中选择任意一个
（4）边界值15
（5）大于15的一类中选择16
后面测试输入字符是否合法：
（1）在A-Z中选取一个进行测试
（2）在a-z中选取一个进行测试
（3）数字字符也要进行测试一下
（4）特殊字符;#$*&空测试
边界值分析法：一般来讲边界值分析法和等价类划分法都是相辅来进行测试的。此处一定要注意的是范围区间是半开半闭还是闭区间还是开区间，这样都会影响我们的边界值。
因果图法：直观表达程序输入条件和输入动作的相互关系。应用于多种输入条件，程序的输出又依赖于输入条件的各种情况。

白盒测试（结构化测试，透明测试）

测试人员对内部结构是非常了解得，针对程序的逻辑（语句|条件|条件组合|分支|路径）来设计测试用例
白盒测试的缺点：
1、代价比较大
2、无法检测代码中遗漏的路径和数据敏感性错误。
3、不能直接验证需求和正确性。
白盒测试的主要测试方法：
代码检测法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法

灰盒测试

关注输出对于输入的准确性。

按状态来分：

静态测试：

无需执行被测程序，通过评审软件文档或代码，检查软件是否符合编程标准，来发现程序的不足之处，减少错误出现的概率。

动态测试：

运行被测程序检查运行结果是否符合预期，并分析效率。

按测试执行方式：

手工测试：

专门人员从用户的视角来检验软件是否符合设计要求。

自动化测试：

使用单独的测试工具软件控制测试的自动化执行以及对预期的结果进行自动检查。
比较两种测试方式：
手工测试因为是人来测试，就比较容易发现缺陷，而且容易实施，灵活，但是正是因为人来实施就会有缺点：覆盖量化难，重复测试效率低，不可靠，依赖人力资源。二自动化测试就恰恰相反。

class 3: 其他测试：

一、回归测试：（可以针对具体的功能模块）
软件功能修复后再重新测试确认没有引入新的错误，关注关键模块和重点功能组件
软件研发周期中可能会有多次回归测试，而且尽量实现成自动化
二、Monkey测试：（搞怪测试）
用一些随机的稀奇古怪的方式来操作软件，以测试系统的健壮性和稳定性。
Android应用SDK工具
三、冒烟测试（针对全流程）
来自于硬件板卡验证术语，用来确定代码中的更改会按预期进行，且不会破坏整个版本的稳定性。

class 4:软件测试模式

第一种模型 :
传统的瀑布模型：每一阶段都以上一阶段的输出为标准。项目计划---------需求分析------软件设计----------程序开发---------软件测试-----------集成维护
优点：
1、强调需求
2、阶段分工明确
3、按阶段划分比较清晰
4、每一部分都有文档，所以比较方便
缺点：
1、难以适应需求的频繁变化
2、项目周期完成后才能看到结果
3、强调阶段，完成都是有时间点的。
4、文档工作量大

#第二种模型：V模型（最后才会发现问题）

验收测试就是最后再查看是否满足需求，满足合同。将测试放在最后一个阶段，发现缺陷的时间比较晚，所以修改成本高，牵扯的面比较广，更容易引起其他的bug.

#第三种模型：W模型（开发测试看起来并行但还是串行，满足不了敏捷开发的特点。有利于今早发现问题，不适用于迭代的开发）

第四种模型：X模型（左边是针对片段进行的开发和测试）

探索式测试：没有提前计划的。
第五种模型：H模型（只要测试准备完成就可以开始测试，可以交叉进行，尽早发现问题）。

特殊模式-----敏捷测试（敏捷价值观：响应变化，个体与交互，客户协作重于合同谈判）

强调从客户出发，强调尽早测试不间断的测试，具备条件即测试，强带持续反馈，重点在于预防缺陷。
对比传统测试：

传统测试
敏捷测试
测试是最后一部分
开发和测试紧密合作
严格的变更管理
可以接受变更，拥抱变更
预先计划
随时更改计划
有严格的入口和出口标准
没有明显的~回归测试时进行重量级的自动化测试
每个阶段都在进行自动化测试
严格依赖流程走
无需严格按照流程
测试和开发团队相互独立
测试盒开发无缝隙合作
基于脚本的测试—SBT，先做测试设计再进行测试与BT（探索式测试，是一种思维）比较：ET是与测试脚本无关的，先探索找出被测的BUG，
ST：完全按照设计来，测试用例很详细，

ST
ET
系统性强
自由灵活
容易管理、控制
和ST互补
设计在先，执行在后
执行和设计并行
主要是验证自己的思想
不断和系统交互，带着问题测试
可预见
学习过程
探索式测试的优点：
*
激发测试人员的创造性和工作乐趣。
*
增加了发现新的BUG的可能性。
*
在较短时间内找到更多BUG以有利于对被测系统作出评估。
*
更加有效地实施自动化
*
适用于敏捷项目

探索式测试缺点：
*
bug的重复利用和重现上有限
*
依赖测试人员的测试技能和知识深度比较大。
*
只有在被测系统完全可用才可以更有作用（因为要不断交互）
*
生产率难定义