Re: Compilers QA

Tim Josling <>
17 Jul 2001 23:09:53 -0400

          From comp.compilers

Related articles
Compilers QA (Ori Idan) (2001-07-03)
Re: Compilers QA (2001-07-06)
Re: Compilers QA (Tim Josling) (2001-07-17)
Re: Compilers QA (Joachim Durchholz) (2001-07-18)
Re: Compilers QA (2001-07-23)
Re: Compilers QA (Paul Pluzhnikov) (2001-07-23)
Re: Compilers QA (2001-07-23)
| List of all articles for this month |

From: Tim Josling <>
Newsgroups: comp.compilers
Date: 17 Jul 2001 23:09:53 -0400
Organization: Melbourne PC User Group
References: 01-07-037
Keywords: testing
Posted-Date: 17 Jul 2001 23:09:53 EDT

Testing is very labour intensive. As a rule of thumb allow twice
as much time for testing as for design and writing the code.

Some things to consider:

Design your system to be as componentized as possible, with
simple clean interfaces between the components. Test the
components before testing the whole thing.

Test all two way combinations of features eg each operator for
each data type.

Try throwing random data at the compiler and ensure it copes.
This is surprisingly powerful in finding bugs. You can start with
a working program and generate lots of minor changes.

Test boundary conditions. Eg char type with 0, 256 (unsigned),
-128 +127 (signed).

Throw as much real live test input as you can find, from
different sources. Real users will do many unbelievable things.
'Why would you want to do that?' is the question you will be

Tim Josling

Ori Idan wrote:
> I have written a compiler for 8 bit processor (Motorola HC08) and I am now
> facing the problem of writing a Test plan and other QA documents for it.
> It seems there are many combinations I have to check, for example, Add,
> Subtract etc. on 8bit ant 8bit,
> 8bit and 16 bit, 16bit and 16bit.
> It seems as almost infinite number of combinations...
> How is is usually done in other comercial compilers?
> Ori Idan

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.