軟件測試工程師的疑惑

/軟件測試常見問題1．基礎學問部分1、如何描述一個缺陷？看到這個問題，或許有些讀者會覺得可笑：哪個測試人員不會描述缺陷？但是現(xiàn)實中卻真的存在許多測試人員提交的缺陷須要向開發(fā)人員進行說明或者演示后，才能讓人明白他真剛要表達的意思。事實上，是否能夠清楚地描述軟件缺陷，確定體現(xiàn)著一個測試人員的實力水平凹凸。除了極個別的不能重現(xiàn)的缺陷外，一個軟件缺陷至少應當描述清楚三方面的內容：缺陷概述、詳細內容、重現(xiàn)步驟。缺陷概述——用一到兩句話詳細地描述缺陷的癥狀，使管理人員一下子就能看明白或許是什么問題。詳細內容——詳細地描述缺陷的癥狀，可以發(fā)表自己對該缺陷的一些看法。詳細內容主要供程序員進行分析。重現(xiàn)步驟——詳細描述如何在系統(tǒng)中重現(xiàn)缺陷，這是特殊重要的一項內容，假如重現(xiàn)步驟描述的特殊清楚，將大大加快開發(fā)人員修改缺陷的速度。通常狀況下，許多缺陷管理軟件把“詳細內容”和“重現(xiàn)步驟”進行了合并，即只有一個文本輸入框供測試人員錄入信息，這就導致許多測試人員疏忽了去描述“重現(xiàn)步驟”。此外其他諸如測試版本、測試環(huán)境、發(fā)覺日期等幫助信息也應當細致錄入。2、缺陷是誰“生產”的？這是一個“老生常談”的問題。尤其在追究一些質量問題責任的時候。經常聽測試人員埋怨：“這些模塊簡直是垃圾！不值得測試！奢侈我的時間！”，開發(fā)人員則埋怨：“重要的問題發(fā)覺不了，卻成天盯著那些無關痛癢的小問題，還不如自己去測試！”。不符合用戶要求的都可以稱之為缺陷，因此缺陷的來源主要有兩類：一類是沒有正確理解用戶需求，由系統(tǒng)需求或者分析人員設計出來的缺陷，這類缺陷主要由設計人員“生產”；另外一類是程序開發(fā)人員沒有依據(jù)設計要求進行開發(fā)或者編寫的代碼存在錯誤而引起的缺陷，這類缺陷由程序開發(fā)人員“生產”。對于那些開發(fā)流程不規(guī)范的組織，通常開發(fā)人員會包辦測試前的大部分工作。在這種環(huán)境下，幾乎沒有什么設計文檔，軟件開發(fā)主要依據(jù)程序設計人員的想像來進行，這個時候的缺陷則主要由開發(fā)人員“生產”。測試人員不是缺陷的“生產”者，因為測試人員沒有寫過一行代碼，這是否意味著測試人員可以在一旁“幸災樂禍呢”？事實恰好相反，測試人員和缺陷關系更加密切，他們是“缺陷的缺陷”的制造者。所謂“缺陷的缺陷”，主要指測試人員提交的“不是缺陷”的缺陷，即測試人員沒有正確理解需求，從而提交了根本“不是缺陷”的缺陷，這種缺陷也是測試人員經常受到指責的重要緣由。關于上面的埋怨，測試和開發(fā)雙方都須要擺正心態(tài)：因為實際雙方都在不停的“生產”著缺陷，只是創(chuàng)建的方式不同罷了。3、缺陷產生的緣由是什么？在上個問題中，已經介紹了設計人員、開發(fā)人員、測試人員都會“生產”軟件缺陷。在實際工作中，缺陷產生的方式更是層出不窮，緣由也是多種多樣。例如開發(fā)人員去接杯水，碰巧和另外一個接水的同事聊了幾句，結果回到工位時遺忘了要在某個推斷語句追加此前已經想好的一個推斷條件，這無疑會產生一個缺陷。因此很難一下子把缺陷產生的緣由全部陳設出來，下面只是一些引起缺陷的典型緣由：（1）開發(fā)人員不太了解需求，不清楚應當“做什么”和“不做什么”，經常做不合需求的事情，因此產生了缺陷；（2）軟件系統(tǒng)越來越困難，開發(fā)人員不太可能精通全部的技術。假如不能正確地駕馭新的技術或者學問，可能會產生缺陷；（3）技術文檔普遍編寫的很差，甚至文檔本身就有缺陷，導致運用者產生更多的缺陷；（4）軟件需求、設計報告、程序經常發(fā)生變更，每次變更都可能產生新的缺陷；（5）任何人在編程時都可能犯錯誤，導致程序中有缺陷；（6）技術人員常處于進度的壓力之下，不能靜心思索也很簡潔產生缺陷，尤其是在Deadline接近之際，常見的加班是開發(fā)人員疲于應付進度；（7）許多開發(fā)人員過于自信，寵愛說“沒問題”，因此對于一些代碼不進行細致的調試，這也是一些缺陷產生的緣由；（8）常見的拷貝代碼也會把缺陷隨之復制到新的程序中，尤其是復制其它團隊成員的代碼更簡潔使一些缺陷隱藏在程序中。4、軟件的質量應當由什么人來負責？對于一些開發(fā)管理混亂或者測試剛剛起步的組織，產品質量一發(fā)生問題，習慣上會歸咎于測試小組，認為測試人員沒有測試好產品，所以才產生了那么多的缺陷。對于開發(fā)管理規(guī)范一些或者測試體系已經建立確定時間的組織，假如客戶投訴產品質量問題，則往往開發(fā)人員和測試人員會一起接受懲處。這種處理方式多少會讓測試人員心理稍稍平衡一些。追根溯源，軟件發(fā)生質量問題實際是項目管理不規(guī)范引起的。因此，假如要追究責任的話，軟件質量問題的責任應當由整個團隊來擔當。只有提高整個團隊的開發(fā)水平，才能提高質量。此外，也應當相識到軟件發(fā)覺問題是正常的現(xiàn)象，很少有軟件實現(xiàn)了零缺陷。做為公司領導者，應當詳細問題詳細分析，不要老是考慮如何懲處自己的成員。5、測試能保證質量嗎？在軟件質量方面，目前多數(shù)IT企業(yè)主要實行三種措施：技術評審、過程檢查、軟件測試。技術評審：技術評審最初是由IBM公司為了提高軟件質量和提高程序員工作效率而接受的，主要指對項目支配、軟件需求、系統(tǒng)設計等文檔進行有效評審的過程。技術評審可以由專家團隊組成，也可以由組織內部人員組成，它可以盡量避開設計人員在某些方面發(fā)生“閉門造車”的情形。通過技術評審，可以盡早地發(fā)覺工作成果中的缺陷，并幫助開發(fā)人員剛好消退缺陷，從而有效地提高產品的質量。過程檢查：屬于質量工程師（QA）的工作范疇，主要檢查軟件項目的“工作過程和工作成果”是否符合已經制定的相關規(guī)范。在項目執(zhí)行過程中，質量保證人員要不斷的依據(jù)項目支配對項目進行有效的監(jiān)督和檢查。通過過程檢查，可以找出明顯不符合規(guī)范的工作過程或者工作成果，剛好訂正開發(fā)中的錯誤。因此，軟件測試只是保證質量的最常用手段，僅僅通過測試是不能夠保證質量的，還要輔以技術評審、過程檢查等手段。6、測試人員是否須要開發(fā)技能？ 在許多測試網站的論壇上，這個問題都是津津樂道的熱門話題。而究其根源，主要是因為許多測試人員做不了開發(fā)才來做測試，于是其中的許多人便懷著一些“膽怯 ”心理，和同行反復探討這個問題，期望其他人能夠確定“即使不會開發(fā)也能做好測試”的觀點，以便在心理上得到一些勸慰。是否須要開發(fā)技能和測試人員從事的測試工作種類有極大關系，信任許多人都聽過微軟曾經聘用一名家庭主婦來測試Windows操作系統(tǒng)的故事。事實上，假如從事單元測試、集成測試等較接近程序代碼的工作，無疑須要開發(fā)技能，這類工作對測試人員開發(fā)技能的要求甚至會超過程序員；而從事基本的界面測試、用戶功能測試，不會開發(fā)不會有大的影響。但是，原則上還是建議測試人員最好具備確定的開發(fā)實力，而且是開發(fā)實力越強越好，開發(fā)技能對測試工作可以說是“百利而無一害”，例如可以更簡潔避開報告重復的缺陷、對缺陷緣由進行更精確的定位等等。同時，由于國內多數(shù)公司對測試人員沒有分類，要想得到更多的發(fā)展機會，也應當學會開發(fā)，便于從事各種類型的測試工作，除非只從事那些遠離代碼的測試工作。此外，駕馭一門開發(fā)語言后，進行測試的時候可以站在程序開發(fā)的角度進行思索，而且知道程序如何編寫，就更簡潔發(fā)覺問題。7、測試的目的是什么？測試的目的是為了發(fā)覺盡可能多的缺陷，這個觀念很簡潔讓人接受，但是卻很難落實到實際工作中，因為測試的目的經常被定位為“證明軟件沒有問題”。軟件質量是否優(yōu)良在投產后才能有所體現(xiàn)。正確理解測試的目的特殊重要。假如認為測試的目的是為了說明程序中沒有缺陷，那么測試人員就會向這個目標靠攏，因而下意識地設計許多不易暴露錯誤的測試示例，這些測試用例恰恰證明軟件實現(xiàn)了預期功能，這樣的測試是不真實的。成功的測試在于發(fā)覺了迄今尚未發(fā)覺的缺陷，測試人員的職責是設計這樣的測試用例——它能有效地揭示潛藏在軟件里的缺陷。8、一個軟件產品測試結束時沒有發(fā)覺任何新的缺陷，這樣的軟件質量確定好嗎？測試只能證明缺陷存在，不能證明缺陷不存在。而徹底的、全面的測試又難以成為現(xiàn)實，現(xiàn)實中要考慮時間、費用等限制，不允許無休止地測試。通常的測試結束，只是滿足確定條件下的測試結束，最終的“測試”還是交給了用戶。因此，即使測試結束了，質量也不確定好。例如測試小組在時間緊迫的狀況下，只測試了核心模塊，這樣的軟件系統(tǒng)質量一般不會好。9、測試中的80-20原則是什么？測試中的80-20原則是說一般狀況下，在分析、設計、實現(xiàn)階段的復審和測試工作能夠發(fā)覺和避開80%的Bug，而系統(tǒng)測試又能找出其余Bug中的80%，最終的5%的Bug可能只有在用戶的大范圍、長時間運用后才會暴露出來。因為測試只能夠保證盡可能多地發(fā)覺錯誤，無法保證能夠發(fā)覺全部的錯誤。還有就是一般狀況下80％的缺陷聚集在20％的關鍵核心業(yè)務模塊中。10、測試到Zero-bug是測試工作的目標和原則嗎？通常對于相對困難的產品或系統(tǒng)來說，Zero-bug是一種志向，Good-enough是我們的原則。Good-enough原則就是一種權衡投入/產出比的原則：不充分的測試是不負責任的；過分的測試是一種資源的奢侈，同樣也是一種不負責任的表現(xiàn)。執(zhí)行測試工作的關鍵在于：如何界定什么樣的測試是不充分的，什么樣的測試是過分的。解決這一問題的通常方法是制定最低測試通過標準和測試內容，然后詳細問題詳細分析。11、通常測試工作要達到什么目標？（1）確保產品完成了它所承諾或公布的功能。這一目標就是軟件要符合需求，開發(fā)出的軟件應當達到全部功能都有明確的書面說明在某種意義上和ISO9001是同一種思想，測試的首要目的就是保證全部預定功能是存在并且經過規(guī)范的測試。當然書面文檔的不健全甚至不正確會導致測試效率低下、測試目標不明確和測試范圍不充分，進而導致最終測試的作用不能充分發(fā)揮、測試效果不志向。因此詳細問題確定要詳細分析，一個好的測試負責人盡量來彌補這些文檔缺陷。（2）確保產品滿足性能和效率的要求?，F(xiàn)在的用戶對軟件的性能方面的要求越來越高，運用起來系統(tǒng)運行效率低(性能低)、或用戶界面不友好、用戶操作不便利(效率低)的產品市場空間確定會越來越小。因此通過測試改善性能也是測試工作一個目標。事實上用戶最關切的不是軟件的技術有多先進、功能有多強大，而是能從這些技術、這些功能中得到多少好處。也就是說，用戶關切的是他能從中取出多少，而不是你已經放進去多少。（3）確保產品是健壯的、適應用戶環(huán)境的。健壯性即穩(wěn)定性，是產品質量的基本要求，尤其對于一個用于事務關鍵或時間關鍵的工作環(huán)境中的應用系統(tǒng)。軟件只有穩(wěn)定的運行，才會不致于中斷用戶的工作，因此通過健壯性測試是軟件測試工作的又一個目標。

