測試缺陷處理流程圖
缺陷管理/軟件缺陷管理是在軟件生命周期中識別、管理、溝通任何缺陷的過程(從缺陷的識別到缺陷的解決關(guān)閉)，確保缺陷被跟蹤管理而不丟失。以下是學(xué)習(xí)啦小編為大家整理的關(guān)于測試缺陷處理流程圖，給大家作為參考，歡迎閱讀!
測試缺陷處理流程圖
軟件缺陷
處理方法
通常大家發(fā)現(xiàn)軟件缺陷時會對軟件缺陷進(jìn)行分類，可分類的方式只有一種，就是嚴(yán)重級別,難道沒有其它的分法嗎。比如我們碰到下面這種情況，測試人員發(fā)現(xiàn)有一種功能是必需加入進(jìn)去的，這時他與程序員說，程序員說沒有時間或是不必要，這時這種情況則會形成兩者的扯皮，最終的結(jié)果也就不了了知了，這樣會挫傷測試人員的積極性，下次他們再也不會盡心的考慮產(chǎn)品的問題，只要可以運(yùn)行就可以了。其實這種情況是可以解決的,下面我會提到一個新的軟件缺陷分類概念，從而有效的解決這個問題。
在軟件缺陷中不僅僅只是嚴(yán)重極別，更多的則是功能沒有做到。說到這里也許大家都理解了，就是需求沒有考慮到，可需求不會一次就很完美的，需要大家的共同努力，來不斷的完善。那么怎樣才能讓測試人員提出的好的建議得到有效的執(zhí)行?這就是我下面想說的。在軟件缺陷中還有一種分法，跟據(jù)缺陷內(nèi)容來分，主要分為需求Bug與程序Bug，對于這種分法的好處就是明確了Bug處理的責(zé)任人。對于程序Bug我們都知道是由相關(guān)開發(fā)人員進(jìn)行處理。下面主要討論一下需求Bug，需求Bug從名稱上來看就知道是要交由需求人員進(jìn)行處理?？稍趺刺幚?，怎樣在處理的過程中有效?這時，我們的測試人員將需求Bug不是提交給程序員，而是提交給需求分析人員，由他們進(jìn)行處理。不過這里我想強(qiáng)調(diào)的是對需求Bug的定位，如果這個Bug在軟件需求說明書中明確提到了，這時就不可能定位它為需求Bug，它是必須讓程序員實現(xiàn)的，稱為軟件功能缺陷，提交由程序員進(jìn)行處理。但如果需求說明書沒有明確提到的，我們則可以定位為需求Bug。
優(yōu)點
這樣處理有以下好處，首先需求Bug再不象以前，沒有人進(jìn)行確認(rèn)，需求的處理人員本來就是需求人員，由他們確認(rèn)與跟蹤是最好不過的，因為他們對需求有絕對的權(quán)威。同時測試人員其實就是最早的用戶，他們的需求就是用戶的需求，這種方法加強(qiáng)了需求人員與測試人員的溝通，使需求得到有效的補(bǔ)充，從而讓產(chǎn)品更加完善。還有測試人員從本質(zhì)上來說與程序員還是對立的，這里如果為了這樣一個不是軟件本身問題的問題形成與開發(fā)人員的對立，則會出現(xiàn)贏得戰(zhàn)役而丟失整個戰(zhàn)爭的情況，測試人員協(xié)調(diào)好與開發(fā)人員的關(guān)系，讓他們更有效的對軟件本身的缺陷形成有效的關(guān)注是最好的。還有最為關(guān)鍵的一點，測試人員的激情是最重要的，如果他們的想法沒有得到體現(xiàn)，這時會漸漸的失去對測試的興趣，從而軟件的質(zhì)量則會無法得到保證，通過這種方法可以讓他們看到自己的建議可以通過對需求人員的反映得到實現(xiàn)，讓他們時時覺得自己的想法是可以通過這種方法來有效的推行，這樣工作的積極性才會有保障。
缺陷
不過從實施的角度來說，還是有一定的困難的，首先要讓大家改變以前那種凡是Bug就是由開發(fā)人員負(fù)責(zé)的觀念，其次需求人員的工作量要加大，不過廣泛的了解需求是他們的本份工作，想來不會很困難，還有必需要有有效的Bug管理工具，比如BugManage等等，不要出現(xiàn)那種對需求人員說了，可過兩天就忘的情況出現(xiàn)，這時需求Bug的生命周期會出現(xiàn)跨越兩個軟件開發(fā)周期，因為有些需求會在下一版實現(xiàn)，這時測試人員需要延長對這些需求Bug的管理，不過我想這些需求是他們提出的，會有興趣對這些Bug進(jìn)行管理的。
測試缺陷處理流程圖相關(guān)文章：
1.測試用例流程圖