控制测试程序包括？盘点控制测试的方法有哪些

关于控制程序的测试

我一般把控制程序测试分为三级：L1 功能、功能块、程序块级别的测试；L2 系统级别测试，半实物仿真；L3 实物测试。

至于这种划分是否科学合理，我觉得这个事情也没有定论，只是为了方便，划分的粗一点还是细一点都没问题。除了结构化文本语言，我没怎么用过61131-3中的其他几种语言，可能是以前用C，比较习惯了，自然过渡到ST，对其他的图形化的编程工具，没用过，也不知道咋用。

L1级别测试就是对程序中使用的功能、功能块和程序块进行逐个测试。我自己最早开发程序的时候基本不进行L1级别测试，基本把子程序（指的是功能、功能块和程序块）写出来，编译无错误就可以，再写主程序，调用这些子程序，编译，直接进行L2级别的测试，出了问题再去子程序里面去找，直到把这些问题都修正。

这种方式存在的问题是：有可能问题太多，程序根本不能运行；系统输出或者响应不正常，但是根本定位问题出在哪个子程序。

对于开发者来说，进行这样的调试非常困难。调试过程头晕脑胀，非常耗费脑细胞，耗时耗体力。

比较好的方式是每一个子程序都对应一个单独的测试程序，分别进行子程序的单独测试。现在已经有一些开源的库，对程序进行unity测试。

通过子程序测试，把每个子程序测试完成，确保每个子程序功能正确。然后进行主程序测试。这样可以把测试分块分区域，第一保证测试的完备，第二节约查找问题的时间。

L2 级别测试目前也就是把主程序和子程序组合在一起进行测试。因为程序运行的条件不具备，一般是通过几种方式来解决: 屏蔽一部分不能运行的部分；在程序里做一段模拟程序。对于批量生产的产品来说，这两种测试方式都有一些弊端。

我比较推荐采用半实物仿真的方式，或者有的控制器厂家提供仿真模块，这种模式可以对程序进行更充分的测试。

可能会有的工程师说，我到现场直接进行L3级别的测试不就行了，还用这么费劲。这样做主要基于下面两个原因：第一我们希望现场的调试时间越短越好，现场条件比较艰苦，测试环境不好搭建，调试时间过长客户感受变差；第二个原因是现场实物测试存在风险，不是所有的功能都很容易实现。