20年研發管理經驗談(十一)

20年研發管理經驗談(十一)

本文繼20年研發管理經驗談(十)。

此文是對我個人測試思想的一個總結,由於經驗不夠,知識淺薄,如果有什麼不合理的地方請一笑了之。

一、面向對象的概念
  所謂的面向對象是軟件開發的一種重要的思維方式,是把軟件開發過程中出現的事物,用一個個的對像來分析.一般一張數據表可以封裝為一個對像。用個形象的比喻:我們現在要做一張桌子,首先我們考慮到的是我們要做的是什麼?是桌子;桌子是用來干什麼的呢?是用來吃飯、喝茶、看書、打麻將的;然後就要考慮桌子由哪些部分組成?由桌面和桌腿來組成;接着我們需要考慮我們採用什麼材料呢?紙?不行…那可什麼都幹不成,OK,用木頭;接着就可以開始把組成桌子的組件做為對象開始分析–桌面如何做是用刀砍的還是用刨子刨呢?桌腿又如何做…
  一套完整的方法成形了就可以具體實現了,在做的過程中桌面要做多大,桌腿要做多長都要事先考慮到是不是要留出接口,這些就是我們給組成桌子的組件賦予的屬性。OK,現在可以做出具體的實物了,做好實物組件(對象)以後就要將做好的桌面桌腿進行組裝,由於我們事先考慮好了組件的屬性,考慮到了必須預留接口,因此我們可以很輕易的組合成功,桌子做出來了。以上就是面向對象的思想的一個簡要的比喻

  了解面向對象必須了解的幾個名詞:對象、方法、屬性、繼承、多態。

 

二、遊戲測試
  遊戲測試是整個軟件測試行業中比較特殊的一部份,他有着大多數軟件測試的共性,也具備自身的特性,而相對於許多通用軟件的測試來說,遊戲測試所具備的特性是非常明顯的。現在就簡要的說說上面提到的共性和特性。
共性:
1、測試的目的就是為了盡可能的發現軟件存在和潛在的問題。
2、測試都是需要測試人員按照產品行為描述來實施。產品行為描述可以是書面的規格說明書、需求文檔、產品文件、或是用戶手冊、源代碼、或是工作的可執行程序。
3、每一種測試都需要產品運行於真實的或是模擬環境之下。
4、每一種測試都要求以系統方法展示產品功能, 以證明測試結果是否有效, 以及發現其中出錯的原因, 從而讓程序人員進行改進。
總之,軟件測試就是對產品進行盡可能的全面檢查,盡可能的發掘bug,提高軟件質量,從而為企業創造利潤。

特性:
  網絡遊戲世界從某種意義上說是另一個人類社會,只是人們在網絡遊戲世界中進行着在被允許的範圍內的活動,包括了修鍊、交流、合作、經商、欺詐、情感、衝突等等。而在遊戲製作時這些進行這些行為的部分就是一個個完整的功能,我們在進行測試的時候,需要考慮的不僅僅是能否實現功能,要考慮更多的是人們在進行操作時會如何做,可能有多少種做法,這些做法應該有什麼樣的響應,哪些做法是被禁止的,在進行了被禁止的操作后應該有什麼的響應。因此這裏就是涉及到了遊戲世界的測試方法:
1、遊戲情節的測試,主要指遊戲世界中的任務系統的組成, 有人也稱為遊戲世界的事件驅動, 我喜歡稱為遊戲情感世界的測試。
2、遊戲世界的平衡測試,主要表現在經濟平衡,能力平衡( 包含技能, 屬性等等),保證遊戲世界競爭公平。
3、遊戲文化的測試,比如整個遊戲世界的風格, 是中國文化主導,還是日韓風格等等,大到遊戲整體,小到N P C( 遊戲世界人物) 對話, 比如一個書生,他的對話就必需斯文, 不可以用江湖語言。

以上陳述中關於遊戲特性的部分概念是曾在金山公司的測試人陳衛俊提出來過的,在此引用。

 

