20年研發管理經驗談（十一）

本文繼20年研發管理經驗談（十）。

此文是對我我的測試思想的一個總結，因爲經驗不夠，知識淺薄，若是有什麼不合理的地方請一笑了之。

1、面向對象的概念
　　所謂的面向對象是軟件開發的一種重要的思惟方式，是把軟件開發過程當中出現的事物,用一個個的對像來分析.通常一張數據表能夠封裝爲一個對像。用個形象的比喻：咱們如今要作一張桌子，首先咱們考慮到的是咱們要作的是什麼？是桌子；桌子是用來幹什麼的呢？是用來吃飯、喝茶、看書、打麻將的；而後就要考慮桌子由哪些部分組成？由桌面和桌腿來組成；接着咱們須要考慮咱們採用什麼材料呢？紙？不行...那可什麼都幹不成，OK，用木頭；接着就能夠開始把組成桌子的組件作爲對象開始分析--桌面如何作是用刀砍的仍是用刨子刨呢？桌腿又如何作...
　　一套完整的方法成形了就能夠具體實現了，在作的過程當中桌面要作多大，桌腿要作多長都要事先考慮到是否是要留出接口，這些就是咱們給組成桌子的組件賦予的屬性。OK，如今能夠作出具體的實物了，作好實物組件（對象）之後就要將作好的桌面桌腿進行組裝，因爲咱們事先考慮好了組件的屬性，考慮到了必須預留接口，所以咱們能夠很輕易的組合成功，桌子作出來了。以上就是面向對象的思想的一個簡要的比喻

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

 

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

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

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

 

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

　　以上陳述的種種，無非是想將面向對象的思想用到測試中的好處列舉出來，或許經驗淺薄說的有些蒼白，可是我堅信一點，測試是一種思想，是一種絕對不亞於開發思想的學問，要想作好測試就須要具有良好的測試思想，或者良好的測試思想不是一天兩天可以造成的可是相信只要把測試當作一種職業，看成一種事業來作，把本身真正當成保證產品質量的最後一道關卡，成爲一個BT（BestTester）就指日可待了！

軟件測試用例的認識誤區

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

　　在實際軟件項目測試過程當中，因爲對軟件測試用例的做用和設計方法的理解不一樣，測試人員（特別是剛從事軟件測試的新人）對軟件測試用例存在很多錯誤的認識，給實際軟件測試帶來了負面影響，本文對這些認識誤區進行列舉和剖析。

 

 

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

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

　　這種認識的不良影響可能會使很多人認爲測試用例設計就是如何肯定測試的輸入數據，從而掩蓋了測試用例設計內容的豐富性和技術的複雜性。若是測試用例設計人員把這種認識拿來要求本身，則害了本身；拿來教人，則害了別人；拿來指導測試，則害了測試團隊。聽起來彷佛是「小題大作」，可是毫不是「危言聳聽」。

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

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

 

 

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

　　在肯定測試用例設計目標時，一些項目管理人員強調測試用例「越詳細越好」。具體表如今兩個方面：儘量設計足夠多的設計用例，測試用例的數量閱讀越好；測試用例儘量包括測試執行的詳細步驟，達到「任何一我的均可以根據測試用例執行測試」，追求測試用例越詳細越好。

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

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

　　測試用例中的測試步驟須要詳細到什麼程度，主要取決於測試用例的「最終用戶」（即執行這些測試用例的人員），以及測試用例執行人員的技能和產品熟悉程度。若是編寫測試用例的人員也是測試用例執行人員，或者測試用例的執行人員深入瞭解被測軟件，測試用例就沒有必要太詳細。而若是是測試新人執行測試用例，或者軟件測試外包給獨立的第三方公司，那麼測試用例的執行步驟最好足夠詳細。

 

誤區之三：追求測試用例設計「一步到位」

　　如今軟件公司都意識到了測試用例設計的重要性了，可是一些人認爲設計測試用例是一次性投入，測試用例設計一次就「萬事大吉」了，片面追求測試設計的「一步到位」。

這種認識形成的危害性使設計出的測試用例缺少實用性，或者誤導測試用例執行人員，誤報不少不是軟件缺陷的「Bug」，這樣的測試用例在測試執行過程當中「形同虛設」，不免淪爲「垃圾文檔」的地步。

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

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

 

 

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

　　在與測試同行交流的過程當中，很多剛參加測試工做的測試新人常常詢問的一個問題是：「怎麼才能設計好測試用例？」。由於他（她）們之前歷來沒有設計過測試用例，面對大型的被測試軟件感到「老虎吃天，無從下口」。

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

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

　　所以，實際測試過程當中，一般安排經驗豐富的測試人員進行測試用例設計，測試新人能夠從執行測試用例開始，隨着項目進度的不斷進展，測試人員的測試技術和對被測軟件的不斷熟悉，能夠積累測試用例的設計經驗，編寫測試用例。