運用靜態測試以后
每天可以對每位測試人員按功能模塊提交的靜態測試問題數進行統計;
每周都可以為每位測試人員應提交的靜態測試問題數目制定目標;
每周可以對每位測試人員的靜態測試問題質量進行評估和總結,營造積極進取的測試團隊氛圍
靜態測試的問題分類及切入點
文檔規范問題
“文檔規范”類的問題屬于所有問題分類中比較淺顯,但同時也是問題數量較為龐大的一類。諸如軟需中字段缺失,字段描述錯誤,錯別字等等。
查找方法:多采用橫向對比、縱向對比、多元對比的方法,細心、耐心的查找即可做好。當項目大或者工期緊的情況,可以不必花太多精力在此類問題上。
設計錯誤問題——“設計出來了,但是設計錯了”
此類問題需要對程序處理流程和業務處理邏輯非常清楚才能挖掘出來,具有較高的難度,測試經理和測試骨干應多關注和發現此類的問題。
查找方法:可在編寫流程圖、mm圖和狀態遷移圖的時候,理清楚程序處理流程和業務處理邏輯,再結合PRD、UC和開發設計文檔查找設計得不對的靜態測試問題。
設計不完善問題——“設計出來了,但是設計得不好”
“設計不完善”類的問題在大多數文檔中是頻頻出現的,比如前后邏輯矛盾,表述歧義,表達不清晰,邏輯混亂,存在誤解等等。此類問題應該是項目組成員重點關注的問題,因為這直接影響了了解需求的深度和廣度,直接影響了測試用例的編寫實效,以及將來測試執行時的測試粒度和深度。
查找方法:要發現此類問題,同樣可以借助編寫流程圖和狀態遷移圖,同時多思考,多分析,多詢問,多考察,借助所有提交靜態測試的文檔,真正做到“咀嚼需求”,這樣能提示測試質量和測試效果,是事半功倍。
設計遺漏問題
此類問題在各項目靜態測試中所占比重是較小的,但若是有,則是將是高質量的問題。此類問題需要站得高,看得遠,沒有多年的相關業務背景的積淀,和對項目的充分廣泛的涉獵,此類問題是很難發現的。
查找方法:在充分了解業務相關背景的基礎上,憑借業務設計經驗,充分理解了文檔和設計思想后,才能發現其中沒有考慮到的問題。
需求問題
此類問題是以發現目前設計與原始需求相矛盾、相抵觸或者不一致的問題為目的,彌補因某些原因錯寫、漏寫的需求要點,保證設計的完整性、完善性和正確性。
查找方法:綜合前面所有的查找方法。
原文轉自:http://www.uml.org.cn/Test/201208244.asp