[SystemSafety] State of the art for "safe Linux"
Steve Tockey
steve.tockey at construx.com
Wed Aug 7 20:10:06 CEST 2024
Paul Sherwood wrote:
“I am making these statements to remind folks of the clear, obvious weaknesses in statement coverage as an approach.”
Agreed, however it also needs to be clearly and obviously stated that neither fuzz testing nor experience-in-use should ever be considered as viable alternatives.
— steve
On Aug 7, 2024, at 5:10 AM, Paul Sherwood <paul.sherwood at codethink.co.uk> wrote:
On 2024-08-07 12:11, Prof. Dr. Peter Bernard Ladkin wrote:
On 2024-08-07 11:38 , Paul Sherwood wrote:
On 2024-08-07 10:28, Prof. Dr. Peter Bernard Ladkin wrote:
[Dewi Daniels] If
your tests haven't achieved statement coverage, then there's code that
you've never executed, not even once, during your testing.
I understand the argument, but this last sentence is flawed.
How is the last sentence "flawed"? It seems to me a clear statement of the obvious (which I imagine is what Dewi intended).
Because we can **test**, without creating **tests**. We may have executed the code, but not created tests for it.
Let me rephrase. Dewi's statement above is a tautology.
I looked up that word, to check it still means what I learned in school...
"Needless repetition of the same sense in different words; redundancy.
An instance of such repetition.
An empty or vacuous statement composed of simpler statements in a fashion that makes it logically true whether the simpler statements are factually true or false; for example, the statement Either it will rain tomorrow or it will not rain tomorrow."
In any case it's still clear that the logic of the original statement is flawed, as I explained.
I imagine he made it in order to remind us of the importance of statement coverage in constructing tests of critical software.
I expect he did. I am making these statements to remind folks of the clear, obvious weaknesses in statement coverage as an approach.
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20240807/9d7e077b/attachment.html>
More information about the systemsafety
mailing list