之前看到有小伙伴说：软件测试（测试工程师）没啥技术含量，也没有难度。
其实，真正牛逼的测试工程师，是需要掌握很多技能的，要熟悉产品的各项功能、应用场景，根据产品整理测试用例、记录结果等等。。。
这里简单的给大家介绍下关于测试的一些基本知识
黑盒测试 又叫 功能测试、数据驱动测试 或 基于需求规格说明书的功能测试。该类测试注重于测试软件的功能性需求。
采用这种测试方法，测试工程师把测试对象看作一个黑盒子，完全不考虑程序内部的逻辑结构和内部特性，只依据程序的《需求规格说明书》，检查程序的功能是否符合它的功能说明。
测试工程师无需了解程序代码的内部构造，完全模拟软件产品的最终用户使用该软件，检查软件产品是否达到了用户的需求。黑盒测试方法能更好、更真实地从用户角度来考察被测系统的功能性需求实现情况。
在软件测试的各个阶段，如 单元测试、集成测试、系统测试及验收测试 等阶段中，黑盒测试都发挥着重要作用，尤其在系统测试和确认测试中，其作用是其他测试方法无法取代的。
白盒测试 又称 结构测试、透明盒测试、逻辑驱动测试 或 基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
白盒测试的测试方法有 代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
白盒测试法的覆盖标准有 逻辑覆盖、循环覆盖 和 基本路径测试。
其中 逻辑覆盖 包括 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖 和 修改条件判断覆盖 。六种覆盖标准发现错误的能力呈 由弱到强 的变化：
语句覆盖：每条语句至少执行一次。
判定覆盖：每个判定的每个分支至少执行一次。
条件覆盖：每个判定的每个条件应取到各种可能的值。
判定/条件覆盖：同时满足判定覆盖、条件覆盖。
条件组合覆盖：每个判定中各条件的每一种组合至少出现一次。
修改条件判断覆盖：每一个判断的所有可能结果都出现过、每一个判断中所有条件的所有可能结果都出现过、每一个进入点及结束点都执行过、判断中每一个条件都可以独立的影响判断的结果。
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
集成测试的方法有两种：非增量式测试 和 增量式测试。
非增量式是每个模块测试完了再连接。
增量式则是测一个模块，就连接一个模块。而采用增量式测试时又有两种选择：自顶向下结合、自底向上结合。
自顶向下的集成测试就是 按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试。
优点：
较早地验证了主要控制和判断点
按深度优先可以首先实现和验证一个完整的软件功能
功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用
支持故障隔离。
缺点：
柱的开发量大
底层验证被推迟
底层组件测试不充分
适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
自底向上集成是 从系统层次结构图的底层模块开始进行组装和集成测试的方式。对于某一个层次的特定模块，因为它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在测试过程中，如果想要从子模块得到信息可以通过直接运行子模块得到。也就是说，在集成测试的过程中只需要开发相应的驱动模块就可以了。
优点：
对底层组件行为较早验证
工作起初可以并行集成，比自顶向下效率高
减少了桩的工作量；支持故障隔离。
缺点：
驱动的开发工作量大
对高层的验证被推迟，设计上的错误不能被及时发现
适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
软件测试类型按开发阶段分为：
单元测试 又称为模块测试，是针对软件设计的最小单位——程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
集成测试 又称为 组装测试 或 联合测试，在单元测试的基础上需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
确认测试 的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般由第三方测试机构进行。
系统测试：软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，目的在于与系统需求比较，发现问题。
验收测试：以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。不是对系统进行全覆盖测试，而是对核心业务流程进行测试。
测试用例（Test Case）是为某个特殊目标而编制的 一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。
根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。
在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。
尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。
为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。
如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。
完成测试实施后需要对测试结果进行评估，并且编制测试报告。
判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。
通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
软件测试和软件开发一样，都遵循软件工程原理，遵循管理学原理。
测试专家通过实践总结出了很多很好的测试模型。这些模型将测试活动进行了抽象，明确了测试与开发之间的关系，是测试管理的重要参考依据。
与瀑布模型有公共的特性，V模型中的过程从左到右，描述了开发的过程到最后测试全经过。
清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
局限性：
把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。
测试与开发是同步进行的，明确地标注了生产周期中开发与测试之间的对应关系，从而更好、更快、更全地发现问题。
局限性：
W 模型和 V 模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。
H 模型将测试活动从开发流程完全独立出来，使测试流程形成一个完全独立的流程，将测试准备活动与测试执行活动清晰地体现出来。其他流程可以是任何的开发流程，测试这边只要测试条件成熟（满足测试就绪点），测试执行活动就可进行（与其他流程并发地进行）。
是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
充分的体现了测试过程。
软件测试不仅仅指测试的执行，还包括很多其他的活动（计划、需求分析、用例设计、环境搭建、提交缺陷、评估总结等）。
软件测试要尽早准备，尽早执行，具有很强的灵活性。
软件测试可以根据被测物的不同而分层次进行。
不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点,测试执行活动就可以开展。
局限性：
管理性要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制。
技能要求高：H 模型要求能够很好的定义每个迭代的规模，不能太大也不能太小。
测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大的困难。
X 模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。
优势：
很好地处理测试与开发的交接过程（交接的过程是一个时间段，而不是一个点）。
己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。
X 模型还定位了探索性测试，这是给有经验的测试人员在测试计划之外发现更多的软件缺陷。
局限性：
探索性测试可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。
------------ END ------------
●专栏《嵌入式工具》
●专栏《嵌入式开发》
●专栏《Keil教程》
●嵌入式专栏精选教程
关注公众号回复“加群”按规则加入技术交流群，回复“1024”查看更多内容。
点击“阅读原文”查看更多分享。
