軟件測試人員的基本修養

671

  見到題目,你或許會想起電影《喜劇之王》中尹天仇所看的《演員的自我修養》一書,還有那句經典的台詞:我是一個演員,跑龍套的也是演員!更會對影片中周星馳所扮演角色對夢想成為一名出色的演員而孜孜以求的情節記憶猶新。人們說行行相通,一通百通。我們這裡就說說測試人員的基本修養。

代碼編寫,不可或缺

喬布斯說:Design is not just what it looks like andfeels like, design is how it works(設計不僅是外形和感覺,設計關乎如何運作)。那麼可以說測試亦是如此,測試不是簡單地拿過來用一用。當開發人員将開發完成的軟件提交到測試人員那裡以後,測試人員首先需要做的是迅速透徹地理解軟件的功能。你會說這是需求讨論階段已經介入的工作,沒錯,但除了理想狀況,很多時候是趕鴨子上架,容不得按常理出牌。或者你會說要先做版本驗證測試(BVT)查看其可測性,但這都是理想狀況。

  而無論如何,你首先要搞明白提交過來的東西具備哪些功能以及是如何工作的?事先準備好滿足測試需要的軟硬件環境自然不必多說。開發經驗的作用不光局限于對編碼及相關技術的理解,還會使你更加了解開發人員的心理感受,從編碼心理和工作習慣的角度,更好地弄懂軟件是如何工作的。這一點多多少少有點兒隻可意會不易言傳的感覺。我在工作中切身體會到,有些朋友搞定編碼的思路,可以使人強烈感受到一股強大的、嚴密的邏輯氣息。那思路和風格從頭到尾自成一體——氣派、美妙,令人贊歎不已。

  世界著名計算機科學家,1984年圖靈獎獲得者Niklaus Wirth提出“算法+數據結構=程序”。清代人薛雪所撰《一瓢詩話》中有:如此體會,則詩神詩旨,躍然紙上。那麼我要說:如此體會,則碼神碼旨,亦躍然紙上。

全面深入,T型路線

         T字型知識架構是指在細分領域細緻專精,相關技術領域也要有所了解。測試人員真的需要了解相關技術嗎?答案是肯定的。這裡說的相關技術并非指測試相關,而是指開發所用的相關技術。說得再直白些,最好是懂得相關技術,甚至是該領域的技術專家。

  我曾親身經曆過這樣一件事情:在一個有着廣泛市場影響的項目中,新版本發布增加了新的功能,在HTML頁面中使用JavaScript來控制控件的顯現。而發布時間緊迫,不允許有更多的時間使用正向用例來驗證功能的正确性。盡管如此,我們也針對這小小的控件設計了将近百條用例。涉及的方面包括從頁面的正反向跳轉來驗證控件的版本升級,到控件的跨域調用、浏覽器的兼容、服務設置及幹擾,如此種種,無一不需要通過了解相關技術,才能設計出有價值的用例。當然,有些有價值的用例來自于使用習慣,這可以說是很難有章可循的,需要靠經驗的積累。最後,還要檢查JavaScript文件内容是否正确。這樣一來,最大限度地保證了産品上線後該功能點萬無一失。

理清思路,有的放矢

  很多人會認為,在測試工作中引入巧妙的編程技巧或者使用酷炫無比的技術手段,就代表測試水平高超。這種做法顯然舍本求末,沒有明白測試行為本身的目的。對于專業測試人員,這點誤區可以理解,但不可接受。軟件測試的目的,一方面是為了盡可能發現軟件存在的缺陷,追蹤直至解決這些缺陷;另一方面是為了度量被測試對象質量的優劣程度,對可能出現的問題從技術和其他方面采取相應的措施。兩者都是為了降低潛在的商業風險。

  一般來說,我們首先會根據軟件系統本身的特點,其應用場景及開發人員等相關資源,去制訂相應的測試策略,其中包括制訂測試計劃、分配測試資源、設計測試用例等。測試工作前期的大部分内容,不僅需要相關的技術知識,還包括更多的相關應用領域的知識和經驗,以及分析能力。而這一切行為皆為降低産品潛在的商業風險所服務。誠然,使用優美的代碼和酷炫的技術完成測試任務無可厚非,而無論如何,主旨不可偏離。

積基樹本,夯實基礎

  好比說,找來一些幫手來壘牆,這自然不需要什麼高深的建築理論,但要做對整體工程進行把控的建築工程師則需要讀過建築理論,掌握相關的基礎知識。計算機科學領域中的基礎知識,包括數據結構、操作系統、編譯原理、數據庫原理等。基礎知識越是夯實飽滿,也才越容易被融會貫通、結合實踐從而得到寶貴的升華。數據庫産品種類繁多,各類軟件開發框架也層出不窮,而不變的永遠是基礎知識和基本原理。假如你明白高級語言應用開發學習的内容無外乎語法、框架和類庫這三部分,學習起來自然不會眉毛胡子一把抓。

  在計算機科學領域,如果涉及性能優化(時間複雜度、空間複雜度、數據庫、操作系統、網絡、并行計算、向量計算等)、複雜的數據結構、協議模型等特殊的問題,那麼基礎知識也就成了解決問題的必要條件。不用多說,作為專業技術人員,牢牢掌握這些知識是走向一流水平的不二法門。順便說句題外話,這些基礎知識同時也被看做試金石,可以幫助你進入一流水平的研發團隊。

與人分享,談吐有緻

  與人打交道,就難免涉及人際方面的事宜。溝通的技巧和方式自然是舉不勝舉,說上三天三夜也未必窮盡。所以在這裡對此高談闊論多少會顯得有些捉襟見肘。但很重要且有效的一點溝通技巧可能會被忽略,那就是“不抱怨,找方法”。當團隊之間、成員之間需要就某個問題進行交涉,甚至可能會發生争論乃至争吵時,最好少說多做,提出解決辦法并且付諸行動。這裡向大家推薦閱讀卡耐基的《人性的弱點》以及費希爾的《溝通力》。希望能汲取其中的營養,完善性格的弱點,潛移默化地在無形之中大顯神威。

一絲不苟,持之以恒

  在軟件測試的整個周期中,可能會出現一些不是總能重現的問題,這類問題的處理方式可大有講究。從工程學的角度說,遇到這樣的問題,不能及時找到原因而修複的話,需要降低該問題的優先級,等待再次重現,保留現場抓取的相關記錄。這樣既不會影響當前版本的發布,又毫無疏漏地追蹤了曾經偶然出現的問題。某個問題一旦出現,是不能輕易放過的。既然不是總能重現,那如何證明此問題是否已經解決呢?當然,反複驗證是重要的一方面。經過反複驗證,其實還不能有把握地說這類問題已經修複。是不是心裡還是沒底呢?那就去看一看源碼。

  每天反複做一件事,堅持10年,任何人都會有所成就。當企業和項目負責人,等待你那封TestSignoff郵件發出的時候,你是否可以滿懷信心地點擊Send按鈕呢?是否可以對發布前提交的版本做到胸有成竹,錦囊之中自有乾坤呢?百年三萬六千日,朝着自己的人生目标,努力過好每一天。修養的形成不在于猛攻,而在于點滴的積累和潤物無聲地打磨。