測試注意問題

2021-10-16 12:23:39 字數 3610 閱讀 5362

很多時候,由於人力資源的不足,測試專案負責人都是在執行測試,這樣就使整個專案缺乏控制,一些問題(例如:有些成員的缺陷質量不夠合格;

開發人員修改不及時,系統某些功能發生嚴重問題導致部分功能無法測試。)得不到解決,耽誤了進度。所以測試負責必須全程監控專案,盡可能多的掌握資訊。

通常,測試負責人需要完成下面這些內容的管理工作:測試用例執**況;每個測試員提交的缺陷情況;測試中是否發生突發問題。

這裡的版本主要是指測試物件的版本控制,也就是指對開發部提交的產品進行版本控制。

在開發小組版本管理不規範的情況下,測試小組進行版本控制十分重要,要保證測試物件是可以控制的。

建議開發和測試雙方進行明確的約定,可以各自指定專門的測試版本負責人,制定提交原則,對提交情況進行詳細的記錄,這樣基本避免了版本失控導致的測試失誤或無效。

人員流動不僅僅是測試部門,這是it行業的普遍現象。從管理者角度,主管需要多多和團隊內成員進行溝通,建立乙個融洽的團隊環境,及時掌握情況,可以早些進行相應的調整。

但是只有企業建立好的用人制度,給員工提高廣闊的發展空間和好的培訓學習機會,才能從根本上解決這一問題。

加強專案管理,強化文件管理並保證文件的有效性,可以大大減少由於人員流失帶來的損失。同時,測試部門要建立培訓機制,使新到員工接受直接或者間接的培訓,快速適應工作。

我們經常聽開發人員說:「這不是缺陷!」,「這個缺陷沒有,因為我的系統上執行正常!」。

測試工程師本身就是做質量工作的,提交的成果本身就應該質量高些,為什麼還會有這種現象?提交的缺陷引起爭議是一種正常的現象,例如測試人員描述不清楚就會引起爭議。

減少甚至避免這種現象的方法是交叉測試,交叉測試是提高測試質量的乙個有效手段,當然交叉測試會增加一定的測試成本投入。

在測試任務完成後,測試工程師之間互相驗證彼此提交的缺陷,就會避免了缺陷描述不清、因執行環境而產生的缺陷等一系列問題,從而大大降低了回歸測試以及交流的成本,因而這種投入也是值得的,實際開發人員在單元測試階段也會進行交叉測試,來提高開發質量。

另外,測試人員一定要按照規範描述測試中發現的缺陷,乙個缺陷至少描述清楚概要描述、詳細描述、重現步驟三方面的內容,缺陷管理參考第八章的內容。

在實際專案開發中,我們常常看到有些單位忽視測試團隊存在的意義,當要實施測試時,往往臨時找幾個程式設計師充當測試人員。

也有些單位儘管認識到了組建測試團隊的重要性,但在具體落實的時候往往安排一些毫無開發經驗的行業新手去做測試工作,這常常導致測試效率低下,測試人員對測試工作索然無味。

根據筆者的經驗,測試團隊應首先聘請一名資深的測試領域專家,他應具有極為豐富的同類專案軟體測試經驗,對軟體開發過程中常見的缺陷或錯誤了然於胸;此外,他還具有較好的親和力和人格魅力。

其次,專案測試團隊還具有很多具備一技之長的成員,如對某些自動化測試工具運用嫻熟或能輕而易舉地編寫自動化測試指令碼等。

另外,測試團隊還應聘請一些兼職成員,如驗證測試實施過程中,同行評審是最常使用的一種形式,這些同行專家就屬於兼職測試團隊成員的範疇。至於測試團隊裡裡的測試新手,這部分人可以安排去從事交付驗證或黑盒測試之類的。

同化現象是指隨著時間的推移,開發人員會逐漸影響測試人員的思維和對缺陷的判斷能力,尤其是針對同一產品,同一組開發人員和同一組測試人員共同配合了很長時間,很多本來是缺陷的問題,由於測試人員對軟體「習慣成自然」的使用,會不被當成缺陷,尤其是在開發人員的解釋和說服下。

同化現象發生可能意味著「惡性迴圈」的開始:測試人員會幫著開發人員解釋乙個個缺陷的合理性,一輪一輪的測試都不會發現問題。招聘新的人員,不同的測試專案組輪換去測試不同的產品,就可以避免。

同時建議產品可以發布測試版,更多的人對其進行測試,就可以發現更多的問題。

社會心理學家曾作過乙個試驗:在召集會議時先讓人們自由選擇位子,之後到室外休息片刻再進入室內入座,如此五至六次,發現大多數人都選擇他們第一次坐過的位子。

這種現象稱為定位效應,說明人們習慣上凡是自己認定的,人們大都不想輕易改變它。定位效應在開發人員和測試人員身上都有體現。

例如開發工程師針對某一自己寫的功能,經常進行**移植,這種複製的「功能」,由於上一次經過除錯,在新的地方往往不會認真除錯,這些**往往會帶來共享變數衝突等許多種型別的缺陷。

