淺談測試需求分析

奇技指南 本文轉載自Qtest之道,做者:sunny微信

什麼是需求分析

小編理解的需求分析就是要弄清楚用戶須要的是什麼功能,用戶會怎樣使用系統。這樣測試時才能更清楚的知道系統該怎麼樣運行,才能更好的設計測試用例,才能更好的測試。網絡

測試需求分析是測試工做的第一步,通過需求分析,對原始需求列表中列出的每個需求點,找到咱們須要測試的測試要點;針對所肯定的測試要點,分析測試執行時對應的測試方案/方法架構

爲何作需求分析

需求分析的必要性

若是要成功的作一個測試項目,首先必須瞭解測試規模、複雜程度與可能存在的風險,這些都須要經過詳細的測試需求來了解。所謂知己知彼,百戰不殆。測試需求不明確,只會形成獲取的信息不正確,沒法對所測軟件有一個清晰全面的認識,測試計劃就毫無根據可言。性能

測試需求分析越詳細精準,代表對所測軟件的瞭解越深,對所要進行的任務內容就越清晰,就更有把握保證測試的質量與進度。學習

若是把測試活動比做軟件生命週期,測試需求分析就至關於軟件的需求規格,測試策略至關於軟件的架構設計,測試用例至關於軟件的詳細設計,測試執行至關於軟件的編碼過程。只是在測試過程當中,咱們把」軟件」兩個字所有替換成了」測試」。這樣,咱們就明白了整個測試活動的依據來源於測試需求,因此需求分析是整個測試活動必不可少的環節。測試

不作需求分析的後果

不作需求分析或需求分析不到位,可能會產生很嚴重的問題,好比:網站

1.浪費時間和資源實現了用戶不須要的需求; 2.遺漏了需求文檔中沒提到,但很重要的需求,致使客戶滿意度下降。 3.需求分析不到位,錯誤的估計了測試的工做量,致使延誤發佈週期,可能會下降發佈質量。編碼

以上的幾個問題,在實際開發中是比較常見的,主要的緣由就是需求分析不到位,會致使影響客戶的滿意度。架構設計

怎麼作需求分析

經過需求文檔瞭解需求的實現背景

拿到一個需求後,咱們首先應該通讀需求文檔,先經過需求文檔,對要作的需求的背景有總體瞭解,其實這個過程也是對需求文檔測試的過程,對需求總體的瞭解後,咱們能夠先記錄一些疑惑,爲後面需求的分析作準備工做,這個環節咱們應該更多的瞭解一些需求的目的和一些用戶的使用場景。設計

分析需求合理性

能夠經過業務知識來分析需求的合理性,而不是單單經過系統是怎樣實現的來判斷需求是否合理,這也是測試人員必備的技能之一,即須要咱們有深厚的業務功底,而後在經過結合系統現有的實現來分析需求的合理性。

在我看來需求是否合理主要包括兩個方面:第一,知足客戶需求。第二,在系統原有的基礎上,儘可能減小改動成本。

肯定測試的範圍和優先級

經過以上對需求的分析,咱們就能夠肯定測試的範圍和優先級了。首先咱們要肯定好這個需求所涉及的所有測試點,而後經過分析,分析出測試範圍的優先級。

細化測試點並肯定測試方法

肯定了測試範圍和優先級後,就能夠對各模塊進行細化,能夠用xmind列出各個模塊下的測試點,各模塊或大的測試點須要寫出對應的測試方法,或測試策略。是否須要接口測試、性能測試,是否須要提早準備數據,或會遇到什麼樣的測試難點,採起怎樣的應對措施。

肯定哪些工做測試人員能夠提早介入

根據以往的經驗咱們都知道,在開發一個比較複雜的需求的週期中,測試的前期準備工做一般都是比較充足的,固然特殊狀況除外,所以在肯定了測試範圍和優先級後,測試人員和測試負責人應該先肯定一下哪些需求測試是能夠提早介入的,好比,參與開發的概要設計會、提早根據需求編寫case召開用例評審會,在提測前把需求和設計及測試範圍明確,規避了後面的測試的進度風險和質量風險。

查缺補漏

作完了需求的細化後,要對本身作的需求分析從頭至尾再捋一遍,查看有沒有什麼遺漏的,由於需求也可能有遺漏的地方。主要關注有沒有場景需求沒有考慮全面, 涉及的修改範圍被遺漏了,以及一些特殊的關聯配置沒有考慮到的,另外若是需求作了一些變更也要及時補充需求分析,主要是分析變更可能帶來的風險,以及準備哪些應對之策。

如何提升分析能力

熟悉業務,瞭解系統

任何系統都有大的業務背景,只要熟悉了業務知識才能更有效的使用系統。

任何系統在使用過程當中,都有一個熟悉的過程,對系統越熟悉,越容易發現系統問題和業務問題。

用客觀的思考方式站在用戶的角度分析

做爲測試人員若是想提高需求分析能力,首先應該作到的就是站在客戶的角度分析客戶須要什麼和客戶想要什麼,站在業務或者系統現有實現的角度,給需求和開發人員一些設計上的建議,換句話說就是若是拋開客戶,你這個需求作的在高大上,在酷炫,都是沒有意義的。

多思考,不要拘束於慣性思惟

咱們知道一我的作一個工做時間越久,也就是咱們說的經驗越豐富,可能這個思惟方式就會越被限定住。好比,測試的統計表多了,當拿到一個新增的統計表的時候,首先想到的是公用用例上所列的測試點基本上就是最全的了,我都不用思考,直接用就好了。

其實這是一個誤區,公用用例的目的是幫助咱們減小一些沒必要要的內耗,可是咱們的思惟不要被它所限定,若是公用用例中某個點是錯的,那咱們豈不要一錯再錯了。因此做爲一個測試人員若是想要提高本身的需求分析能力,必定要多思考,不要被這種慣性思惟束縛,不要被所謂的經驗束縛。

不要閉門造車,利用好網絡資源

提高需求分析能力,多思考是很是重要的,可是不是讓你傻思考,當你的進步遇到瓶頸的時候,不要閉門造車,作井底之蛙,要充分利用網絡上的學習資源,學習一些前輩的經驗,並把這些運用到實際的需求分析中去。山外青山樓外樓,多瀏覽和關注一些關於需求分析的網站或者微信公衆號,廣開言路,相信會對你的需求分析能力有很是大的提高。

善於總結分享

基於以上四點咱們還要作到善於總結,樂於分享,把常常見到的用例設計的誤區和一些好的需求分析實例,和需求分析習慣分享給周圍的小夥伴,這樣能夠集衆人之所長,不斷提高咱們的需求分析能力。

(360技術原創內容,轉載請務必保留文末二維碼,謝謝~)

關於360技術 360技術是360技術團隊打造的技術分享公衆號,天天推送技術乾貨內容 更多技術信息歡迎關注「360技術」微信公衆號

相關文章
相關標籤/搜索