测试知识点

什么是软件测试
使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
什么是测试用例
1.评价测试人员的标准主要有两个，即发现的有效Bug数和编写的有效测试用例数。
2.测试用例：英文为Test Case，缩写为TC。指的是在测试执行之前设计的一套详细的测试方案，包括测试环境，测试步骤，测试数据和预期结果。
3.测试用例 = 输入 + 输出 + 测试环境
测试用例结构组成
1.测试用例分为：模块划分，前提条件（包括测试数据，测试环境，操作步骤前提等），用例步骤（注意做到一条用例一个明确操作），期望结果，执行结果，备注（标注不符合预期的表现，或者link case failed相关bug）。针对比较稳定的版本，发版周期较长的稳定产品，规范化的用例结构是这样的。
2.针对敏捷性开发，版本迭代比较快的产品，基本使用思维导图编写用例，用例结构只要包括：前提条件，执行步骤，预期结果和执行结果即可。
测试用例管理工具
1.Quality Center：Quality Center是一个基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷，此外，通过Quality Center还可以创建报告和图来监控测试流程。付费平台，普及率不高。
2.TestManager：Rational测试解决方案中推荐的测试用例管理工具。文件夹形式的管理，可以对测试用例无限分级。可以和Rational的测试工具robot、functional相结合。但测试用例很多时不太稳定。有时会造成测试用例的丢失。且必须安装客户端才可使用。和开发人员交流不方便。
3.TestDirector：和Rational测试系列其名的测试管理工具，有测试用例执行跟踪的功能。
4.TestLink： Web方式的界面。和bugzilla缺陷管理工具的整合，可以自定义和其他缺陷管理工具的整合。同时具有需求管理的功能。
5.Excel形式：多适用于移动端应用用例编写，编写修改方便，便于维护。
6.思维导图：最常见的为MindManager，Xmind
Tips
1.测试用例模板
2.Bug 模板
3.公司里测试部门的组织结构
4.用什么工具管理Test Case和Bug
5.测试分为几个组，分别是什么 等等
6.以上这些根据公司不同而不同，面试的时候可以问面试官相关的问题，例如 
软件测试分类
1.黑盒和白盒测试
2.静态和动态测试
3.单元测试、集成测试、系统测试、验收测试
4.功能测试
5.性能测试
6.回归测试、Smoke测试、随机测试（探索性测试）
黑盒和白盒测试的概念
1.黑盒测试(Black-Box Testing), 指的是把被测的软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。
2.白盒测试(White-Box Testing), 指的是把盒子盖打开，去研究里面的源代码和程序结构。
3.在软件公司里，往往采用黑盒和白盒技术相结合的方法，对软件的整体功能和性能进行黑盒测试，对软件的源代码采用白盒测试
静态和动态测试
1.所谓的静态测试(Static Testing), 是指不实际运行被测软件，而只静态的检查程序代码、界面或文档中可能存在的错误的过程。
2.动态测试(Dynamic Testing), 是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态还是静态测试，唯一的标准就是看是否运行程序。
黑盒白盒，静态动态的关系
1.它们只是一个测试的不同分类角度而已，而且它们之间还有包含交叉的关系，总结一下4句话：
2.黑盒测试有可能也是动态测试(运行程序，只看输入和输出), 也有可能是静态测试(不运行程序，只查看界面)
3.白盒测试有可能也是动态测试(运行程序，并分析代码结构), 也有可能是静态测试(不运行程序，只是静态查看代码)
4.动态测试有可能也是黑盒测试(运行程序，只看输入和输出), 也有可能是白盒测试(运行程序，并分析代码结构)
5.静态测试有可能也是黑盒测试(不运行程序，只是查看界面), 也有可能是白盒测试(不运行程序，只是静态查看代码)
单元测试-集成测试-系统测试-验收测试
1.软件测试中基本且重要的概念，它们都是按照软件测试的阶段来划分的。
2.单元测试：对软件中的最小可可测试单元（最小的功能模块）进行检查和验证。
3.集成测试：是单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。（接口测试）
4.系统测试：是指将整个软件系统看做1个整体进行测试，包括对功能、性能、安全、兼容性进行测试。
5.验收测试（Acceptance Testing）: 是指在系统测试的后期，以用户测试为主，或有测试人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。
比较：
 
