軟件測試01-軟件測試工作流程

軟件創(chuàng)造客戶價值軟件測試工作流程軟件測試過程編寫測試計劃內(nèi)容：

時間和人員安排同行評審及同行評審負責人；里程碑制定；進度表；風險計劃的制定；培訓(xùn)的計劃；

測試計劃需要進行評審；需求確認需求確認測試工作的介入

1.測試開始介入的時間和系統(tǒng)組的建立時間幾乎同時進行. 2.用充足的時間去分析用戶需求(在NEU-APN事業(yè)部的名稱為仕樣書)中可以測試內(nèi)容,同時可以發(fā)現(xiàn)其中測試比較困難的內(nèi)容并及時考慮解決措施 3.根據(jù)不同功能考慮進行不同級別的測試,采用不同的測試方法.需求學習的方法

測試人員自己閱讀和分析仕樣書,講解自己負責部分的功能,并回答其他測試人員的提問. 要求不遺漏仕樣書中的任何功能,在講解中追加自己對仕樣書的理解,以及對測試難點部分考慮的測試方法.需求確認培訓(xùn)的展開

組內(nèi)的培訓(xùn)

功能測試方法和操作測試方法；自動測試；

部門的培訓(xùn)

各模塊功能培訓(xùn)；開發(fā)技能培訓(xùn)；專業(yè)知識；需求確認測試設(shè)計編寫測試大綱

1.形成通用的功能測試集，包含詳細的測試點（以前是日方編寫測試點）； 2.要求追加對測試難點的測試方法或者測試用例. 3.對于二期開發(fā)的項目,要求包含以前項目的的全部功能；測試設(shè)計測試大綱的同行評審

同行評審的內(nèi)容：測試點的理解錯誤，測試用例的遺漏；

同行評審的類型：組內(nèi)的和開發(fā)人員參與的同行評審；同行評審的過程：制定負責人，收集問題表，組織召開同行評審會議，跟蹤關(guān)閉已經(jīng)解決的問題。

測試設(shè)計測試實施制定小計劃

依據(jù)系統(tǒng)組的Release計劃；一般測試的周期比較長，大約4-6個月，所以針對于每個版本提交的功能的不同以及每次測試時間長短的不同,調(diào)整和制定測試組小計劃. 這樣的計劃只要在項目例會中傳達或者通過Email通知相關(guān)測試人員即可測試實施測試方法

在測試過程中,要根據(jù)軟件產(chǎn)品的質(zhì)量情況以及功能提交的情況采用不同角度的測試方法. 1.在項目初期,提交的功能比較少,軟件產(chǎn)品的質(zhì)量還達不到性能測試和極限測試的要求時.我們需要按照測試大綱進行測試,以保證提交的功能達到基本要求,然后再關(guān)注每個功能的細節(jié),這樣可以盡可能保證開發(fā)人員完成的功能達到一個滿意的質(zhì)量目標.測試實施測試方法

2.當軟件產(chǎn)品的功能大部分已經(jīng)提交時(也許這時軟件產(chǎn)品的質(zhì)量仍沒有達到性能測試和極限測試的要求).我們在按照測試大綱進行測試的過程中,除了要對基本功能進行嚴格測試外,更要注意不同功能之間的接口以及會受到接口影響的部分功能,因為這個階段由接口造成的錯誤比較多.測試實施測試方法

3.當軟件產(chǎn)品的功能全部提交,并且當前的錯誤發(fā)現(xiàn)曲線趨于平緩,這就說明按照測試大綱進行測試已經(jīng)很難提高錯誤的發(fā)現(xiàn)率.這時則需要采取其他測試方法包括性能,極限測試和脫離測試大綱的可用性測試. 這里的性能和極限測試系統(tǒng)復(fù)雜度小于與軟件提交前的性能和極限測試時的系統(tǒng)復(fù)雜度.測試實施測試方法 4.二期開發(fā)類型的項目測試執(zhí)行過程中,每個階段都要注意原來項目的功能的實現(xiàn)情況,特別需要注意的是與新添加以及變更功能相關(guān)功能的測試.即新添加的功能不能影響原有的功能 注:對于二期開發(fā)項目的性能測試,在沒有具體指標前,對它的要求是性能至少不低于原來的項目.測試實施測試報告

Day_Bug_Report：每個測試人員填寫；Bugbase：由登錄者負責把每個人的測試結(jié)果整理到Bugbase上，進行重復(fù)的過濾;BugbaseStatus:對于Bugbase作的一些分析圖表；提交給日方的BugList：包括CheckList和Bugbase的內(nèi)容;

測試實施錯誤描述要求錯誤現(xiàn)象描述清晰準確,操作步驟簡單有效.

