網絡配圖
1.1目的
測試文檔集的目的是證實軟件與5.3中規(guī)定的要求的符合性。其中包含允許作這種證實的全部 元素。
1.2一致性
1.2.1測試文檔集中的每個文檔所包含的信息應是正確的并且是可驗證的。
1.2.2測試文檔集中的每個文檔不應自相矛盾.并且不應與產品說明和用戶文檔集矛盾。
1.3內容要求
1.3.1測試文檔集一般應包含:
a)測試計劃;
b)測試說明;
c)測試結果(報告)。
1.3.2測試文檔集應包含組成該匯集的全部文檔的清單,清單中應包含全部文檔的標題及其標識符。
1.3.3測試文檔集中的每個文檔都應包括:
標題;
產品標識;
——修改歷史,或說明該文檔演變的任何其他元素;
—一目次或對內容的說明;
——該文檔正文中引用的文檔的標識符;
——有關作者和審查者的信息;
術語表。
1.3.4測試文檔集可由一個文檔或多個文檔組成。
1.4方法
注:未推薦特定的技術或方法。
1.4.1在產品說明和5.3軟件質量要求中提及的所有質量特性均應經測試用例測試。
1.4.2在產品說明和5.3軟件質量要求中提及的每個質量特性至少應經一個測試用例測試。
注:測試計劃可引用任何其他文檔,前提是被引用的文檔與用戶文檔集之間存在某種關系。
1.4.3用戶文檔集中說明的所有功能,以及待完成的任務的代表性的功能組合,均應經測試用例 測試。
1.4.4用戶文檔集說明的每個功能至少應經一個測試用例測試。
1.4.5測試用例應能證實軟件與用戶文檔集中的陳述的符合性。
1.4.6當產品說明中提及需求文檔時,所涉及的內容應經測試用例測試。
1.4.7應指明選作測試用例設計基礎的功能分解層次。
注:功能可能是:
——用戶文檔中的一段;
個Shell命令;
——人機界面的按鈕;
語言命令。
1.4.8應指明測試用例的設計方法。
注:可能的設計方法有:
——邊界值分析;
檢查表;
數據流分析;
故障插入;
——容量測試。
1.4.9所有安裝規(guī)程均應經測試用例測試。
1.4.10在產品說明和用戶文檔集中指明的所有操作限制均應經測試用例測試。
1.4.11對所標識的違反句法條件的輸入應經測試用例測試。
1.4.12如果用戶文檔集中給出若干示例,這些示例應用作測試用例,但整個測試不應局限于這些 示例。
1.4.13當5.3軟件質量要求中的任何要求不適用時,應說明理由。
1.4.14應對產品說明和用戶文檔集中所陳述的所有配置進行測試。
2.1通過——失敗準則
測試計劃應指明用于判定測試結果是否證實軟件與產品說明和用戶文檔集的符合性準則。
2.2測試環(huán)境
測試計劃應規(guī)定將要進行的測試所處的軟件測試環(huán)境。
注:可采用配置等效性證實。
2.3進度
測試計劃應規(guī)定每個測試活動和測試里程碑的進度。
注:測試活動可能有:
——測試環(huán)境搭建;
——測試文檔編制;
——測試執(zhí)行。
2.4 風險
2.4.1測試計劃應識別、更新并記錄測試活動中存在的風險,并提供應對措施。
2.5人力資源
測試計劃中應明確每個測試活動所需的人力資源情況。
2.6工具和環(huán)境資源
2.6.1測試計劃中應明確執(zhí)行測試活動所需的工具。
2.6.2如果使用特殊的工具和環(huán)境,測試計劃中應說明選擇這些工具和環(huán)境的原因以及預期的結果。
2.7 溝通
測試計劃中應規(guī)定溝通機制和方式,以便在利益相關方之間共享測試文檔和測試項。
3.1測試用例說明
3.1.1對每個測試用例的說明應包括:
a)測試目標;
b)唯一性標識符;
c)測試的輸入數據和測試邊界;
d)詳細實施步驟;
e)系統(tǒng)的預期行為;
D 測試用例的預期輸出;
g)結果解釋的準則;
h)用于判定測試用例的肯定或否定結果的準則;
i)可陳述的對基于GB/T 25000.10—2016的質量特性的引用。
3.1.2當有必要提供與測試計劃中提供的信息相比對的補充信息時,應陳述環(huán)境及其他測試條件(詳 細的配置和初步工作)。
3.2測試規(guī)程
3.2.1測試規(guī)程應包括:
a)測試準備;
b)開始和執(zhí)行測試所必需的動作;
c)記錄測試結果所必需的動作;
d)停止和最終重新啟動測試的條件和動作。
3.2.2為提供測試的可重復性和可再現性,測試規(guī)程應足夠詳細。
3.2.3在軟件被糾正之后,對于所涉及的功能和任何相關的功能,應有一種重新測試的規(guī)程。 注:說明測試規(guī)程可采用偽語言或命令語言。
4.1執(zhí)行報告
4.1.1執(zhí)行報告應包括測試用例結果的全部匯總。
4.1.2執(zhí)行報告應證實已按測試計劃執(zhí)行了所有測試用例。
4.1.3對于每個測試用例,執(zhí)行報告均應包括以下內容:
a)測試用例的標識符;
b)測試執(zhí)行日期;
c)實施測試的人員姓名和職責;
d)測試用例執(zhí)行的結果;
e)發(fā)現的異常清單;
f)對于每一異常,要引用相應的異常情況報告;
g)可陳述的對基于GB/T 25000.10-2016的質量特性的引用。
4.2異常情況報告
4.2.1異常情況報告應包括所發(fā)現的全部異常匯總。如果有的話,還應包括糾正情況和通過再測試 的驗證情況。
4.2.2對于每個異常,異常情況報告的說明性部分應包括如下內容:
a)異常的標識符;
b)軟件的標識符;
c)對異常的說明;
d)執(zhí)行測試用例中異常發(fā)生點;
e)異常的嚴重程度和可重現程度;
D 可陳述的對基于GB/T 25000.10-2016的質量特性的引用。
注1:異常的嚴重程度可以是“致命的”“嚴重的”“重大的”“微小的”“輕微的”。
注2:可重現程度可以是“總是出現”“有時出現”“隨機出現”“未嘗試”“不可再現”“N/A”。
4.2.3異常情況報告的糾正部分應論證發(fā)現的所有異常均已糾正,或者未糾正的原因。
4.2.4異常情況報告的糾正部分對每個糾正項應包含如下內容:
a)糾正項的標識符;
b)糾正的日期;
c)糾正者的姓名;
d)對應于糾正項的修改標識符;
e)糾正項的可能影響;
D 糾正者可能有的評論。
4.2.5異常情況報告中經重新測試驗證的部分,應證實所有已糾正的功能都具有用戶文檔集中定義 的行為。
4.2.6異常情況報告中經重新測試驗證的部分對每個驗證項應包含如下內容:
a)驗證項的標識符;
b)驗證日期;
c)驗證者的姓名;
d)用于驗證的測試用例;
e)驗證的結果;
f)可陳述的對基于GB/T 25000.10—2016的質量特性的引用。
4.3測試結果的評估
關于執(zhí)行報告和異常情況報告的評估應表明:在所使用的判定測試結果是否在該軟件的符合性準 則的界限內,所有的期望行為是可獲得的。
編輯:Tyche TAG:/醫(yī)療器械軟件/測試文檔/文檔集/評估