測試這東西(一)

2021-04-12 19:49:48 字數 2609 閱讀 6537

關於測試這東西,玩了四年,仍然沒有摸透它的脾氣。

有人說,測試是為了發現更多的缺陷,也有人說,測試是為了保證產品的質量。都沒錯啊,乙個是從職責的角度來看,乙個是從控制的角度來看。

測試,其實就是乙個驗證的過程,測試人員竭盡所能的折騰一套軟體,看它是否符合客戶要求的標準,是否能經得起折騰,藉以評價產品的***不好。不就是這樣嗎?:-)

常規的測試理論是遵循了v模型中的v&v過程,也就是validation and verification。validation是對客戶需求的驗證,比如通常所說的驗收測試、beta測試。verification指的是軟體過程中每一次確認活動,包括客戶需求確立以後的每一階段關鍵產物的評審與測試。

按照v模型的概念,我們將軟體過程分為了客戶需求、需求規格、概要設計、詳細設計、編碼、系統測試這幾個關鍵的階段。每乙個階段都會有相關的評審與測試,因此,以客戶需求為主要依據的測試,我們稱之為驗收測試,著重於使用者需求的驗證,通常由客戶來做;以需求規格為主要依據的測試,被稱為系統測試,著重於對產品綜合能力的驗證,通常由專業的測試人員來做;以概要設計為依據的測試叫做整合測試,著重於對各級別的介面所進行的驗證,通常會由編碼人員與測試人員一起完成;以詳細設計為依據的測試就成為了單元測試,著重於對**的最小級別進行驗證,通常由編碼人員實現。看到這樣的乙個規則,我們很容易理清,每乙個測試階段,所要測試的物件是不同的,而相應的依據一旦通過了評審,便可以著手進行該項測試的準備。

相對於之前的每乙個關鍵階段而言,測試階段的執行順序剛好相反。編碼階段只能執行單元測試,只有單元測試通過了,才可以對單元與單元之間進行整合,測試它們之間的介面,這被稱之為整合測試。當軟體所有的模組完成之後並且通過了整合測試,那麼就可以進入系統測試階段了。這個時候,測試人員摩拳擦掌,躍躍欲試,不找出bug不罷休。

然而,到底每乙個測試階段的測試工作是怎樣開展的呢?這樣的乙個過程,我們稱之為測試管理過程。每乙個測試階段,都會包括測試計畫、測試設計、測試執行這三部分,有些人會把它劃分得更細,比如獲取測試需求、測試實施、搭建測試環境等。

測試計畫並不是單純的寫乙個時間表,它是當對應的作為測試依據的文件定格之後(通常我們叫做基線化)就開始做的,最主要的目的是要告訴你的專案組成員,你要做什麼(明確測試目的)?對什麼來做(明確測試物件及測試需求)?怎麼做(制定測試策略)?要使用什麼來做(確定測試資源)?何時做(安排測試進度)?需要注意跟控制什麼(估計測試風險,使用規避手段)?

測試設計是要在測試計畫通過了評審之後才做的,主要的產物是測試用例,是將你的測試策略公升級為詳細的步驟,對你確定的測試物件進行驗證,應該要出現的理想結果是什麼。當執行測試的時候,人們依據這份文件,會發現實際的結果與預期的不一樣,於是便把它判定為缺陷。輔助的測試設計產物還包括測試環境的搭建、測試指令碼、測試使用的資料等。關於測試指令碼,是要衡量開發成本與預期收益的,不可以為使用了自動化的測試就是測試高手,這是個極其嚴重的誤區。測試指令碼的目的是要提高你的測試效率,怎樣設計還是依賴於乙個人的測試水平,如果片面的追求程式設計技能,把這認為是測試技能的提高,那麼你不用做測試了,去做開發吧。在單元測試跟整合測試過程中會使用較多的測試指令碼,是因為這些**的復用率極高,幾乎編碼過程中的每天都會執行n遍。而系統測試階段,由於測試重點不同,測試指令碼的復用率也遠遠達不到前兩個階段的效果,自然就更要慎重了。要知道,乙個常規的80/20法則,描述了乙個事實,就是80%的缺陷是手工測試出來的,只有20%的缺陷是使用自動化測試得到的。你花費了兩個月的時間去做了一套測試指令碼,卻只需要執行四五遍,發現的缺陷也寥寥可數,畢竟測試中的很多驗證點是程式無法實現的。那麼,如果使用兩個月的人工測試,收到的效果會是天壤之別。你會選擇哪一種方式呢?