操作步驟簡單有效,是要求測試人員在時間允許的情況下,可以把原來需要十幾二十步才能再現(xiàn),根據(jù)自己的分析和再現(xiàn)盡量縮短(這樣開發(fā)人員根據(jù)操作步驟,可能不需要去再現(xiàn)錯誤,就知道錯誤發(fā)生的原因了)

錯誤現(xiàn)象描述不清晰準確,會造成開發(fā)人員的理解上歧義.要求測試人員在填寫錯誤現(xiàn)象時不能寫象“某某功能錯誤”,“某某現(xiàn)象錯誤”這樣的文字,要說明錯誤現(xiàn)象是什么,最好附加說明正確的現(xiàn)象應(yīng)該是什么.測試實施錯誤描述要求

2.要有充足的錯誤信息. 我們的測試分為導(dǎo)航版和PC版兩個測試版本. 導(dǎo)航版的錯誤,一般要保留錯誤現(xiàn)象發(fā)生時的錯誤圖片.有些錯誤不但要提供錯誤圖片,還要提供當前的調(diào)試信息;死機的錯誤,除了提供錯誤現(xiàn)象圖片和調(diào)試信息外還需要提供死機堆棧以及寄存器中的內(nèi)容. PC版的錯誤,也與導(dǎo)航版類似.一般錯誤要保存錯誤現(xiàn)象圖片和調(diào)試信息;死機錯誤還要保存死機時的堆棧.測試實施調(diào)試信息

mapdsp_ClearOrderOfDisplayRequestMapSetNum=0DisplayNum=1 [MAP_Center_Position]MapsetNo(0)CenterPos(0x4c9574f1,0x13a0949b)DispNo(0)CurrentNo(0) [MAP_Clock_End](Y/M/D)1900/1/1Week(1)(H:M:S)12:44:16SysTime(0xcd8160)[MAPDRAW_Cancle]CheckClearinMAPDRW_iFirstFailiMapSetNo,iLayer(0,1) [MAPDRAW_Cancle]CheckClearinMAPDRW_iFirstFailiMapSetNo,iLayer(0,3)堆棧信息

:_os_breakProgram+2() :_os_checkTaskStackSize+4E() :_scrn_GroundInit+50() 和 SP[0026907C]:0000000Cfbmem_AreaSize SP+4[00269080]:0666DD24_os_checkTaskStackSize SP+8[00269084]:FE000616_os_vAttachToStopRun+26

寄存器信息

R10001C6EBC*[001C2AE0]HPR+184 R11FFFFFFFF*[00000000] R1200000000*[00000000]check_find R1300005090*[00000000]SIT_INT_STACK+488E R1400E80234*[00000000]___ghsbegin_bss+5ACE4 R1500000008*[FFFFFFFF]tsk_count R16069D0736*[C542180B]__e_entfnc+AE R1700E80370*[00005090]___ghsbegin_bss+5AE20提高錯誤的再現(xiàn)率

這個問題,很多測試人員不重視,他們認為只要我測試出錯誤就可以了.其實不然,本來一些錯誤的再現(xiàn)率就很低,在測試人員這里不容易再現(xiàn)(至少測試人員還知道錯誤出現(xiàn)的大概步驟),那么在開發(fā)人員那里就更難再現(xiàn),給開發(fā)人員分析錯誤帶來很大困難.因此我們要求測試人員發(fā)現(xiàn)錯誤后要盡力尋找再現(xiàn)方法,提高錯誤的再現(xiàn)率.1/n的描述是最不好的描述。 不過,這對測試人員來說的確也是一種挑戰(zhàn)測試實施重視確認測試

確認測試的時機：

建議在測試功能過程中進行一些簡單問題的確認，可以節(jié)約專門的確認時間；

確認方法： 再現(xiàn)率較低的錯誤,確認測試要遠超過發(fā)現(xiàn)錯誤時的測試次數(shù),比如一個Bug再現(xiàn)率是3/10,那么確認時至少要做到20次.再現(xiàn)率更低的錯誤,確認測試要在多個版本中進行. 確認測試執(zhí)行,不能只關(guān)注Bug本身,要對Bug相關(guān)部分的功能都進行測試,以確保Bug的修改不會影響其他部分. 測試實施測試評價

專門的評價組；評價內(nèi)容：性能，用戶測試，全系統(tǒng)的內(nèi)容，不針對于功能；評價結(jié)果：除了填寫B(tài)uglist，對于產(chǎn)品的評價內(nèi)容體現(xiàn)在測試組的周報中；測試實施組間協(xié)調(diào)在工作的過程中，需要和其他組進行協(xié)作或是提供支持的地方。目前的工作中，測試組面臨的組間協(xié)調(diào)對象主要是各個開發(fā)組；

協(xié)調(diào)的內(nèi)容：系統(tǒng)組例會上各個工作組之間的安排；測試過程中，對于問題的請教；測試現(xiàn)場的保留；測試實施組間協(xié)調(diào)

問題的詢問

