ÁùºÏ²ÊÖ±²¥¿ª½±

There are two approaches to the definition of the term unit: a generic description and an architectural description. 

In a generic description, a unit would be defined as a file or a function. From a specific, architectural point of view, a unit would be an element in the software architecture. A specific definition based on the architecture can reduce the number of test objects in unit testing. A unit defined this way can include multiple functions in multiple files.

This approach does not violate the requirements of ISO 26262 or Automotive SPICE. Furthermore, if the architecture has been developed top-down, you can designate higher levels of your architecture as pure integration testing and thus also save test objects at unit test level. The tests thus omitted at unit level are then performed in software integration testing (SWE.5).

Some organizations close the gap with their own requirements by adapting the definition of a unit.  Typical additions include:

• Define units more precisely, e.g. by defining units as an encapsulation of data and instructions at the level of a function in the programming language C.
• Requirements for the unit construction process, e.g. by specifying the maximum cyclomatic complexity.

Pro-tip: Well-intentioned requirements that are too general or too strict for a concrete project, can be discussed and negotiated with the client to define a coherent solution as a substitute measure. This can significantly reduce efforts. From a risk perspective, the right time defining units is as early as possible.

By the way, in TPT you can test all kinds of unit definitions. From the tool¡¯s point of view, it doesn¡¯t matter. In order to reduce the resulting total effort in the testing process to a minimum, we recommend not to define units generically. This facilitates refactoring activities and reduces additional efforts.

Learn more about unit testing before your competitors do.