軟體測試面試時專案經驗怎麼介紹 需要從哪幾方面說

2021-04-20 21:00:40 字數 4829 閱讀 4875

1樓:匿名使用者

先介紹專案的整體規模:設計了多少用例、發現了多少缺陷……在區域性介紹:測試的流程、用例設計的方法……你在專案中的角色和職責……自己的特色、那裡做的最好、遇到什麼困難……總結……

2樓:

專案簡介,人員投入,環境,測試流程,工具,自己職責,測試總結,學習到了什麼,**不足,

3樓:匿名使用者

專案的內容,自己的職責。 如果自己負責測試的,最好說一下自己對測試方面的恭喜,如開發了什麼樣的測試工具。

軟體測試 專案總結怎麼寫啊?高手指教下

4樓:匿名使用者

能表達得有條理就可以了。不必介意格式。總結無非就是總結經驗,吸取教訓咯,本人什麼時候參加了什麼專案的測試

這個專案是幹什麼的

我在專案組中做了什麼

遇到了什麼困難 如何解決的

通過這個專案我學習到了什麼

我要感謝誰誰誰

我以後要在什麼方面加強

此致敬禮

附件一x專案的測試工作到今天算是全部結束了,除了後期維護必要的一些回歸測試和使用者使用手冊的撰寫外,整個測試階段告一段落。

從10月底進入專案,在測試經理的幫助下開始學著寫專案測試文件,到根據文件的每日功能測試及回歸測試,再到整個專案進行迭代後對測試文件的重新架構及整體回歸測試,直至最後的統一交付測試,我個人提交總bug數為244個。

在這244個bug的提交和回歸過程中,在測試文件的寫作及修訂中,我對整個專案的邏輯及架構逐步清晰,對專案之間所需的複雜互動的認識也越發深入,對專案功能邏輯上的測試如何進行也更加明晰。

下面我簡單談談對專案的認識、經驗和教訓,以及對未來改進的一些建議!

一、對專案的認識

進入這個專案是在今年十月底,當時測試經理和c已經把setting(當時是admin)部分的測試結束了,所以我直接開始接著d的測試文件繼續往下寫(當時是從revenue的report部分開始,即現在的report模組)。因為跳過了邏輯部分,所以對整個專案邏輯理解很不夠,開始寫的測試文件也非常淺顯,就是描述了一下頁面布局。這裡我的感覺是,測試人員進入專案初期,專案經理有必要指派專門人員與測試人員溝通,幫助其理清整個專案的順序邏輯。

當時c簡單地跟我介紹了一下整個專案,我的感覺是溝通不夠,對邏輯理解比較欠缺。

report部分寫完,就直接開始測試——用自己剛寫完的文件進行測試,效果顯然不夠理想。因為測試人員剛進行該模組測試文件的編撰,再讓他對該模組進行測試,這樣做的乙個後果就是,測試人員會先入為主地覺得自己不需要按部就班地照著文件進行測試(因為文件就是自己寫的)。還有乙個很大的問題就是,倘若測試人員在文件撰寫上存在嚴重漏洞的話,他在測試時仍然不可能發現自己的漏洞所在。

所以我建議測試文件撰寫人員與測試人員最好不要是同乙個人,這樣有助於發現測試文件構建的漏洞。

測試完report後,緊接著開始進行expense模組測試文件的撰寫。這時我開始接觸到一些邏輯,即expense與setting部分聯絡的邏輯。這時遇到的問題最多最雜,隨時隨地都需要與c,甚至專案經理進行溝通。

由於之前對主功能(setting部分)的不熟悉,這種一邊溝通一邊撰寫的測試文件可以說是漏洞百出。由於專案時間也比較緊,我需要在一周內完成整個expense模組的測試文件,所以最終完成的文件很不理想。這裡我覺得還是之前溝通不到位的問題,應該有乙個對整個專案非常熟悉的人來幫助測試人員理清整個專案邏輯再進行測試文件撰寫,而不是一開始就撰寫測試文件。

接著就是根據自己撰寫的expense文件對expense模組進行測試,效果也不夠理想。這裡我還有乙個建議就是,如果測試人員在初始進入專案時沒有得到及時溝通,至少需要給他一周時間先對主功能(即setting部分)進行完整測試,對照需求手冊及主功能發現的bug,對主功能進行深入理解。

