112年檢察事務官三等系統分析
|
二、請列舉及解釋至少三種不同的需求驗證技術 (Requirements Validation Techniques)，並請說明那些需求是屬於不可測試 (Not Testable)。（25分） |
答：
(一)三種不同的需求驗證技術(Requirements Validation Techniques)
1.靜態分析(Static Analysis)：
(1)定義：
a.在不實際執行程式的情況下，單純就程式碼的內容進行分析。這種方式，僅能分析到程式碼「靜態」的特性。
b.以人工或自動化方法評估軟體是否滿足規範。
c.可以分為審查與檢視方法，例如規範技術複審、文件複審、資料庫複審，以及演算法分析審查。
(2)最常用的工具：
a.原始碼分析器(Code Analyzer)：檢查程式語法是否正確。
b.結構檢查器(Structure Checker)：
可以繪出受測程式的階層式結構圖，並且自動檢查其是否發生結構上的錯誤。
c.資料分析器(Data Analyzer)：
可以自動檢查受測程式的資料結構、資料宣告，以及模組介面的正確性。
d.順序檢查器(Sequence Checker)：
自動檢查受測程式各種事件的處理順序是否正確。
(3)測試技術：
a.檢視(Inspection)：
(a)是一種審查軟體工程中產出的文件或代碼的正式方法，目的是找出錯誤或缺陷。
(b)選擇要審查的部分和參與的人員，參與者獨立地閱讀材料，尋找可能的問題。集體討論找到的問題，並且根據審查結果修改文件或代碼。
b.結構化逐步審查(Structured Walkthrough)：
(a)是一個方法，用於確保軟體或系統的各個組件都被正確、完整地審查和驗證。它強調對軟體工件的細節進行深入、結構化的審查。
(b)參與審查的人員可能包括軟體設計師、開發人員、測試人員、專案經理，以及其他利益相關者。審查過程通常有一個固定的流程或議程，包括開始和結束時間、特定的審查範疇和目標，以及後續行動的決策。
c.主動審查(Active Review)：
(a)是一種軟體工程審查方法，其中參與者被賦予特定的角色或任務，使他們在審查過程中更加主動和專注。
(b)例如一個審查員可能被指定為性能專家，而另一個審查員則專注於安全性問題。鼓勵審查員深入研究工件，並且從多個角度識別潛在問題。
2.動態分析(Dynamic Analysis)：
(1)定義：
a.實際將程式碼執行起來同時分析，可以收集到程式在執行期的行為及資訊以進行分析。
b.最常見的動態分析是單元測試。
(2)優點：
a.識別執行時環境中的漏洞。
b.允許分析無法存取實際程式碼的應用程序。
c.識別在靜態程式碼分析中可能出現漏洞。
d.允許驗證靜態程式碼分析結果。
e.可以針對任何應用程式進行。
(3)限制：缺點
a.自動化工具提供了一切正在解決的錯誤安全感。
b.不能保證原始程式碼的完整測試覆蓋率。
c.自動化工具會產生誤報 (False Positive) 及漏報 (False Negative) 的問題。
d.自動化的工具只能和它們用來掃描的規則一樣好。
e.將漏洞追溯到程式碼中的精確位置比較困難，需要更長時間才能修正問題。
3.動態測試(Dynamic testing)：
(1)定義：
運作被測試的程式，輸入測試資料，檢查運作結果與預期結果的差異，從而判斷系統中是否存在缺陷的過程。
(2)測試技術：
a.黑箱測試：
測試人員完全不考慮程式內部的邏輯結構和內部特性，只要依據程式的需求規格說明書，檢查程式的功能是否符合它的功能性說明的測試方法。主要是在系統測試階段時採用。
b.白箱測試：
使用被測程式內部如何工作的資訊，允許測試人員對程式內部邏輯結構及有關資訊來設計和選擇測試案例，對程式的邏輯路徑進行測試。其測試基於覆蓋全部程式碼、分枝、路徑，以及條件。
c.灰箱測試：
基於被測試程式邏輯結構的基礎上，從系統功能介面上設計測試案例。通常是作為黑箱測試的補充或在黑箱發現缺陷以後，回到原始程式碼分析原因確認問題時採用。
※參考資料：
1.http://w1a2d3s4q5e6.blogspot.tw/2012/11/blog-post_7.html
2.李允中-軟體工程-第六章軟體測試.pdf
3.http://www.ithome.com.tw/node/71531
4.軟體測試概念.ppt
5.https://read01.com/4D5zy3.html
6.http://www.gss.com.tw/index.php/security/384-gss-0015
7.http://www.cc.ntu.edu.tw/chinese/epaper/0023/20121220_2309.html
8.https://www.testingexcellence.com/static-analysis-vs-dynamic-analysis-software-testing/
(二)那些需求是屬於不可測試(Not Testable)
是那些難以或無法使用具體測試或檢查方法來驗證其實現的需求。原因如下：
1.過於主觀：例如吸引人的使用者界面是主觀的，因為可以有多種解釋。
2.不明確的定義：
例如軟體需求是要求系統應該運行得很快，這是不明確的。因為很快到底有多快？是1秒、2秒還是10秒？這樣的需求會使開發者感到困惑，因為他們不知道具體需要達到什麼標準。
3.缺乏上下文：
對於軟體需求來說，如果一個需求說系統應該提供足夠的安全性，但是沒有進一步說明什麼是足夠的或是針對哪方面的安全性，那麼這個需求就缺乏上下文。開發者或測試者可能會不清楚如何實現或測試這樣的需求。
留言列表
國考資訊處理解答 (7)