測試時出現(xiàn)仕樣中沒有明確說明的錯誤現(xiàn)象時,需要測試人員及時與開發(fā)人員溝通,由開發(fā)人員確認是否是錯誤.這樣不但可以提供錯誤提交的質(zhì)量,另一方面也節(jié)省開發(fā)人員分析錯誤后,再與測試人員討論的時間測試實施組間協(xié)調(diào)現(xiàn)場的調(diào)試 測試時發(fā)現(xiàn)嚴重錯誤(多為再現(xiàn)率較低的錯誤)時,需要測試人員及時找到相關(guān)開發(fā)人員,根據(jù)現(xiàn)場進行分析和調(diào)試.這樣可以最大程度減少開發(fā)人員和測試人員再現(xiàn)錯誤時間以及開發(fā)人員分析錯誤的時間. 矛與盾是互相對立的.現(xiàn)場調(diào)試節(jié)省了開發(fā)人員時間,但是也不同程度的浪費了測試人員的時間.(現(xiàn)在比較好的解決方法是測試人員使用多于一臺的機器進行測試)測試實施組間協(xié)調(diào) 經(jīng)常與開發(fā)人員溝通,可以了解開發(fā)人員如何去實現(xiàn)某個功能,這些實現(xiàn)方法可能就會有漏洞,根據(jù)這些漏洞的測試,常常會有事半功倍的效果.這種方法,在軟件開發(fā)的中后期很有效. 畢竟開發(fā)人員設(shè)計軟件時主要考慮如何完成仕樣中說明的功能,到項目中后期正常的功能基本不會出錯,但是一些功能的細節(jié)和容錯的處理是開發(fā)人員容易忽略的地方.測試實施自動測試工作

工具：SQA,只能進行PC版的自動測試；操作Log:導(dǎo)航機上進行操作記錄的工具；

應(yīng)用：靜態(tài)的，無自車走動的；重復(fù)的，可以大大節(jié)省手動測試的內(nèi)容；

限制：不適合檢驗結(jié)果；測試實施里程碑總結(jié)及評審

如果測試執(zhí)行的時間比較長，不同的測試階段之間的跨越比較明顯，通常會作里程碑的總結(jié)；測試實施SPTO

責任者：測試負責人

主要工作：監(jiān)督工作進度；檢查工作質(zhì)量；進行信息反饋；及時發(fā)現(xiàn)問題，提供解決措施；風險的跟蹤，調(diào)整計劃；測試實施SQA工作由事業(yè)部的SQA人員對于測試的各項活動和輸出進行檢查，填寫不合格問題；測試組內(nèi)容設(shè)立QA人員，協(xié)助測試負責人進行一些工作的檢查和監(jiān)督，并填寫SQA周報；測試實施SCM工作

配置項包括：需求文檔，和CheckList;

注意內(nèi)容：1.使用成為基準的內(nèi)容，開始下一步的工作；2.對于CheckList標識版本，需要時進行翻譯；測試實施度量數(shù)據(jù)的收集

收集形式：測試組個人周報；

收集內(nèi)容：時間的分配：包括測試設(shè)計時間，使用CheckList測試時間，隨機測試時間，確認測試，再現(xiàn)測試的時間等等，規(guī)模：總的和本周的CheckList編寫數(shù)目；確認工作的進度；每個版本測試和確認的Bug數(shù)；

測試實施總結(jié)經(jīng)驗 市場上所有有關(guān)測試的書籍都是在講測試的理論,很少發(fā)現(xiàn)有講測試經(jīng)驗的.因為經(jīng)驗只有從實際的測試工作中得到.每個項目完成后,我們或多或少都會有一些好的工作經(jīng)驗,積累這些經(jīng)驗才能使我們的測試能力逐步提高.

測試工作沒有最好,只有更好.測試總結(jié)2.多談不足 測試工作的經(jīng)驗不光是需要積累好的經(jīng)驗,更重要的是主動發(fā)現(xiàn)我們工作的不足,改進不足才能逐步完善測試工作.

測試工作中的某些經(jīng)驗的獲得,就像是足球場上的守門員一樣,他需要經(jīng)歷失敗才能走向成功.測試總結(jié)我們面前的挑戰(zhàn)開發(fā)人員只把測試人員當作測試人員來看 一方面開發(fā)人員由于質(zhì)量意識不強,他們認為測試人員就是幫助他們測試代碼的. 開發(fā)人員在編碼和單體測試時,沒有對代碼的質(zhì)量進行有效的保證,最后測試人員進行測試時,大量的Bug使開發(fā)人員和測試人員都感到心情很壞,對產(chǎn)品的質(zhì)量影響很大. 對于測試人員來說,一個幾天測試才能發(fā)現(xiàn)錯誤的項目而獲得成就感要遠高于每天都能測試出很多錯誤的項目.一個錯誤很多的項目對于測試