三、如何用面向對象的思想進行測試
  上面了解了面向對象的概念以及遊戲測試和通用軟件測試的區別以後我們可以進入正題了—如何用面向對象的思想進行遊戲測試?
  首先,和所有通用軟件以及硬件產品一樣,我們的遊戲是一個產品,是一個存在的實體,因此,我們把這個”實體”當做一個大的對象開始分析,整個遊戲由哪些部分構成,而構成整個遊戲的大的部分又由哪些組件構成,認真分析完這些以後就可以着手進行測試了,注意,這裏說”可以進行測試了”意思不是馬上就能進入測試,聽我慢慢道來。 
  ”工欲善其事,必先利其器”—某位高人說的,我們做測試也是一樣,分析完畢后,我們要做的還是分析 ^_^ 不過這裏的分析和之前的分析有點點區別,這裏我們需要分析的是具體功能的關鍵測試點和風險點,測試不能盲目,打蛇要打七寸…..在這裏我們就是把某個具體的功能作為一個對象,我們要分析組成這個功能的是哪些因素,一共有哪些測試點,哪些測試點是關鍵點,哪些是高風險點,一一列舉出來,這樣我們就一目瞭然了,然後就是我們打算採用何種方式來進行測試,這裏就是方法了.測試的方式可能有很多種(比如在不同的操作系統下進行測試等),因此我們也需要一一列舉,此外我們需要分析的還有測試過程中我們需要用到的具體測試手法、具體的數值、特定的環境等等這些就是屬性,當然這些我們也必須整理出來。
  將以上提到的對象、方法、屬性整理成文檔就是我們測試時所必須的測試用例了。當然,還是老話,測試用例的優劣是以覆蓋面來評判的,這裏就需要經驗了,簡單說就是靠累積以及學習。
  OK,測試用例我們完成了,剩下的就是實施測試了,實施測試時個人覺得一定要按照用例的描述去執行,如果在測試過程中覺得用例不完善可以先更新用例再進行測試,一定不要先測試再補用例!!
  接下來就是測試報告,報告中包含的應該有所有測試點的簡述,包括了通過測試的部分和存在bug的部分。bug管理是很重要的一環,在這裏不詳述。
  關於測試流程在這裏就不做具體說明,在這裏希望闡述的是一種測試的思想,個人覺得測試除了要有紮實的相關基礎知識以便更深入的了解產品以外,更重要的是測試思想,具備了完善的測試思想才能有計劃的完成每一步測試,從而提高測試的效率,保證測試產出的質量,也更好的保證產品的質量。面向對象是一種思想,用面向對象的思想來組織、計劃、實施測試工作,能讓我們在測試工作中有很強的目的性,他能清楚地告訴我們今天要做什麼,明天要做什麼,我們要做的是哪些,說回遊戲測試,遊戲開發是一個迭帶的開發模式,因此測試工作往往會有很大的隨機性,因此當我們接到一個新功能時,首先要明確我們要測得這個功能是做什麼的,有什麼用,這個功能怎麼使用。OK,我們了解了這個功能是什麼,能做什麼就可以開始細化分析了:這個功能共由哪些子功能組成,這些子功能是否有自己的子功能點,一層層的分析下去,然後就是從最底層的功能點分析:這個功能什麼情況下要發揮其功效,發揮其功效的因素有哪些,怎麼樣去發揮具體的功效,該功能有沒有相應的容錯機制,這些就是我們的詳細測試點和測試手法。然後向上一層一層分析,一直到最頂層就是我們的功能完整的測試方針。這樣我們就把面向對象的思想完全用到了測試中。當然,在分析的過程中我們必須考慮到,與遊戲情節、遊戲風格、遊戲平衡、玩家的易用性是否衝突等等因素,適時地給策劃提出正確的建議。

  以上陳述的種種,無非是想將面向對象的思想用到測試中的好處列舉出來,或許經驗淺薄說的有些蒼白,但是我堅信一點,測試是一種思想,是一種絕對不亞於開發思想的學問,要想做好測試就需要具備良好的測試思想,或者良好的測試思想不是一天两天能夠形成的但是相信只要把測試當做一種職業,當作一種事業來做,把自己真正當成保證產品質量的最後一道關卡,成為一個BT(BestTester)就指日可待了!

軟件測試用例的認識誤區

  軟件測試用例是為了有效發現軟件缺陷而編寫的包含測試目的、測試步驟、期望測試結果的特定集合。正確認識和設計軟件測試用例可以提高軟件測試的有效性,便於測試質量的度量,增強測試過程的可管理性。

  在實際軟件項目測試過程中,由於對軟件測試用例的作用和設計方法的理解不同,測試人員(特別是剛從事軟件測試的新人)對軟件測試用例存在不少錯誤的認識,給實際軟件測試帶來了負面影響,本文對這些認識誤區進行列舉和剖析。

 

 

誤區之一:測試輸入數據設計方法等同於測試用例設計方法

  現在一些測試書籍和文章中講到軟件測試用例的設計方法,經常有這樣的表述:測試用例的設計方法包括:等價類、邊界值、因果圖、錯誤推測法、場景設計法等。這種表述是很片面的,這些方法只是軟件功能測試用例設計中如何確定測試輸入數據的方法,而不是測試用例設計的全部內容。

  這種認識的不良影響可能會使不少人認為測試用例設計就是如何確定測試的輸入數據,從而掩蓋了測試用例設計內容的豐富性和技術的複雜性。如果測試用例設計人員把這種認識拿來要求自己,則害了自己;拿來教人,則害了別人;拿來指導測試,則害了測試團隊。聽起來似乎是“小題大做”,但是絕不是“危言聳聽”。

  無疑,對於軟件功能測試和性能測試,確定測試的輸入數據很重要,它決定了測試的有效性和測試的效率。但是,測試用例中輸入數據的確定方法只是測試用例設計方法的一個子集,除了確定測試輸入數據之外,測試用例的設計還包括如何根據測試需求、設計規格說明等文檔確定測試用例的設計策略、設計用例的表示方法和組織管理形式等問題。

  在設計測試用例時,需要綜合考慮被測軟件的功能、特性、組成元素、開發階段(里程碑)、測試用例組織方法(是否採用測試用例的數據庫管理)等內容。具體到設計每個測試用例而言,可以根據被測模塊的最小目標,確定測試用例的測試目標;根據用戶使用環境確定測試環境;根據被測軟件的複雜程度和測試用例執行人員的技能確定測試用例的步驟;根據軟件需求文檔和設計規格說明確定期望的測試用例執行結果。

 

 

