|
希望閱讀本文的朋友是做過測試并有一定經(jīng)驗的，不然，你明白我說的什么意思，但你對本文并不一定深有體會。
測試人員的定位
這其實是個有趣味且值的問題，包括經(jīng)常跟測試人員打交道的開發(fā)人員，甚至測試人員自己都沒弄清楚自己職位到底該如何的定位。當(dāng)別人問人什么是軟件測試時？ 噢！等等，我翻翻書，“軟件測試是通過一定的測試方法和工具發(fā)現(xiàn)軟件的中的缺陷從而來提高軟件質(zhì)量。” 噢？測試發(fā)現(xiàn)軟件中的所有缺陷么？不能！ 噢？測試真的可以提高軟件質(zhì)量么？這個還真不敢保證。 詢問者輕蔑的的走開了，處于禮貌，他們可能沒有笑出聲來，但他們的眼神已經(jīng)告訴了測試人員答案，測試是個可有可無的工作。留下測試員非常的窩火，但貌似真的找不出非常有力的證據(jù)，來證明自己的存在“不可或缺”和“不可代替”的價值。 ---------------------------------------------------- 軟件測試人員接受專門的培訓(xùn)來發(fā)現(xiàn)并報告問題，他們通過發(fā)現(xiàn)和報告軟件的異常問題和存在的風(fēng)險，進(jìn)而幫助公司、開發(fā)團(tuán)隊、客戶和最終用戶。 那么我們可以把測試人員比作警察嗎？在軟件開發(fā)過程中并沒鐵定的“憲法”，他們并不能依照“法律”是去“逮捕”任何人，盡管軟件開發(fā)的世界里完全可以制定出一定的法律。在法律的世界里，一方受到懲罰，一定有另一方面受到的傷害。但軟件缺陷不是這樣，也許這個缺陷會造成巨大的傷害，也許一定傷害也沒有。也許我們的“法律”根本無法評估一個的傷害到底有多大。 好吧！既然不能做警察，那來做法管好了，讓測試人員來做“質(zhì)量把關(guān)人”。這其實操作起來很困難，也不太公平。所謂“質(zhì)量把關(guān)人”，就是在軟件發(fā)布前將該軟件看做一個商品。由測試人員來權(quán)衡風(fēng)險、必要性、市場需求和成本開銷。噢！測試人員的高度不夠，評估和承擔(dān)風(fēng)險其實是項目管理者或公司管理層的任務(wù)。 到后面可能測試人員已經(jīng)拋棄了測試人員的本質(zhì)工作（發(fā)現(xiàn)并提交問題），而是花費大量的時間在權(quán)衡和評估每一個問題。其實，測試人員清楚地知道不客發(fā)現(xiàn)和解決多少問題。軟件代碼里總是還潛伏著一些問題，所以，他們一般不太情愿蓋那個質(zhì)檢合格的紅印。這就是說等“質(zhì)量把關(guān)人”去確定產(chǎn)品合格，可能要猴年馬月了。 測試人員其實更愿意做偵查取證小組或驗尸法醫(yī)。他們只提取證據(jù)。接下來的你們看著辦吧。 好吧！軟件測試人員的工作遠(yuǎn)不至這個，以下任何要求都可能決定測試人員的使命，你（測試人員）期望的是哪種要求？
對于測試人員來說這太啰嗦（復(fù)雜）了，他們只是單純的喜歡找缺陷（bug），并像探秘一樣的把缺陷定位出來。這就像好玩的尋寶游戲。沒人事先知道答案，這樣對測試人員來說才是有趣的挑戰(zhàn)。
測試人員有趣的特質(zhì)
好吧！為了完成這項有趣的挑戰(zhàn)，測試人員應(yīng)該具備什么樣的特質(zhì)呢？ 首先要有好奇心，想弄清楚事物是怎么運(yùn)行的；其次喜歡動手試驗，想知道嘗試使用功能演示時不同的用戶場景和試驗會發(fā)生什么。 再次，需要一點膽大精神，不害怕會破壞什么東西，不管你有多位高權(quán)重，他們也不害怕把發(fā)現(xiàn)的事實告訴你，他們更不害怕站出來據(jù)理力爭，一定要把他們相信可能影響到產(chǎn)品成功的問題解決掉。 善于分析，善于學(xué)習(xí)，事實上，測試人員一直在學(xué)習(xí)，他們的工作性質(zhì)要求如此。技術(shù)總是在變化，接到的每個項目或多或少跟上一個項目不一樣。有時候有很好的文檔，有時候卻沒有，必須問出正確的問題，研究正確的問題，把謎題的各個碎片聯(lián)系在一起，然后得出正確的結(jié)論。 當(dāng)然，測試人員也有不好的特質(zhì)，尤其對于那些經(jīng)驗豐富的人為說，不容易信任人，這是從實踐中歷練出來的，別人總是告訴他們模塊X不需要測試，或代碼Y“沒動過”，這種信息錯的數(shù)多到數(shù)不清了。所以，就算你告訴測試人員草是綠的他們也要親自過目才敢相信。當(dāng)然了，不是所有的測試人員都具備這些特質(zhì)。好吧！也許你做測試是為了一份穩(wěn)定的工作來生活。也許你不是“真正的”測試員。
尋找測試的樂趣
只懂執(zhí)行其他人測試想法的人，不能算是一個真正意義上的測試人員。當(dāng)一個測試人員運(yùn)行一大堆已有的測試用例時，容易心生厭煩。可能會快運(yùn)行這些測試，只是想讓他們從眼前消失，這意味者他們可能不會非常關(guān)注執(zhí)行的測試，當(dāng)然也就不能像認(rèn)真徹底的執(zhí)行者一樣找出某些問題。 很多測試人員覺得單調(diào)乏味而不屑運(yùn)行回歸測試，雖然大部分測試員都理解甚至同意回歸測試的必要性。 一個“真正的”測試人員一定會把這些已有測試看作自己的職責(zé)范圍，重新考慮其中的想法，提出問題，充實和改變測試，探究原來的分析沒有考慮到的地方。如果原來的分析實在很棒，尋阿能他們也找不出來太多可有更新充實的內(nèi)容，進(jìn)而增加了無聊指數(shù)。
并非發(fā)現(xiàn)的所有問題都可以得到解決
雖然，看到這個結(jié)果會打擊測試人員的積極性，但這是真的。最有經(jīng)驗的的測試人員會同情地拍拍你的肩膀說：地球人都知道事情不僅僅是發(fā)現(xiàn)問題那么簡單。他們也會充分理解、會力支持你的決定：問題A、B、C 可以不解決，并不會有人對這樣的決定怪罪你。擁有多年工作經(jīng)驗的測試人員會說出大家都愉悅的意見，因為他們從這家公司的項目經(jīng)驗中學(xué)乖了，知道這樣會給他們（以及他們部門）帶來最好的質(zhì)量結(jié)果。但是需要記住，他們之所以肯犧牲問題A、B、C ，很可能是為了說服你解決更嚴(yán)重的問題D 和E 。當(dāng)然，大多數(shù)測試員是希望發(fā)現(xiàn)的所有問題都能夠得到處理，現(xiàn)實總沒希望的那么好。
測試員只喜歡有趣的缺陷
所有的測試人員都會告訴你，缺陷是存在的，然后缺陷就真的存在了。一般來說，讓事情變得好玩并非缺陷的數(shù)目。比如一個測試人員可以在大的網(wǎng)站應(yīng)用程序中發(fā)現(xiàn)上千個表面錯誤，就是語句與錯別字，給用戶看的文本有語法錯誤，圖標(biāo)上的顏色不對，或都屏幕上有東西位置放得不對。 測試人員非常討厭這樣的錯誤，特別是發(fā)現(xiàn)有很多的時候。因為記錄這類錯誤比發(fā)現(xiàn)它們所花費的時間更長。而且他們一般屬于低優(yōu)先級，很容易得到解決。對！測試人員就是變態(tài)的喜歡讓開發(fā)員束手無策的問題，這樣似乎更能體驗他們的能力與價值。
不要去預(yù)測問題優(yōu)先級
在IT領(lǐng)域經(jīng)驗豐富的前輩會告訴你，某個應(yīng)用程序的最終用戶可能會對你覺得微不足道的問題深切關(guān)注。這跟人的“煩惱因素”有很大關(guān)系，一個錯別字或字體用得不恰當(dāng)可能不會影響用戶的使用，項目組的所有人都認(rèn)為這是個小問題。但是對于每天要看兩千遍的用戶來說，“煩惱因素”是非常高的。 例一個雙擊鼠標(biāo)就可以完成的操作，我設(shè)計成了三擊，只是多點了一個鼠標(biāo)而已。這也許有趣，但對于每天操作幾百遍的用戶來說，他會破口大罵地拿起鼠標(biāo)甩到地上。這太令人討厭了。這影響的他們的工作效率，也行效率與績效、獎金掛鉤。 測試人員報告他們發(fā)現(xiàn)的一切問題，其中經(jīng)驗豐富的人員會根據(jù)其理解來報告嚴(yán)重程度，但一般來說不要試圖預(yù)測業(yè)務(wù)優(yōu)先級。他們理解中的業(yè)務(wù)優(yōu)先級通常就像開發(fā)團(tuán)理解的一樣，是不太完整的，并不是基于用戶的個人體驗做出的。經(jīng)常有用戶愿意“將就”使用有嚴(yán)重錯誤的代碼，卻在最后一刻強(qiáng)迫要求修改或添加看起來并不重要的東西。 測試人員的工作是尋找、發(fā)現(xiàn)、報告，而不是用神一樣的能力去評判，測試人員應(yīng)該隨心所欲的提供他們的專業(yè)意見，事實上，項目組的所有人都應(yīng)該隨心所欲地提供專業(yè)意見。
報告你發(fā)現(xiàn)的所有問題
有一個令人遺憾的現(xiàn)實，那就是測試人員不將他們發(fā)現(xiàn)的所有錯誤報告出來。原因可能有很多，但最常見的是他們覺得報告某一種或某一類錯誤沒有意義，因為反正都不會被解決的。這是從實踐中“學(xué)”來的，你通常會發(fā)現(xiàn)有這類態(tài)度的測試人員不抱幻想、厭倦、憤世嫉俗、對工作不感興趣。他們報告缺陷的興趣和熱情已經(jīng)被工作環(huán)境慢慢消磨掉了。另一個原因也許是他們相信從政治上和實際上來說，報告他們發(fā)現(xiàn)的一切東西是不“聰明”的，他們應(yīng)該只報告那些公司在乎的東西。那么，如果公司看不到整個大局，怎么知道在不在乎呢？每個人都明白很多錯誤是不能（或者從財務(wù)的角度來說不應(yīng)該）在產(chǎn)品發(fā)布前解決的。成功項目管理的“藝術(shù)和工藝”的一個要素是對推遲和解決哪些缺陷做出正確的決策。比如，項目組決定解決1 4 個缺陷，推遲另外3 2 個。但是測試人員選擇不報告3 2 4 個缺陷，因為開發(fā)團(tuán)隊“從不解決”字段錯誤，這意味著項目經(jīng)理和上層的管理者正在根據(jù)錯誤、不全面的信息作決策。在這個例子里，用戶界面就不能在萬眾矚目的黃金時段隆重登場。 另外，就算是在一個并不解決某類錯誤的公司，報告每個錯誤也可能會最終改變公司的政策（或稱之為“一直實行的陳規(guī)”）。如果一個測試人員報告了4 0 個錯誤，一個都沒解決，應(yīng)用程序就發(fā)布了，然后用戶以緊急的優(yōu)先級報告同樣的錯誤并要求盡快地解決它們，那么開發(fā)團(tuán)隊和項目經(jīng)理以后就會開始注意這類缺陷
測試員一直在想法破壞你的程序
好的測試人員同時是富有創(chuàng)造力和想象力的。測試通常是一個破壞的過程，正因為如此，在正式產(chǎn)品環(huán)境下運(yùn)行測試需要非常謹(jǐn)慎的決策。好的測試人員不必試圖證明軟件運(yùn)行正常，他們是來證明軟件不能正常運(yùn)行的。這一態(tài)度差異是測試人員能發(fā)現(xiàn)如此多缺陷的主要原因，他們就是想發(fā)現(xiàn)缺陷。他們分析手上所有的信息，坐下來思考怎么才能破壞應(yīng)用程序。項目組里沒有其他人有這樣的使命。開發(fā)人員一般甚至沒有足夠的時間持續(xù)寫代碼，更不要說試圖擠出足夠的時間來想怎么破壞代碼了。最終用戶通常只是執(zhí)行日常工作的操作，如果有東西“壞掉了”，他們可能陷入恐慌和沮喪之中。另一方面，只有測試人員勇敢地參與進(jìn)來，使出吃奶的勁兒去發(fā)現(xiàn)軟件中的缺陷，他們卻為發(fā)現(xiàn)另開發(fā)人員痛苦的缺陷而興奮不已。 這正好應(yīng)驗了媽媽一直告訴我們的話，要是你只盯人身上壞的一面，那你就只能發(fā)現(xiàn)壞的東西。測試人員全面地盯著系統(tǒng)中出錯的一面找問題，順便也就檢驗了運(yùn)行正常的部分。但他們關(guān)注的焦點總是向著錯的東西，而不是對的東西
測試角色的本質(zhì)
很久之前，就有關(guān)于測試人員的角色的爭論，我們再來總結(jié)性的說說測試角色的本質(zhì)。 一些人認(rèn)為測試人員的角色是保證質(zhì)量，如果有人能決定到底“質(zhì)量”指什么？ 這個似乎很難說清。 另一些人認(rèn)為他們的角色是通過訓(xùn)練開發(fā)人員的尋找缺陷幫助他們編寫出更好的代碼----在開始編寫的時候就不存在錯誤的編碼； 還有一些測試專家集中精研究為何以及如何找到缺陷：在不同的環(huán)境下尋找缺陷所涉及的策略、技術(shù)和術(shù)語。 所有這些說法都很有趣，在某種意義上都是對業(yè)界有溢的。但是，從本質(zhì)上來說，測試的意義就是發(fā)現(xiàn)缺陷。測試人員通過項目組和管理層展示缺陷、問題或瑕疵“保證質(zhì)量”，進(jìn)而幫助他們做出更好的決策；他們通過向開發(fā)人員展示其代碼中的錯誤，使其知錯就改引以為戒，進(jìn)而幫助他們改進(jìn)工作；他們學(xué)習(xí)新的策略和技術(shù)以便發(fā)現(xiàn)更多的（或者更重要的）缺陷，他們把工作歸類到新的策略里，如游歷式，進(jìn)而幫助 其他人發(fā)現(xiàn)缺陷。如果在測試過程中沒有發(fā)現(xiàn)（或者只發(fā)現(xiàn)了很少的）錯誤，那么這也是重要的信息。 ------------------------------------------------------------------------------ 注：本文內(nèi)容取自《測試之美》第1章 “這對你有好處么”，這是一本很好的書，讀完第1章收獲頗多，但正如不少人說話，作者寫得太散了，沒有條理。好吧！我把這一部分的精彩抽取出來與各位分享。 |
|
|
