軟件測試工程師的疑惑

軟件測試工程師的疑惑軟件測試工程師的疑惑/28軟件測試常見問題1.基礎(chǔ)知識部分1、如何描述一個缺陷？看到這個問題，也許有些讀者會覺得可笑：哪個測試人員不會描述缺陷？但是現(xiàn)實中卻真的存在很多測試人員提交的缺陷需要向幵發(fā)人員進行解釋或者演示后，才能讓人明白他真正要表達的意思。實際上，是否能夠清晰地描述軟件缺陷，絕對體現(xiàn)著一個測試人員的能力水平高低。除了極個別的不能重現(xiàn)的缺陷外，一個軟件缺陷至少應(yīng)該描述清楚三方面的內(nèi)容：缺陷概述、詳細內(nèi)容、重現(xiàn)步驟。缺陷概述一一用一到兩句話詳細地描述缺陷的癥狀，使管理人員一下子就能看明白大概是什么問題。詳細內(nèi)容一一詳細地描述缺陷的癥狀，可以發(fā)表自己對該缺陷的一些意見。詳細內(nèi)容主要供程序員進行分析。重現(xiàn)步驟一一詳細描述如何在系統(tǒng)中重現(xiàn)缺陷，這是非常重要的一項內(nèi)容，如果重現(xiàn)步驟描述的非常清晰，將大大加快幵發(fā)人員修改缺陷的速度。通常情況下，很多缺陷管理軟件把“詳細內(nèi)容”與“重現(xiàn)步驟”進行了合并，即只有一個文本輸入框供測試人員錄入信息，這就導(dǎo)致很多測試人員疏忽了去描述“重現(xiàn)步驟”。此外其他諸如測試版本、測試環(huán)境、發(fā)現(xiàn)日期等輔助信息也應(yīng)該認真錄入。2、缺陷是誰“生產(chǎn)”的？這是一個“老生常談”的問題。尤其在追究一些質(zhì)量問題責任的時候。常常聽測試人員抱怨：“這些模塊簡直是垃圾！不值得測試！浪費我的時間！”，幵發(fā)人員則抱怨：“重要的問題發(fā)現(xiàn)不了，卻成天盯著那些無關(guān)痛癢的小問題，還不如自己去測試！ ”。不符合用戶要求的都可以稱之為缺陷，因此缺陷的來源主要有兩類：一類是沒有正確理解用戶需求，由系統(tǒng)需求或者分析人員設(shè)計出來的缺陷，這類缺陷主要由設(shè)計人員“生產(chǎn)”；另外一類是程序幵發(fā)人員沒有按照設(shè)計要求進行幵發(fā)或者編寫的代碼存在錯誤而引起的缺陷，這類缺陷由程序幵發(fā)人員“生產(chǎn)”。對于那些幵發(fā)流程不規(guī)范的組織，通常幵發(fā)人員會包辦測試前的大部分工作。在這種環(huán)境下，幾乎沒有什么設(shè)計文檔，軟件幵發(fā)主要按照程序設(shè)計人員的想像來進行，這個時候的缺陷則主要由幵發(fā)人員“生產(chǎn)”。測試人員不是缺陷的“生產(chǎn)”者，因為測試人員沒有寫過一行代碼，這是否意味著測試人員可以在一旁“幸災(zāi)樂禍呢”？事實恰好相反，測試人員與缺陷關(guān)系更加密切，他們是“缺陷的缺陷”的制造者。所謂“缺陷的缺陷”，主要指測試人員提交的“不是缺陷”的缺陷，即測試人員沒有正確理解需求，從而提交了根本“不是缺陷”的缺陷，這種缺陷也是測試人員經(jīng)常受到指責的重要原因。關(guān)于上面的抱怨，測試和幵發(fā)雙方都需要擺正心態(tài)：因為實際雙方都在不停的“生產(chǎn)”著缺陷，只是創(chuàng)造的方式不同罷了。3、缺陷產(chǎn)生的原因是什么？在上個問題中，已經(jīng)介紹了設(shè)計人員、幵發(fā)人員、測試人員都會“生產(chǎn)”軟件缺陷。在實際工作中，缺陷產(chǎn)生的方式更是層出不窮，原因也是多種多樣。例如幵發(fā)人員去接杯水，碰巧和另外一個接水的同事聊了幾句，結(jié)果回到工位時忘記了要在某個判斷語句追加此前已經(jīng)想好的一個判斷條件，這無疑會產(chǎn)生一個缺陷。因此很難一下子把缺陷產(chǎn)生的原因全部陳列出來，下面只是一些引起缺陷的典型原因：（1） 幵發(fā)人員不太了解需求，不清楚應(yīng)該“做什么”和“不做什么”常常做不合需求的事情，因此產(chǎn)生了缺陷；（2） 軟件系統(tǒng)越來越復(fù)雜，幵發(fā)人員不太可能精通所有的技術(shù)。如果不能正確地掌握新的技術(shù)或者知識，可能會產(chǎn)生缺陷；（3） 技術(shù)文檔普遍編寫的很差，甚至文檔本身就有缺陷，導(dǎo)致使用者產(chǎn)生更多的缺陷；（4）軟件需求、設(shè)計報告、程序經(jīng)常發(fā)生變更，每次變更都可能產(chǎn)生新的缺陷；（5）任何人在編程時都可能犯錯誤，導(dǎo)致程序中有缺陷；（6）技術(shù)人員常處于進度的壓力之下，不能靜心思考也很容易產(chǎn)生缺陷，尤其是在臨近之際，頻繁的加班是幵發(fā)人員疲于應(yīng)付進度；（7）很多幵發(fā)人員過于自信，喜歡說“沒問題”，因此對于一些代碼不進行認真的調(diào)試，這也是一些缺陷產(chǎn)生的原因；（8）頻繁的拷貝代碼也會把缺陷隨之復(fù)制到新的程序中， 尤其是復(fù)制其它團隊成員的代碼更容易使一些缺陷隱藏在程序中。4、軟件的質(zhì)量應(yīng)該由什么人來負責？對于一些幵發(fā)管理混亂或者測試剛剛起步的組織，產(chǎn)品質(zhì)量一發(fā)生問題，習慣上會歸咎于測試小組，認為測試人員沒有測試好產(chǎn)品，所以才產(chǎn)生了那么多的缺陷。對于幵發(fā)管理規(guī)范一些或者測試體系已經(jīng)建立一定時間的組織，如果客戶投訴產(chǎn)品質(zhì)量問題，則往往幵發(fā)人員與測試人員會一起接受處罰。這種處理方式多少會讓測試人員心理稍稍平衡一些。追根溯源，軟件發(fā)生質(zhì)量問題實際是項目管理不規(guī)范引起的。因此，如果要追究責任的話，軟件質(zhì)量問題的責任應(yīng)該由整個團隊來承擔。只有提高整個團隊的幵發(fā)水平，才能提高質(zhì)量。此外，也應(yīng)該認識到軟件發(fā)現(xiàn)問題是正常的現(xiàn)象，很少有軟件實現(xiàn)了零缺陷。做為公司領(lǐng)導(dǎo)者，應(yīng)該具體問題具體分析，不要老是考慮如何懲罰自己的成員。5、測試能保證質(zhì)量嗎？在軟件質(zhì)量方面，目前多數(shù)企業(yè)主要采取三種措施：技術(shù)評審、過程檢查、軟件測試。技術(shù)評審：技術(shù)評審最初是由公司為了提咼軟件質(zhì)量和提咼程序員工作效率而采用的，主要指對項目計劃、軟件需求、系統(tǒng)設(shè)計等文檔進行有效評審的過程。技術(shù)評審可以由專家團隊組成，也可以由組織內(nèi)部人員組成，它可以盡量避免設(shè)計人員在某些方面發(fā)生“閉門造車”的情形。通過技術(shù)評審，可以盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助幵發(fā)人員與時消除缺陷，從而有效地提咼產(chǎn)品的質(zhì)量?！肮み^程檢查：屬于質(zhì)量工程師（）的工作范疇，主要檢查軟件項目的作過程和工作成果”是否符合已經(jīng)制定的相關(guān)規(guī)范。在項目執(zhí)行過程中，質(zhì)量保證人員要不斷的按照項目計劃對項目進行有效的監(jiān)督和檢查?！肮ねㄟ^過程檢查，可以找出明顯不符合規(guī)范的工作過程或者工作成果，與時糾正幵發(fā)中的錯誤。因此，軟件測試只是保證質(zhì)量的最常用手段，僅僅通過測試是不能夠保證質(zhì)量的，還要輔以技術(shù)評審、過程檢查等手段。6、測試人員是否需要幵發(fā)技能？在很多測試網(wǎng)站的論壇上，這個問題都是津津樂道的熱門話題。而究其根源，主要是因為很多測試人員做不了幵發(fā)才來做測試，于是其中的很多人便懷著一些“膽怯”心理，與同行反復(fù)探討這個問題，期望其他人能夠肯定“即使不會幵發(fā)也能做好測試”的觀點，以便在心理上得到一些安慰。是否需要幵發(fā)技能與測試人員從事的測試工作種類有極大關(guān)系，相信很多人都聽過微軟曾經(jīng)聘用一名家庭主婦來測試操作系統(tǒng)的故事。實際上，如果從事單元測試、集成測試等較接近程序代碼的工作，無疑需要幵發(fā)技能，這類工作對測試人員幵發(fā)技能的要求甚至會超過程序員；而從事基本的界面測試、用戶功能測試，不會幵發(fā)不會有大的影響。但是，原則上還是建議測試人員最好具備一定的幵發(fā)能力，而且是幵發(fā)能力越強越好，幵發(fā)技能對測試工作可以說是“百利而無一害”，例如可以更容易避免報告重復(fù)的缺陷、對缺陷原因進行更準確的定位等等。同時，由于國內(nèi)多數(shù)公司對測試人員沒有分類，要想得到更多的發(fā)展機會，也應(yīng)該學(xué)會幵發(fā)，便于從事各種類型的測試工作，除非只從事那些遠離代碼的測試工作。此外，掌握一門幵發(fā)語言后，進行測試的時候可以站在程序幵發(fā)的角度進行思考，而且知道程序如何編寫，就更容易發(fā)現(xiàn)問題。7、測試的目的是什么?測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷，這個觀念很容易讓人接受，但是卻很難落實到實際工作中，因為測試的目的常常被定位為“證明軟件沒有問題”。軟件質(zhì)量是否優(yōu)良在投產(chǎn)后才能有所體現(xiàn)。正確理解測試的目的十分重要。如果認為測試的目的是為了說明程序中沒有缺陷，那么測試人員就會向這個目標靠攏，因而下意識地設(shè)計很多不易暴露錯誤的測試示例，這些測試用例恰恰證明軟件實現(xiàn)了預(yù)期功能，這樣的測試是不真實的。成功的測試在于發(fā)現(xiàn)了迄今尚未發(fā)現(xiàn)的缺陷，測試人員的職責是設(shè)計這樣的測試用例一一它能有效地揭示潛伏在軟件里的缺陷。8、一個軟件產(chǎn)品測試結(jié)束時沒有發(fā)現(xiàn)任何新的缺陷，這樣的軟件質(zhì)量一定好嗎？測試只能證明缺陷存在，不能證明缺陷不存在。而徹底的、全面的測試又難以成為現(xiàn)實，現(xiàn)實中要考慮時間、費用等限制，不允許無休止地測試。通常的測試結(jié)束，只是滿足一定條件下的測試結(jié)束，最后的“測試”還是交給了用戶。因此，即使測試結(jié)束了，質(zhì)量也不一定好。例如測試小組在時間緊迫的情況下，只測試了核心模塊，這樣的軟件系統(tǒng)質(zhì)量一般不會好。9、測試中的80-20原則是什么？測試中的80-20原則是說一般情況下，在分析、設(shè)計、實現(xiàn)階段的復(fù)審和測試工作能夠發(fā)現(xiàn)和避免80%的，而系統(tǒng)測試又能找出其余中的80%，最后的5%的可能只有在用戶的大范圍、長時間使用后才會暴露出來。因為測試只能夠保證盡可能多地發(fā)現(xiàn)錯誤，無法保證能夠發(fā)現(xiàn)所有的錯誤。還有就是一般情況下80％的缺陷聚集在20％的關(guān)鍵核心業(yè)務(wù)模塊中。10、測試到是測試工作的目標和原則嗎？通常對于相對復(fù)雜的產(chǎn)品或系統(tǒng)來說，是一種理想，是我們的原則。原則就是一種權(quán)衡投入/產(chǎn)出比的原則：不充分的測試是不負責任的；過分的測試是一種資源的浪費，同樣也是一種不負責任的表現(xiàn)。執(zhí)行測試工作的關(guān)鍵在于：如何界定什么樣的測試是不充分的，什么樣的測試是過分的。解決這一問題的通常方法是制定最低測試通過標準和測試內(nèi)容，然后具體問題具體分析。11、通常測試工作要達到什么目標？（1）確保產(chǎn)品完成了它所承諾或公布的功能。這一目標就是軟件要符合需求，開發(fā)出的軟件應(yīng)該達到所有功能都有明確的書面說明在某種意義上與9001是同一種思想，測試的首要目的就是保證所有預(yù)定功能是存在并且經(jīng)過規(guī)范的測試。當然書面文檔的不健全甚至不正確會導(dǎo)致測試效率低下、測試目標不明確和測試范圍不充分，進而導(dǎo)致最終測試的作用不能充分發(fā)揮、測試效果不理想。因此具體問題一定要具體分析，一個好的測試負責人盡量來彌補這些文檔缺陷。（2）確保產(chǎn)品滿足性能和效率的要求?，F(xiàn)在的用戶對軟件的性能方面的要求越來越高，使用起來系統(tǒng)運行效率低（性能低）、或用戶界面不友好、用戶操作不方便（效率低）的產(chǎn)品市場空間肯定會越來越小。因此通過測試改善性能也是測試工作一個目標。實際上用戶最關(guān)心的不是軟件的技術(shù)有多先進、功能有多強大，而是能從這些技術(shù)、這些功能中得到多少好處。也就是說，用戶關(guān)心的是他能從中取出多少，而不是你已經(jīng)放進去多少。（3）確保產(chǎn)品是健壯的、適應(yīng)用戶環(huán)境的。健壯性即穩(wěn)定性，是產(chǎn)品質(zhì)量的基本要求，尤其對于一個用于事務(wù)關(guān)鍵或時間關(guān)鍵的工作環(huán)境中的應(yīng)用系統(tǒng)。軟件只有穩(wěn)定的運行，才會不致于中斷用戶的工作，因此通過健壯性測試是軟件測試工作的又一個目標。2．測試管理部分1、測試負責人要進行嚴格的測試進度跟蹤嗎？很多時候，由于人力資源的不足，測試項目負責人都是在執(zhí)行測試，這樣就使整個項目缺乏控制，一些問題（例如：有些成員的缺陷質(zhì)量不夠合格；開發(fā)人員修改不與時，系統(tǒng)某些功能發(fā)生嚴重問題導(dǎo)致部分功能無法測試。）得不到解決，耽誤了進度。所以測試負責任必須全程監(jiān)控項目，盡可能多的掌握信息。通常，測試負責人需要完成下面這些內(nèi)容的管理工作：測試用例執(zhí)行情況；每個測試員提交的缺陷情況；測試中是否發(fā)生突發(fā)問題。2、測試也有版本控制嗎？這里的版本主要是指測試對象的版本控制，也就是指對開發(fā)部提交的產(chǎn)品進行版本控制。在開發(fā)小組版本管理不規(guī)范的情況下，測試小組進行版本控制十分重要，要保證測試對象是可以控制的。建議開發(fā)和測試雙方進行明確的約定，可以各自指定專門的測試版本負責人，制定提交原則，對提交情況進行詳細的記錄，這樣基本避免了版本失控導(dǎo)致的測試失誤或無效。3、如何處理測試人員的流動問題？人員流動不僅僅是測試部門，這是行業(yè)的普遍現(xiàn)象。從管理者角度，主管需要多多和團隊內(nèi)成員進行溝通，建立一個融洽的團隊環(huán)境，與時掌握情況，可以早些進行相應(yīng)的調(diào)整。但是只有企業(yè)建立好的用人制度，給員工提高廣闊的發(fā)展空間和好的培訓(xùn)學(xué)習機會，才能從根本上解決這一問題。加強項目管理，強化文檔管理并保證文檔的有效性，可以大大減少由于人員流失帶來的損失。同時，測試部門要建立培訓(xùn)機制，使新到員工接受直接或者間接的培訓(xùn)，快速適應(yīng)工作。4、為什么開發(fā)人員經(jīng)常抱怨測試工程師提交的缺陷質(zhì)量太差？我們經(jīng)常聽開發(fā)人員說：“這不是缺陷！”，“這個缺陷沒有，因為我的系統(tǒng)上運行正常！”。測試工程師本身就是做質(zhì)量工作的，提交的成果本身就應(yīng)該質(zhì)量高些，為什么還會有這種現(xiàn)象？提交的缺陷引起爭議是一種正常的現(xiàn)象，例如測試人員描述不清楚就會引起爭議。減少甚至避免這種現(xiàn)象的方法是交叉測試，交叉測試是提高測試質(zhì)量的一個有效手段，當然交叉測試會增加一定的測試成本投入。在測試任務(wù)完成后，測試工程師之間互相驗證彼此提交的缺陷，就會避免了缺陷描述不清、因運行環(huán)境而產(chǎn)生的缺陷等一系列問題，從而大大降低了回歸測試以與交流的成本，因而這種投入也是值得的，實際開發(fā)人員在單元測試階段也會進行交叉測試，來提高開發(fā)質(zhì)量。另外，測試人員一定要按照規(guī)范描述測試中發(fā)現(xiàn)的缺陷，一個缺陷至少描述清楚概要描述、詳細描述、重現(xiàn)步驟三方面的內(nèi)容。5、“讓那些新手來做測試，反正他們也不會什么”正確嗎？在實際項目開發(fā)中，我們常?？吹接行﹩挝缓鲆暅y試團隊存在的意義，當要實施測試時，往往臨時找?guī)讉€程序員充當測試人員。也有些單位盡管認識到了組建測試團隊的重要性，但在具體落實的時候往往安排一些毫無開發(fā)經(jīng)驗的行業(yè)新手去做測試工作，這常常導(dǎo)致測試效率低下，測試人員對測試工作索然無味。根據(jù)筆者的經(jīng)驗，測試團隊應(yīng)首先聘請一名資深的測試領(lǐng)域?qū)＜?，他?yīng)具有極為豐富的同類項目軟件測試經(jīng)驗，對軟件開發(fā)過程中常見的缺陷或錯誤了然于胸；此外，他還具有較好的親和力和人格魅力。其次，項目測試團隊還具有很多具備一技之長的成員，如對某些自動化測試工具運用嫻熟或能輕而易舉地編寫自動化測試腳本等。另外，測試團隊還應(yīng)聘請一些兼職成員，如驗證測試實施過程中，同行評審是最常使用的一種形式，這些同行專家就屬于兼職測試團隊成員的范疇。至于測試團隊里里的測試新手，這部分人可以安排去從事交付驗證或黑盒測試之類的工作。6、測試同化現(xiàn)象是什么？同化現(xiàn)象是指隨著時間的推移，開發(fā)人員會逐漸影響測試人員的思維和對缺陷的判斷能力，尤其是針對同一產(chǎn)品，同一組開發(fā)人員和同一組測試人員共同配合了很長時間，很多本來是缺陷的問題，由于測試人員對軟件“習慣成自然”的使用，會不被當成缺陷，尤其是在開發(fā)人員的解釋和說服下。同化現(xiàn)象發(fā)生可能意味著“惡性循環(huán)”的開始：測試人員會幫著開發(fā)人員解釋一個個缺陷的合理性，一輪有一輪的測試都不會發(fā)現(xiàn)問題。招聘新的人員，不同的測試項目組輪換去測試不同的產(chǎn)品，就可以避免。同時建議產(chǎn)品可以發(fā)布測試版，更多的人對其進行測試，就可以發(fā)現(xiàn)更多的問題。7、測試工程師如何避免定位效應(yīng)？社會心理學(xué)家曾作過一個試驗：在召集會議時先讓人們自由選擇位子，之后到室外休息片刻再進入室內(nèi)入座，如此五至六次，發(fā)現(xiàn)大多數(shù)人都選擇他們第一次坐過的位子。這種現(xiàn)象稱為定位效應(yīng)，說明人們習慣上凡是自己認定的，人們大都不想輕易改變它。定位效應(yīng)在開發(fā)人員和測試人員身上都有體現(xiàn)。例如開發(fā)工程師針對某一自己寫的功能，經(jīng)常進行代碼移植，這種復(fù)制的“功能”，由于上一次經(jīng)過調(diào)試，在新的地方往往不會認真調(diào)試，這些代碼往往會帶來共享變量沖突等許多種類型的缺陷。定位效應(yīng)體現(xiàn)在測試人員身上就是測試過的功能不再進行認真測試：在回歸測試時，之前由于進行過認真的測試，往往會認為某些功能是可靠，只要驗證一些以前發(fā)現(xiàn)的缺陷是否修改完成就可以了。這種現(xiàn)象在反復(fù)多次回歸時表現(xiàn)的更加突出，因為回歸測試中很多功能都會進行多次反復(fù)測試。眾所周知，開發(fā)人員在修改缺陷時往往會引入新的缺陷，測試人員的疏于防范就會把這些缺陷帶到用戶這里。解決這種問題的方案一般有兩個：完整的執(zhí)行測試用例：這種方法投入較大，但是在開發(fā)產(chǎn)品時最好在最后一次回歸測試時測試的執(zhí)行一次全部的測試用例。交叉測試：測試人員交叉測試，就可以很大程度的避免定位效應(yīng)。測試工程師在回歸測試時互相交換任務(wù)，反復(fù)測試某一功能的機會大大減少，從而也就不會“主觀的”人員某些功能沒有缺陷。通常上面的兩個方法都是結(jié)合使用的，既要進行交叉測試，又要全面執(zhí)行測試用例，測試覆蓋面要盡可能的廣泛。8、測試人員忽然辭職怎么辦？目前行業(yè)人員流動較大已經(jīng)成為一種不爭的事實，員工的辭職大多數(shù)都會給組織帶來一定的影響，而這種影響基本是不可能避免的。在測試領(lǐng)域，員工忽然辭職也會帶來很大的負面影響，尤其測試隊伍規(guī)模較小時。面對這種情況，我們所能做的，就是如何最大限度的降低這種影響。根據(jù)作者的經(jīng)驗，主要有兩種方法：第一種是在測試人員內(nèi)部建立一個良好的學(xué)習環(huán)境，大家互相學(xué)習，這樣某些特有技術(shù)不會被某一個人所掌握，而互相學(xué)習和提高自身，也是大多數(shù)成員愿意做的；第二種就是在組織中進行知識管理，把技術(shù)作為知識沉淀下來，這樣新的員工在接手工作時容易上手，通過學(xué)習快速適應(yīng)環(huán)境。此外，日常還要注意工作規(guī)范化，例如形成盡可能多的文檔，都可以降低員工離職帶來的損失。9、測試人員工作發(fā)生問題測試經(jīng)理應(yīng)該如何做？測試人員工作發(fā)生問題是測試經(jīng)理經(jīng)常要面對的問題，作為測試部門的領(lǐng)導(dǎo)，首先要做的是指出測試人員所犯的錯誤，使其盡快改正錯誤。唯一不能做的就是盯著下屬的錯誤不放?？偠⒅聦俚氖д`，是一個領(lǐng)導(dǎo)者的最大失誤。英國行為學(xué)家波特說：當遭受許多批評時，下級往往只記住開頭的一些，其余就不聽了，因為他們忙于思索論據(jù)來反駁開頭的批評。身為測試經(jīng)理要根據(jù)測試人員的心理來進行指導(dǎo)，最大限度的調(diào)動每個人員的積極性來參加工作。、不深入到具體測試工作時，測試經(jīng)理如何考核員工？這種現(xiàn)象在測試規(guī)模較大的組織中很常見。測試經(jīng)理應(yīng)該盡可能的安排每周與每個成員在不被打擾的環(huán)境下進行談話，這樣可以盡早發(fā)現(xiàn)和解決很多問題。做為一個測試經(jīng)理，主要工作之一就是定期的評定組織做了些什么并且是怎樣做的。同時還要為員工做一個報告——關(guān)于充分了解測試人員正在做什么和怎樣做的報告，以此來給測試人員做做工作成績考核。這份報告要了解到每個人的動態(tài)。測試經(jīng)理和每個員工重點是談?wù)勀壳暗墓ぷ鳎绱蠹以诠ぷ髦械膯栴}或意見；是否需要幫助等。許多管理者經(jīng)常抱怨沒有時間在一周會見每一個員工來談他們的工作。但是根據(jù)作者的經(jīng)驗，如果不能安排時間和員工進行每周的談話，員工會來打擾測試經(jīng)理的工作，因為員工很多問題還要要來找測試經(jīng)理商議。同時對待員工要用他們能接受的方式，而不是我們自己可以接受的方式?！凹核挥瑁鹗┯谌恕?，這條黃金法則可能會對許多生活中的純粹的社交因素有效，但是并不是總對工作有用。有效率的管理者知道應(yīng)該逐漸了解每一個員工需要怎樣的對待方式?？傊挥斜M可能多的和員工接觸，才能更精確的進行考核。、測試經(jīng)理如何面對加班問題？大多數(shù)情況下，作者是不主張加班的。當員工每周工作超過40個小時的時候，他們開始在工作的時候關(guān)心自己的事。他們花錢，會給很久沒有聯(lián)系的人打電話，因為員工們一直都在工作。員工不能在太疲勞的狀態(tài)下完成工作，這是因為他們在工作時不能關(guān)心自己，這種情況下通常效率很低。測試管理工作的重要任務(wù)之一就是要創(chuàng)造一個環(huán)境，讓員工在工作時間內(nèi)完成工作，同時還要鼓勵他們每周不要超過40小時，甚至可以基于他們在40個小時能夠完成的工作量給他們酬勞。通常情況下這樣做能夠提升創(chuàng)造力，從而會逐漸提高效率。測試工作本身的一個突出特點就是不斷重復(fù)枯燥、冗長的測試，如果在疲勞狀態(tài)下，很有可能精力不集中，略過一些重要的測試環(huán)節(jié)。而且有的時候測試需要編寫測試驅(qū)動程序，這種情況更需要較好的狀態(tài)來工作。、測試管理者如何面對自己的錯誤？每個人都會犯錯。我們可能會因為忘記開會而使客戶發(fā)怒，承認自己犯錯是一件尷尬的事情，尤其是管理人員認為對自己負責的項目小組承認犯錯可能會失去尊嚴。如果我們不是經(jīng)常犯錯，承認錯誤的時候其實能夠贏得尊敬。例如我們忘記一次會議，然后為此向同事或者客戶道歉，其他的人會理解我們的。不管做了什么，不要否認或故意忽略自己的失誤。故意忽略不會讓錯誤消失，這只會讓錯誤成長為怪物、為什么計劃定期的培訓(xùn)?測試工作和開發(fā)工作一樣，不但要面對日新月異的新技術(shù)，還要學(xué)習相關(guān)系統(tǒng)的領(lǐng)域知識。只有在不斷的學(xué)習中，才能做好工作，跟上行業(yè)的發(fā)展。如果測試管理者沒有基于不斷的變化而培訓(xùn)員工，就會給組織帶來一定的損失。日常培訓(xùn)可以是關(guān)于特定項目或者是技術(shù)，通常采用下面幾種方法：（1）測試部門內(nèi)自由交流方式的培訓(xùn)。這種培訓(xùn)的交流比較隨意，可以在周五的例會上進行交流，也可以大家一起坐在茶館里進行交流。方法可以采用“頭腦風暴法”，讓每個組員討論一個特定的領(lǐng)域，這種交流方法特別對同時要做很多不同項目的小組比較有益處。當每個人做不同的項目，這會有助于每個人了解你小組所有的工程。（2）跨部門的互相學(xué)習。測試工作需要很多領(lǐng)域以與技術(shù)知識，這些知識單靠自學(xué)是遠遠不夠的。和其它部門的同事進行交流是一個相當好的辦法，大家在工作中可以在技術(shù)等各個方面互相得到提高。（3）外部培訓(xùn)。外部培訓(xùn)盡管投入較高，但也是值得的。這些專家一般在自己的領(lǐng)域非常精通，可以快速提高整個測試團隊的水平。也可以通過測試小組介紹一些朋友來進行培訓(xùn)，這種方式可以降低成本。培訓(xùn)是構(gòu)造學(xué)習型組織的基本條件，也是提高員工水平的重要方法。經(jīng)常的定期培訓(xùn)，可以增強組織凝聚力，使員工更加愿意長期留在組織中發(fā)展。做為測試負責人，定期的進行培訓(xùn)是十分必要的。、時間上不允許進行全部測試，測試負責人應(yīng)該如何做？這個問題也許十分可笑，可是現(xiàn)實中我們的測試經(jīng)理們卻不得不面對這個問題。這里的全部測試不是指對軟件進行遍歷測試，而是指測試負責人制定的測試計劃包含的全部測試內(nèi)容。通常，不管是開發(fā)產(chǎn)品還是做具體的項目，都會發(fā)生耽誤進度的情況。一旦整體進度不能向后延遲，項目相關(guān)人員習慣上的做法就是縮減測試時間。尤其在功能還沒有開發(fā)完成的情況下，這種現(xiàn)象更為突出。擔負著質(zhì)量重任的測試經(jīng)理，如何來解決這個問題呢？比較好的做法是按照下面的步驟逐步來完成和改進工作：（1）按照測試任務(wù)的輕重緩急，盡最大努力完成測試任務(wù)。在時間不足的情況下，我們應(yīng)該對測試任務(wù)按照優(yōu)先級來劃分，重要緊急的任務(wù)先完成。這個時候的測試任務(wù)是一種輔助性工作，其目的就是盡最大努力來提高質(zhì)量。因此，面對這種情況，測試負責人要做的就是帶領(lǐng)測試小組充分利用所有資源來保證質(zhì)量。（2）在實際工作中和開發(fā)人員共同配合，逐步改進工作。只有整個團隊的軟件開發(fā)能力提高了，才能從根源上解決問題。因此，測試負責人要帶領(lǐng)團隊和開發(fā)小組共同尋找適合自己的開發(fā)模式，從而使項目規(guī)劃的更加合理，進而按照預(yù)定計劃來開展測試工作。總之，在任何情況下，測試負責人都不應(yīng)該抱怨。只有積極的面對問題，才能更好的解決問題。、公司不重視測試，測試負責人如何開展測試工作？目前國內(nèi)的軟件公司不重視測試仍然是一種普遍現(xiàn)象。盡管很多公司在意識上已經(jīng)開始重視測試，但是在具體工作中，往往由于追趕進度、節(jié)省資源等方面原因而忽略測試工作。在這種情況下，測試負責人仍要對軟件質(zhì)量負主要責任。在這種環(huán)境下，測試負責人應(yīng)該如何開展工作呢？首先，要主動去配合開發(fā)人員完成工作。尤其是不能抱怨環(huán)境，在任何情況下抱怨是不能解決問題的，只能加重矛盾的激化。在此基礎(chǔ)上，逐漸顯出測試工作的重要性，然后再逐步健全測試體系。其次，用實際行動來證明測試工作的重要性。只有測試工作的業(yè)績逐步表現(xiàn)出來，人們才會真正的注意到測試的重要性。因此，測試負責人從點滴開始做起，才能逐步做好測試工作。要想做好軟件，把開發(fā)的軟件產(chǎn)品形成商品，測試工作必須和開發(fā)一樣重視。否則，質(zhì)量不好的產(chǎn)品，很快會被市場淘汰的。現(xiàn)代的軟件規(guī)模越來越大，測試工作也會越來越重要，因此測試負責人只要堅持做好工作，可發(fā)揮作用的空間會越來越大。最后要說的是，如果真的是在一個沒有希望的團隊里，測試負責人可以考慮辭職。辭職也是一個不錯的選擇，到新的環(huán)境去發(fā)揮自己的能力，要比長時間的懷著“郁悶”的心情去工作好的多。、測試管理者需要是技術(shù)專家嗎？測試管理者在測試項目中的主要任務(wù)是制定測試策略，管理測試計劃的落實情況，并且還要為測試項目的進行創(chuàng)造良好的執(zhí)行環(huán)境。同時還要調(diào)動員工的創(chuàng)造性，對員工的工作作出評估。這些工作不一定要求測試管理者達到專家的水平。但是在實際工作中，由于測試人員的短缺，測試管理者常常做為測試員來執(zhí)行具體的測試任務(wù)。尤其在規(guī)模較小的測試團隊，測試管理者的日常工作通常以具體的測試執(zhí)行工作為主，這個時候更需要測試管理者有較好的背景知識?？傮w說來，技術(shù)方面的背景知識對測試管理者是十分有益的。例如：分配工作任務(wù)、做進度預(yù)算，以與一些具體的執(zhí)行工作，都需要一定的背景知識。當然，做為一個測試管理者，沒有必要精通所有的技術(shù)，那也是辦不到的。測試管理者做到正確的幫助員工最好地完成工作，并且提供最好的完成工作的環(huán)境就可以了。3．測試流程部分1、測試人員要需要何時參加需求分析？原則上，測試人員對需求了解得越深入對測試工作越有利，所以最好一開始就應(yīng)該參加需求分析工作。這樣可以帶來如下得好處：測試人員全程參與需求分析，對需求了解很深刻，減少了很多與開發(fā)人員的交互，節(jié)省了時間。測試人員參與前期開發(fā)討論，直接掌握了不清晰的需求點；早期確定測試用例的編寫思路，為測試打好了基礎(chǔ)；可以獲取一些測試數(shù)據(jù)，為測試用力設(shè)計提供幫助；可以發(fā)現(xiàn)需求不合理的地方，降低了測試成本。測試人員主要的工作之一就是確認系統(tǒng)是否正確實現(xiàn)了需求。測試人員不參與前期的工作，就只能依賴最后形成的需求文檔，甚至由開發(fā)人員來講解需求，而這些缺求可能發(fā)生了“問題”，因為這個需求是已經(jīng)經(jīng)過分析的需求，很多的內(nèi)容可能與用戶的真正要求發(fā)生了偏差。同時如果只看最后形成的需求文檔，對需求也會有理解上的偏差。因此作為測試人員要盡可能的獲取到“第一線”的需求資料，才能真正地了解用戶的業(yè)務(wù)，從而更好的對系統(tǒng)進行測試。當然，如果測試人員不能參與需求環(huán)節(jié)，一定要通過其他途徑保證需求的精確性，例如和開發(fā)人員進行集中討論需求疑問的項目會議，并且一定要加強測試案例評審，甚至于是測試需求的評審。2、系統(tǒng)測試階段低級缺陷較多怎么辦？在系統(tǒng)測試階段，如果仍有很多低級缺陷，說明測試對象是不合格的，沒有達到測試標準。如果系統(tǒng)階段發(fā)現(xiàn)的簡單缺陷（也就是不應(yīng)該有的缺陷）較多，最好停止測試，轉(zhuǎn)由開發(fā)人員進行測試，發(fā)現(xiàn)問題立刻修改，因為這種由測試人員進行的成本較高，反復(fù)交互還會耽誤進度。建議建立預(yù)測試制度：系統(tǒng)測試前對核心模塊進行抽查測試，如果問題較多（例如平均每個核心模塊發(fā)現(xiàn)10個以上缺陷），就可以停止本次測試，直到抽測后發(fā)現(xiàn)問題較少才可以啟動系統(tǒng)測試。3、缺陷流落到客戶那里有什么后果？如果軟件缺陷被遺落并流落到客戶那里，結(jié)果就是代價高昂的電話或者現(xiàn)場支持費用，還可能需要修復(fù)、重新測試和發(fā)布新的產(chǎn)品，更糟糕的情況是產(chǎn)品要被召回甚至被客戶起訴。這種成本付出非常高，幾乎是在內(nèi)部修改缺陷的幾何級數(shù)倍。質(zhì)量之父把質(zhì)量的費用分為整合費用和非整合費用兩類，整合費用是指與一次性計劃和執(zhí)行測試相關(guān)的全部費用，用于保證軟件按照預(yù)期方式進行。如果發(fā)現(xiàn)缺陷，經(jīng)過一系列的缺陷處理流程而解決缺陷，這種費用就是非整合費用。在自己的作品中詳細論述了內(nèi)部的整合費用和內(nèi)部的非整合費用之和遠遠小于外部也就是客戶引起的非整合費用?？傊?，軟件缺陷一定要盡可能的在內(nèi)部解決，這對節(jié)約成本、提高產(chǎn)品知名度都大有裨益。4、什么是冒煙測試？冒煙測試從操作上是一個隨機的測試，操作對象通常是核心業(yè)務(wù)模塊。測試員任意操作，要是發(fā)現(xiàn)多數(shù)功能走不下去（大概20％），那么這個冒煙測試就算是結(jié)束了。冒煙測試一般不用參照測試用例。執(zhí)行冒煙測試的目的是對要測試的產(chǎn)品進行一個大概的度量。如果冒煙測試不能通過，通常不會啟動測試計劃。因為軟件缺陷較多的情況下，啟動測試計劃會浪費更多的人力和物力。通俗的說，對“垃圾”產(chǎn)品執(zhí)行測試實際是測試人員搶了程序設(shè)計人員的工作，這些缺陷應(yīng)該在開發(fā)階段消滅，只有這樣才可以真正的節(jié)約成本。5、在集成測試的時候，已經(jīng)對一些子系統(tǒng)進行了功能測試、性能測試等等，那么在系統(tǒng)測試時能否跳過相同內(nèi)容的測試?因為集成測試是在仿真環(huán)境中開展的，那不是真正的目標系統(tǒng)。再者，單元測試和集成測試通常由開發(fā)小組執(zhí)行。根據(jù)測試心理學(xué)的分析，開發(fā)人員測試自己的工作成果雖然是必要的，但不能作為成果已經(jīng)通過測試的依據(jù)。為了保證測試的客觀性，應(yīng)當由機構(gòu)的獨立測試小組來執(zhí)行系統(tǒng)測試。6、什么是測試策略？測試策略描述測試工程的總體方法和目標。描述目前在進行哪一階段的測試（單元測試、集成測試、系統(tǒng)測試）以與每個階段內(nèi)在進行的測試種類（功能測試、性能測試、覆蓋測試等）。測試策略的制定主要包含三個方面的內(nèi)容：（1）確定測試過程要使用的測試技術(shù)和工具；（2）制定測試啟動、停止、完成標準；（3）進行風險分析和應(yīng)對方案。例如測試與外部接口或者模擬物理損壞、安全性威脅。測試計劃最關(guān)鍵的一步就是將軟件分解成單元，按照需求編寫測試計劃。7、代碼會審是如何進行的？在研發(fā)小組將所開發(fā)的程序經(jīng)驗證后，提交測試組后，測試實施工作基本開始了。這個時候，測試人員要仔細閱讀有關(guān)資料，包括規(guī)格說明、設(shè)計文檔、使用說明書與在設(shè)計過程中形成的測試大綱、測試內(nèi)容與測試的通過準則，全面熟悉系統(tǒng)，編寫測試計劃，設(shè)計測試用例，作好測試前的準備工作。為了保證測試的質(zhì)量，我們一般測試過程分成幾個階段，即：代碼審查、單元測試、集成測試和驗收測試。代碼會審是由一組人通過閱讀、討論和爭議對程序進行靜態(tài)分析的過程。會審小組由組長，2?3名程序設(shè)計和測試人員與程序員組成。 會審小組在充分閱讀待審程序文本、控制流程圖與有關(guān)要求、規(guī)范等文件基礎(chǔ)上，召開代碼會審會，程序員逐句講解程序的邏輯，并展開熱烈的討論甚至爭議，以揭示錯誤的關(guān)鍵所在。實踐表明，程序員在講解過程中能發(fā)現(xiàn)許多自己原來沒有發(fā)現(xiàn)的錯誤，而討論和爭議則進一步促使了問題的暴露。例如，對某個局部性小問題修改方法的討論，可能發(fā)現(xiàn)與之有牽連的甚至能涉與到模塊的功說明、模塊間接口和系統(tǒng)總結(jié)構(gòu)的大問題，導(dǎo)致對需求定義的重定義、重設(shè)計驗證，大大改善了軟件的質(zhì)量。代碼會審盡管需要一定的成本，但是在大型軟件中，是必不可少的。8、回歸測試中未解決的缺陷如何處理？軟件的后期測試就是一個反復(fù)回歸的工作，有些問題可能修改多次才能解決，尤其是那些在開發(fā)環(huán)境下不存在的問題，這些問題很容易被程序員忽視，拖到最后才解決。因此大部分回歸測試就是和開發(fā)人員反復(fù)配合解決那些上次測試中沒有解決的缺陷。這里重點討論的是最后一次回歸測試后，仍然發(fā)現(xiàn)有些缺陷沒有解決時測試經(jīng)理應(yīng)該如何做。在管理不規(guī)范的組織中，由于進度或者其它方面的壓力，開發(fā)工作已經(jīng)停止，通常會將這些問題置之不理。正確的做法時把這些沒有解決的問題形成一個未解決缺陷報告，然后召開項目會議進行討論，對不同的問題采取不同的處理方式：嚴重性的問題：有些問題較難解決，往往會被拖到最后，如果這類缺陷導(dǎo)致軟件功能發(fā)生障礙，則必須解決，這也是質(zhì)量控制的職責所在；功能性的問題：可以考慮升級時解決；一般性問題：不影響使用，可以不解決或者升級解決。這類項目會議通常需要技術(shù)總監(jiān)或者更高級別的人來參加。最后，需要對最終討論沒有解決的缺陷列表進行簽字并存檔，形成一個基線。特別要注意的某些缺陷是否修改不能由程序員或者測試人員來決定，這樣有可能帶來嚴重的后果——導(dǎo)致缺陷失控，最終形成沒有人對質(zhì)量負責的局面。9、狀態(tài)為已經(jīng)修改的缺陷沒有修改怎么辦？首先要對這類缺陷進行分析：(1)有些問題在開發(fā)環(huán)境下沒有重現(xiàn)，而開發(fā)人員迫于進度壓力，往往會把它標記為已經(jīng)修改。這種條件下測試人員應(yīng)該和開發(fā)人員進行直接溝通；有些問題測試人員沒有描述清楚，開發(fā)人員認為問題不存在也可能把問題標記為已經(jīng)修改(正確的做法是標記問題為商討或者不存在狀態(tài))。測試人員應(yīng)該清晰的描述問題，減少這類問題的發(fā)生，尤其要描述清楚運行環(huán)境以與缺陷的重現(xiàn)步驟；第三類情況