标签：冒烟 流程 分类 测试人员 用例 测试用例 测试 软件
一.测试的分类
单元测试：又称模块测试。对软件的组成单位进行测试，其目的是检验软件基本组成单位的正确性。测试对象是软件测试的最小单位：模块。注意：单元测试是白盒测试，白盒测试不是单元测试。
集成测试：也称联合测试（联调）、组装测试：将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。单元测试是一个模块内部的测试，集成测试是在模块之间进行测试（至少两个）。
系统测试：将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。虽然系统测试包括冒烟测试和回归测试，但三者之间是有严格的先后顺序的，即：先冒烟、再系统、后回归。
验收测试（交付测试）：是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
黑盒测试：也是功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据和输出数据。
白盒测试：又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是指打开盒子，去研究里面的源代码和程序结果。
灰盒测试：是介于白盒测试和黑盒测试之间的一种，灰盒测试多用于集成测试阶段，不仅关注输入、输出的正确性，同时也关注程序内部的情况。
静态测试：是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。代码静态分析和文档测试都属于静态测试。
动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性、健壮性、等性能。动态测试由三部分组成：构造测试用例、执行程序、分析程序的输出结果。大多数软件测试都属于动态测试。
人工测试：是由人一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一种。缺点：执行效率慢，量大易错。
自动化测试：就是在预设条件下运行系统或应用程序，评估运行结果。（预先条件包括：正常条件和异常条件）。简单来说，自动化测试就是是把人为驱动的测试行为，转化为机器执行的一种过程。
冒烟测试：该术语来自硬件，指对一个硬件或一组硬件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试，也可以理解为该种测试耗时短，仅用一袋烟的功夫就足够了。
回归测试：指修改了旧的代码之后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。（自动回归测试将大幅度降低系统测试、维护升级等阶段的成本）。
探索性测试：可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。对探索性测试最直白的定义是：同时设计测试和执行测试。
随机测试：是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分。
二.测试的流程
1.项目立项：项目经理负责拟定项目计划书，产品经理负责设计产品的原型图和PRD。
2.需求分析：明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
3.需求评审：不管是自研产品或其他产品，测试人员都要参加需求评审的会议。一方面，便于了解需求进而更好地开展之后的测试工作；另一方面，测试人员往往是从用户角度考虑居多，更加能够从用户的角度提出符合实际的建议。
1）制定测试计划：
待需求最终确定下来后，则可以开始制定测试计划，确定测试目标、测试范围、测试方法、测试策略、资源安排、风险评估等。
2）测试用例设计：
待测试计划拟定好后，可开始进行用例设计。一般先使用思维导图工具整理大概框架，再使用测试用例管理工具（testlink）按功能模块、使用场景进行设计。
4.用例评审：因为一个人的思想是有局限性的，待用例设计好后，最好项目组的所有人员（产品经理、研发人员、测试人员）都参与用例评审，以便查缺补漏，尽可能使用例覆盖更全面。
5.冒烟测试：待研发人员提交版本后，测试人员便可以进行冒烟测试（当然，冒烟测试的用例要提前选好）。
6.一轮测试：待冒烟测试通过，则可以开始执行第一轮的测试，也就是根据用例来测试。如果有必要，可以进行第二轮、第三轮、第N轮的测试。
7.缺陷报告：发现的bug使用缺陷管理工具记录下来。
8.回归测试：待研发人员把本次需修复的bug都修复完成后（并不一定是所有bug都需要修复，有些推迟的、有些被判定为不是bug的、有些影响不大的都可以暂时不修复），即可进行回归测试。主要是验证缺陷是否真的修复，是否会影响现有系统的使用。
9.验收测试：不是对系统进行全覆盖测试，而是对核心业务流程进行测试。
10.交付/上线：测试完成之后，服务器人员就会上线，测试人员需要进行线上回归，回归完成后测试人员还要对线上环境进行跟踪，处理反馈等。
三.详细的测试流程
按工作内容划分：功能、接口、性能、自动化。
实际开发中，测试顺序：接口、功能、性能、自动化
标签：冒烟,流程,分类,测试人员,用例,测试用例,测试,软件 来源： https://blog.csdn.net/m0_56809584/article/details/120477384
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。