初学测试
目录
1.测试定义
标准定义：在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估
简单的说就是： 在软件中找存在的BUG
2.测试的分类
1.按照开发阶段划分：
单元测试 集成测试 系统测试 验收测试
###
单元测试，又称模块测试。对软件的组成单位进行测试，其目的是检验软件基本组成单位的正确性。
测试的对象的是软件你测试的最小单位：模块
###
集成测试也称联合测试（联调）、组装测试：将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的
测试工作。集成主要目的是检查软件单位之间的接口是否正确。
###
系统测试：将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行
阶段，包括回归测试和冒烟测试。
1.回归测试（Regression Testing）：指修改了旧的代码之后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
（自动回归测试将大幅度降低系统测试、维护升级等阶段的成本）。
2.冒烟测试（smoke testing）：该术语来自硬件，指对一个硬件或一组硬件进行更改或修复后，直接给设备加电。如果没有冒烟，则
该组件就通过了测试，也可以理解为该种测试耗时短，仅用一袋烟的功夫就足够了
###
验收测试（交付测试）：是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确
保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
2.按照是否查看代码划分：
黑盒测试 白盒测试 灰盒测试
###
黑盒测试也是功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据和输出数据。
###
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是指打开盒子，去研究里面的源代码和程序结果。
###
灰盒测试是介于白盒测试和黑盒测试之间的一种，灰盒测试多用于集成测试阶段，不仅关注输入、输出的正确性，同时也关注程序内部的情况。
3.按照测试是否执行划分：
静态测试 动态测试
###
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，对需求规格说明书、
软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错
###
动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性、健壮性、等性能
4. 按照测试对象划分：
性能测试 安全测试 兼容性测试 文档测试 界面测试
###
1.性能测试
检查系统是否满足需求规格说明书中规定的性能。
通常表现在以下几个方面：
对资源利用（如内存、处理机周期等）进行的精确度量
对执行间隔
日志事件（如中断，报错）
响应时间
吞吐量（TPS）
辅助存储区（例如缓冲区、工作区的大小等）
处理精度等进行的监测
###
2.安全测试
安全测试是一个相对独立的领域，需要更多的专业知识。如：WEB的安全测试、需要熟悉各种网络协议、防火墙、CDN、熟悉各种操作系统
的漏洞、熟悉路由器等。
###
3.兼容性测试
兼容性测试主要是指，软件之间能否很好的运作，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃。
平台测试
浏览器测试
软件本身能否向前或向后兼容
测试软件能否与其它相关软件兼容
数据兼容性测试
最常见的兼容性测试就是浏览器的兼容性测试，不同浏览器在css，js解析上的不同会导致页面显示不同。
常见的IE8的兼容性。
###
5.易用性测试（用户体验测试）
易用性（Useability）是交互的适应性、功能性和有效性的集中体现。又叫用户体验测试。
###
6.业务测试
业务测试是指：测试人员将系统的整个模块串接起来运行、模拟真实用户实际的工作流程。满足用户需求定义的功能来进行测试的过程。
###
7.界面测试
界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外
还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
3.测试的方法
等价类划分： 有效等价类和无效等价类 边界值分析法 因果图法 场景法 正交表
。。。未完待续
4.测试的生命周期
需求分析 测试计划 环境设置 测试用例 缺陷记录 测试周期
###
1.需求分析
在此阶段，测试人员分析需求文档，已检查客户所述的要求。在检查要求后，测试人员制定测试计划以检查软件是否满足需求。
1).进入条件 - 对于测试计划需求规范的规划，应该提供应用程序体系结构文档和明确定义的验收标准。
2).活动行为 - 准备所有要求和查询的列表，并从技术经理/主管，系统架构，业务分析师和客户处获得解决。列出要执行的
所有类型的测试(性能，功能和安全性)。列出测试环境详细信息，其中应包含执行测试用例的所有必要工具。
3).交付成果 - 列出可测试要求和测试环境详细信息的所有必要测试。
###
2.创建测试计划的创建是STLC(软件测试生命周期)的关键阶段，它定义了所有测试策略。测试人员确定整个项目的估计工作量和成本。
此阶段在成功完成需求分析阶段后进行。此阶段提供的测试策略和工作量估算文档。成功完成测试计划创建后，可以开始测试用例执行。
1).进入条件 - 需求文档活动行为 - 定义目标以及软件的范围。列出测试中涉及的方法。测试过程概述。
2).测试环境的解决。准备测试计划和控制程序。角色和责任的确定。列出测试可交付成果，定义风险(如果有)。
3).交付成果 - 测试策略文档。测试估算文件是此阶段的交付成果。
###
3. 环境设置
测试环境的设置是一项独立的活动，可以与测试用例开发一起启动。这是手动测试程序的重要部分，因为没有环境测试无法进行。环
境设置需要一组必要的软件和硬件来创建测试环境。测试团队不参与设置测试环境，而是创建测试环境的高级开发人员完成。
1).进入条件 - 测试策略和测试计划文档。测试用例文档。测试数据。
2).活动行为 - 通过分析需求规范来准备软件和硬件列表。在设置测试环境之后，执行测试用例以检查测试环境的准备情况。
3).交付成果 - 执行报告。缺陷报告。
###
4. 测试用例
执行测试用例在成功完成测试计划后执行。在此阶段，测试团队启动案例开发和执行活动。测试团队记下详细的测试用例，并在需要时
准备测试数据。准备好的测试用例由团队的同行成员或质量保证负责人进行审核。 RTM(需求可追溯性矩阵)也在此阶段准备。需求可跟
踪性矩阵是行业级格式，用于跟踪需求。每个测试用例都与需求规范一起映射。可以通过RTM完成向后和向前可追溯性。
1).进入条件 - 需求文档。
2).活动行为 - 创建测试用例。执行测试用例。根据要求绘制测试用例。
3).交付成果 - 测试执行结果。具有缺陷详细说明的功能列表。
###
5. 缺陷记录
测试人员和开发人员根据测试覆盖范围，质量，时间消耗，成本和关键业务目标评估软件的完成标准。此阶段确定了软件的特性和缺点
。深入分析测试用例和错误报告，以检测缺陷的类型及其严重性。 缺陷记录分析主要用于根据严重程度和类型找出缺陷分布。如果检测
到任何缺陷，则将软件返回给开发团队以修复缺陷，然后在测试的所有方面对软件进行重新测试。 一旦测试周期完全完成，然后测试关
闭报告，并准备测试指标。
1).进入条件 - 测试用例执行报告。缺陷报告
2).活动行为 - 它根据测试覆盖率，质量，时间消耗，成本和关键业务目标评估软件的完成标准。缺陷记录分析通过对类型和
严重性进行分类来找出缺陷分布。
3).交付成果 - 关闭报告，测试指标
###
6. 测试周期
关闭测试周期结束报告包括与软件设计，开发，测试结果和缺陷报告相关的所有文档。如果存在具有相同规范的软件，此阶段将评估开发
策略，测试过程，可能的缺陷，以便将来使用这些实践。
1).进入条件 - 所有与软件相关的文档和报告。
2).活动行为 - 如果存在具有相同规范的软件，则评估开发策略，测试过程，将来可能存在的缺陷以使用这些实践。
3).交付成果 - 测试结束报告。
5.测试用例
-
测试用例的定义：
测试用例是执行测试的依据，把测试系统的操作步骤用文档的形式描述出来
-
测试用例包含？
用例编号 用例描述 【用例所属模块】 执行条件 预期结果 测试输入 实际结果 【测试人】 【测试版本】 【测试日期】 【备注】
-
测试用例文档的方式
Excel word 方式 bug管理工具里可以直接写
-
测试用例开始写的时间
拿到对应的模块进行编写。
-
测试用例的注意：
根据需求文档或者是原型图年写的用例的覆盖度[80%-90%].
书写用例有正反 反向用例【异常用例】 8：1
代表性：
针对性：
可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果
6.BUG的定义、分类、生命周期
1.BUG定义
软件的bug狭义的是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户发现和提出的软件可改进细节，或与需求文
档存在差异的功能实现等。
我们的职责就是发现这些bug，提交给开发，让开发去修改
2.BUG类型
要确定一个bug类型，需要对项目（或产品）有比较深的理解，这个划分对开发定位问题影响较小，但对于问题类型的统计就比较重要了。
常见的bug类型划分：代码错误，界面优化，设计缺陷，配置相关，安装部署，安全相关，性能问题，标准规范，测试脚本，其他。
其他划分：功能类，界面类 性能类 易用性类 兼容类 其他
缺陷的等级:
bug的等级一般分为四级，也有分五级的，如果是等级越高，那么对应的优先级也会高一些，然后有些公司还会根据你提的bug数量和bug
等级，作为绩效考核的一部分。
1）致命性错误
1.常规操作引起的系统崩溃，死机，死循环
2.造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露
3.涉及金钱
4.用户数据受到破坏，或者危及人身安全
2）严重错误
1.重要功能不能实现
2.错误的波及面广，影响到其他重要功能实现
3.非常规操作导致的程序崩溃，死机，死循环
4.数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显影响
3）一般错误
不影响产品的运行，不能成为故障起因，但对产品外观和下道工序影响较大的缺陷
1.次要功能能不能正常实现
2.操作界面错误（包括数据窗口内列名定义，含义不一致）
3.查询错误，数据错误显示
4.简单的输入限制未放在前台进行控制
5.删除操作未给出提示
4）细微错误
程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
1.界面不规范
2.辅助说明描述不清楚
3.提示窗口文字未采用行业术语
4.界面存在文字性错误
优先级分为4级，一般问题越严重，其处理的优先级越高
3.BUG生命周期
就是一个bug被发现到这个bug被关闭的过程
1.发现bug--提交bug---指派bug---研发确认bug------（否）设计如此 重复bug,无法重现
2.发现bug--提交bug---指派bug---研发确认bug-------(是）研发是否解决-------（否）不予解决，延期
3.发现bug--提交bug---指派bug---研发确认bug-------(是）研发是否解决-------（是）回归验证bug---是否通过验证-----（是） 关闭bug
4.发现bug--提交bug---指派bug---研发确认bug-------(是）研发是否解决-------（是）回归验证bug---是否通过验证-----（否） 激活------指派bug
7.面试题：
1.有没有你印象深刻的bug?
有很多印象深刻的bug,比如说后台播放 av source时rev on开启back camera后，关闭，重复开启-关闭几次后机器出现重启。
2.bug的生命周期
新建bug指派给开发--开发已解决----评价验证bug,修复后---关闭bug
当你打开了一个bug,但开放不认为是bug,如何处理？
首先查找需求说明书和式样书，寻找确切的依据，如果是用户体验票，侧从用户的角度来说明为什么是bug,如果开发依然
认为不是bug的话，交由产品经理来判定
3.对于复现率不高的bug如何处理？你再发现bug并确认bug的过程中
复现率不高的bug要立马录像，拍照片，截取log,保留现场，直接叫开发来调查问题。
如果现场已经被破坏，只能在以后每天的测试中带着再现，把这个问题在测试人员中展开一下，别的测试人员也可以帮忙验证。
