點評「現代軟體測試原則」盤點

2021-10-17 02:06:13 字數 3536 閱讀 2368

我之前也梳理過很多測試方面的原則,可以概括為十大測試原則:

測試目標要明確,並建立合理的階段性目標

一切從客戶/使用者的角度出發,想客戶所想

測試盡早介入,一旦專案啟動,測試就要介入進去。

盡可能確保軟體的可測試性

持續地測試、持續地反饋,最大程度地降低研發成本,提高研發效率

測試時不能窮盡的,應設定合理的測試目標或測試終止的條件

基於專案的上下文來制定相應的測試策略

基於風險的測試策略總是有效的

測試計畫不僅是文件,更是乙個過程,應根據測試狀態不斷變化而進行調整

80/20原則,發現錯誤越多的地方,越要投入更多的測試資源或進行更深入的測試

所謂現代測試原則,是適應敏捷開發模式的 (人們往往把敏捷開發看成是現代開發模式) ,而不適合傳統開發模式的。從敏捷開發目標看,就是要做到快速交付、持續交付。作為測試,就是如何助開發一臂之力,實現高質量的持續交付。alan page和brent jensen(簡稱:ab)認為「 在敏捷開發中,測試人員可以開始從質量所有者轉變為可交付質量的大使,提供價值,並改善團隊的質量文化 」。這種提法值得商榷:

在傳統開發中,測試人員也不應該是質量的所有者 。質量一定是整個團隊和公司管理者共同擁有,而且測試人員也不是質量的管理者,因為有質量管理人員或質量保證人員(qa),甚至不是質量改進的最主要的驅動者 (團隊的每乙個都應該是質量的驅動者) ,因為還有工程過程組(sepg)。雖然上線後漏掉缺陷,有些公司第乙個責怪的人會是測試人員。即使在傳統的公司中,這樣做的公司也算是比較落後的公司,不能把落後的公司的實踐算在傳統測試的頭上。如果要問責,也是要把開發人員和測試人員一塊叫過來,看看問題究竟出在**。

大使,有全權代表的含義,也有形象代言人的含義, 這裡是指:敏捷 測試人員作為質量的代言人還是作為全權代表? 感覺都不對,這樣是不是回到老路上去,而且把測試的責任搞含糊了。 測試人員就是不斷暴露軟體產品的質量風險,不斷發現問題,及時反饋給團隊,幫助團隊持續提公升質量 。

感覺ab的出發點就錯了。那我們再看看這七項現代測試原則有什麼新東西?是不是真正能成為敏捷測試的原則?

1.我們的首要任務是改善業務

ab認為 :現代測試人員,熱衷於提高效率,並希望加快發布流程,更快地為客戶提供價值。強調為團隊增添價值,應用於功能團隊的良好測試思維是增值,而非成本,因為過去人們往往把測試看作是成本中心。這種價值可以通過資料來驅動,表示為客戶所熟悉的一些指標。

點評 :不僅是測試,開發也一樣,都是為業務服務的,業務驅動開發、業務驅動測試,甚至我們說: 不以業務敏捷的敏捷都是偽敏捷 。從這一點看,這條原則沒錯。但是,這條原則適合傳統的開發,而不侷限於敏捷方法; 也適合整個敏捷團隊, 而 不侷限於測試人員。其次,ab的解釋,並沒有真正觸及到「業務為先的測試」、「業務驅動測試」的實質,即如何明確表達「業務驅動測試的準則」。

2.我們加速團隊,並使用精益思維和約束理論等模型來幫助識別、排序和緩解系統的瓶頸。

ab認為 :測試人員做較少的測試,更多是驅動質量的提公升,指導開發人員設計小規模的測試( 這來自google公司對測試的劃分:小規模、中等規模、大規模的測試,而不是我們通常說的單元測試、系統測試、驗收測試) ,讓開發人員做更多測試。測試人員負責那些大規模的測試。通過單項工作的結對體驗 (如結對程式設計、結對測試) ,團隊可以在**中找到更多缺陷,並更快地培育質量。

(不急,先了解兩個知識點)

補充知識點: 精益思想 (正好也是7項原則) 1) 尊重一線人員 。工作在一線的人最了解實際情況,能制定更好的應對措施,更有能力提出正確的改進意見; 2) 消除浪費 。任何不能為客戶增加價值的行為即是浪費,為了消除浪費,必須以價值流來識別浪費,並指出浪費的根源並消除它,識別和消除浪費的過程是持續不斷的; 3) 增強學習 。軟體開發是持續學習的過程,從而能夠面對各種挑戰; 4) 盡量延遲決定 。直到能夠基於事實而非不確定的假定和**來做出決定,因為系統越來越複雜,軟體開發中存在更多的不確定性; 5) 構建質量 。如果從研發的各個階段(需求、設計、程式設計等)都能保證產出物的質量,我們就能以最低的成本達到產品的質量目標,即最大程度地減少浪費; 6) 快速交付 。只有將產品交付給使用者,才產生價值。交付越快,產生價值越早; 7) 整體優化 。區域性的優化,若不能帶來整體的改善,將是沒有價值的。