expense測試完成後,開始對整個專案進行回歸測試。在這個過程中,我逐漸理清了整個專案的邏輯,也開始試圖修改以前的文件。但由於文件量太大,文件結構不夠清晰,時間也比較緊,修改難於進行。

大部分原因是我經驗不足造成的,之前撰寫測試文件時,思路過於混亂,想到**寫到**,導致最後文件難於維護和修改。

回歸測試結束後,整個系統邏輯已經比較清晰。這時專案進行新一輪的迭代,使用者需求改了很多,其中包括增加、修改大量功能、名稱,以及對整個系統結構進行重構。這對測試文件而言改動點非常多(包括結構順序改變、測試編號訂正、功能模組名稱修改等),而且需求文件並未因此變化,造成最後測試文件與需求文件的不匹配。

這是乙個協調的過程,系統迭代後,需求文件應及時隨著系統進行修改。

迭代開發過程中,測試基本上是專案改到哪就測到哪,這裡面最大的問題不是發現修改模組的bug,而是發現修改該模組後牽涉到的其它模組出現的bug。這種連帶bug的產生可以說是防不勝防,讓測試人員苦惱不已。到現在我也沒想出解決辦法,只能說對模組之間的聯絡及互動邏輯理解仍需加深。

迭代開發後期,開始對整個系統從頭回歸一遍,這時候又發現了許多以前從未出現的bug。這個時期大家都很煩躁困惑,曾經運轉良好的頁面,突然出現儲存問題;曾經更新正常的功能,突然無法更新;曾經顯示正常的excel,突然顯示錯誤… …這些都讓人苦惱,當然,這些應該都是正常現象。測試人員在測試後期尤其需要提高警惕,不能漏過任何乙個功能點,更不能忽略任何一次貌似無用的查詢、翻頁、按鍵。

最後,是大家一起進行的交付測試,人員包括了所有的程式設計人員及測試人員。這期間,除了對基本功能的回歸測試外,還包括了併發測試及效能測試(這主要是程式設計人員在做),除此之外,我將過去提交修正過的所有bug重新驗證了一遍。在併發測試中,我們發現了很多之前單人測試難以發現的併發問題(包括多人一起提交,一起選擇,一起修改等等),併發問題可以說層出不窮,甚至包括了同一臺電腦開啟兩個頁面分別進行修改的問題(由於我從一開始就是開啟兩個頁面來測,乙個為使用者本人,乙個為該使用者**人delegator,所以有些問題在早期已經暴露),這是測試中的乙個重點,也是比較嚴重的漏洞,需要在以後多加留意。

在驗證過去修正過的bug時,仍然發現不少問題,有些是bug本身的問題,有些是bug附帶問題,還有很多驗證時聯想到的問題。這一驗證過程效果非常明顯,所以我建議在專案末期有必要將過去修正的bug重新認真驗證一遍,可以在短時間內收到奇效。

至此,整個專案的測試算是告一段落。使用者過來測試後提出一些bug,經過分析,絕大部分屬於使用者的一些想法,與測試漏洞無關,整個測試算是圓滿結束。

二、經驗和教訓

這個專案是我接手的第乙個專案,也是乙個理論聯絡實際的過程,回想起來,收穫頗豐。

經驗主要如下:

1、 學會如何將書中的理論與實踐相結合;

2、 學會如何根據專案demo及需求文件撰寫測試文件;

3、 學會如何根據專案變更修改測試文件;

4、 學會如何用英文撰寫文件,提交,驗證問題;

5、 學會如何理清專案邏輯,如何更深入地撰寫文件並進行測試;

6、 學會如何與程式設計人員溝通交流,獲得解答,以便正確提交bug;

教訓如下:

1、 撰寫測試文件前沒有理清業務邏輯,導致前期測試深度不夠;

2、 撰寫測試文件時結構不清晰,導致後期難以維護和修改;

3、 測試過程中心態有些浮躁,有些急於求成;

4、 還沒有形成測試思維,測試過程思維顯得有些混亂;

5、 對bug輕重緩急界定不夠,導致有時測試難以繼續進行(對一些影響進度的低級別bug優先順序定得太低);

