建立單元測試的基礎(chǔ)
通過自動化創(chuàng)建、執(zhí)行和維護測試的過程，建立單元測試的基礎(chǔ)。只有讓單元測試的工作更容易創(chuàng)建和維護，開發(fā)團隊才會對所有組件采用全項目的單元測試。
避免依賴以UI為中心的晚期周期測試
避免依靠后期周期性的、脆性的、以UI為中心的測試，那只會是耗時和昂貴的診斷和修復(fù)。與其專注于自動化測試所有的手動測試場景，不如投資于單元和API測試的堅實基礎(chǔ)，以確保與UI溝通的架構(gòu)首先是穩(wěn)固的。
理解整個測試金字塔的代碼覆蓋率
了解整個金字塔上下的代碼覆蓋率，以及對需求/用戶故事的可追溯性，因為如果沒有它，開發(fā)團隊就不會真正知道什么已經(jīng)測試過，什么還沒有測試。此外，不了解測試覆蓋率意味著不知道在金字塔的每一個層次上要測試什么，這意味著即使是微小的變化也需要如此多的測試，從而使整個過程陷入僵局。請看我之前關(guān)于基于變更的測試的文章。
用服務(wù)虛擬化左移
利用應(yīng)用依賴性的服務(wù)虛擬化，以便在開發(fā)生命周期的更早階段進行自動API測試。提高自動化程度和更早發(fā)現(xiàn)錯誤是成功的關(guān)鍵。更早推動API測試有助于發(fā)現(xiàn)系統(tǒng)的關(guān)鍵方面，如性能和架構(gòu)的合理性。這也是安全測試的一個重要階段。
利用變更影響分析加速敏捷發(fā)展
在每次構(gòu)建的基礎(chǔ)上，通過變更影響分析加速敏捷開發(fā)，以了解每個新迭代所帶來的風險細節(jié)。變更影響分析提供的分析是使測試只專注于絕對需要測試的內(nèi)容的關(guān)鍵，而不是采用其他方式的救急方法。
推薦閱讀：
本文內(nèi)容不用于商業(yè)目的，如涉及知識產(chǎn)權(quán)問題，請權(quán)利人聯(lián)系SPASVO小編(021-60725088-8054)，我們將立即處理，馬上刪除。
sales@spasvo.com