功能测试和性能测试
1.功能测试（Function Testing): 检查实际软件的功能是否符合用户的需求。可细分为：
2.逻辑功能测试、界面测试、易用性测试、安装卸载测试、兼容性测试、安全测试。
3.性能测试 (Performance Testing): 一般要用到自动化工具。软件的性能分为时间和空间的性能：
4.时间性能：主要指软件的一个具体事务的响应时间(Respond Time)
5.空间性能：主要指软件运行时所消耗的系统资源 （e.g. CPU, 内存，硬盘等）。
6.软件性能测试的分类：一般性能测试、稳定性测试、负载测试、压力测试。
性能测试分类
1.一般性能测试：指被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。例如只让1个用户多次登录，记录系统资源的消耗情况(CPU,内存等），并记录单个用户的平均登录时间。
2.稳定性测试（Reliability Testing）: 是指连续运行被测系统，检查系统运行时的稳定程度。用错误发生的平均时间间隔(MTBF)来衡量系统的稳定性，MFBF越大，系统的稳定性越强。
3.负载测试(Load Testing): 通常是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。例如让1个，2个，5个，10-100个用户并发登录，在这个过程中每次都观察资源消耗情况，当发现资源消耗快要达到临界值时(CPU 80%), 停止增加用户，例如现在的并发用户数为50，我们就用这50个用户同时多次重复登录，直到系统出现故障为止。 负载测试为我们测试系统在临界状态下运行是否稳定提供了一种办法。
4.压力测试 (Stress Testing): 通常是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。比如我们不断地增加并发登录的用户数，120，150，170，200…、当增加到200个用户并发登录时，系统崩溃了，这是我们就知道此软件所能承载的最大登录并发数为200个左右。
案例 – 纸杯测试
微软公司的一道面试题，面试官随意选一个物品，让应聘者在规定的时间内说出测试策略或是设计测试用例。

要求应聘者有一定的生活常识，了解常用的测试方法，并且思维要敏捷，有发散性。我们可以从 基本功能测试、易用性测试、界面测试、压力测试、性能测试等角度去思考。比如安全性问题，杯子所用的材料是否符合食品卫生标准，在内外温度等环境因素下是否会与所盛各种饮料所应，而产生对人体有害的物质。

以下是相关的答案，仅供参考：
(1)      基本功能测试（逻辑功能测试）：
硬度：是否达到设计标准。
装载能力：在杯子内分别装入少量的、半杯的、满杯的，看其装载量是否达到设计标准。
装载种类：开水（是否产生异味）、温水、冷水、冰水、咖啡，有颜色的饮料……
(2)       界面测试（UI测试）：
看其形状、大小设计是否适合人方便拿起。
外观是否吸引人（广告嘛），常新悦目
带广告的图案沾水后是否掉色、模糊
(3)       易用性测试：
看其形状、大小设计是否适合人方便拿起。
残疾人士用此杯去喝水的容易程度。
杯子设计是否上大下小，在运输过程中可以套在一起有效利用空间，在使用完也可以方便拿走。
（4）稳定性测试，装入液体后记录其多久以后漏水
（5）安全性测试，材料问题，符合食品卫生标准，温度，异味
（6）本地化测试，为国际化和本地化的需要，广告图案和文字是否在政治，宗教和文化方面具有广泛的适用性。
回归测试、Smoke测试、随机测试
这3个概念也很重要，他们既不属于测试阶段，也不算是具体的测试方法。
1.回归测试(Regression Testing), 是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。
2.冒烟测试(Smoke Testing), 是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
3.随机测试（Random Testing），是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。缺点，不如测试不系统，无法统计覆盖率/需求覆盖率，很难回归测试等，所以一般都是先作大规模的正规测试，如果时间允许的话，就辅助一些随机测试。
总结
 
黑盒测试技术
1.等价类方法
2.边界值方法
3.因果图法
4.流程图法
等价类方法总结
1.等价类的定义
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。
2.等价类划分的步骤
(1)先考虑输入数据的数据类型（合法和非法的类型）
(2)再考虑数据范围（合法类型中的合法区间和非法区间）
(3)画出示意图，区分等价类
(4)为每一个等价类编号
(5)从一个等价类中选举一个测试数据构造测试用例
理论上来说，如果等价类里面的一个数值能够发现缺陷，那么该等价类里面的其他数值也能够发现缺陷。实际过程中，首先要确保等价类的划分是争取的，否则也得不到正确的结果。多看一些案例，将这种思想应用到实际工作中。
等价类和边界值的关系
其实边界值和等价类的联系是很紧密的，边界值就是根据等价类划分的过程中产生的。而由于边界的地方最容易出错，我们在从等价类中选取测试数据的时候也经常选取边界值。

举一反三！
黑盒测试技术 – 因果图法
1.所谓的原因，指的就是输入；所谓的结果，指的就是输出。
2.因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。
3.实际在测试的时候可以画因果图，但是笔者认为其有画蛇添足之嫌。其实因果图方法的本质就是构造所有输入条件的排列组合，达到这一目的就可以了。而且因果图的画法比较理论化，晦涩难懂，因此这里就不做过多的介绍。
4.因果图法小结
因果图的步骤
找出所有输入条件和输出条件，并编号。
分析输入条件之间的关系，是互斥还是可以同时满足。
画出输入条件的排列组合情况。
编写测试用例。

2. 因果图的应用场合
当软件的输入条件较多的时候，我们可以考虑用因果图法来设计测试用例，考虑输入的所有排列组合情况，防止遗漏。

3. 因果图的局限性
假如有N个条件，每个条件有真或假两种取值，那么理论上就有2的N次方种排列组合，这就大大增加了测试用例的数目，不便于维护。我们可以根据实际情况判断并精简输入条件的个数。
黑盒测试技术 – 流程图法
1.我们在编程的时候，一般都需要画程序的算法流程图。我们同样可以将这一思想应用到黑盒测试领域。算法流程图是针对程序内部结构的，而黑盒测试的流程图是针对整个系统业务功能流程的。
2.比如我们测一个B-C(商家对顾客)的电子商务网站，可以画一个顾客购物的流程图。再如，我们要测试某个机票预定系统，可画一个订票的流程图。凡是涉及业务流程的地方，我们都可以应用这种方法。我们来总结一下流程图法的步骤。
第一步：详细了解需求。
第二步：根据需求说明或界面原型，找出业务流程的各个页面及各页面之间的流转关系。
第三步：画出业务流图（路径图）
第四步：写用例，覆盖所有的路径分支。
流程图法一般不是针对具体某个页面或是某个模块的测试，而是将被测系统看作一个完整的系统，从宏观上来分析其业务流程，然后再画出流程图来。其好处在于能够使测试人员对被测系统有一个总体的把握，防止测试的时候有遗漏的页面或模块。
黑盒测试技术的综合运用
1.在实际测试过程中，我们往往需要综合各种测试技术。
2.我们首先应用流程图法画出被测软件的总体业务流程，然后针对具体某个页面或是模块，再应用等价类的思想来划分输入范围(重点测试边界值)，如果涉及多个输入条件的组合情况，我们再应用因果图法考虑所有情况的排列组合。
 
测试用例的设计
依据的方法：等价类划分法\边界值分析法\因果图法\流程图法 等。
我们编写的测试用例一般包括功能测试用例、非功能测试用例、百盒测试用例。
功能测用例主要是基于需求的业务逻辑，是设计的重点。
非功能测试用例主要包括界面测试用例、易用性测试用例、性能测试用例、兼容性测试用例、安全性测试用例等。
白盒测试用例一般在单元测试之前编写，需要白盒测试的基本知识。
缺陷管理
1.Bug的分类
2.缺陷报告
3.提交缺陷报告的注意事项
4.Bug的处理流程
5.常见的缺陷管理工具
Bug的分类
1.Bug的基本定义：软件的Bug指的是软件中（包括程序和文档）不符合用户需求的问题，从这个定义中我们可以知道判断一个Bug的标准就是看其是否符合用户的需求。
2.那么常见的Bug从不同的角度，可以将Bug分为多种类型。
按严重程度（Severity）划分。例如：系统崩溃、严重、一般、次要、建议。
按优先级（Priority）划分。表示处理和修正软件缺陷的先后顺序。例如：高(High)、中(Middle)、低(Low)。
按照测试种类划分。可以将Bug分为逻辑功能类、性能类、界面类、易用性类、兼容性类等等，就是前面讲到的Bug分类。
按功能模块划分。二八原则，我们在测试的时候可以统计一下Bug主要集中在哪些模块里，找到重点测试的区域。
按Bug生命周期划分。每个Bug都有其生存和死亡的生命周期，可以这样划分：New，Investigated，Confirmed，Fixed，Closed，Reopen。
缺陷报告
1.不同的项目组会有不同的缺陷报告模板，报Bug时应该按照模板严格填写各项内容，使得缺陷报告更加完整。
2.开发人员对Bug的解决情况 和 测试人员的验证情况  通常是测试人员和开发人员沟通的机会。
提交缺陷报告的注意事项
缺陷报告是测试人员的主要工作产品之一。缺陷报告的读者通过缺陷报告来了解和评价测试人员，好的测试报告会增加开发人员对测试人员的信任度，差的缺陷报告会影响开发人员的效率，也会影响测试人员自身的声誉。下面列出了一些提交Bug时的注意事项：
确保重现Bug
要用最少且必要的步骤描述Bug
简洁、准确、完整
一个Bug一个报告
测试人员要经常换位思考，尽量多站在开发人员的角度上思考问题。提交Bug时保持中立客观的态度，不要掺杂强烈的个人主观感情在里面。“You”，“My”，“They”等不应该出现在Bug的描述里。
Bug的处理流程
实际上，不同公司的Bug处理流程一般是不同的，同一公司不同项目的Bug处理流程也不尽相同。一般情况下的Bug的bug处理流程如下图所示：
 
常见的缺陷管理工具
“工欲善其事，必先利其器”，使用合适的缺陷管理工具，可以使我们的缺陷管理事半功倍。
比较流行的Bug管理工具：TrackRecord、Clearquest、Bugzilla(Free)、Mantis(Free)、JIRA(Free)、Github(Free)。很多公司也有自己研发的Bug管理工具，例如微软的
生命周期
软件的生命周期：
 
软件开发和软件测试的生命周期：
 
认识几个模型
 
 
 
 
软件测试计划
编写测试计划的注意事项。编写测试计划时，应注意以下四点：
增强计划的实用性，一切从实际出发，不流于形式。
坚持“5W1H”规则，明确内容与过程。
采用评审和更新机制，保证测试计划满足实际需求。
分别创建测试计划与测试策略。(测试策略重点在HOW，目标性强。)
5W1H分别指：
 
公司里测试部门的组织结构
手工和自动化比例
开发和测试人员比例
外包测试的比例
软件测试工程师所需具备的素质三心二意1能力
三心：细心、耐心和信心
二意：服务意识、团队合作意识
1能力：沟通能力
如何成为一名优秀的测试工程师
大侠是怎样炼成的？测试高手是怎样炼成的？
内功是基础，测试人员也需要打好基础，计算机硬件、网络、操作系统、数据库、移动Ａｐｐ，语言等等。
内功基础上就是各种武术招式了，测试里面的武术招式就是各种测试技术，比如黑盒测试中的等价类、边界值、因果图．．．白盒测试中的语句覆盖、分支覆盖、路径覆盖．．．这些技术都比较实用，还有实现自动化测试等。但是打好基础是前提。
走　　理论－＞实践－＞理论　　的路线。
什么是ＣＭＭ
1.全称为Capability Maturity Model,  即“能力成熟度模型”，是一个主流的标准质量模型，是由卡耐基－梅隆大学于２０世界８０年代定制的，最初只是应用于本校的软件项目开发中，后来逐渐推广为主流的行业标准。
2.对于做欧美外包项目的软件公司，ＣＭＭ还是很有作用的，因为欧美很多公司都认可ＣＭＭ认证，如果公司过了ＣＭＭ３或ＣＭＭ４，那么说明该公司具备了承接国际项目的经验和实力。
华为ＣＭＭ４，东软ＣＭＭ５。
微软，甲骨文等国际知名公司往往没有过ＣＭＭ。一流公司做标准，二流公司做品牌，三流公司做产品，微软不需要遵循别人的标准，微软就是标准的制定者。
软件测试的一些基本原则
Zero Bug 与Good Enough
1.Zero Bug指的是软件没有任何Bug, Good Enough指的是只要软件达到一定的质量要求，就可以停止测试了。
2.Good Enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源浪费，同样也是不负责的表现。如何界定是个问题，涉及到测试计划的制定。
3.软件测试要尽早执行，实践证明，在大多数情况下，在需求分析阶段就会产生缺陷，而且需求分析阶段引入的缺陷是最多的，其修复成本却是最低的，所以软件测试应该尽早执行，越早执行，风险越小。
4.缺陷的二八定理。一般情况下，软件８０％的缺陷集中在２０％的模块中。如果发现某一程序模块比其他模块有更多的缺陷，就要投入更多的人力和精力重点测试这２０％的模块，以提高我们的测试效率。也成为缺陷的集群现象或者虫子窝现象。
5.缺陷具有免疫性。要求测试人员根据新版本的特点去修改维护测试用力。
6.值得注意的经验，每修复３－４个Bug, 一般就会产生一个新的缺陷，所以开发人员要充分注意修改错误所产生的影响和波及的效果。
Next
内存管理的相关知识
Junit的使用
移动端兼容测试
主要针对安卓的兼容性测试要考虑哪些方面：
1.    厂商
2.    机型兼容
3.    Rom
4.    分辨率适配
5.    竞品

l    厂商兼容：
考虑目前是市场上主流的厂商，例如：Oppo，Vivo，华为，三星，小米等。同时要注意厂商的更迭，针对安卓机型的快速迭代，约半年厂商的分布和市场占有率就会有一个很大的变化，要注意维护厂商兼容的列表，及时调整优先级。

l    机型兼容：
根据厂商的市场占有率，每个厂商选取最近热门的top机型考虑兼容，也要注意机型列表的维护，机型更迭速度在安卓市场上，大概半年就会有150款机型的交替更新，兼容机型的列表要保证一定频率的更新。可以通过功能埋点来关注应用所分布的机型数据进行对应的兼容列表调整。

l    Rom兼容：
1.    Android原生系统不同版本的兼容：最好能了解到不同版本间代码层面的差异，比如Adroid5.0和Android6.0之间的控件差异，兼容的时候应该注意什么着重测试。
Ø    Android 6.0新控件
a)    TextInputLayout的使用：高级炫酷带有提示的输入框，相当于输入框中的战斗框：使用需要依赖design类库： compile 'com.android.support:design:23.0.0+'
b)     FloatingActionButton的使用：总是能悬浮在界面上的Button，可以设置点击事件，使用需要依赖design类库： compile 'com.android.support:design:23.0.0+'
2.    Android定制Rom的兼容：
定制Rom都基于谷歌Android系统。得益于安卓系统的开放性，为了创造出个性化的操作体验，各厂商在一个劲的堆配置进行军备竞赛的同时，自然也不忘对操作系统进行大修大改。测试时要考虑到厂商的定制Rom的特性进行兼容测试。
a)    UI系列定制： MIUI、华为EMUI、乐视EUI、中兴MiFavor UI及其旗下努比亚nubia UI 、酷派Cool UI、联想VIBE UI及其旗下ZUK ZUI等。

b)    OS系列定制：魅族Flyme OS、OPPO Color OS、锤子Smartisan OS、一加H2OS/Oxygen OS、VIVO Funtouch OS、金立Amigo OS、360 OS、IUNI OS等

3．Root情况：同时针对系统权限要求比较高的应用，兼容要考虑操作系统的Root和非Root状态

l    分辨率适配：
测试中常见的兼容测试类型，市场分布的主流分辨率都要考虑兼容，测试应用展示是否能够正常显示。

l    竞品兼容：
对于很多应用来说，在同一环境与竞品共存的情况会出现资源抢占的事件，考虑到用户手机环境比较复杂，对于同类型应用的并存状态，要进行兼容测试，保证在类似应用抢占资源的过程中不会导致手机系统出现问题，和测试应用本身出现问题。

l    IOS兼容：
a)    分辨率兼容
b)    机型兼容
c)    处理器兼容：硬件兼容，苹果机型的处理器分A4~A10
d)    Api兼容：不同系统版本苹果对于调用api的要求也在不断改变，同样应用在不同系统可调用api规则不一样的情况下，要考虑兼容