定位效應體現在測試人員身上就是測試過的功能不再進行認真測試:在回歸測試時,之前由於進行過認真的測試,往往會認為某些功能是可靠,只要驗證一些以前發現的缺陷是否修改完成就可以了。

這種現象在反覆多次回歸時表現的更加突出,因為回歸測試中很多功能都會進行多次反覆測試。眾所周知,開發人員在修改缺陷時往往會引入新的缺陷,測試人員的疏於防範就會把這些缺陷帶到使用者這裡。解決這種問題的方案一般有兩個:

(1)完整的執行測試用例:這種方法投入較大,但是在開發產品時最好在最後一次回歸測試時測試的執行一次全部的測試用例。

(2)交叉測試:測試人員交叉測試,就可以很大程度的避免定位效應。測試工程師在回歸測試時互相交換任務,反覆測試某一功能的機會大大減少,從而也就不會「主觀的」認為某些功能沒有缺陷。

通常上面的兩個方法都是結合使用的,既要進行交叉測試,又要全面執行測試用例,測試覆蓋面要盡可能的廣泛。

測試人員工作發生問題是測試經理經常要面對的問題,作為測試部門的領導,首先要做的是指出測試人員所犯的錯誤,使其盡快改正錯誤。唯一不能做的就是盯著下屬的錯誤不放。

總盯著下屬的失誤,是乙個領導者的最大失誤。

英國行為學家波特說:當遭受許多批評時,下級往往只記住開頭的一些,其餘就不聽了,因為他們忙於思索論據來反駁開頭的批評。身為測試經理要根據測試人員的心理來進行指導,最大限度的調動每個人員的積極性來參加工作。

這個問題也許十分可笑,可是現實中我們的測試經理們卻不得不面對這個問題。這裡的全部測試不是指對軟體進行遍歷測試,而是指測試負責人制定的測試計畫包含的全部測試內容。

通常,不管是開發產品還是做具體的專案,都會發生耽誤進度的情況。

一旦整體進度不能向後延遲,專案相關人員習慣上的做法就是縮減測試時間。尤其在功能還沒有開發完成的情況下,這種現象更為突出。擔負著質量重任的測試經理,如何來解決這個問題呢?

比較好的做法是按照下面的步驟逐步來完成和改進工作:

(1)按照測試任務的輕重緩急,盡最大努力完成測試任務。在時間不足的情況下,我們應該對測試任務按照優先順序來劃分,重要緊急的任務先完成。這個時候的測試任務是一種輔助性工作,其目的就是盡最大努力來提高質量。

因此,面對這種情況,測試負責人要做的就是帶領測試小組充分利用所有資源來保證質量。

(2)在實際工作中和開發人員共同配合,逐步改進工作。只有整個團隊的軟體開發能力提高了,才能從根源上解決問題。

因此,測試負責人要帶領團隊和開發小組共同尋找適合自己的開發模式,從而使專案規劃的更加合理,進而按照預定計畫來開展測試工作。總之,在任何情況下,測試負責人都不應該抱怨。只有積極的面對問題,才能更好的解決問題。

測試管理者在測試專案中的主要任務是制定測試策略,管理測試計畫的落實情況,並且還要為測試專案的進行創造良好的執行環境。同時還要調動員工的創造性,對員工的工作作出評估。

這些工作不一定要求測試管理者達到專家的水平。但是在實際工作中,由於測試人員的短缺,測試管理者常常做為測試員來執行具體的測試任務。

尤其在規模較小的測試團隊,測試管理者的日常工作通常以具體的測試執行工作為主,這個時候更需要測試管理者有較好的背景知識。

總體說來,技術方面的背景知識對測試管理者是十分有益的。例如:分配工作任務、做進度預算,以及一些具體的執行工作,都需要一定的背景知識。當然,做為乙個測試管理者,沒有必要精通所有的技術,那也是辦不到的。

測試管理者做到正確的幫助員工最好地完成工作,並且提供最好的完成工作的環境就可以了。

Installation 測試注意點

1 start installer by double click,command line 2 install under differrent user previlege 3 install on pc with limited space 4 install while other sw i...

系統測試注意點

在談到怎麼做效能測試之前,要先明確為什麼要做效能測試。通常,效能測試的目標主要有以下幾種 1 賣點。和別的產品相比,效能指數有較大的提公升。2 和自己的老闆本相比,無明顯下降。3 某些產品,效能指標是作為requirement,那麼這類產品,效能測試用來確認滿足使用者需求。系統的效能在低負載的情況下...

效能測試注意事項

效能測試注意事項 1 伺服器端和客戶端一定要同乙個區域網內,否則網路因素會成為效能測試的瓶頸。2 在效能測試指令碼中要注意檢查點的設定,否則都不清楚指令碼是否真的成功執行操作。3 設定引數化和關聯是效能測試指令碼調通的關鍵。4 錄製指令碼時通常會包括一些 think time,因此在回放指令碼時,注...