測試執行是在必備的**實現之後才可以做的。拿著文件做設計,卻不在真正的環境中執行,就變成了紙上談兵的趙括。因此,你可以說測試設計是最重要的,我毫不反對,但是,測試執行卻是最關鍵的。只有這個時候,你才能了解軟體的質量如何,存在多少問題,需要怎樣修復。在這時,才是我們經常說的測試階段(單元測試階、整合測試階段、系統測試階段)。測試階段中,缺陷管理變成了重中之重,缺陷的追蹤與控制成為彌補軟體缺陷、控制產品質量的最直接有效的手段。

在測試的每個環節都會產生相應的文件:測試計畫、測試用例、測試報告,這三份文件成為最基本的資源。乙份文件的好壞,關鍵不在於文筆怎樣,而是能否清晰的表達你的意圖,並讓所有的人員能夠了解,使得你所做的工作是可見可控的,不會出現較大的偏差。因此,寫文件不是隨便完成任務那麼簡單,它融入了你全部的思想、你的技能、你的溝通水準,是站在一定的高度上來完成的。即使你是個捉蟲能手,但你不會寫文件,不會把自己的思路清晰的表達出來,這至少能表明你不是個優秀的測試人員。

我絕對不贊同乙個測試新手去寫什麼測試計畫、測試用例。他能把測試報告、缺陷描述寫清楚就不錯了。試想,誰也不是天生的文件高手,必然是經過千錘百鍊、日益積累而成的。先要學會測試,能從測試中找到很多的缺陷,知道測試應該是怎樣一種過程,再開始進行文件的修煉。

我並不認為乙個測試人員一開始寫測試計畫/用例的時候,就能夠根據使用者需求/需求規格/概要設計/模組設計這類的文件,寫出好的東東。畢竟在國內,大多數技術類文件並不是很過關的。因此,我覺得要練習寫,就要從乙個你比較熟悉的已經成形的軟體開始練起。此時你不需要去假想乙個軟體應該是怎樣,而是針對乙個實際的軟體開始操作,記錄你的操作跟你的結果,把它變為你的測試用例。測試計畫更不消說,自然是要在你熟悉這套軟體,知道怎樣去測它的基礎上來完成的。

經過了這樣乙個鍛造,你會明白要怎樣展現自己的思路,在新專案中,根據分析或設計文件,你只要考慮它具體實現的是什麼,然後根據你的測試思想,你的撰寫經驗,來完成乙份較高質量的測試文件。

雜談測試這東西

關於軟體測試這東西,玩了四年,仍然沒有摸透它的脾氣。有人說,軟體測試是為了發現更多的缺陷,也有人說,軟體測試是為了保證產品的質量。都沒錯啊,乙個是從職責的角度來看,乙個是從控制的角度來看。軟體測試,其實就是乙個驗證的過程,軟體測試人員竭盡所能的折騰一套軟體,看它是否符合客戶要求的標準,是否能經得起折...

雜談測試這東西

關於軟體測試這東西,玩了四年,仍然沒有摸透它的脾氣。有人說,軟體測試是為了發現更多的缺陷,也有人說,軟體測試是為了保證產品的質量。都沒錯啊,乙個是從職責的角度來看,乙個是從控制的角度來看。軟體測試,其實就是乙個驗證的過程,軟體測試人員竭盡所能的折騰一套軟體,看它是否符合客戶要求的標準,是否能經得起折...

組長這東西

我是這專案的組長,第一次幹這活,問題有是很正常滴.專案的每乙個階段,基本上是按軟體工程的意思來辦的,這也是為了公司的文件化管理做個開始.首先說分任務吧,分的不好下面又難完成,輕鬆了上面又不好交代,那完成的結果也沒有乙個標準 怎麼辦?好了,既然沒有標準,但問題總得解決吧,那就是溝通咯,這不 我的死肋就...