I am testing an embedded system consisting of multiple processors working in different speeds, with different resources, all communicating through dedicated channels using a proprietary message protocol. The unit under test are the mentioned channels. There is no insight into the actual data over them (those are internal buses, so scopes or logic analyzers can't be used) I am using a top-down approach using high level tests to infer that the underlying code is really working. Anyone tested similar systems and can share tips on testing ?
Add a comment
|
2 Answers
Black-box testing is a very useful and necessary form of work in QA. If you can cover all inputs (including wrong ones, error corrected and so on), and get all the outputs correctly, it doesn't really matter what goes on inside for the purpose of certifying the channels.
The basics of QA are testing the product against the spec, and against conditions the spec hasn't thought of. As long as you satisfy that, you don't need the test every level of the machine. It helps to understand how it works, particularly for diagnosing the bugs, but it isn't an absolute must.
-
Basically I agree, but since the input is time dependent (some sort random data stream) and is build of multiple concurrent inputs covering all inputs is even more impossible than usual.– RsfCommented May 13, 2011 at 12:01
In the past when I've tested embedded systems I've used the debug and diagnostic tools the developers have created for their own use. I suggest you have a chat with the developers and see what tools they have and if necessary what tools they could add to help you test the system.
-
this was my first step, actually I am working very closely with the dev. team sharing most of the debug tools– RsfCommented May 11, 2011 at 15:52