Low-level testing

Article: Low-level testing solutions and challenges


Low-level testing is a kind of software testing, that is checking if each module, function, class, and method work correctly. It verifies the system functionality at the source code level, processor instructions, registers, memory, or hardware interface. Low-level tests are commonly used in embedded systems that are integrated with hardware and have limited resources.

The aim is to identify and eliminate logical, syntactical, or implementation bugs in the code before it’s integrated with other system components. Typically, low-level tests are carried out by developers creating and modifying the source code.

This kind of testing is necessary to maintain the quality and reliability of our software, but it requires a creative approach due to many challenges, such as:

  • Changing requirements: In an agile approach, the requirements are often changing and incomplete, which makes it difficult to write low-level tests in the early project phase. Low-level tests need to be flexible and easily adaptable to source code changes.
  • Code complexity: Source code can be complicated and difficult to understand, especially if it’s written in low-level languages such as Assembler or C. The code can also contain numerous dependencies, conditions, loops, exceptions, or recursions, making analysis and testing challenging.
  • Integration with other modules: Only the functionality of single code units is being checked by low-level testing, not guaranteeing they will work correctly with other modules or services used by the application.
  • Lack of documentation: The source code can be insufficient or not documented at all, which makes checking and understanding difficult. The documentation may also be outdated or inconsistent with the code itself, leading to bugs and inaccuracies.
  • Time shortage: Low-level testing may be time-consuming and laborious, especially if the code is extensive, and often changed.  Developers may be put under pressure by deadlines and priorities and not have enough time to test the code systematically and thoroughly.
  • Equipment shortage: This kind of testing requires specialized equipment such as debuggers, compilers, linkers, emulators, simulators, or code analyzers. These kinds of tools can be unavailable, expensive, difficult to use, or incompatible with the code or testing environment.
  • Communication:  Both the tester and developer can have different perspectives on what is important and what the customer’s expectations are. They can also have different work approaches, which might influence cooperation and information exchange. A significant issue that can arise is the various levels of knowledge and experience between testers and developers, which can affect their trust and respect toward each other.

czytaj dalej

Article: The matter of an embedded systems test infrastructure team tasks


Today, embedded systems are used in a wide range of industries and devices we use, from smartphones through TV sets to cars. To assure the systems are of the highest quality, it is essential to test them and, for that to happen, create appropriate test environments. The test infrastructure team provides the essential elements for conducting tests as well as the tools for the management of the testing process itself. They are the key component both for testers, who need access to the right set of tools, as well as for the customer himself who expects reliable test results.

An important part of the test infrastructure are test environments. Testing of embedded systems is focused on the actual device, which may require various types of sensors, actuators or communication interfaces (used for interaction with the surroundings or other systems) in order to work properly. When testing particular components such as an ECU (Electronic Control Unit), for example, the test environment simulates input signals and allows the tester to check output signals produced by the device. Therefore, one of the primary tasks of the infrastructure department is finding solutions, which enable us to simulate the environment, in which the device under test will be used.
In our company, B&R X20 series, controllers, and Vector VT System devices are commonly used for this purpose, which the tester is operating using the Vector CANoe software. While the Vector VT System uses a build-in communication interface within CANoe, it was the test infrastructure team’s task to create a real-time communication solution with the other components.

czytaj dalej