2．測試管理部分1、測試負責人要進行嚴格的測試進度跟蹤嗎？許多時候，由于人力資源的不足，測試項目負責人都是在執(zhí)行測試，這樣就使整個項目缺乏限制，一些問題（例如：有些成員的缺陷質量不夠合格；開發(fā)人員修改不剛好，系統(tǒng)某些功能發(fā)生嚴峻問題導致部分功能無法測試。）得不到解決，耽擱了進度。所以測試負責任必需全程監(jiān)控項目，盡可能多的駕馭信息。通常，測試負責人須要完成下面這些內容的管理工作：測試用例執(zhí)行狀況；每個測試員提交的缺陷狀況；測試中是否發(fā)生突發(fā)問題。2、測試也有版本限制嗎？這里的版本主要是指測試對象的版本限制，也就是指對開發(fā)部提交的產品進行版本限制。在開發(fā)小組版本管理不規(guī)范的狀況下，測試小組進行版本限制特殊重要，要保證測試對象是可以限制的。建議開發(fā)和測試雙方進行明確的約定，可以各自指定特地的測試版本負責人，制定提交原則，對提交狀況進行詳細的記錄，這樣基本避開了版本失控導致的測試失誤或無效。3、如何處理測試人員的流淌問題？人員流淌不僅僅是測試部門，這是IT行業(yè)的普遍現(xiàn)象。從管理者角度，主管須要多多和團隊內成員進行溝通，建立一個融洽的團隊環(huán)境，剛好駕馭狀況，可以早些進行相應的調整。但是只有企業(yè)建立好的用人制度，給員工提高廣袤的發(fā)展空間和好的培訓學習機會，才能從根本上解決這一問題。加強項目管理，強化文檔管理并保證文檔的有效性，可以大大削減由于人員流失帶來的損失。同時，測試部門要建立培訓機制，使新到員工接受干脆或者間接的培訓，快速適應工作。4、為什么開發(fā)人員經常埋怨測試工程師提交的缺陷質量太差？我們經常聽開發(fā)人員說：“這不是缺陷！”，“這個缺陷沒有，因為我的系統(tǒng)上運行正常！”。測試工程師本身就是做質量工作的，提交的成果本身就應當質量高些，為什么還會有這種現(xiàn)象？提交的缺陷引起爭議是一種正常的現(xiàn)象，例如測試人員描述不清楚就會引起爭議。削減甚至避開這種現(xiàn)象的方法是交叉測試，交叉測試是提高測試質量的一個有效手段，當然交叉測試會增加確定的測試成本投入。在測試任務完成后，測試工程師之間相互驗證彼此提交的缺陷，就會避開了缺陷描述不清、因運行環(huán)境而產生的缺陷等一系列問題，從而大大降低了回來測試以及溝通的成本，因而這種投入也是值得的，實際開發(fā)人員在單元測試階段也會進行交叉測試，來提高開發(fā)質量。另外，測試人員確定要依據(jù)規(guī)范描述測試中發(fā)覺的缺陷，一個缺陷至少描述清楚概要描述、詳細描述、重現(xiàn)步驟三方面的內容。5、“讓那些新手來做測試，反正他們也不會什么”正確嗎？在實際項目開發(fā)中，我們經?？吹接行﹩挝缓鲆暅y試團隊存在的意義，當要實施測試時，往往臨時找?guī)讉€程序員充當測試人員。也有些單位盡管相識到了組建測試團隊的重要性，但在詳細落實的時候往往支配一些毫無開發(fā)閱歷的行業(yè)新手去做測試工作，這經常導致測試效率低下，測試人員對測試工作索然無味。依據(jù)筆者的閱歷，測試團隊應首先聘請一名資深的測試領域專家，他應具有極為豐富的同類項目軟件測試閱歷，對軟件開發(fā)過程中常見的缺陷或錯誤了然于胸；此外，他還具有較好的親和力和人格魅力。其次，項目測試團隊還具有許多具備一技之長的成員，如對某些自動化測試工具運用嫻熟或能輕而易舉地編寫自動化測試腳本等。另外，測試團隊還應聘請一些兼職成員，如驗證測試實施過程中，同行評審是最常運用的一種形式，這些同行專家就屬于兼職測試團隊成員的范疇。至于測試團隊里里的測試新手，這部分人可以支配去從事交付驗證或黑盒測試之類的工作。6、測試同化現(xiàn)象是什么？同化現(xiàn)象是指隨著時間的推移，開發(fā)人員會慢慢影響測試人員的思維和對缺陷的推斷實力，尤其是針對同一產品，同一組開發(fā)人員和同一組測試人員共同協(xié)作了很長時間，許多原來是缺陷的問題，由于測試人員對軟件“習慣成自然”的運用，會不被當成缺陷，尤其是在開發(fā)人員的說明和勸服下。同化現(xiàn)象發(fā)生可能意味著“惡性循環(huán)”的起先：測試人員會幫著開發(fā)人員說明一個個缺陷的合理性，一輪有一輪的測試都不會發(fā)覺問題。聘請新的人員，不同的測試項目組輪換去測試不同的產品，就可以避開。同時建議產品可以發(fā)布測試版，更多的人對其進行測試，就可以發(fā)覺更多的問題。7、測試工程師如何避開定位效應？社會心理學家曾作過一個試驗：在召集會議時先讓人們自由選擇位子，之后到室外休息片刻再進入室內入座，如此五至六次，發(fā)覺大多數(shù)人都選擇他們第一次坐過的位子。這種現(xiàn)象稱為定位效應，說明人們習慣上凡是自己認定的，人們大都不想輕易變更它。定位效應在開發(fā)人員和測試人員身上都有體現(xiàn)。例如開發(fā)工程師針對某一自己寫的功能，經常進行代碼移植，這種復制的“功能”，由于上一次經過調試，在新的地方往往不會細致調試，這些代碼往往會帶來共享變量沖突等許多種類型的缺陷。定位效應體現(xiàn)在測試人員身上就是測試過的功能不再進行細致測試：在回來測試時，之前由于進行過細致的測試，往往會認為某些功能是牢靠，只要驗證一些以前發(fā)覺的缺陷是否修改完成就可以了。這種現(xiàn)象在反復多次回來時表現(xiàn)的更加突出，因為回來測試中許多功能都會進行多次反復測試。眾所周知，開發(fā)人員在修改缺陷時往往會引入新的缺陷，測試人員的疏于防范就會把這些缺陷帶到用戶這里。解決這種問題的方案一般有兩個：(1)

