Re: [tag] Prior Art - wiki updated - notes attached

[Kevin Looney <Kevin.T.Looney@Sun.COM>]

Shouldn't ADL be mentioned somewhere for Prior Art?

It's not necessarily a 1-1 corelation with TA's, however it is a 
formalization of specifications (which contain TAs).

Kevin L

Paul Rank wrote:
> I've updated the Prior Art section of the wiki with a couple links 
> provided by Stephen.  Attached are my notes/summary of the items we 
> now have in th prior art section.
> Paul
>
>
> ------------------------------------------------------------------------
>
>
>   Prior art (examples of test assertions)
>
> ------------------------------------------------------------------------
>
>
>       Test Assertion Documents for WS-I profiles
>       <%5Bhttp://www.ws-i.org/Testing/Tools/2005/01/BP11_TAD_1-1.htm>
>       (2003-2005)
>
>     * Test assertions for the WS-I Basic Profile definition
>     * Test Assertion consists of:
>           o ID
>           o Entry Type - definitions | types | operation | portType |
>             binding | import
>           o Test Type - required | recommended | driverTestable |
>             informational | notTestable
>           o Enabled - true | false
>           o Additional Entry Types
>                 + Message Input
>                 + WSDL Input
>           o Prerequisites
>           o Profile Requirements
>                 + Target
>                 + Partial-Target
>                 + Collateral
>           o Context
>           o Assertion Description
>           o Failure Message
>           o Failure Detail Description
>           o Comment
>
> ------------------------------------------------------------------------
>
>
>       HTML 4.01 Test Suite - Assertions
>       <http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_toc.html%20>
>       (2002)
>
>     * Test Assertion consists of:
>           o ID
>           o Reference (pointer to the spec)
>           o Assertion text
>           o Tests
>     * Assertion text is prefaced by (may), (must), (informative) or
>       (should)
>     * Assertion text is sometimes prefaced by (author)
>
> ------------------------------------------------------------------------
>
>
>       Sample marked-up chapter from the Java Language Specification
>       <http://www.oasis-open.org/apps/org/workgroup/tag/download.php/24154/conversions.html>
>       (JLSv3)
>
>     * Assertions identified as text within specification
>     * "Simple" Sun model - test assertion consists of:
>           o An ID
>           o A string of text
>           o A pointer to the location in the specification
>     * Similar approach is used at Sun for JavaDoc based specs (API)
>
> ------------------------------------------------------------------------
>
>
>       SOAP Version 1.2 Specification Assertions and Test Collection
>       <http://www.w3.org/TR/soap12-testcollection/> (2003)
>
>     * Test Assertion consists of:
>           o ID
>           o Location of the assertion (pointer to the location in the
>             spec)
>           o Text from the Specification
>           o Comments
>           o Tests - pointer to the tests for this assertion
>
> ------------------------------------------------------------------------
>
>
>       DejaGnu Testing Framework
>       <http://www.delorie.com/gnu/docs/dejagnu/dejagnu_6.html%20> - A
>       POSIX conforming test framework
>
>     * POSIX standard 1003.3 defines what a testing framework needs to
>       provide, in order to permit the creation of POSIX conformance
>       test suites. Can not find a link to POSIX 1003.3
>     * The POSIX documentation refers to assertions. An assertion is a
>       description of behavior. For example, if a standard says "The
>       sun shall shine", a corresponding assertion might be "The sun is
>       shining." A test based on this assertion would pass or fail
>       depending on whether it is daytime or nighttime.
>     * 1003.3 specifies a set of allowed output messages, and their
>       definitions:
>           o PASS
>           o FAIL
>           o UNRESOLVED
>           o UNRESOLVED
>           o UNTESTED
>           o UNSUPPORTED (conditional)
>
> ------------------------------------------------------------------------
>
>
>       Unisoft - Glossary of Assertion Based Testing Terms
>       <http://www.unisoft.com/glossary.html>
>
>     * Contains a set of terms which are useful when developing
>       assertion based tests - aligned with POSIX 1003.3
>     * Assertion Definition - A statement of behavior for an element to
>       be tested. These are normally derived from text describing
>       software to be tested (the specification).
>     * Many other terms defined - worthwhile to review
>
> ------------------------------------------------------------------------
>
>
>       Guidelines on Abstract Test Suites and Conformance Clauses
>       <http://lists.oasis-open.org/archives/tag/200709/pdf00000.pdf> -
>       Norwegian Technology Standards Institution
>
>     * Structure Abstract Test Suite (ATS) in a clear, hierarchical way.
>     * Document explains how to generate ATS
>           o Identify test purpose- "what does your part of the
>             standard specify?"
>           o decompose test purpose - Need to answer: "For an
>             implementation to be in conformance to the test purpose
>             specified, what
>             requirements have to be satisfied?"
>           o Repeat identify an decompose until all test purposes are
>             decomposed into sufficiently small pieces
>     * The ATS is then used to define the testable assertions.
>
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>