-1

I have already looked at the answers in: What is the difference between integration and interface tests?

The answers to these questions are (understandably) too abstract.

In the context of embedded system: What is interface testing? The module interfaces with another module with a function call?

Should I just verify that they are compiled with the same ABI?

2

In the context of an embedded system, interface testing is most likely to refer to testing the interface between the embedded system and whichever external system is using it.

For instance, if the embedded system is the software driving something like a pin pad/payment terminal with touch screen, card reader, and so on, interface testing could include:

  • sending transaction information to the device and verifying that it displays correctly
  • checking the display of options on the device
  • checking the device can correctly read a credit/debit/chip/touchless card
  • checking the device correctly responds to touch input
  • checking the device correctly handles user signature
  • checking the device correctly handles pin pad entry

System testing would focus more on transaction flow - that is, sending transaction information, making payment using the device, and receiving completion information in order to generate a receipt. Interface testing is more focused on the interaction between the modules.

That said, I don't know how the ISTQB would define it, but I suspect the definition would be similar (if more academically worded)

Update January 24, 2020 Following the discussion in Comments, a few more thoughts:

Let's say your device has a class CardInformation with methods GetCardNumber() and CheckPin().

GetCardNumber() calls Display.CardSwipePrompt(), Input.ReadSwipe(), and `Input.GetCardNumberFromSwipe()'.

CheckPin() calls Display.PinPrompt(), Input.ReceivePin(), and Input.CheckPinAccuracy()

If you are testing the integration of CardInformation and Input, you'll use stubs for the two Display methods called, and you'll need to use some kind of fake or shim to inject values into the Input ReadSwipe() and ReceivePin() methods, but you will be able to check the accuracy of the CheckPinAccuracy() and GetCardNumberFromSwipe() methods.

| improve this answer | |
  • Unfortunately, I dont have enough reputation to create new tags. The ones I wanted to create are "iso26262" and "vcycle". In these contexts, the "unit" is a module. According to iso26262, interface testing is part of integration testing. The steps you are describing would be requirements directly from customer .i.e. system test or even requirement test. – aiao Jan 23 at 15:44
  • Welcome to the "fun" of imprecise verbiage. In that context, interface tests would be tests that exercise communication between two modules, no matter how they are performed. In the context I've worked with throughout my career, interface tests are what I described. – Kate Paulk Jan 23 at 15:56
  • "interface test would be test that exercise communication between two modules."... perfect. If a module is a .c file, and they call functions from each other, this is their "interface"; how do you test this. The problem that I have with google (and this answer) is that it assumes interface = user interface. – aiao Jan 23 at 16:23
  • @aiao - in that case, testing would need to be done via a code-based framework, because you won't be able to access the internal interfaces any other way. – Kate Paulk Jan 23 at 18:15
  • "testing would need to be done via a code-based framework".. agreed... What should I be testing in interface testing?. Note: Functionality against architecture requirements are already covered in unit testing. – aiao Jan 24 at 14:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.