2024地理信息一致性與測試

地理信息一致性與測試目 次前言 II引言 III范圍 1規(guī)范性引用文件 1術(shù)語、定義和縮略語 1術(shù)語和定義 錯誤！未定義書簽。縮略語 3一致性 4符號 4UML符號 4標識符 4框架 5模塊化規(guī)范 5概述 5一致性條款 5一致性類 6抽象測試套件 6模塊化標準 7可執(zhí)行測試套件 7一致性測試報告 8附錄A（資料性）抽象測試套件 10附錄B（資料性）樣式構(gòu)造的實例模板 16附錄C（資料性）UML模型 18附錄D（資料性）URI結(jié)構(gòu) 19附錄E（資料性）一致性測試報告示例 20附錄F（資料性）整體綜合性評價結(jié)果 22參考文獻 24I引 言本文件依據(jù)ISO標準中關(guān)于地理信息一致性和測試所定義的核心概念進行撰寫。同時，它還采納了OGC模塊化規(guī)范中的關(guān)鍵組件，涵蓋了需求、需求類、抽象測試用例以及一致性類等多個層面。盡管沿III地理信息一致性與測試范圍規(guī)范性引用文件本文件沒有規(guī)范性引用文件。術(shù)語、定義和縮略語術(shù)語和定義下列術(shù)語和定義適用于本文件。摘要abstract<作為修飾詞>獨立于實現(xiàn)。抽象測試用例abstracttestcase一致性測試用例conformancetestcase測試一個特定的需求或一組相關(guān)的需求。注1：抽象或一致性測試用例是導(dǎo)出可執(zhí)行測試用例的正式基礎(chǔ)。從某種意義上說，它應(yīng)該是完整的，即足以使測試判定能夠明確地分配給每個可能觀察到的測試結(jié)果。注2：ISO/IEC/IEEE24765:2017，3.4210包括測試用例或測試的定義。抽象測試套件abstracttestsuiteATS測試規(guī)范需求的一組一致性類。注：通過標準中指定的一個或多個一致性測試類的測試是符合全部或部分標準的根據(jù)。[來源：OGC08-131r3，4.2]一致性conformance一致性conformity滿足規(guī)定的要求。注：當沒有歧義時，可以省略修飾語“一致性”。例如，“測試報告”與“一致性測試報告”相同。1一致性條款conformanceclause符合條款conformityclause本條款包含符合國際標準或規(guī)范的所有要求。注：在本文件中，規(guī)范代表技術(shù)規(guī)范。一致性等級conformanceclass一致性測試類conformancetestclass一組抽象測試用例，該組測試案例被滿足時要接收一份單獨的一致性證書。注：OGC08-131r3將一致性證書定義為“符合全部或部分標準的證據(jù)，授予通過該標準中規(guī)定的一個或多個一致性測試等級的證書”。一致性測試conformancetesting測試產(chǎn)品以確定產(chǎn)品在多大程度上是符合要求的。一致性測試報告conformancetestreport測試報告testreport以有組織的格式呈現(xiàn)每個一致性類和抽象測試用例結(jié)論的文檔。一致性測試結(jié)果conformancetestresult測試結(jié)果testresult對測試中的實現(xiàn)執(zhí)行可執(zhí)行測試用例期間記錄的所有信息可執(zhí)行測試用例executabletestcase實現(xiàn)的特定測試，以滿足包含需求的規(guī)范中規(guī)定的特定需求。注：用可執(zhí)行表達式實例化抽象測試用例?？蓤?zhí)行測試模塊executabletestmodule用于測試單個一致性證書的相關(guān)可執(zhí)行測試用例集?？蓤?zhí)行測試套件executabletestsuite可執(zhí)行測試模塊集。標識符identifier語言上獨立的字符序列，能夠唯一地和永久地識別與之關(guān)聯(lián)的字符。[來源：ISO19135-1:2015，4.1.5]實施implementation規(guī)范的實現(xiàn)。注：在適用的地理信息標準文件中，這包括地理信息服務(wù)和數(shù)據(jù)集的相關(guān)規(guī)范。實現(xiàn)一致性聲明implementationconformancestatement2已實現(xiàn)的一致性類聲明。測試中的實現(xiàn)implementationundertest正在進行一致性評估的實現(xiàn)。[來源：ISO/IEC18477-4:2017，3.1.40]無定論的判決inconclusiveverdict當通過和不通過都不適用時的測試判決。模塊化modular由單獨的部分組成，當組合在一起時，形成一個完整的整體。模塊化規(guī)范modularspecification以模塊化結(jié)構(gòu)組織其需求和一致性類的規(guī)范。模塊化標準modularstandard以模塊化結(jié)構(gòu)組織其要求和一致性類的標準。需求類requirementsclass具有相同規(guī)格指標以滿足一致性測試類的所有需求的集合。注：OGC08-131r3在名稱“需求類”下定義了一個類似的概念，它是所有需求模塊的集合，這些模塊必須全部滿足才能滿足一致性測試類。specification包含需求和這些需求的抽象測試用例的文檔。規(guī)范化對象specificationtarget規(guī)范中某些要求適用的實體。注：OGC08-131r3在名稱“標準化目標”下定義了一個類似的概念，標準化目標是一個可能收到需求類一致性證明的實體。standard以協(xié)商一致方式制定并經(jīng)公認機構(gòu)批準的文件，該文件規(guī)定了活動或其結(jié)果的規(guī)則、準則或特點，供共同和重復(fù)使用，目的是在特定情況下的達到最佳實現(xiàn)。注：標準應(yīng)以科學(xué)、技術(shù)和經(jīng)驗的綜合成果為基礎(chǔ)，旨在促進最佳共有效益。[來源：ISO/IECGuide2:2004，3.2]測試工具testtool執(zhí)行可執(zhí)行測試套件的應(yīng)用程序?？s略語3下列縮略語適用于本文件。ATC：抽象測試案例（AbstractTestCase）ATS：抽象測試套件（AbstractTestSuite）CWA：封閉世界假設(shè)（ClosedWorldAssumption）ETC：可執(zhí)行測試案例（ExecutableTestCase）ETM：可執(zhí)行測試模型（ExecutableTestModule）ETS：可執(zhí)行測試套件（ExecutableTestSuite）ICS：實現(xiàn)一致性聲明（ImplementationConformanceStatement）IUT：測試中的實現(xiàn)（ImplementationUnderTest）OWA：開放世界假設(shè)（OpenWorldAssumption）SA：存根假設(shè)（StubAssumption）TEAM：測試，評估與量測（Test，Evaluation，andMeasurement）UML：統(tǒng)一建模語言（UnifiedModelingLanguage）URI：統(tǒng)一資源標識符（UniformResourceIdentifier）一致性本文件定義了四個一致性類：——“模塊化規(guī)范”（規(guī)范指標：規(guī)范）；——“模塊化標準”（規(guī)范指標：標準）；——“可執(zhí)行測試套件”（規(guī)范指標：可執(zhí)行測試套件）；——“一致性測試報告”（規(guī)范指標：測試工具）。要求符合本文件的規(guī)范、標準、測試套件或測試工具應(yīng)執(zhí)行與該規(guī)范化對象相關(guān)的一致性類。應(yīng)使用本標準附錄A1提供了一致性類的URI。注：本文件中的URIs與ISO/TC211提供的官方URL相關(guān)。表1一致性類統(tǒng)一資源標識符一致性類統(tǒng)一資源標識符模塊化規(guī)范/19105/-/2/conf/ModularSpecification模塊化標準/19105/-/2/conf/ModularStandard可執(zhí)行測試套件/iso19105/-/2/conf/TestSuite一致性測試報告/iso19105/-/2/conf/report符號UML在本文件中概念化的模式用統(tǒng)一建模語言（UML）展示，ISO19103給出了本文件中使用的UML的特定配置文件。標識符本標準中的規(guī)范性條款用URI表示：4</iso19105/-/2>。本文件中出現(xiàn)的所有需求和抽象測試用例標識均以URI為基礎(chǔ)部分。框架ATS（ETS）ETS對IUT圖1一致性測試的一般方法模塊化規(guī)范概述注：這使得編寫規(guī)范更加困難，但有望使規(guī)范更易于閱讀和理解。這種權(quán)衡通常是值得的，因為規(guī)范的讀者總是比其貢獻作者多幾個數(shù)量級。使規(guī)范的實施更容易是本標準的一個重要目標。一致性條款要求1/req/specification/ConformanceClause規(guī)范應(yīng)包含一致性條款。要求2/req/specification/ConformanceClauseStatement一致性條款應(yīng)以要滿足的一致性類聲明開始，以便實現(xiàn)聲明與該規(guī)范的一致性。要求3/req/specification/ConformanceTarget一致性條款應(yīng)指定規(guī)范中每個一致性類的規(guī)范化對象。一致性類將抽象測試用例模塊化（見附錄A）。附件B.1中提供了示例一致性條款模板。要求4/req/specification/ConformanceClauseReference一致性條款應(yīng)引用附件的ATS。5一致性類要求5/req/specification/CorrespondenceRequirementsClasses需求類應(yīng)以與一致性類一致的方式對規(guī)范中的需求進行劃分。每個需求類將與一個類似命名的一致性類一一對應(yīng)，該一致性類測試所有需求類的需求。附錄B.2中提供了示例要求。要求6/req/specification/SpecificationTarget要求類中的所有要求應(yīng)具有相同的規(guī)范化對象。要求7/req/specification/ConformanceTest應(yīng)在至少一個抽象測試用例中測試需求。要求8/req/specification/ConformanceClassIdentification一致性類應(yīng)由URI標識。要求9/req/specification/ConformanceClassDependency一致性類應(yīng)說明其所依賴的任何其他一致性類。其他一致性類也應(yīng)該應(yīng)用于測試一致性。抽象測試套件在不考慮一致性類之間依賴關(guān)系的情況下，ATS具有層次結(jié)構(gòu)。一致性類可用于幫助規(guī)劃、開發(fā)或理解ATS。一致性類由一個或多個抽象測試用例組成（見附錄C）。抽象測試用例用作生成可執(zhí)行測試用例的基礎(chǔ)，并且獨立于IUT。（見附錄。要求10/req/specification/ATSStructureATC的結(jié)構(gòu)應(yīng)遵循一致性類的結(jié)構(gòu)。B.3中提供了示例要求。要求11/req/specification/ATCTemplate抽象測試用例應(yīng)包含：a）測試用例標識符；b）測試目標（可選）；測試方法（包括測試判定標準）；參考需求（可選）。B.4中提供了示例要求。要求12/req/specification/ATCIdentifier抽象測試用例的標識符應(yīng)為URI。建議1/rec/specification/ATSTestPurpose每一個抽象測試用例都應(yīng)該包含測試目的，用于提供關(guān)于預(yù)期所達到目標的精確描述。6要求13/req/specification/ATCTestMethod抽象測試用例的測試方法應(yīng)包含其測試目的的測試判定標準。要求14/req/specification/ATCTestReference抽象測試用例的參考應(yīng)確定測試的需求。許可1/per/specification/ATSElementsATS可能包含標識符、測試方法和需求參考以外的其他元素。注：為了提供向后兼容性，ATC中可能包含測試類型[2]。測試類型可以是基本測試或能力測試。通常，基本測試可提供IUT符合的初步證據(jù)。能力測試檢查IUT的可觀察能力是否與聲稱的能力一致。模塊化標準要求15/req/standard/Dependency模塊化ISO/TC211標準應(yīng)遵循本標準第8章規(guī)定的模塊化結(jié)構(gòu)。依賴關(guān)系：/19105/-1/2/req/ModularSpecification作為XML模式和本體的ISO/TC211標準的實現(xiàn)需要訪問模式和模式內(nèi)單個資源的官方URI。對于一致性測試和文檔，一致性類、一致性測試、標準的要求和建議也需要唯一標識。要求16/req/standard/Identification所有可識別的需求類、需求、一致性類和抽象測試用例都應(yīng)參照附錄D的URI標識?？蓤?zhí)行測試套件可執(zhí)行測試套件（ETS）是ATS的實例化，其中所有與實現(xiàn)相關(guān)的參數(shù)都分配有特定值。要求17/req/test-suites/ExecutableTestSuite可執(zhí)行測試套件應(yīng)涵蓋抽象測試套件中指定的所有一致性類。要求18/req/test-suites/ExecutableTestModule可執(zhí)行測試套件應(yīng)以與一致性類一致的方式分割可執(zhí)行測試模塊中的可執(zhí)行測試用例。每個可執(zhí)行測試模塊應(yīng)與一個類似命名的一致性類一一對應(yīng)，該一致性類測試所有需求類的需求。要求19/req/test-suites/ETC一個可執(zhí)行的測試用例應(yīng)源自一個或多個抽象測試用例。要求20/req/test-suites/ETCTemplate一個可執(zhí)行測試案例應(yīng)該包含：a）測試用例標識符；測試說明；測試表達；相應(yīng)的參考。7要求21/req/test-suites/ETCTestIdentifier可執(zhí)行測試用例的標識符應(yīng)為URI。要求22/req/test-suites/ETCTestDescription可執(zhí)行測試用例的測試描述應(yīng)包括與ETC實施的ATC一致的測試描述。要求23/req/test-suites/ETCTestExpression可執(zhí)行測試用例的測試表達式應(yīng)實施與ETS實施的ATC測試方法一致的判定標準。要求24/req/test-suites/ETCTestReference可執(zhí)行測試用例的參考應(yīng)標識已實現(xiàn)的ATC。注：ATC標識符是一個URI。對于適用的ISO/TC211文件，這是指附件D中提供的URI結(jié)構(gòu)。一致性測試報告一致性測試的結(jié)果記錄在一致性測試報告中。要求25/req/report/TestReport一致性測試報告應(yīng)包含根據(jù)IUT實施的要求類的測試結(jié)論。建議2/rec/report/ICSIUT應(yīng)提供實現(xiàn)一致性聲明（ICS），該聲明提供已實現(xiàn)的一致性類的聲明，以允許根據(jù)相關(guān)要求測試實現(xiàn)。注1：ICS表示要測試IUT的需求類，例如，ICS可以是Web服務(wù)能力描述文檔中實現(xiàn)的需求類的URI。注2：通常，一致性測試報告由兩部分組成：摘要和詳細信息部分。參見附錄E中的示例。示例1：失敗、警告、信息、通過、通過_人工、跳過、不適用、未定義，請參閱Ares（2016）6685626。示例2：通過、失敗、不確定、無、錯誤，參見ES201873-1。要求26/req/report/TestVerdict測試判定應(yīng)是結(jié)果值的聲明。[12（見附件D.1中給出的值。8要求27/req/report/OverallResult分配的測試判定應(yīng)綜合到IUT的整體一致性判定評估中。注1：總體結(jié)果是一致性類結(jié)果的綜合。注2：IUT的其中一個問題與依賴性問題有關(guān)。此類依賴性通常已存在于評估IUT所依據(jù)的規(guī)范中。此外，規(guī)范本身經(jīng)常引塊化為不同的文檔，因此，它們之間存在邏輯關(guān)系。在實際的測試中，會有不同的結(jié)果綜合方法來評估整體結(jié)果。這些結(jié)果合成方法包括但不限于附件F中提供的方法。IUT在測試過程中提供的所有信息的記錄和保留對于分析階段和審計來說是必要的。要求28/req/report/RecordAuditability一致性測試的結(jié)果應(yīng)是可審核的。注：無論結(jié)果分析是手動進行還是自動進行，都應(yīng)記錄每個正在執(zhí)行的測試用例的所有輸入和輸出。要求29/req/report/ResultRepeatability一致性測試的結(jié)果應(yīng)是可重復(fù)的。注：為了實現(xiàn)可靠的一致性測試的目標，在給定的IUT上執(zhí)行可執(zhí)行測試用例的結(jié)果需要在執(zhí)行時始終相同。需要能夠執(zhí)行完整的ETS并觀察到與在其他情況下獲得的結(jié)果相同的測試結(jié)果。要求30/req/report/ResultComparability一致性測試的結(jié)果應(yīng)具有可比性。注：IUT一致性的總體摘要需要獨立于進行測試的測試實驗室[6][7還是由任何（第三方）完成測試實驗室進行的。9附錄 A（資料性）抽象測試套件概況本附錄規(guī)定了抽象測試套件（ATS），任何聲明與本文件一致的實現(xiàn)需完全通過該測試。以下測試標識符相對于：<iso19105/-2/>一致性測試類：模塊化規(guī)范概述此一致性類的URI標識符為：</19105/-1/2/conf/ModularSpecification>這個需求類的URI標識符是：</19105/-1/2/req/ModularSpecification>下面的測試標識符是相對于</19105/-1/2>規(guī)范包含一致性條款測試id： /conf/specification/ConformanceClause測試方法： 對于適用的規(guī)范，檢查是否存在一致性條款。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ConformanceClause一致性條款以一致性類的聲明開始測試id： /conf/specification/ConformanceClauseStatement測試方法： 對于一致性條款檢查一致性類是否在一致性條款的抽象測試套中指定，否則檢查一致性條款是否引用了ATS附件。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ConformanceClauseStatement一致性條款中規(guī)定了每個一致性類的規(guī)范化對象測試id： /conf/specification/ConformanceTarget測試方法： 對于一致性條款，檢查是否指定了每個一致性類的規(guī)范化對象。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ConformanceTarget在抽象測試套件中聲明了實際的一致性類測試id： /conf/specification/ConformanceClauseReference測試方法： 對于一致性條款，檢查它是否引用了附件中的ATS。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ConformanceClauseReference需求與一致性類的對應(yīng)關(guān)系10測試id： /conf/specification/CorrespondenceRequirementsClasses測試方法： 對于需求類中的所有需求，檢查這些需求是否與一致性類一致。如果constraint的值為‘true’，則測試通過。參考： /req/specification/CorrespondenceRequirementsClasses一個需求類中的所有需求都具有相同的規(guī)范化對象測試id： /conf/specification/SpecificationTarget測試方法： 對于需求類中的所有需求，檢查這些需求是否具有相同的規(guī)范化對象。如果constraint的值為‘true’，則測試通過。參考： /req/specification/SpecificationTarget至少在一個抽象測試用例中測試需求測試id： /conf/specification/ConformanceTest測試方法： 對于需求，檢查是否至少有一個抽象測試用例來測試該需求。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ConformanceTest一致性類由URI標識測試id： /conf/specification/ConformanceClassIdentification測試方法： 對于一致性類，檢查它是否由URI標識。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ConformanceClassIdentification指定測試依賴的標識測試id： /conf/specification/ConformanceClassDependency測試方法： 對于依賴一致性類，檢查它是否由URI標識。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ConformanceClassDependencyATS與需求類一致測試id： /conf/specification/ATSStructure測試方法： 對于ATS，檢查其層次結(jié)構(gòu)是否與一致性類一致。如果constraint的值為‘true’，則測試通過。參考： /req//specification/ATSStructureATC遵循模板測試id： /conf/specification/ATCTemplate測試方法： 對于抽象測試用例，檢查它是否根據(jù)給定的模板指定。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ATCTemplateATS由URI標識測試id： /conf/specification/ATCIdentifier11測試方法： 對于抽象測試用例，檢查它是否由有效的URI標識。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ATCIdentifierATC測試方法包含測試判決測試id： /conf/specification/ATCTestMethod測試方法： 對于抽象測試用例的測試方法，檢查它是否包含其測試目的的測試判定標準。如果constraint的值為‘true’，則測試通過。參考： /req//specification/ATCTestMethodATC參考要求測試id： /conf/specification/ATCTestReference測試方法： 對于抽象測試用例，檢查它是否標識了被測試的需求。如果constraint的值為‘true’，則測試通過。參考： /req/specification/ATCTestReference一致性測試類：模塊化標準概述此一致性類的URI標識符為：</19105/-1/2/conf/模塊化標準>這個需求類的URI標識符是：</19105/-1/2/req/模塊化標準>下面的測試標識符是相對于</19105/-1/2>模塊化標準遵循模塊化結(jié)構(gòu)測試id： /conf/standard/Dependency測試方法： 對于模塊化ISO/TC211標準，請檢查它是否符合本標準第8章規(guī)定的所有要求。如果constraint的值為‘true’，則測試通過。參考： /req/standard/Dependency所有標識都遵循附錄D測試id： /conf/standard/Identification測試方法： 對于適用的ISO/TC211標準檢查所有可識別的需求類需求一致性類抽象測試用例和相應(yīng)的資源是否由可引用的URI標識，如附錄D中給出的。如果constraint的值為‘true’，則測試通過。參考： /req//standard/Identification一致性測試類：可執(zhí)行測試套件概述此一致性類的URI標識符為：</iso19105/-/2/conf/TestSuite>此需求類的URI標識符為：12</19105/-1/2/req/TestSuite>下面的測試標識符是相對于</iso19105/-1/2>可執(zhí)行測試套件應(yīng)涵蓋所有ETMs測試id： /conf/test-suites/ExecutableTestSuite測試方法： 對于可執(zhí)行測試套件，檢查它是否涵蓋了抽象測試套件中指定的所有ETM。如果constraint的值為‘true’，則測試通過。參考： /req/test-suites/ExecutableTestSuite可執(zhí)行測試模塊應(yīng)與一致性類一致測試id： /conf/test-suites/ExecutableTestModule測試方法： 對于可執(zhí)行測試套件檢查可執(zhí)行測試用例在可執(zhí)行測試模塊中的劃分方式與一致性類一致。如果constraint的值為‘true’，則測試通過。參考： /req/test-suites/ExecutableTestModule可執(zhí)行測試源自相應(yīng)的ATC/ATCs測試id： /conf/test-suites/ETC測試方法： 對于可執(zhí)行的測試用例，檢查它是否引用了相應(yīng)的ATC/ATCs。如果constraint的值為‘true’，則測試通過。參考： /req/test-suites/ETCETC遵循指定模板測試id： /conf/test-suites/ETCTemplate測試方法： 對于可執(zhí)行測試用例，檢查它是否遵循指定的模板。如果constraint的值為‘true’，則測試通過。參考： /req/test-suites/ETCTemplateETC由URI標識測試id： /conf/test-suites/ETCTestIdentifier測試方法： 對于可執(zhí)行測試用例，檢查它是否由URI標識如果constraint的值為‘true’，則測試通過。參考： /req/test-suites/ETCTestIdentifierETC包含一個測試描述測試id： /conf/test-suites/ETCTestDescription測試方法： 對于可執(zhí)行的測試用例，檢查它是否包含與ETC實現(xiàn)的ATC一致的測試描述。如果constraint的值為‘true’，則測試通過。參考： /req/test-suites/ETCTestDescriptionETC包含一個測試表達測試id： /conf/test-suites/ETCTestExpression13測試方法： 對于可執(zhí)行的測試用例，檢查它是否包含一個測試表達式，該表達式執(zhí)行與ETS執(zhí)行的ATC測試方法一致的判定標準。如果constraint的值為‘true’，則測試通過。參考： /req/test-suites/ETCTestExpressionETC應(yīng)包含對要求的參考測試id： /conf/test-suites/ETCTestReference測試方法： 對于可執(zhí)行測試用例，檢查它是否包含對其實現(xiàn)的ATC的引用。如果constraint的值為‘true’，則測試通過。參考： /req/test-suites/ETCTestReference一致性測試類：一致性測試報告概述此一致性類的URI標識符為：</iso19105/-/2/conf/report>此需求類的URI標識符為：</iso19105/-/2/req/report>下面的測試標識符是相對于</iso19105/-1/2/>根據(jù)ICS提供一致性測試報告測試id： /conf/report/TestReport測試方法： 對于一致性測試報告，請檢查是否根據(jù)ICS提供了測試結(jié)論。如果constraint的值為‘true’，則測試通過。參考： /req/report/TestReport測試結(jié)論是對結(jié)果值的描述測試id： /conf/report/TestVerdict測試方法： 對于測試結(jié)論，請檢查它是否是結(jié)果值聲明。如果constraint的值為‘true’，則測試通過。參考： /req/report/TestVerdict測試判決被合成為一個整體一致性判決評估測試id： /conf/report/OverallResult測試方法： 對于IUT，檢查是否有總體一致性判定評估。如果constraint的值為‘true’，則測試通過。參考： /req/report/OverallResult一致性測試是可查證的測試id： /conf/report/ResultAuditability測試方法： 針對IUT運行ETS，檢查是否記錄了每個正在執(zhí)行的測試用例的所有輸入和輸出。如果constraint的值為‘true’，則測試通過。14參考： /req/report/ResultAuditability一致性測試是可重復(fù)的測試id： /conf/report/ResultRepeatability測試方法： 對同一IUT運行可執(zhí)行測試套件兩次，檢查兩個結(jié)果是否相同。如果constraint的值為‘true’，則測試通過。參考： /req/report/ResultRepeatability一致性測試具有可比性測試id： /conf/report/ResultComparability測試方法： 在不同的測試實驗室針對相同的IUT運行可執(zhí)行測試套件檢查兩個結(jié)果是否相同。如果constraint的值為‘true’，則測試通過。參考： /req/report/ResultComparability15附錄 B（資料性）樣式構(gòu)造的實例模板一致性條款模板示例一致性條款模板可以如下：個一致性等級：——“；——“；——...；——“Cn”（規(guī)范目標：目標Tn）。聲明符合本文件的規(guī)范、標準、測試套件或測試工具應(yīng)實現(xiàn)與該規(guī)范目標相關(guān)的一致性類。提供了一致性類URI。其中Ci為一致性等級，Ti為規(guī)范目標，X為附錄順序，j為表順序。第5章中顯示了一個示例一致性條款，其中包含描述性文本和格式化表格。需求模板示例需求模板如下：需求聲明依賴：{URIs}為需求名，Requirementstatement為規(guī)范性需求語第8章、第9章和第10章中編號為1至30的要求是格式化要求聲明的示例。抽象測試套件模板示例抽象測試套件模板可以如下：本附件規(guī)定了一個抽象測試套件（ATS），任何聲稱符合本文件的實現(xiàn)都應(yīng)通過該套件。下面的需求標識符是相對于<URI>。其中URI是標準/規(guī)范的URI。在本文件的附件A中可以找到一個示例。抽象測試用例模板測試id： /conf/confcls/test測試目的： 測試目的測試方法： 測試目方法參考： /conf/reqcls/req其中confcls為一致性類名，test為一致性測試名，Testpurpose為測試目的描述，testmethod為測試方法描述，reqcls為需求類名，req為需求名。16在本文件的附件A中可以找到一個示例。17附錄 C（資料性）UML模型基于OGC08-131r3概念模型修改，以便在本附錄中使用，以更好地理解模塊化規(guī)范。適用規(guī)范包含需求類和相應(yīng)的ATS，ATS由測試相應(yīng)需求類的一致性類組成。需求類中的需求都共享相同的規(guī)范目標。根據(jù)至少一個抽象測試用例測試需求。ETS源自相應(yīng)的ATS，并針對IUT執(zhí)行，以檢查ICS的URI中提供的聲明能力是否得到正確開發(fā)。一致性測試結(jié)果用于導(dǎo)出IUT的一致性測試報告。參見圖C.1中的UML模型。圖C.1UML模型18附錄 D（資料性）URI結(jié)構(gòu)規(guī)范性聲明模板：網(wǎng)址/標準號/-[partNumber]/editionNumber/statementType/nsClassId/nsId。來源：——標準號：標準的主要編號，如“19115”；——部件號：對于有多個部分的標準，如“-1”。如果標準沒有部分：“-”；——版本號：ISO官方版本號，如“1”；——聲明類型：req（requirement），rec（recommendation）或per（permission）；——nsClassId：規(guī)范聲明的類ID；——nsID：規(guī)范聲明的內(nèi)部ID。例子：ISO19131第2版要求類“內(nèi)容”中要求“范圍”的URI：</19131/-/2/req/content/extent>。注1：文檔的版本號放在語句類型之前，以便為一個版本中的所有語句啟用一個主URI。預(yù)計每個版本的聲明都需要檢查。注2：資源的內(nèi)容應(yīng)顯示規(guī)范性聲明。一致性類和測試模板：/標準號/-[partNumber]/編輯號/conf/lassId/TestId。來源：——標準號：標準的主要編號，e.g.“19115”；——部件號：對于有多個部分的標準，如“-1”，如果標準沒有部分：“-”；——編輯號：ISO官方編輯號，e.g.“1”；——類Id：一致性類的類ID；IDID（僅用于一致性測試）。例子：ISO19131第2版中一致性類“內(nèi)容”中一致性測試“allContent”的URI：</19131/-/2/conf/content/allContent>。注1：文檔的版本號放在conf之前，以便為一個版本中的所有一致性類啟用一個主URI。預(yù)計測試的需要對每個版本進行檢查。注2：資源的內(nèi)容應(yīng)該描述一致性類和測試。19附錄 E（資料性）一致性測試報告示例OGCTEAM在OGCATSOGCTEAM（）運行此ETS并測試相應(yīng)的實現(xiàn)[9]。參見圖E.1中的示例。圖E.1OGC團隊引擎的樣本測試報告INSPIRE（ETF）的一致性測試報告INSP