完整的執(zhí)行測試用例：這種方法投入較大，但是在開發(fā)產品時最好在最終一次回來測試時測試的執(zhí)行一次全部的測試用例。(2)

交叉測試：測試人員交叉測試，就可以很大程度的避開定位效應。測試工程師在回來測試時相互交換任務，反復測試某一功能的機會大大削減，從而也就不會“主觀的”人員某些功能沒有缺陷。通常上面的兩個方法都是結合運用的，既要進行交叉測試，又要全面執(zhí)行測試用例，測試覆蓋面要盡可能的廣泛。8、測試人員突然辭職怎么辦？目前IT行業(yè)人員流淌較大已經成為一種不爭的事實，員工的辭職大多數(shù)都會給組織帶來確定的影響，而這種影響基本是不行能避開的。在測試領域，員工突然辭職也會帶來很大的負面影響，尤其測試隊伍規(guī)模較小時。面對這種狀況，我們所能做的，就是如何最大限度的降低這種影響。依據(jù)作者的閱歷，主要有兩種方法：第一種是在測試人員內部建立一個良好的學習環(huán)境，大家相互學習，這樣某些特有技術不會被某一個人所駕馭，而相互學習和提高自身，也是大多數(shù)成員情愿做的；其次種就是在組織中進行學問管理，把技術作為學問沉淀下來，這樣新的員工在接手工作時簡潔上手，通過學習快速適應環(huán)境。此外，日常還要留意工作規(guī)范化，例如形成盡可能多的文檔，都可以降低員工離職帶來的損失。9、測試人員工作發(fā)生問題測試經理應當如何做？測試人員工作發(fā)生問題是測試經理經常要面對的問題，作為測試部門的領導，首先要做的是指出測試人員所犯的錯誤，使其盡快改正錯誤。唯一不能做的就是盯著下屬的錯誤不放。總盯著下屬的失誤，是一個領導者的最大失誤。英國行為學家波特說：當遭受許多指責時，下級往往只記住開頭的一些，其余就不聽了，因為他們忙于思索論據(jù)來反對開頭的指責。身為測試經理要依據(jù)測試人員的心理來進行指導，最大限度的調動每個人員的主動性來參加工作。10、不深化到詳細測試工作時，測試經理如何考核員工？這種現(xiàn)象在測試規(guī)模較大的組織中很常見。測試經理應當盡可能的支配每周和每個成員在不被打擾的環(huán)境下進行談話，這樣可以盡早發(fā)覺和解決許多問題。做為一個測試經理，主要工作之一就是定期的評定組織做了些什么并且是怎樣做的。同時還要為員工做一個報告——關于充分了解測試人員正在做什么和怎樣做的報告，以此來給測試人員做做工作成果考核。這份報告要了解到每個人的動態(tài)。測試經理和每個員工重點是談談目前的工作，例如大家在工作中的問題或看法；是否須要幫助等。許多管理者經常埋怨沒有時間在一周會見每一個員工來談他們的工作。但是依據(jù)作者的閱歷，假如不能支配時間和員工進行每周的談話，員工會來打擾測試經理的工作，因為員工許多問題還要要來找測試經理協(xié)商。同時對待員工要用他們能接受的方式，而不是我們自己可以接受的方式?！凹核挥?，勿施于人”，這條黃金法則可能會對許多生活中的純粹的社交因素有效，但是并不是總對工作有用。有效率的管理者知道應當慢慢了解每一個員工須要怎樣的對待方式?？傊?，只有盡可能多的和員工接觸，才能更精確的進行考核。11、測試經理如何面對加班問題？大多數(shù)狀況下，作者是不主見加班的。當員工每周工作超過40個小時的時候，他們起先在工作的時候關切自己的事。他們花錢，會給很久沒有聯(lián)系的人打電話，因為員工們始終都在工作。員工不能在太乏累的狀態(tài)下完成工作，這是因為他們在工作時不能關切自己，這種狀況下通常效率很低。測試管理工作的重要任務之一就是要創(chuàng)建一個環(huán)境，讓員工在工作時間內完成工作，同時還要激勵他們每周不要超過40小時，甚至可以基于他們在40個小時能夠完成的工作量給他們酬勞。通常狀況下這樣做能夠提升創(chuàng)建力，從而會慢慢提高效率。測試工作本身的一個突出特點就是不斷重復枯燥、冗長的測試，假如在乏累狀態(tài)下，很有可能精力不集中，略過一些重要的測試環(huán)節(jié)。而且有的時候測試須要編寫測試驅動程序，這種狀況更須要較好的狀態(tài)來工作。12、測試管理者如何面對自己的錯誤？每個人都會犯錯。我們可能會因為遺忘開會而使客戶發(fā)怒，承認自己犯錯是一件尷尬的事情，尤其是管理人員認為對自己負責的項目小組承認犯錯可能會失去尊嚴。假如我們不是經常犯錯，承認錯誤的時候其實能夠贏得敬重。例如我們遺忘一次會議，然后為此向同事或者客戶致歉，其他的人會理解我們的。不管做了什么，不要否認或有意忽視自己的失誤。有意忽視不會讓錯誤消逝，這只會讓錯誤成長為怪物。13、為什么支配定期的培訓?測試工作和開發(fā)工作一樣，不但要面對日新月異的新技術，還要學習相關系統(tǒng)的領域學問。只有在不斷的學習中，才能做好工作，跟上行業(yè)的發(fā)展。假如測試管理者沒有基于不斷的變更而培訓員工，就會給組織帶來確定的損失。日常培訓可以是關于特定項目或者是技術，通常接受下面幾種方法：（1）測試部門內自由溝通方式的培訓。這種培訓的溝通比較隨意，可以在周五的例會上進行溝通，也可以大家一起坐在茶館里進行溝通。方法可以接受“頭腦風暴法”，讓每個組員探討一個特定的領域，這種溝通方法特殊對同時要做許多不同項目的小組比較有好處。當每個人做不同的項目，這會有助于每個人了解你小組全部的工程。（2）跨部門的相互學習。測試工作須要許多領域以及技術學問，這些學問單靠自學是遠遠不夠的。和其它部門的同事進行溝通是一個相當好的方法，大家在工作中可以在技術等各個方面相互得到提高。（3）外部培訓。外部培訓盡管投入較高，但也是值得的。這些專家一般在自己的領域特殊精通，可以快速提高整個測試團隊的水平。也可以通過測試小組介紹一些摯友來進行培訓，這種方式可以降低成本。培訓是構造學習型組織的基本條件，也是提高員工水平的重要方法。經常的定期培訓，可以增加組織凝合力，使員工更加情愿長期留在組織中發(fā)展。做為測試負責人，定期的進行培訓是特殊必要的。14、時間上不允許進行全部測試，測試負責人應當如何做？這個問題或許特殊可笑，可是現(xiàn)實中我們的測試經理們卻不得不面對這個問題。這里的全部測試不是指對軟件進行遍歷測試，而是指測試負責人制定的測試支配包含的全部測試內容。通常，不管是開發(fā)產品還是做詳細的項目，都會發(fā)生耽擱進度的狀況。一旦整體進度不能向后延遲，項目相關人員習慣上的做法就是縮減測試時間。尤其在功能還沒有開發(fā)完成的狀況下，這種現(xiàn)象更為突出。擔負著質量重任的測試經理，如何來解決這個問題呢？比較好的做法是依據(jù)下面的步驟逐步來完成和改進工作：（1）依據(jù)測試任務的輕重緩急，盡最大努力完成測試任務。在時間不足的狀況下，我們應當對測試任務依據(jù)優(yōu)先級來劃分，重要緊急的任務先完成。這個時候的測試任務是一種幫助性工作，其目的就是盡最大努力來提高質量。因此，面對這種狀況，測試負責人要做的就是帶領測試小組充分利用全部資源來保證質量。（2）在實際工作中和開發(fā)人員共同協(xié)作，逐步改進工作。只有整個團隊的軟件開發(fā)實力提高了，才能從根源上解決問題。因此，測試負責人要帶領團隊和開發(fā)小組共同找尋適合自己的開發(fā)模式，從而使項目規(guī)劃的更加合理，進而依據(jù)預定支配來開展測試工作。總之，在任何狀況下，測試負責人都不應當埋怨。只有主動的面對問題，才能更好的解決問題。15、公司不重視測試，測試負責人如何開展測試工作？目前國內的軟件公司不重視測試照舊是一種普遍現(xiàn)象。盡管許多公司在意識上已經起先重視測試，但是在詳細工作中，往往由于追逐進度、節(jié)約資源等方面緣由而忽視測試工作。在這種狀況下，測試負責人仍要對軟件質量負主要責任。在這種環(huán)境下，測試負責人應當如何開展工作呢？首先，要主動去協(xié)作開發(fā)人員完成工作。尤其是不能埋怨環(huán)境，在任何狀況下埋怨是不能解決問題的，只能加重沖突的激化。在此基礎上，慢慢顯出測試工作的重要性，然后再逐步健全測試體系。其次，用實際行動來證明測試工作的重要性。只有測試工作的業(yè)績逐步表現(xiàn)出來，人們才會真正的留意到測試的重要性。因此，測試負責人從點滴起先做起，才能逐步做好測試工作。要想做好軟件，把開發(fā)的軟件產品形成商品，測試工作必需和開發(fā)一樣重視。否則，質量不好的產品，很快會被市場淘汰的?，F(xiàn)代的軟件規(guī)模越來越大，測試工作也會越來越重要，因此測試負責人只要堅持做好工作，可發(fā)揮作用的空間會越來越大。最終要說的是，假如真的是在一個沒有希望的團隊里，測試負責人可以考慮辭職。辭職也是一個不錯的選擇，到新的環(huán)境去發(fā)揮自己的實力，要比長時間的懷著“郁悶”的心情去工作好的多。16、測試管理者須要是技術專家嗎？測試管理者在測試項目中的主要任務是制定測試策略，管理測試支配的落實狀況，并且還要為測試項目的進行創(chuàng)建良好的執(zhí)行環(huán)境。同時還要調動員工的創(chuàng)建性，對員工的工作作出評估。這些工作不確定要求測試管理者達到專家的水平。但是在實際工作中，由于測試人員的短缺，測試管理者經常做為測試員來執(zhí)行詳細的測試任務。尤其在規(guī)模較小的測試團隊，測試管理者的日常工作通常以詳細的測試執(zhí)行工作為主，這個時候更須要測試管理者有較好的背景學問?？傮w說來，技術方面的背景學問對測試管理者是特殊有益的。例如：支配工作任務、做進度預算，以及一些詳細的執(zhí)行工作，都須要確定的背景學問。當然，做為一個測試管理者，沒有必要精通全部的技術，那也是辦不到的。測試管理者做到正確的幫助員工最好地完成工作，并且供應最好的完成工作的環(huán)境就可以了。