誤區之二:強調測試用例設計得越詳細越好

  在確定測試用例設計目標時,一些項目管理人員強調測試用例“越詳細越好”。具體表現在兩個方面:盡可能設計足夠多的設計用例,測試用例的數量閱讀越好;測試用例盡可能包括測試執行的詳細步驟,達到“任何一個人都可以根據測試用例執行測試”,追求測試用例越詳細越好。

  這種做法和觀點最大的危害就是耗費了很多的測試用例設計時間和資源,可能等到測試用例設計、評審完成后,留給實際執行測試的時間所剩無幾了。因為當前軟件公司的項目團隊在規劃測試階段,分配給測試的時間和人力資源是有限的,而軟件項目的成功要堅持“質量、時間、成本”的最佳平衡,沒有足夠多的測試執行時間,就無法發現更多的軟件缺陷,測試質量更無從談起了。

  編寫測試用例的根本目的是有效地找出軟件可能存在的缺陷,為了達到這個目的,需要分析被測試軟件的特徵,運用有效的測試用例設計方法,盡量使用較少的測試用例,同時滿足合理的測試需求覆蓋,從而達到“少花時間多辦事”的效果。

  測試用例中的測試步驟需要詳細到什麼程度,主要取決於測試用例的“最終用戶”(即執行這些測試用例的人員),以及測試用例執行人員的技能和產品熟悉程度。如果編寫測試用例的人員也是測試用例執行人員,或者測試用例的執行人員深刻了解被測軟件,測試用例就沒有必要太詳細。而如果是測試新人執行測試用例,或者軟件測試外包給獨立的第三方公司,那麼測試用例的執行步驟最好足夠詳細。

 

誤區之三:追求測試用例設計“一步到位”

  現在軟件公司都意識到了測試用例設計的重要性了,但是一些人認為設計測試用例是一次性投入,測試用例設計一次就“萬事大吉”了,片面追求測試設計的“一步到位”。

這種認識造成的危害性使設計出的測試用例缺乏實用性,或者誤導測試用例執行人員,誤報很多不是軟件缺陷的“Bug”,這樣的測試用例在測試執行過程中“形同虛設”,難免淪為“垃圾文檔”的地步。

  “唯一不變的是變化”。任何軟件項目的開發過程都處於不斷變化過程中,用戶可能對軟件的功能提出新需求,設計規格說明相應地更新,軟件代碼不斷細化。設計軟件測試用例與軟件開發設計并行進行,必須根據軟件設計的變化,對軟件測試用例進行內容的調整,數量的增減,增加一些針對軟件新增功能的測試用例,刪除一些不再適用的測試用例,修改那些模塊代碼更新了的測試用例。

  軟件測試用例設計只是測試用例管理的一個過程,除此之外,還要對其進行評審、更新、維護,以便提高測試用例的“新鮮度”,保證“可用性”。因此,軟件測試用例也要堅持“與時俱進”的原則。

 

 

誤區之四:讓測試新人設計測試用例

  在與測試同行交流的過程中,不少剛參加測試工作的測試新人經常詢問的一個問題是:“怎麼才能設計好測試用例?”。因為他(她)們以前從來沒有設計過測試用例,面對大型的被測試軟件感到“老虎吃天,無從下口”。

  讓測試新人設計測試用例是一種高風險的測試組織方式,它帶來的不利後果是設計出的測試用例對軟件功能和特性的測試覆蓋性不高,編寫效率低,審查和修改時間長,可重用性差。

  軟件測試用例設計是軟件測試的中高級技能,不是每個人(尤其是測試新人)都可以編寫的,測試用例編寫者不僅要掌握軟件測試的技術和流程,而且要對被測軟件的設計、功能規格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。

  因此,實際測試過程中,通常安排經驗豐富的測試人員進行測試用例設計,測試新人可以從執行測試用例開始,隨着項目進度的不斷進展,測試人員的測試技術和對被測軟件的不斷熟悉,可以積累測試用例的設計經驗,編寫測試用例。

 

 

 

【精選推薦文章】

自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"