[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Prior Art - wiki updated - notes attached
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]