电路板的制作测试流程是什么样的
测试是具有试验性质的测量，即测量和试验的综合。而测试手段就是仪器仪表。由于测试和测量密切相关，在实际使用中往往并不严格区分测试与测量。测试的基本任务就是获取有用的信息，通过借助专门的仪器、设备，设计合理的实验方法以及进行必要的信号分析与数据处理，从而获得与被测对象有关的信息。测试最终的结果是将显示的信息输入到信息处理库中，进行控制。
电路板的测试流程
通电前检测：一个电路板焊接完后，在检查电路板是否可以正常工作时，通常不直接给电路板供电，而是要按下面的步骤进行，确保每一步都没有问题后再上电也不迟：
1、连线是否正确：对照原理图检查板子连线是否正确，按照电路图的线路逐一检查；
2、检查元器件安装情况：二极管极性电容以及芯片的安装是否有误。检查各个器件的焊接是否有虚焊。
3、检查电源接口及其它是否有短路：检查电源、各个电平之间是否有短路。电路设计中应该增加保护电路如自恢复保险丝。电源部分可以设计0Ω电阻，在上电测试电源前线不焊接其，以免电平不正常烧毁后面单元的芯片。
通电后检测：通电后依照下述步骤进行检查：
1、通电观察：通电后不要急于测量电气指标，而要观察电路有无异常现象，例如有无冒烟现象，有无异常气味，手摸集成电路外封装，是否发烫等。如果出现异常现象，应即关断电源，待排除故障后再通电检查。
2、静态测试：逐级检查电平状态是否达到预期，逐步恢复焊接0Ω电阻。子电路的调试顺序一般按信号流向进行，将前面调试过的电路输出信号作为后一级的输入信号，为最后统调创造条件。
3、动态测试：逐步加入外部输入、输出信号，对系统各个部分进行调试。这一步需结合软件进行联合调试。
推荐阅读：http://www.elecfans.com/d/823046.html
正规的测试流程是什么样的这篇文章告诉你
一名测试工程师的学习之路，所有博客链接已存放在该链接下：一个Tester
大厂测试流程是什么样的？这篇文章告诉你！一、评审阶段1.1需求评审1.2设计评审1.3用例评审1.3.1功能用例评审1.3.2联调用例评审二、测试阶段2.1冒烟测试2.2功能测试2.3联调测试2.4回归测试三、发布上线（预发布->生产）一、评审阶段1.1需求评审一般在需求评审阶段中，参与者至少会有产品经理、开发、测试。如果项目需求比较大、还会有PMO、业务方、UI设计师等参与到需求评审中。作为测试而言，在需求评审中，最需要做两件事。
理解需求：对于测试而言，我们需要在需求评审会议上理解需求，不要出现会上无问题，会后三连问的情况，这样也比较耽误产品的时间。提出疑问：因为产品的需求也不一定合理，我们要带着问题参与到评审中。而且如果是新进入一个公司，对于公司的业务不太熟悉的时候，需求评审也是一个熟悉业务的好机会。需求评审阶段，我们需要关注以下相关问题。
交付目标：该需求面向的人群是谁？是外部用户、供应商？还是公司内部商务、运营、客服使用。交付计划：需求的上线计划，验收计划，是否灰度，以及测试工作量的评估。业务流程：本次是新增的功能或流程？还是原有业务流程增加新的节点或是修改节点逻辑。1.2设计评审设计评审：就是开发在听完产品的需求后，先编写好开发设计文档。然后根据项目的大小决定是否需要进行设计评审，如果只是小的优化或功能，一般就不会进行设计评审，而对于比较大的项目，就会拉上产品、测试进行设计的评审。在设计评审中，常常会发现开发对需求的理解与产品是不一致的。而作为测试而言，参与设计评审一是为了加深需求的理解，二是理解开发的设计，也要注意开发的设计是否合理。
在设计评审中，测试一般需要关注以下相关的问题(不一定全面，可能会存在相关差异)。
流程设计图：开发设计的流程图是否能达到产品需求的流程？数据库表设计：是否新增表？是否需要分库分表？如何保证唯一性？表字段默认值？是否需要添加索引？接口：接口层面分为本系统和上下游系统。本系统：新增接口的调用方是谁？原有接口修改后是否影响上下游业务？上下游系统：调用其他系统接口或者被其他系统调用的接口，是否有对接？需要评估是否对接口负载有影响？一般核心域的核心接口，在有新增入参的情况下，也会根据线上情况进行不同入参下的性能测试，评估接口QPS是否能达到预期，防止上线后出现性能问题。组件变更：是否有配置变更，配置的默认值是否合理？是否有环境变量变更？相关组件是否有变更？灰度：是否有开关？灰度方案是什么？是根据用户灰度还是？回滚：如果出现问题，回滚方案是什么？回滚时相关域的回滚顺序是怎么样的？1.3用例评审1.3.1功能用例评审功能用例评审：测试人员在编写好用例后，可以通过邮件的形式将发送给对应开发和产品，查看用例场景是否有遗漏。一般开发和产品不怎么看这个邮件的话，就可以抽了十多分钟，拉上会议，进行一个当面的用例评审。 如果是新入职的新人，一般是编写好用例后，先发送邮件给产品、开发，抄送给本组的测试同事，然后再拉上产品、开发进行一个当面的沟通。
1.3.2联调用例评审联调用例评审：如果需求涉及到多个系统的话，一般是需要进行一个联调用例评审。评审前一般是会先确定好本次需求的主测试，然后主测会编写好联调文档。
联调用例评审会上会有以下几件事需要做：
宣讲用例：主测宣讲联调的用例，各系统的测试查看是否有场景遗漏，并进行补充。确定分工：相关基础数据的准备交给对应系统。确定是否有本次需求系统无需变更，但是要协助联调的系统，确定跟进人。问题记录：对于联调评审中无法确定的问题，进行记录，后续跟进解决。二、测试阶段2.1冒烟测试冒烟测试：在开发提测后，就进入测试阶段。首先进行冒烟测试，冒烟测试一般需要注意相关问题：
静态代码扫描：进行静态代码扫描，是否有blocker、critical的代码。代码编译&服务部署：测试分支进行开发代码编译和部署，查看是否能编译和部署成功。且部署成功后，一般会查看环境中服务的日志，查看有无明显的报错日志。冒烟测试用例：首先执行冒烟的自动化Case,然后根据自己设计的冒烟阶段的用例，执行用例并测试。关于静态代码扫描、代码编译等，需要看所在公司对于相关测试平台的建设。例如我现在所在的公司，就是可以创建一个流水线，其中可以配置下面这些功能：代码编译、单元测试、单元测试覆盖率、静态代码检查、项目打包，镜像烘焙、部署、系统测试(自动化代码执行)。所以一般开发提测后，就是执行一下对应的流水线，查看代码是否能编译通过，静态代码扫描是否有问题，原先的自动化Case中的冒烟Case是否能通过等
在冒烟测试过程中，我们需要有以下记录：
用例上传及执行：上传冒烟测试用例，并在执行用例后，记录为用例已执行。BUG记录：如果冒烟Case不通过，提冒烟Bug给开发。工时记录：记录冒烟测试阶段的使用工时。补充冒烟自动化Case：如果是接口域，根据情况看是否需要补充冒烟的自动化AT，有则补充自动化AT，分组设置为冒烟。2.2功能测试功能测试：在冒烟测试通过后，进行到功能测试。功能测试与冒烟测试的不同在于，冒烟测试只是先将主流程走了一遍，而功能测试需要考虑常规情况和异常情况下的所有情况。在功能测试阶段需要注意以下问题：
前置准备：准备好基础的测试数据，相关变更需要在测试环境中执行等。用例执行：根据用例设计执行功能测试部分的用例。一般而言，在功能测试阶段，需要调用外部系统服务的话，采用Mock的方式，Mock外部系统的返回，除去Mock外部系统的正常返回，还要Mock超时，抛出异常等异常情况。预期结果：测试用例执行的结果是否符合预期结果。在功能测试过程中，我们需要有以下记录：
用例上传及执行：上传功能测试用例，并在执行用例后，记录为用例已执行。BUG记录：如果功能Case不通过，提功能测试阶段Bug给开发。工时记录：记录功能测试阶段的使用工时。补充自动化Case：补充本次需求的自动化Case。功能测试报告：发送功能测试报告，内容包括是否通过？遗留问题及风险点。2.3联调测试联调测试：一般只有当需求涉及到多个系统的变更的时候，才需要进行联调测试。而联调测试一般就是各系统将各自的服务部署再Staging联调环境中后，模拟生产一样，按照联调用例走一趟实际的流程。
在联调测试中，需要关注以下的点：
真实数据：联调的数据要是真实的数据，一定不能Mock数据！！！。而且不要直接修改数据库、Redis中的数据核心流程回归：对于原有的核心的流程，也要做到一定程度的回归，防止对原有流程有影响。联调日报：主测需要通过邮件的形式汇报整体联调的进度，以及联调进度的风险、联调发现的问题等。2.4回归测试回归测试：在测试分支进行完功能测试后，在发布上线前，开发合并代码到dev、master分支后，分别进行一次回归测试。回归测试一般需要注意相关问题：
回归时间：一般而言，当有一个域需要在明天发布，会在确定今天这个域没有发布、或这个域今天需要发布上线的需要已经上线后，才让开发合并代码到dev分支或者master分支，待合并代码后再进行回归。静态代码扫描：代码依次合并到dev、master分支后，进行静态代码扫描，确保没有blocker、critical。SDK升级：本域服务和依赖的外部服务需要升级为正式版，不使用SNAPSHOT版。全量AT回归：针对接口域，会进行全量接口自动化AT的回归，确保自动化Case没有失败的情况下才会进行下一步。在回归测试过程中，我们需要有以下记录：
用例上传及执行：上传回归测试用例，并在执行用例后，记录为用例已执行。BUG记录：如果回归时Case不通过，提回归测试阶段Bug给开发。工时记录：记录回归测试阶段的使用工时。三、发布上线（预发布->生产）`预发布环境连接的是真实生产的数据库，所以回归测试完成后，一般会先发布到预发布环境。待开发、产品验收无问题后，才会发布到生产环境。在这个过程中，需要注意以下几方面。
依赖变更：确定相关组件、配置、环境变量是否做了变更。在很多情况下，有些DB变更需要提前做，因为可能有的DB变更需要长达几个小时，如果等到要发布的时候，才想到要变更，可能今天就发布不了了。验收：一般而言，是先发布到预发布环境，待产品、开发验收无问题，才会进行生产发布。如果有问题，重新修改代码再推预发布再验收。生产发布完成后，产品也需要再进行一遍验收。发布顺序：检查发布域的版本号是否为正式版，且要按照顺序发布。发布系统可以做到模块关联，设置某一个域发布完成之后，另一个域才能发布。发布时间间隔：根据域的重要性不同，生产服务器机器数量也不同，所以发布的时候会设置批次。而每个批次的发布之间，最好进行一定时间的间隔。日志监控：在生产发布的过程中，需要通过日志系统查看有无异常日志，如果出现预期外的异常日志，需要和开发沟通后判断是否需要回滚。告警监控：通过发布系统查看是否有本域告警和上下游告警，如果有，也需要找开发确认是否有影响，再决定是否回滚。回滚：如果出现核心流程的告警，或者不能确定的告警和异常情况下，一般会先直接进行回滚操作。需要注意的是，需要注意回滚的顺序。如果由于回滚前，造成相关异常数据，在回滚后，还需要进行异常数据的处理。写在最后：以上就是一个大概的测试流程的总结，其中肯定也会有一些遗漏，各公司之间的测试流程也会有差异。所以觉得总结的还可以的，请一键三连！觉得还有要补充的，可以在下方留言！