[SystemSafety] "Ripple20 vulnerabilities will haunt the IoT landscape for years to come"

[Olwen Morgan]

On 01/07/2020 18:12, Martyn Thomas wrote:

<snip>

> ...  and, in practice, a SPARK development wouldn't find anything much 
> at all in any cost-effective amount of unit testing, so it's a 
> sensible engineering decision to omit it.


I'm not so sure. Presumably the CbyC approach would effectively replace 
100% equivalence-class testing ... BUT ...

(1) How well would that protect you against errors that would be 
detected by 100% strong, robust boundary-value testing? (see Jorgensen's 
definition - bib details below - sorry if the cut-and-paste from Amazon 
makes for iffy formatting)

(2) Could it identify code through which there were more simple paths 
than actually needed to pass all the equivalence-class test cases? - Or 
is one testing only for functional correctness and not minimal 
control-flow complexity? (Given the ordure I've seen in C program 
flowgraphs, I'd want at least some way to warn people if their code was 
unnecessarily cumbersome.)

That's the reason I try to ensure that my code units have the property 
that every set of test cases that achieves 100% boundary-value coverage 
also attains 100% simple-path coverage. It's not instead-of CbyC (where 
that is possible) but belt-and-braces-in-addition-to CbyC - which in C 
developments is, I think, entirely justified.


Olwen


  Jorgensen, P. C., Software Testing: A Craftsman's Approach, Auerbach
  Publications, 4ed, 2013, ISBN-10:1466560681, ISBN-13:978-1466560680





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20200701/aeb03b2b/attachment.html>