From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,42427d0d1bf647b1 X-Google-Attributes: gid103376,public From: john@assen.demon.co.uk (John McCabe) Subject: Re: Ada Core Technologies and Ada95 Standards Date: 1996/04/16 Message-ID: <829673790.5774@assen.demon.co.uk>#1/1 X-Deja-AN: 147813632 x-nntp-posting-host: assen.demon.co.uk references: <00001a73+00002c20@msn.com> <315FD5C9.342F@lfwc.lockheed.com> <828474655.17825@assen.demon.co.uk> newsgroups: comp.lang.ada Date: 1996-04-16T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) wrote: >>We do this by using LDRA Testbed with limits on the minimum level of >>statement and branch coverage of 100%, and 70% on LCSJ's. I'm not sure >>exactly where those figures are derived from, but they seem >>reasonable. The only problem here is that we've found a few bugs in >>that tool as well! >Surely that's not the *only* problem. Surely the test cases fail to >cover every combination of requirements, and therefore some bugs slip >through. To some extent this is obviously true. However, one way we have tried to minimise the effect of this is to keep a close working relationship with our customer, to ensure that we are as completely aware as possible of what the possible combinations of requirements are. In this way our testing can simulate the real operation of the instrument as possible. One particular case of this is where we have been in discussions with our customer as to the how they intend to implement the command sequencing on the 1553 interface. Through these discussions we have found out that the timing requirements of events at our end of the bus are also used at the other end of the bus as minimum inter-command gaps. Therefore if we complete our command processing (i.e. initiate events and finish any housekeeping etc) within those times, we do not need to consider the case where the next command arrives while we are still processing the last one. >>... Based on >>the methods you and I use, would it not be better to use the ACVC >>suite as a basis for the compiler vendors tests, and also require the >>compiler vendors to submit their own test suites for approval. >At least *some* of the compiler vendors' tests include proprietary code >from their customers, and they simply cannot release that code. I can see that being a minor problem. I would have thought it would be fairly simple to produce a minimal, modified version of most problem reports that could be released without jeopardising the confidentiality of the customer's code. I, for example, tend to cut my problem reports down to the bare minimum of code which causes a problem. Best Regards John McCabe