LabVIEW程序测试
工程师经常不太关注测试，将更多时间用于其他开发。通过一定程度的测试，可以保证节省时间。
开发人员必须清楚地了解对测试的期望程度。此外，还必须标准化测试方法并跟踪测试结果。在开发需求和设计规范时，还要制定测试计划，以帮助验证系统及其所有组件是否正常工作。测试反映了希望实现的质量目标。例如，如果性能比健壮性更重要，请开发更多的性能测试，并减少尝试错误输入或内存不足的情况。
测试不是事后的想法。考虑将测试作为初始设计阶段的一部分，并在整个开发过程中进行测试，以尽快发现并修复问题。
有多种测试方法。可以使用以下测试方法来帮助提高VI项目的质量。
静态和动态代码分析
静态代码分析是指用于将源代码与预先建立的样式、组织和质量标准进行比较的技术或工具。无需编译或执行应用程序即可执行静态代码分析。
注意可以使用LabVIEW VI分析器工具包来执行静态代码分析。
动态代码分析是指用于了解软件在执行期间如何工作的工具，它涉及在代码运行时对其进行测试。在执行动态代码分析时，可以使用黑盒和白盒测试。执行动态代码分析以检测内存泄漏和性能改进区域，识别意外行为或错误的来源，并确保应用程序对不同的目标执行相同的操作。使用“配置文件性能和内存”窗口可以执行动态代码分析。
注还以使用桌面执行跟踪工具包来执行动态代码分析。
黑盒和白盒测试
黑盒测试的方法基于软件的预期功能，而不了解其工作原理。它被称为黑盒测试，因为看不到内部工作原理。可以主要基于对模块的需求和接口的了解来执行黑盒测试。对于子VI，可以在子VI的接口上执行黑盒测试，以评估各种输入值的结果。如果鲁棒性是质量目标，请包括错误的输入数据，以查看子VI是否成功处理它。例如，对于数字输入，请参阅subVI如何处理Inf（无穷大）、NaN（不是数字）和其他超出范围的值。
白盒测试方法是在了解软件内部工作原理的情况下设计的。使用白盒测试来检查所有主要的执行路径是否正常工作。通过检查框图并查看Case结构的条件和控制循环的值，可以设计检查这些路径的测试。大规模白盒测试是不切实际的，因为测试所有可能的路径都很困难。
尽管对于大型程序很难完全实现白盒测试，但可以选择测试最重要或最复杂的路径。可以将白盒测试与黑盒测试相结合，以进行更全面的软件测试。
单元、集成和系统测试
使用黑盒和白盒测试来测试软件的任何组件，无论是单个VI还是完整的应用程序。单元、集成和系统测试是项目的阶段，可以在其中应用黑盒和白盒测试。
单元测试
可以使用单元测试来集中精力测试各个软件组件。例如，可以测试单个VI，以确保其正常工作，处理超出范围的数据，具有可接受的性能，以及程序框图上的所有主要执行路径是否正确执行和执行。各个开发人员可以在处理模块时执行单元测试。
单元测试可能涉及的一些常见问题示例包括：
每个输入的边界条件，例如空数组和空字符串，或0表示大小输入。确保浮点参数处理Inf和NaN。
每个输入的值都无效，例如大小输入的–3。
奇怪的输入组合。
缺少文件和错误的路径名。
当用户单击文件对话框中的“取消”按钮时会发生什么情况？
如果用户中止VI会发生什么？
定义各种用于全面测试VI的输入集，编写一个测试VI，使用每个输入组合调用VI，并检查结果。使用交互式数据记录创建输入集或测试向量，并以交互方式检索它们以重新测试VI。可以从以编程方式执行数据记录的测试VI自动检索数据。
若要执行单元测试，可能需要创建一些尚未实现或仍在开发的组件的存根。例如，如果正在开发一个与仪器通信并将信息写入文件的VI，则另一个开发人员可以处理以特定格式写入信息的文件I/O驱动程序。要尽早测试组件，可以通过创建具有相同接口的VI来创建文件I/O驱动程序的存根。此存根VI可以以易于检查的格式写入数据。稍后在集成阶段，可以使用实际文件I/O驱动程序测试驱动程序。
还可以使用LabVIEW VI分析器工具包以交互方式或以编程方式测试VI，了解LabVIEW编程的风格、效率和其他方面。
无论测试VI，请准确记录测试的方式，时间和内容，并保留创建的任何测试VI。如果为付费客户和内部使用创建VI，则此测试文档尤其重要。修改VI时，请运行现有测试以确保没有破坏任何内容。还要更新添加的任何新功能的测试。
集成测试
对单元组合执行集成测试。单元测试通常会发现大多数错误，但集成测试可以揭示意想不到的问题。模块可能无法按预期协同工作。由于它们操作共享数据的方式，它们可以以意想不到的方式进行交互。
注意只能在LabVIEW完整和专业开发系统中进行集成测试。
还可以在将整个系统组合在一起之前，在早期阶段执行集成测试。例如，如果开发人员创建了一组与仪器通信的VI，他可以开发单元测试来验证每个子VI是否正确发送了适当的命令。他还可以开发集成测试，将多个子VI相互结合使用，以验证没有意外的交互。
不要将集成测试作为综合测试来执行，在这种测试中，将所有组件组合在一起并尝试测试顶级程序。这种方法可能很昂贵，因为很难确定大量VI中问题的具体来源。相反，请考虑使用自上而下或自下而上的测试方法进行增量测试。
使用自上而下的方法，可以逐步集成主要组件，使用作为存根实现的系统较低级别的组件来测试系统。验证现有组件在现有框架中协同工作后，可以启用其他组件。
使用自下而上的方法，首先测试低级模块，然后逐步向高级模块发展。首先测试组合成简单系统的少量组件，例如驱动程序测试。组合一组模块并验证它们是否协同工作后，请添加组件并使用已调试的子系统对其进行测试。
自下而上的方法包括范围逐渐增加的测试，而自上而下的方法包括随着新组件的添加而逐渐完善的测试。
无论采用哪种方法，都必须在每个步骤中执行回归测试，以验证以前测试的功能是否仍然有效。回归测试包括重复部分或全部先前的测试。如果需要多次执行相同的测试，请考虑开发具有代表性的测试子集以用于频繁回归测试。可以在每个阶段运行这些测试子集。如果出现问题，可以运行更详细的测试来测试单个模块集，也可以作为开发期间定期发生的更详细的回归测试的一部分。
系统测试
集成后进行系统测试，以确定产品是否满足客户期望，并确保软件在硬件系统中按预期工作。可以使用一组黑盒测试来测试系统，以验证是否满足要求。通过系统测试，可以测试软件以确保它按预期适合整个系统。大多数LabVIEW应用程序执行某种I/O操作，并还与其他应用程序通信。确保测试应用程序与其他应用程序的通信方式。
测试系统时，请考虑以下问题：
是否满足性能要求？
如果应用程序与另一个应用程序通信，它是否能很好地处理该应用程序的意外故障？
可以通过Alpha和beta测试来完成此测试。Alpha和beta测试用于捕获开发人员未考虑或未完成的测试用例。在Alpha测试期间，在内部测试功能完整的产品，看看是否出现任何问题。贝塔测试发生在阿尔法测试完成后。在beta测试期间，客户在现场测试产品。
阿尔法和贝塔测试是一些公司唯一的测试机制。不幸的是，Alpha和beta测试实际上可能是不准确的，不能替代其他形式的测试，这些测试严格测试每个组件以验证组件是否符合既定目标。当这种类型的测试在开发过程的后期完成时，合并因此而建议的更改是困难和昂贵的。
形式化验证方法
一些测试方法试图通过探索来发现问题，但许多软件工程师是软件形式验证的支持者。正式的验证方法试图从数学上证明软件的正确性。
主要思想是分析程序的每个函数，以确定该函数是否执行期望的功能。可以在数学上声明函数之前的前提条件列表以及作为函数结果而存在的后置条件。可以通过从程序开始时开始并在完成每个函数时添加条件来执行此过程，也可以从最后开始向后工作，为每个函数开发一组最弱的先决条件来执行此过程。多个第三方资源包含有关验证过程的详细信息。
这种类型的测试变得更加复杂，因为通过使用循环和条件将更多可能的执行路径添加到程序中。许多人认为，正式测试为查看可以在小案例中提供帮助的软件提供了有趣的想法，但是验证测试对于大多数程序来说是不切实际的。
需要说明的是，上述的例程和文档，都是可以下载的，双击即可打开，其中压缩文件是可以采用粘贴复制的方式，拷贝到硬盘上。这不是图片，各位小伙伴看到后尝试一下，这个问题就不用加微信咨询了。有关LabVIEW编程、LabVIEW开发等相关项目问题，可联系我们。