3．測試流程部分1、測試人員要須要何時參加需求分析？原則上，測試人員對需求了解得越深化對測試工作越有利，所以最好一起先就應當參加需求分析工作。這樣可以帶來如下得好處：測試人員全程參和需求分析，對需求了解很深刻，削減了許多和開發(fā)人員的交互，節(jié)約了時間。測試人員參和前期開發(fā)探討，干脆駕馭了不清楚的需求點；早期確定測試用例的編寫思路，為測試打好了基礎；可以獲得一些測試數(shù)據(jù)，為測試用力設計供應幫助；可以發(fā)覺需求不合理的地方，降低了測試成本。測試人員主要的工作之一就是確認系統(tǒng)是否正的確現(xiàn)了需求。測試人員不參和前期的工作，就只能依靠最終形成的需求文檔，甚至由開發(fā)人員來講解需求，而這些缺求可能發(fā)生了“問題”，因為這個需求是已經經過分析的需求，許多的內容可能和用戶的真剛要求發(fā)生了偏差。同時假如只看最終形成的需求文檔，對需求也會有理解上的偏差。因此作為測試人員要盡可能的獲得到“第一線”的需求資料，才能真正地了解用戶的業(yè)務，從而更好的對系統(tǒng)進行測試。當然，假如測試人員不能參和需求環(huán)節(jié)，確定要通過其他途徑保證需求的精確性，例如和開發(fā)人員進行集中探討需求疑問的項目會議，并且確定要加強測試案例評審，甚至于是測試需求的評審。2、系統(tǒng)測試階段低級缺陷較多怎么辦？在系統(tǒng)測試階段，假如仍有許多低級缺陷，說明測試對象是不合格的，沒有達到測試標準。假如系統(tǒng)階段發(fā)覺的簡潔缺陷（也就是不應當有的缺陷）較多，最好停止測試，轉由開發(fā)人員進行測試，發(fā)覺問題馬上修改，因為這種由測試人員進行的成本較高，反復交互還會耽擱進度。建議建立預料試制度：系統(tǒng)測試前對核心模塊進行抽查測試，假如問題較多（例如平均每個核心模塊發(fā)覺10個以上缺陷），就可以停止本次測試，直到抽測后發(fā)覺問題較少才可以啟動系統(tǒng)測試。3、缺陷流落到客戶那里有什么后果？假如軟件缺陷被遺忘并流落到客戶那里，結果就是代價昂揚的電話或者現(xiàn)場支持費用，還可能須要修復、重新測試和發(fā)布新的產品，更糟糕的狀況是產品要被召回甚至被客戶起訴。這種成本付出特殊高，幾乎是在內部修改缺陷的幾何級數(shù)倍。質量之父PhilipCrosby把質量的費用分為整合費用和非整合費用兩類，整合費用是指和一次性支配和執(zhí)行測試相關的全部費用，用于保證軟件依據(jù)預期方式進行。假如發(fā)覺缺陷，經過一系列的缺陷處理流程而解決缺陷，這種費用就是非整合費用。PhilipCrosby在自己的作品中詳細論述了內部的整合費用和內部的非整合費用之和遠遠小于外部也就是客戶引起的非整合費用?？傊?，軟件缺陷確定要盡可能的在內部解決，這對節(jié)約成本、提高產品知名度都大有裨益。4、什么是冒煙測試？冒煙測試從操作上是一個隨機的測試，操作對象通常是核心業(yè)務模塊。測試員隨意操作，要是發(fā)覺多數(shù)功能走不下去（或許20％），那么這個冒煙測試就算是結束了。冒煙測試一般不用參照測試用例。執(zhí)行冒煙測試的目的是對要測試的產品進行一個或許的度量。假如冒煙測試不能通過，通常不會啟動測試支配。因為軟件缺陷較多的狀況下，啟動測試支配會奢侈更多的人力和物力。通俗的說，對“垃圾”產品執(zhí)行測試實際是測試人員搶了程序設計人員的工作，這些缺陷應當在開發(fā)階段殲滅，只有這樣才可以真正的節(jié)約成本。5、在集成測試的時候，已經對一些子系統(tǒng)進行了功能測試、性能測試等等，那么在系統(tǒng)測試時能否跳過相同內容的測試?因為集成測試是在仿真環(huán)境中開展的，那不是真正的目標系統(tǒng)。再者，單元測試和集成測試通常由開發(fā)小組執(zhí)行。依據(jù)測試心理學的分析，開發(fā)人員測試自己的工作成果雖然是必要的，但不能作為成果已經通過測試的依據(jù)。為了保證測試的客觀性，應當由機構的獨立測試小組來執(zhí)行系統(tǒng)測試。6、什么是測試策略？測試策略描述測試工程的總體方法和目標。描述目前在進行哪一階段的測試（單元測試、集成測試、系統(tǒng)測試）以及每個階段內在進行的測試種類（功能測試、性能測試、覆蓋測試等）。測試策略的制定主要包含三個方面的內容：（1）確定測試過程要運用的測試技術和工具；（2）制定測試啟動、停止、完成標準；（3）進行風險分析和應對方案。例如測試和外部接口或者模擬物理損壞、平安性威逼。測試支配最關鍵的一步就是將軟件分解成單元，依據(jù)需求編寫測試支配。7、代碼會審是如何進行的？在研發(fā)小組將所開發(fā)的程序閱歷證后，提交測試組后，測試實施工作基本起先了。這個時候，測試人員要細致閱讀有關資料，包括規(guī)格說明、設計文檔、運用說明書及在設計過程中形成的測試大綱、測試內容及測試的通過準則，全面熟悉系統(tǒng)，編寫測試支配，設計測試用例，作好測試前的準備工作。為了保證測試的質量，我們一般測試過程分成幾個階段，即：代碼審查、單元測試、集成測試和驗收測試。代碼會審是由一組人通過閱讀、探討和爭議對程序進行靜態(tài)分析的過程。會審小組由組長，2～3名程序設計和測試人員及程序員組成。會審小組在充分閱讀待審程序文本、限制流程圖及有關要求、規(guī)范等文件基礎上，召開代碼會審會，程序員逐句講解程序的邏輯，并綻開熱忱的探討甚至爭議，以揭示錯誤的關鍵所在。實踐表明，程序員在講解過程中能發(fā)覺許多自己原來沒有發(fā)覺的錯誤，而探討和爭議則進一步促使了問題的暴露。例如，對某個局部性小問題修改方法的探討，可能發(fā)覺和之有牽連的甚至能涉及到模塊的功說明、模塊間接口和系統(tǒng)總結構的大問題，導致對需求定義的重定義、重設計驗證，大大改善了軟件的質量。代碼會審盡管須要確定的成本，但是在大型軟件中，是必不行少的。8、回來測試中未解決的缺陷如何處理？軟件的后期測試就是一個反復回來的工作，有些問題可能修改多次才能解決，尤其是那些在開發(fā)環(huán)境下不存在的問題，這些問題很簡潔被程序員忽視，拖到最終才解決。因此大部分回來測試就是和開發(fā)人員反復協(xié)作解決那些上次測試中沒有解決的缺陷。這里重點探討的是最終一次回來測試后，照舊發(fā)覺有些缺陷沒有解決時測試經理應當如何做。在管理不規(guī)范的組織中，由于進度或者其它方面的壓力，開發(fā)工作已經停止，通常會將這些問題束之高閣。正確的做法時把這些沒有解決的問題形成一個未解決缺陷報告，然后召開項目會議進行探討，對不同的問題實行不同的處理方式：(1)

