BUG漏測的原因總結,以及如何處理

2022-07-10 12:15:15 字數 2493 閱讀 1908

一、漏測的概率

漏測,是指軟體產品的缺陷沒有在測試過程中被發現,而是在版本發布之後,使用者在使用過程中發現存在的缺陷。

二、預防漏測的意義

我們都知道,缺陷越早被發現,發現和解決缺陷所花的成本就越小,如果缺陷是在測試中發現的,那麼所花的成本將小得多。測試

是保證軟體質量的最重要手段之一,因此,進行漏測分析、預防漏測、促使缺陷盡可能在開發過程早期被發現,是非常有意義的,它有

利於降低軟體產品成本、提高軟體產品質量。

三、原因分析

誰都不敢打包票說自己經手測試的東西沒有問題,包括資深的測試工程師,或多或少的會出現讓缺陷從自己的手中溜走,誰也不能

把軟體所有的功能操作、運用場景想周全,但是像神一樣的老鳥我就不知道了。

漏測原因

對應解決方法

1.需求規格不明確,導致測試用例編寫過於粗獷。

1.先進行需求分析,找出需求規格說明書中不明確、或有疑慮的地方,與需求人員(產品)確認商討,給出明確定義。

2.在測試過程中發現沒有明確和有疑惑點的,也要與需求人員確認商討,要求給出明確寫定義,之後完成測試用例。

3.無法及時確定的,可先編寫大概框架,之後再將測試用例細化,補充完善。

2.需求規格變更,測試用例未及時更新

需求規格變更,導致原來的測試用例與現在的規格不相符合。我們在執行測試用例過程中,如果碰到測試用例與規格不相符合的地方,我們需要記錄下,並根據新規格補充完善測試用例,對存在有疑問的地方需要和產品或設計進行溝通和確認,可以要求需求規格進行明確定義,事後將新增的、修改的測試用例整理成文,發給組內同事組織評審,並將評審之後的用例更新到用例庫中去。

3.測試用例覆蓋不全面,場景出現遺漏

因為測試用例場景設計導致缺陷遺漏是在所難免的,編寫測試用例的同事不可能把所有的場景都能想周全,把所有的場景下的  情況都寫成測試用例這也是不大現實的。對於外部反饋的缺陷,是因為場景設計不全引起的,我們先分析出現問題的場景是客戶必須的場景還是偶然的場景,如果該場景是客戶操作習慣,我們可以通過和技術介面人溝通,確認該場景的一些具體細節,在完善測試用例的過程中我們也要考慮一些和該場景相關聯的場景,將多種場景下測試用例及時完善、評審,增加到用例庫中

4.測試過程中未嚴格按照測試用例執行

我們需要面對現實,測試用例並不能覆蓋所有的使用場景,但是,測試用例是按需求根據規格編寫的,經過了需求分析、開發、測試及其他相關人員的評審,最大程度的保證用例的準確性、全面性。測試用例不一定能保證所有的場景和功能點都能覆蓋到,但是嚴格按照測試用例執行測試,能最大程度上保證我們的軟體質量,盡量避免出現缺陷。就一句話,我們在測試過程中要嚴格按照測試用例執行,不要因為測試用例的繁瑣而拋棄測試用例,進行隨意的測試。如果是因為測試過程中隨意的測試,導致出現遺漏問題,實在是不應該。

5.時間不充足,導致一些功能點在測試過程中被忽略

1,根據功能模組劃分測試優先順序,主要的功能模組優先順序最高,安排有經驗的人測試,安排新手測試一些不重要的功能模組或者很少使用的功能模組,在後續測試過程中,由有經驗的同學將新手測試過的模組進行冒煙測試,確認是否有明顯bug;

2,盡量避免在一些和開發扯不清的情況下浪費自己的時間,如果因為開發人員排查問題占用的時間較長,可以告訴測試負責人,由測試負責人採取相應措施,通過協商來避免類似問題蔓延;

3,增加測試人手

4,加班

6.測試環境受限,導致缺陷漏測

1.原因:環境的組合是無窮的,沒有足夠的時間、人力和其他資源成本在足夠在足夠多的環境中測試。

2.措施:保證主要的作業系統環境,網路環境

作業系統:針對當前使用比例來排序

網路環境:正常網速、低網速

7.開發人員引入的新bug

8.對產品和應用流程的理解不到位

驗證開發人員修復的bug,並將相關聯的功能點遍歷到

方法:根據開發人員的水平,選擇合適的回歸測試策略。

四、目的

不管是因為什麼原因導致缺陷流到客戶現場,問題發生了,我們首先要做的就是彌補缺陷帶來的影響,專案組要評估由此帶來的風險、損失,修正缺陷,提供完善的版本給客戶使用。做完前面的這些工作之後,我們可以、甚至是需要自覺的進行思考總結,吸取經驗教訓,並將出問題的這些情況補充、完善到測試用例中去,對一些常見的情況還需要進行組內學習,避免在以後的工作中再次犯下同樣的錯誤。

如果能做的更好一步,我們可以學習並進行統計,對這些遺漏的bug予以分類,缺陷的嚴重程度、所屬功能模組、遺漏原因分類等等。我們在進行缺陷漏測分類活動時,可以由專人組織發起討論,將需求、開發、測試、技術支援以及其他所有產品生命週期中相關部門的代表組織到一起對近期的漏測進行分析討論,特別是技術支援人員能夠提供很多非常詳細的關於漏測缺陷的資訊,這對漏測分類、累積經驗、教訓吸取非常有幫助。

進行缺陷漏測分析的目的是為了促進軟體質量和開發測試過程得到持續改進,使我們在測試過程中可以考慮得更加周全,彌補思維僵局。具體來講,就是通過分析測試過程中漏測的缺陷,採取一些相應的預防措施以避免今後再發生類似的漏測。測試過程的持續改進將提高測試環境的效果和測試執行的效率、降低遺留到使用者處的缺陷數和缺陷解決成本,從而提公升軟體的質量。

五、總結

缺陷漏測是不能杜絕的,缺陷漏測發生後,我們需要學會思考,吸取經驗教訓,盡可能的降低缺陷的漏測量。

移動app測試中出現bug漏測的原因分析

bug 其實是任何產品都無法避免的乙個問題,不是所有的 bug 都能被發現,包括資深測試,或多或少的會出現線上缺陷,誰也不能把軟體所有的功能操作 運用場景想周全。雖說不能做到完全零缺陷,但是每次發布的產品,我們需要追求缺陷越來越少,產品投訴越來越少。為什麼會出現缺陷漏測,主要有以下幾點 需求評審階段...

如何盡可能的避免漏測

在總結線上問題的時候,我們發現大部分的線上問題是由於功能漏測所導致的。原本應該測試的流程沒有測到,或者是根本沒有考慮到一些情況,這些都會產生漏測。在大部分的產品中,漏測是難以避免的,只要不出大問題,漏測的危害會被人為的粉飾和縮小,但是在某些跟貨幣或貨幣等價物打交道的行業,漏測往往意味著經濟損失,一次...

當開發認為不是bug的時如何處理

1 需求不確定 可以找來產品經理進行確認需不需要改動,三方商量確定好後再看要不要改。2 這種情況不可能發生,所以不需要修改 這個時候,我可以先盡可能的說出是bug的依據是什麼?如果被使用者發現或出了問題,會有什麼不良結果?程式設計師可能會給你很多理由,你可以對他的解釋進行反駁。如果還是不行,那我可以...