三、對未來改進的一些建議

經過這次完整的專案測試,學到了很多,也發現了很多問題。對於未來專案的測試,我如下幾個不太成熟的建議:

1、 在測試之前專案經理有必要對測試人員進行專案培訓,讓測試人員對整個專案心中有數,在撰寫測試文件時有的放矢;

2、 在測試文件撰寫之前需要定義乙個撰寫規範和標準,大家按照同乙個標準撰寫,有利於日後文件的維護;

3、 同乙個專案功能測試至少應有兩人,可以交叉編寫模組測試文件,交叉檢查文件,交叉進行回歸測試,交叉驗證bug,這樣有利於避免單人測試考慮不足的漏洞,也能產生更多新的想法,還能相互督促完善文件,提高測試進度;

4、 從一開始就高度重視併發問題,併發問題暴露得越早越易於修改;

5、 專案後期除了不留死角、輪番地掃遍每乙個角落(多人協作)外,還需要將過去所有解決的bug全部驗證一遍,會發現不少難以預見的bug;

6、 對於本專案,目前還有32個延遲(pending)的bug,裡面大部分為效能和併發問題,還有一些游標、排序及空資料遺留問題,這些看似無關緊要或暫時難以解決的問題都是未來亟需解決的關鍵所在;

5樓:兔丞飛

總結范文如下:

x專案的測試工作到今天算是全部結束了,除了後期維護

必要的一些回歸測試和使用者使用手冊的撰寫外,整個測試階段告一段落。

從10月底進入專案,在測試經理的幫助下開始學著寫專案測試文件,到根據文件的每日功能測試及回歸測試,再到整個專案進行迭代後對測試文件的重新架構及整體回歸測試,直至最後的統一交付測試,我個人提交總bug數為244個。

在這244個bug的提交和回歸過程中,在測試文件的寫作及修訂中,我對整個專案的邏輯及架構逐步清晰,對專案之間所需的複雜互動的認識也越發深入,對專案功能邏輯上的測試如何進行也更加明晰。

從性質、時間、形式等角度可劃分出不同型別的總結,從內容分主要有綜合總結和專題總結兩種。綜合總結又稱全面總結,它是對某一時期各項工作的全面回顧和檢查,進而總結經驗與教訓。專題總結是對某項工作或某方面問題進行專項的總結,尤以總結推廣成功經驗為多見。

總結也有各種別稱,如自查性質的評估及匯報、回顧、小結等都具總結的性質。寫作分為標題、正文、落款。標題又分公文式的,一般由單位名稱、時限、內容、文種組成;文章標題式的、雙標題;正文由前言、主體、結尾組成;結尾又分自然收尾和總結全文;落款由單位名稱和時間組成。

面試時,怎麼介紹自己,面試的時候怎樣介紹自己

面試時應該怎樣做自我介紹?我叫誰誰誰,是 人,有什麼專業,喜好是什麼。介紹自己,還有自己的工作近況 面試的時候怎樣介紹自己?面試官要求做 一分鐘自我介紹 時,我該說些什麼?面試官要求 自我介紹 有什麼意思?一 我是誰。首先是要介紹自己的名字,最好選擇逐字介紹,讓hr清楚你的名字該如何拼寫,同時也能加...

面試時如何作自我介紹,面試時如何作自我介紹

面試時應該怎樣做自我介紹?盡量控制在5分鐘以內。先簡單介紹一下自己的基本情況,然後迅速貼著公司職位的角度說自己的工作經驗,不要說一些無所謂的廢話,那是hr最反感的。直視對方,用沉穩誠懇的語調。首先.介紹你的名字,最好用乙個趣解來介紹,讓氣氛輕鬆一些.然後可以簡單的說下你的成長經歷.如果是玩到大的就別...

求面試時的自我介紹,求面試時的自我介紹

首先,你要做到的是 要自信 爽朗並且面帶微笑的說話。自我介紹時,你可以說 我叫 今年 歲,畢業於 學校,主修 科。希望在貴公司工作。暑假曾經在機械廠辦理過比較輕的一些事情。對了,很重要的一點哦!注意,衣服一定要整潔!面試時,自我介紹,在2分鐘內突出重點 去打雜你就說你能吃苦耐勞就可以了 面試時如何自...