嚴峻性的問題：有些問題較難解決，往往會被拖到最終，假如這類缺陷導致軟件功能發(fā)生障礙，則必需解決，這也是質量限制的職責所在；(2)功能性的問題：可以考慮升級時解決；(3)一般性問題：不影響運用，可以不解決或者升級解決。這類項目會議通常須要技術總監(jiān)或者更高級別的人來參加。最終，須要對最終探討沒有解決的缺陷列表進行簽字并存檔，形成一個基線。特殊要留意的某些缺陷是否修改不能由程序員或者測試人員來確定，這樣有可能帶來嚴峻的后果——導致缺陷失控，最終形成沒有人對質量負責的局面。9、狀態(tài)為已經修改的缺陷沒有修改怎么辦？首先要對這類缺陷進行分析：(1)

有些問題在開發(fā)環(huán)境下沒有重現(xiàn)，而開發(fā)人員迫于進度壓力，往往會把它標記為已經修改。這種條件下測試人員應當和開發(fā)人員進行干脆溝通；(2)

有些問題測試人員沒有描述清楚，開發(fā)人員認為問題不存在也可能把問題標記為已經修改（正確的做法是標記問題為商討或者不存在狀態(tài)）。測試人員應當清楚的描述問題，削減這類問題的發(fā)生，尤其要描述