The testing of individual software components. After [IEEE].
BS 7925-1.British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST)

Building a software application is like building a house. A cliche I know, but one that fits perfectly in this case. Components are our building blocks:- bricks, plumbing joints, damp coursing etc.

However, a component has to be seen in the context of the person using. A group of components integrated together as a system, might be seen as as a single component to be used to build further systems. For example you might be making notes from this article (be my guest) using a Bic biro, notepad and correcting fluid. A system of three components. You are only concerned that they perform as expected. I.e. the biro produces ink until it runs out and then you get a new one. The biro however is itself made up of components, including the casing, lid, nib and the ink. As components they would have been checked by the QA section at the factory, not you.

How does this affect software testing? As components are the basic building blocks of software, their testing is usually of the most basic techniques. Most commonly they will use White Box testing. Thus a combination of static and dynamic analysis. These techniques concentrate on the internal structure of the component.

Both functional and non-functional testing can be undertaken against a component. For example an object might calculate a single formula, rounding up or down to the nearest penny. The functional test include boundary value analysis and equivalence partition testing. Non-functionally, can the object handle a million transactions an hour?

Testing can be manual or automated. A number of tools exist for runtime analysis when the code is being executed.