<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

</head>

<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">

<div><br>

</div>

Paul Sherwood wrote:

<div><br>

</div>

<div><i>“I am making these statements to remind folks of the clear, obvious weaknesses in statement coverage as an approach.”</i></div>

<div><br>

</div>

<div>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.</div>

<div><br>

</div>

<div><br>

</div>

<div>— steve</div>

<div><br>

</div>

<div><br>

</div>

<div><br id="lineBreakAtBeginningOfMessage">

<div><br>

<div>On Aug 7, 2024, at 5:10 AM, Paul Sherwood <paul.sherwood@codethink.co.uk> wrote:</div>

<br class="Apple-interchange-newline">

<div>

<div>On 2024-08-07 12:11, Prof. Dr. Peter Bernard Ladkin wrote:<br>

<blockquote type="cite">On 2024-08-07 11:38 , Paul Sherwood wrote:<br>

<blockquote type="cite">On 2024-08-07 10:28, Prof. Dr. Peter Bernard Ladkin wrote:<br>

<blockquote type="cite">

<blockquote type="cite">

<blockquote type="cite">[Dewi Daniels] If<br>

your tests haven't achieved statement coverage, then there's code that<br>

you've never executed, not even once, during your testing.<br>

</blockquote>

I understand the argument, but this last sentence is flawed.<br>

</blockquote>

How is the last sentence "flawed"? It seems to me a clear statement of the obvious (which I imagine is what Dewi intended).<br>

</blockquote>

Because we can **test**, without creating **tests**. We may have executed the code, but not created tests for it.<br>

</blockquote>

Let me rephrase. Dewi's statement above is a tautology.<br>

</blockquote>

<br>

I looked up that word, to check it still means what I learned in school...<br>

<br>

"Needless repetition of the same sense in different words; redundancy.<br>

An instance of such repetition.<br>

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."<br>

<br>

In any case it's still clear that the logic of the original statement is flawed, as I explained.<br>

<br>

<blockquote type="cite">I imagine he made it in order to remind us of the importance of statement coverage in constructing tests of critical software.<br>

</blockquote>

<br>

I expect he did. I am making these statements to remind folks of the clear, obvious weaknesses in statement coverage as an approach.<br>

_______________________________________________<br>

The System Safety Mailing List<br>

systemsafety@TechFak.Uni-Bielefeld.DE<br>

Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety<br>

</div>

</div>

</div>

<br>

</div>

</body>

</html>