在測試任何應用之前應該了解的20個軟體測試小竅門

2021-07-03 02:31:47 字數 2271 閱讀 3898

寫這篇文章

我希望所有的測試

人員都能閱讀這些軟體測試

良好的實用內容,仔細閱讀所有條目並嘗試將他們運用到每天的測試

工作學習

到所有這些測試的實用內容,但為什麼不在犯錯之前就來學習這些呢? 以下就是我在經歷中學到的最好的一些測試實用技巧:

1)學會徹底的分析測試結果。不要忽視了測試結果,最終的測試結果或許是「pass」或「fail」,但診斷導致「fail」的原因會引導你發現這個問題的解決方案。乙個不僅僅記錄

了bugs而且提供了解決方案的測試人員是難能可貴的。

2)學會在每次測試任何應用時將測試覆蓋最大化。雖然100%的覆蓋或許是不可能的但你應該試著去接近它。

3)為保證最大化的測試覆蓋需要將應用分割成更小的功能模組。在這樣的單元模組上編寫用例,如果可能的話講這些模組分割成更小的部分。 舉個例子:我們假設你將你的**應用分割成了許多模組,「接收使用者資訊」是其中之一。你可以將使用者資訊填寫頁面分割成更小的部分來編寫

測試用例

:比如叫介面測試、

安全測試

、使用者表單的

功能測試

等等。在輸入框裡測試所有的字元型別、字元長度、無效性測試和有效性測試。寫出所有這樣的測試用例以增大測試覆蓋率。

4)當寫用例的時候,首先要考慮怎麼實現目標功能也就是尋找需求上的有效條件,然後再為無效條件編寫用例。這樣就能覆蓋在應用測試過程中出現的常規和非常規操作。

5)積極思考。要抱著找缺陷的目的去測試,不能一開始就想著應用中沒有任何問題。如果你測試的目的就是在找缺陷你就會很自然的發現一些微妙的缺陷。

6)在需求分析和設計階段編寫用例,這樣你就能保證所有的需求都是可以進行測試的。

7)讓開發在編碼之前就能看到你的用例。不要想著等程式發布時測試可以去提報很多缺陷而讓你的用例一直在你自己手裡。要讓開發完整的分析你的用例去開發有質量的程式。這樣就能節省返工的時間。

8)如果可能話要明確和組織你用來做回歸測試的用例,這會保障手工回歸測試能夠快速有效的進行。

9)對臨界應答時間有要求的應用需要對其進行完全地

效能測試

。效能測試是許多應用測試的重要組成部分。由於缺乏測試所需的大量資料,效能測試在人工測試中多半會被測試人員忽略掉,所以需要找到測試應用效能方法。如果不能手工新增測試資料,最好寫一些基本的指令碼來新增效能測試所需的資料,或讓開發人員幫你寫出來。

10)程式設計師不應測試他們自己的**。像我們之前討論過的,開發人員應該對應用做了充分的基本的

單元測試

後才能給測試人員發布應用新版本。測試人員不能為了進行測試去催促開發人員快點發布新版。要讓他們支配好自己的時間。從領導到專案經理都會知道模組什麼時候發布以及能夠預估處相應的測試時間。這是

敏捷專案的乙個典型情形。

11)進行超出需求範圍的測試。對應用進行超出需求要求的測試。

12)做回歸測試時要運用之前的缺陷概覽圖(缺陷概覽圖---不同模組缺陷發現數目與時間的關係圖)。這種明了的圖表可以很好的**應用哪些部分最容易出問題。

13)記錄下測試過程遇到的術語和概念。在測試應用時也一直開著乙個文件,在裡面記錄測試進度和測試狀況。在準備最後的測試報告時就可以利用文件裡記錄的這些內容。這個好習慣會能幫助你提供完整明了的測試報告和應用發布細節。

14)測試人員或開發人員會對應用**進行多次修改來適應測試。這是開發或測試過程中必要的一步來避免事務有效執行,比如在銀行專案中。要記錄下來為適應測試而修改了**的地方,並且在最終發布的時候確保已經將這些修改的地方從最終客戶端的原始檔裡都改正了。

15)讓開發人員遠離測試環境。這是在發布或部署檔案中檢查配置修改是否遺漏的必要步驟。有時開發人員做了一些系統或應用的配置修改,但是卻忘了部署。如果開發人員沒有許可權訪問測試環境,他們就不會不小心修改了測試環境,而且那些遺漏的地方可以在相應的地方找到。

16)讓測試人員在軟體需求分析和設計階段參與進來是很有用的。這樣測試人員可以對軟體有可靠的認識來保障較好的測試覆蓋率。如果沒有讓你參與這個研發週期,你要請求你的領導或經理允許你的測試團隊參與所有的決策議程。

17)測試團隊應該與其他團隊及他們所在組織機構分享最佳測試實踐、經驗。

18)增加與開發人員的交流來知道更多關於產品的知識。只要有可能就進行面對面溝通來迅速解決問題和避免誤解。並且把你對需求的理解或解決了某些問題,確保同樣也通過書面形式如電子郵件進行溝通。不要任何事都靠語言交流。

19)不要把時間全放在高優先順序的任務上。分析所有任務相關的風險,把你的測試任務按優先順序先後排好然後做出相應的計畫。

20)編寫清晰、描述性強、明了的缺陷報告。不要只提供缺陷現象,也要提供缺陷帶來的影響以及所有可能的解決方法。

不要忘了測試是乙份有創造性和挑戰性的工作。它最終取決於你的技能和經驗,你會如何應對這個挑戰。

在閱讀之前,應該如何思考?

解決問題閱讀 比如某乙個漢字或者英文的讀音或者含義 地圖路線 程式問題 如何科學備孕等等?按照閱讀資訊的性質進行分類 第一種 碎片化資訊 指人們通過網路傳媒了解閱讀非常多的資訊,但卻沒有深刻的理解和記憶,讓自己了解的東西成為過眼雲煙,得到的知識都只是碎片式,不完整,不深刻。比如微博熱搜話題,某位明星...

準備發布應用之前要確保關閉debug屬性

在準備發布應用之前要確保關閉debug屬性,即設定androidmainifest.xml中android debuggable false android debuggable false 但是有時候會忘記關掉這個屬性。所以在發布之前最好進行測試,使用aapt工具 aapt list v a my...

沒有自動化測試的應用應該如何測試?

敏捷推薦圍繞應用建立足夠的單元測試和驗收測試,以構建足夠強壯的測試套件。然而,實際情況是 不是所有的應用都有配套的測試套件。敏捷測試討論組 中有乙個有趣的討論,提到如何為沒有任何自動化測試的應用進行測試,成員們提出了多種方法。asad safari發起了這個討論,他說他的一 個應用沒有任何測試 團隊...