補充知識點: 約束理論

約束即阻礙企業有效擴大產出能力、降低庫存和執行成本的環節,即任何乙個多階段生產系統,如果其中乙個階段的產出取決於前面乙個或幾個階段的產出, 那麼產出率最低的階段決定著整個系統的生產能力 。 約束理論是企業識別並消除在實現目標過程中存在的制約因素(即約束)的管理理念和原則 ,主要操作過程是:

1)找出系統中存在哪些約束(來自原料、能力、流程、市場等方面的約束); 2)最大限度利用瓶頸,即提高瓶頸利用率; 3)使企業的所有其他活動服從第二步中提出的各種措施; 4)打破瓶頸,即設法解決第一步中找出的瓶頸;

5)重返第一步,持續改善。

3.測試人員是持續改進的力量,幫助團隊適應和優化以獲得成功,而不是提供安全網來捕捉失效。

ab認為 :隨著逐步將更多**密集型測試任務轉移給開發人員,並讓測試人員指導和領導測試工作,團隊專案的質量得到提高。測試人員不再被視為最後一道質量防線,而成為「設法留住客戶、讓客戶使用應用程式」的第一道攻擊線。

點評 :讓測試人員變被動為主動,幫助團隊持續改進,從而不斷提公升構建的質量,這挺好。從本質上講, 這種任務 是真正sqa人員或管理人員所承擔的責任,只是許多公司sqa人員是缺失的,管理人員也不夠關注質量,結果就讓測試人員來承擔了。但這種原則更應歸為質量文化建設、質量管理的原則,而不能算測試原則。就像前面說的,ab把測試人員當作質量大使,所以讓測試人員更關注 質量文化建設 的建設,從這個角度看,也沒錯。

4.非常關注團隊的質量文化,我們指導、領導和培養團隊,以建立更成熟的質量文化。

ab認為 :建立代替孤立的測試人員的社群,這對於發展成熟的質量文化很重要。借助協作和創新,社群成員與其他成員建立共鳴,並能推進專案的成長和新想法。

點評 :這也是質量文化,不是測試,但具體的實踐——「在企業內部建立社群」挺好。我之前演講或企業內訓中也提過, 當實實在在的測試部門不存在時,我們可以建立虛擬的測試部門——測試社群 。這在一些公司(如cisco)都有類似的實踐。

5.相信: 唯一能夠判斷和評估我們產品質量是客戶。

ab認為 :現代測試實踐中,客戶的反饋是非常重要的。收集客戶反饋,直接或間接地從客戶那裡收集資料,使團隊能夠最好地判斷客戶是如何響應功能的。

6.廣泛使用資料來深入了解客戶使用情況,然後縮小產品假設和業務影響之間的差距。

點評 :這是第1原則、第5原則的延伸,要客觀地獲得使用者的反饋,客戶使用產品的資料是關鍵的資訊**。如何基於這些資料,構建測試模型或幫助我們建立test oracle,需要具體的方法和工具來支援。

7.擴充套件整個團隊的測試能力和專業知識;了解這可能會減少(或消除)對專業測試專家的需求。

ab認為 :「我是否需要辭掉工作並成為開發人員?」不,專注於自己的測試使命,如引領質量文化、尋找改進、投入到測試工具的使用並獲取知識以更好地幫助業務等。

點評 :當測試人員指導開發人員做測試,可能會擔心革了自己的命,所以才有開頭那一問。 如果對測試有信心、對自己有 信心 ,就沒有這種擔心 ,否則做一些改變,「成為開發人員」也不失為明智的選擇。乙個工程師,能做開發工作也能做測試工作,自然在職場上更具競爭力,只是在「開發」和「測試」中,我們還是有自己更擅長的一面。

軟體測試原則

1.測試證明軟體存在缺陷 無論執行什麼樣的測試操作都能證明當前軟體是有缺陷的 2.不能執行窮盡測試 有些功能是沒有辦法將所有的測試情況都邏輯出來,所以任何的測試操作都有結束的時間 3.缺陷存在群集現象 對於軟體功能說,核心功能佔20 非核心80 在實際工作中我們會集中測試20 的核心功能,所以這個部...

軟體測試原則

軟體測試規範 zero bug和good enough 對於相對複雜的產品或系統來說,沒有bug是不可能的,我們只能想方設法把軟體的bug數控制在可以忍受的範圍內 good enough 原則就是一種權衡投入 產出的原則 不充分的測試時不負責任的,過分的測試是一種資源的浪費 不要窮舉測試 窮舉測試指...

軟體測試基礎 軟體測試的原則

所有的軟體測試都應該追溯到使用者需求。即應該重視需求文件,明確最初的需求才能盡可能減少後期的錯誤 盡早啟動測試工作,盡可能早地發現問題。問題越是遺留到後面修改的成本越大 pareto法則適用於軟體測試,又稱28效率法則,即早期應該能夠發現大量的問題 窮盡測試是不可能的,應當做適當的風險分析 殺蟲劑免...