日期:2017年2月22日
功能測試評論的每一個方麵的軟件,確保它是有效的(即函數)正確。很簡單,功能測試看著軟件應該做什麼,確保它確實。所以當功能測試查看應用程序的執行能力,非功能性測試觀察其整體性能(如。通過測試的可伸縮性、可靠性、安全性和兼容性)。
進行功能測試時,您通常需要遵循這一過程是這樣的:
- 使用測試數據來識別輸入
- 確定預期結果應該基於這些輸入
- 運行測試用例與適當的輸入
- 預期結果與實際結果進行比較
這個方法後,如果預期結果和實際結果匹配,你可以得出這樣的結論:軟件功能正確,測試已通過。如果他們不匹配(假設你正確理解結果應該和使用正確的輸入),然後用該軟件有一個問題。
常見的功能測試包括:
- 單元測試:測試單個單元的軟件以確保它適當地執行。
- 集成測試:需要多個獨立單元的軟件和測試他們作為一個群體,以確保適當的互動。
- 煙霧測試:測試軟件的主要部分不全麵的方式,以確保足夠先進的軟件(或不是充斥著太多的問題)繼續進行額外的測試。
- 回歸測試:測試代碼更改沒有負麵影響的功能軟件。
- 完整性測試:測試軟件的主要部分不全麵地進行代碼更改,確保更改之後沒有產生任何嚴重問題。就像冒煙測試寬,淺視圖和單元測試的更深入的觀點,完整性測試寬,淺視圖後新構建和回歸測試的更深入的觀點。
- 用戶驗收測試:通常軟件上線前最後一步,用戶驗收測試確保軟件符合用戶需求。最終用戶一般在測試期間執行這些測試。
除了確認正確應用程序功能的主要領域,這些測試也旨在審查軟件的可用性和可訪問性以及當發生錯誤。
用例,技巧和最佳實踐最受歡迎的功能測試類型
不管什麼類型的功能測試你跑步,有幾種不同的方法可以用來執行這些測試和組織你的工作。來幫助你開始,我們列出了五個最受歡迎的功能測試方法,包括它們是什麼,何時使用他們,做他們的技巧和最佳實踐。
手動腳本測試
- 手動腳本測試是什麼?
- 當你會使用手動腳本測試麼?
似乎是一個理想選擇放棄手工測試的自動化,但並不是所有的測試可以自動化。我們仍然需要在各種情況下手動測試。時一些常見的例子有意義的手工測試的方法包括當你處理遺留係統不容易支持自動化,當您需要遵守嚴格的規定和要求的文檔作為結果,當你需要運行複雜的測試。這最後一點複雜性是開放式的,但這個想法是在處理複雜的測試用例時,有一個人在方向盤可以更容易和更容易發現問題。一般來說,手工測試是更好的在這種情況下,你需要密切模仿真實世界的場景。
手動腳本測試最佳實踐、提示和技巧
- 編寫可重用的測試用例(然後重用它們!):開發測試用例需要時間,所以更多的可重用你可以測試用例,更好的(隻要你記住重用他們在適當的時候)。編寫可重用的測試用例,確保你用簡單的語言,很容易理解,測試步驟短,容易執行。然後,在適當的時候幫助重用測試用例而不是每次重新發明輪子,一定要保持組織的管理你的測試用例就像一個單一來源的真理測試用例管理工具。
- 設計測試由測試數據和配置:依賴於測試數據和配置開發測試步驟將確保你有一切你需要完成測試並完全理解結果。例如,你需要確保你有正確的登錄憑證,以便您可以訪問所有的功能你應該測試,確保你有正確的輸入數據,因為這將影響測試通過或失敗。最終,你需要密切關注測試數據和配置的每一步,因為這些細節也很重要當通知開發人員和產品負責人關於問題和幫助他們理解這些問題的根源。
- 優先級高的風險和複雜的測試用例:你不能有100%的測試覆蓋率結合耗時的手工測試的性質使得它必須優先考慮你的測試用例。手工測試時,需要優先考慮高風險和複雜的測試用例,這些是那些最需要一個人在方向盤上。
- 考慮到自動化的機會(不出船外):雖然你不應該你所有的自動化測試,你應該尋找機會去擁抱自動化為了節省時間和更容易經常運行某些測試(特別是測試變得更加集成在整個軟件開發過程)。記得帶上一個自動化的第一種方法考慮測試時最好手動執行,哪些是適合使用自動化測試。您還應該記住的複雜性。在高度複雜的測試用例應該保持手冊,簡單的煙霧測試自動化可以添加重要的價值。
- 不要忽略文檔的重要性:文檔是手動測試的關鍵,特別是通過報告跟蹤問題。幫助他人的好報告至關重要的團隊(測試人員和開發人員)理解存在哪些問題以及如何找到他們。寫一個強大的報告,你需要一個簡單的標題,明確問題,有序列表的步驟重新創建的問題很容易理解和遵循,細節問題的嚴重性和優先級,和洞察力應該發生什麼,如果問題得到解決。
探索性測試
探索性測試是什麼?
探索性測試是一種定時的方法中,測試人員製定了一定的時間去“探索”軟件。雖然這也是一種手工測試,探索性測試偏離了一個嚴格的工作流程的規劃、設計和執行測試用例的步驟。在這次會議期間,測試的目的是了解軟件是如何運作和識別不同的測試運行基於理解。因為探索性測試不是照本宣科,通常反映在現實生活中用戶將如何與軟件交互。
這種測試方法是互補的上下文驅動的測試,認為沒有“一個最好的方式”進行測試。相反,它認為,測試需要處理不同的基於上下文的每個項目將使用的軟件。探索性測試補充上下文驅動的測試因為考慮到每個軟件的唯一性,而不是支持標準的、放之四海而皆準的測試方法。
你什麼時候應該使用探索性測試?
最好的實例,使用探索性測試包括那些當你下一個時間限製,因為他們需要最少的準備和允許快速反饋,那些沒有任何規範的開發人員時,那些在你需要幫助的時候決定什麼類型的測試運行,而當你想要進行一次良心全方位測試,以確保你沒有錯過什麼時候執行以前的測試。
探索性測試最佳實踐、提示和技巧
- 總是包括探索性測試:不管你計劃使用其他測試方法對於一個給定的項目,你應該總是包括探索性測試。這種包容的探索性測試可以幫助你確定哪些其他測試可能需要運行或使用哪個方法最意義,可以作為很好的檢查你的測試結果已經執行的狀態。最重要的是,你可以在任何階段插入探索性測試項目的(甚至多個階段)。
- 開發一個明確的章程:你需要製定一個明確的憲章每個會話你進行探索性測試。這個憲章應該包括一個使命陳述,你測試的列表區域,所有參與測試人員的名字,會議的日期和時間,任務的列表(包括時間、數量的測試設計和執行和缺陷調查和報道的數量),記錄測試活動和細節在任何你發現的錯誤和問題。一個探索性測試和文檔工具像Tricentis qt可以使這個過程更簡單和更有效率。
- 監控你的時間:因為探索性測試定時,監視你的時間是很重要的。特別地,您應該跟蹤你的時間創建測試和執行測試,發現錯誤和報告bug和建立會話。但也許最重要的是實際的時間花在一個探索性測試會話和你計劃的時間花在一個探索性測試會話。總的來說,這些比較可以幫助您確定多少測試一個軟件可能需要以及哪些地區最需要測試的軟件。
- 探索性測試優先於低價值腳本測試:如果你運行腳本測試,提供幾乎沒有價值,這是一個明確的信號切換到一個探索性模型。探索性測試可以幫助你正確的課程同樣的時間導致更多的價值通過幫助您確定一個新的測試策略,將發現的問題和導致更高質量的最終產品。探索性測試和低價值時腳本測試,每次都是前者獲勝,因為它可以呼吸新想法更緊密地模仿現實世界的用戶體驗和刪除預定所帶來的局限性,腳本測試。
- 使文檔你最好的朋友:探索性測試應該是不同的每一次你這麼做,但這並不意味著你不能從過去工作,什麼沒有。雖然你采取實際行動在不同會話會有所不同,你的高水平的方法肯定可以類似的一次又一次。要理解什麼可行,什麼不,您需要讓文檔你最好的朋友。你可以在憲章通過詳細說明你所做的,你怎麼做到的,你發現為了確定你的努力的整體有效性。作為獎勵,你有更多細節,清晰的路線圖概述時你會有下一步基於探索性會話。
UI /自動化測試
UI /自動化測試是什麼?
UI /自動化測試的行為進行具體測試通過自動化手動(而不是進行)。雖然是真的,當你運行一個測試通過它將運行在自己的自動化,自動化測試不僅是“設置它,忘記它。“自動化,需要開發和維護測試腳本的源代碼,包括更新代碼更新應用程序。此外,你不能僅僅依賴於自動化測試工具,因為你需要的技能的人來操作這些工具和維護源代碼。大家都說,自動化可以幫助你更快地運行測試和自動基於某些條件得到滿足。
自動化可以幫助你更快地運行測試和自動基於某些條件得到滿足。
你什麼時候應該使用UI /自動化測試?
人們很容易嚐試使用你所有的測試自動化的需求,但這樣做將是一個錯誤。例如,太多的自動化測試會導致維護挑戰當試圖跟上改變源代碼的需要。這也意味著你失去了人類方麵的測試,這是至關重要的在真實的場景中捕捉缺陷。正如邁克爾·波頓所說,自動化是更多關於檢查或確認的東西是真的比測試或識別未預料到的問題。
有鑒於此,場景最適合UI /自動化測試包括高風險的場景,需要一個簡單的煙霧測試(如確認用戶登錄瀏覽),簡單的測試,你需要經常運行(自動化可以提高效率)和測試,由於人為錯誤經常失敗。如果你不確定如何自動化,運行一個探索性測試會話可以幫助你做出更明智的決策。雖然不能達到100%的自動化測試,自動化的實例的數量是有意義的使用可能會增加你搬到一個連續的測試模型,因為這種模型需要更多的測試來完成整個開發周期。
UI /自動化測試最佳實踐、提示和技巧
- 早期經常測試,尤其是在高風險的情況下:自動化測試最大的好處之一是能夠快速重複地執行測試沒有手動工作。重要的是要利用這個好處通過運行自動化測試早期(盡快發現問題),通常(盡快發現問題他們出現)。這種“早期經常測試”的心態在高風險的情況下尤為重要,更早、更多的定期測試,更好的位置你會趕上和減輕風險潛在的破壞性的問題。
- 優先考慮維護和追求可持續的源代碼:自動化測試隻是一樣好它的源代碼,和源代碼往往需要定期維護。具體地說,您通常需要更新源代碼開發人員對應用程序進行更改,因為每次的源代碼需要反映這些變化或測試執行時將產生不準確的結果。因此,您需要優先考慮維護。說,你應該讓你的源代碼盡可能可持續,所以你需要做出的改變與應用程序更新將是很小的。即使有一個可持續發展的方法,記住,你仍然需要重新審視每次更新軟件的源代碼。
- 考慮為您的需求的最佳工具(但要記住你的人!):當選擇一個自動化測試工具,考慮您的需求開發語言,操作係統和平台以及每個工具的功能創建功能豐富的測試。工具選擇時是絕對重要的自動化測試,但也不是唯一重要的拚圖的——也將開發自動化測試的人。因此,你還需要考慮易於測試和管理源代碼在工具和你的團隊的相關技能。您可以了解更多關於軟件測試工具,包括最受歡迎的自動化工具,在這裏。
- 定期評估結果,以避免運行低價值測試:隻是因為你可以快速而方便地運行測試如果是自動的,並不意味著你應該這麼做。因為自動化測試的形式仍然需要努力維護源代碼。因此,您需要您的自動化測試的結果進行分析,以確定如果你運行測試不提供任何價值,比如那些經常錯過以後問題表麵或那些通過100%的時間(這可能意味著你不需要測試期間,除非它是一個高風險的情況)。如果你確定低價值測試,你需要決定如果你應該改變測試,改變的方法(如通過手動方法相反),或完全消除測試。
- 認識到自動化測試的局限性:所有自動化帶來的好處,並不是全部進行測試。事實上,即使你可以自動化所有的測試,你不想這樣做,因為自動化有其局限性。很簡單,在一些實例中,您需要一個人類的視角。例如,使用UI測試自動化可以確定如果一個元素呈現,但隻有人類才能確定它出現在正確的地方和看起來不錯。一般來說,自動化測試不反映用戶的經驗,所以你需要記住你的測試用例的目標在決定是否采取一個自動化的方法。
行為驅動開發(BDD)測試
什麼是BDD測試?
行為驅動開發是一個測試優先的方法,測試驅動開發(TDD)的一個子集。BDD鼓勵所有利益相關者之間的合作——測試人員,開發人員,產品所有者,等等——刪除這些不同群體之間的筒倉經常創建一個“破碎的電話”場景,在該場景中,開發人員必須將要求從產品所有者,測試人員必須翻譯要求從開發人員等等。通過將每個人都在一起,BDD”創建一個共同的理解和表麵的不確定性,根據其創始人丹北。換句話說,它可以讓每個人都在同一頁中,讓每一方更容易問一些商業案例的根源,最終幫助大家共同努力,創造一個更好的最終產品滿足用戶的需要。BDD的最終結果是需求中定義簡明英語和場景,通常遵循Given-When-Then格式,測試人員和開發人員可以使用在確定測試需求。一般來說,BDD是一個更加方法,提供高水平的效率和有效性時用戶體驗測試。
你什麼時候應該使用BDD測試?
你應該采用BDD方法編寫測試和規範。BDD是最有幫助的單元測試時,通常需要改變乏味每次軟件更新。BDD可以簡化這個過程,因為它需要測試基於行為,不是基於代碼。
BDD測試最佳實踐、提示和技巧
- 讓你的場景聲明(不是必須):寫作場景聲明格式而不是命令式的格式會導致更好的模擬用戶的角度簡單場景。例如,聲明式場景做一個網上購物可以寫成:
我在我的購物車
當我把我的訂單
然後我應該看到一個訂單確認
命令式的版本的場景會寫成:
我在我的購物車
當我點擊“我的訂單”按鈕
我填寫我的賬單信息
我填寫我的航運信息
我點擊“提交訂單”按鈕
然後我應該看到一個訂單確認
正如這些例子所演示的,聲明版本是更簡單、更容易理解和維護,對用戶的角度來看,沒有一個程序員。
- 理解小黃瓜的語法:的小黃瓜語法Given-When-Then場景中使用的(如上圖)BDD測試是至關重要的。這個語法應該描述上下文(給),行動(時),結果(然後)。這個語法是很重要的,每一項物品的順序出現。放棄一個項目或者將他們的訂單可以改變整個語法意義和負麵影響未來的測試和開發工作。
- 寫作時要注意步驟定義:使用BDD,您需要編寫步驟定義,將你的小黃瓜場景轉化為操作係統將在測試期間。當你開發步驟,你應該寫獨特的定義,以避免問題的係統並不知道哪一步是這場比賽對於一個給定的場景。您還應該確保隻包括一個行動,每一步每一步有一個動作使它更有可能的是,您可以重用步驟在場景。
- 回收你的步驟:如果你用心在寫步驟定義和編寫可重用性,那麼你也應該盡可能多回收你的步驟。回收步驟不僅可以節省時間和精力與創造新的步驟,但它同樣也簡化了維護,任何時候你需要更改一次步驟你可以改變它,改變應用跨多個場景。
- 不要忽視和興趣協作的重要性:許多測試人員和開發人員忽略了合作的重要性或失敗來衡量對方的合作興趣。當這種情況發生時,最終的結果受到損害。無論你是一名開發人員,測試人員,或在其他任何角色,你們都在同一個團隊和有相同的最終目標:交付高質量的軟件,終端用戶解決問題。和協作是實現這一目標的關鍵,在任何情況下,特別是當BDD測試方法。
基於風險的測試
基於風險的測試是什麼?
基於風險的測試是一個組織的方法,重視高危地區的測試軟件。它聲稱,高危地區需要經常測試,有一個高水平的測試覆蓋率,以減輕風險。
你什麼時候應該使用基於風險的測試?
基於風險的測試麵臨時最好使用時間,預算和/或資源限製。你可以確定哪些領域的軟件在許多方麵是高風險的。例如,風險可能是由於高的影響(如。如果一個問題會影響到90%的用戶),敏感信息的存在(如。如果用戶需要共享的信用卡信息或個人身份信息),或一個高水平的複雜性。
基於風險的測試最佳實踐、提示和技巧
- 評估風險在項目級別:為了正確理解所有的潛在風險的一個軟件,你需要評估風險在項目級別來更全麵的了解。這個項目級別的評估應該包括從測試人員和開發人員業務涉眾和應該大綱有什麼潛在的風險,這些風險的影響,計劃測試和減輕風險,可能的原因為每個風險,和一個應急計劃。承擔這個風險評估應該幫助你正確範圍測試需求,並提供每一個人都參與明確的潛在風險,以及它如何會減少。
- 開發一個應急計劃:盡管基於風險的測試的目標是減輕潛在風險,特別重視最有效的風險,有時事情成為漏網之魚。是否你錯過了在測試過程中潛在的風險,這個問題沒有妥善解決,或者別的,它總是重要的應急計劃,貴公司需要采取什麼行動應該任何高風險問題實現。
- 識別風險與啟發式的方法:詹姆斯·巴赫建議采取風險識別的啟發式方法。這種方法需要你與開發人員和測試人員坐下來問潛在風險的開發人員審查的軟件是如何工作的。這樣做可以讓你源直接或問根據需要跟進的問題。在這些討論中,你應該問潛在的弱點和漏洞,威脅和失敗的受害者。你可以把這種啟發式方法進一步通過與產品負責人經曆相同的過程,利益相關者,甚至最終用戶。擴展你的問題這些團體會畫一個更完整的圖片和幫助確定哪些開發人員沒有意識到風險。
- 優先考慮風險使用統計分析:優先考慮風險的最佳方法是使用一個統計分析,重特定風險和影響的嚴重程度會發生的概率。影響的嚴重程度而言,你應該考慮問題的臨界(例如不安全的信用卡數據遠比一個登錄故障更為重要),它的可見性,包括用戶的數量將遇到的問題(例如,它是一個問題在登錄,用戶很可能遇到或一個問題在一些深頁麵,用戶不太可能訪問),和用戶的數量會影響(例如,它適用於所有用戶或用戶隻有一小部分)。當你考慮影響的嚴重程度,你可以在一個滑動規模等級風險從批判到可以忽略不計。在概率方麵,你應該考慮失敗的可能性。當你考慮概率時,你可以在一個滑動規模等級風險不可避免的可能。
- 定期監控風險:軟件和終端用戶/環境變化,也將相關的風險。因此,重要的是要定期監控風險,以確定臨界狀態的變化(由於變化影響的嚴重性或概率)和確定新的風險和/或風險的誘因。就像最初的風險評估,持續監測應在項目水平和測試團隊以外的涉及到利益相關者為了描述最全麵的潛在風險。
交付的軟件體驗用戶期望堅如磐石的測試
今天的用戶技術:他們使用軟件幾乎在日常生活的方方麵麵,他們有很高的期望這個軟件如何工作以幫助他們日常需要更好,更聰明,速度更快。由於這些高期望,軟件測試變得越來越重要,與整個軟件開發過程交織在一起。
就像酒吧已提高了軟件測試的實踐,這也是提高軟件測試人員,他們現在比以往任何時候都更具戰略性團隊的一部分。這些變化為軟件測試人員創造了無限的機會,但利用這些機會都始於建立一個堅實的基礎的技能,包括開發一個深刻理解的各種測試方法,掌握它們的執行。
如果您已經準備好構建基金會通過學習更多關於軟件測試的來龍去脈,Tricentis有你覆蓋。
我們將幫你保持脈衝在所有測試通過我們的東西:
日期:2017年2月22日
