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

1、軟件測試過程需求確認測試設(shè)計測試執(zhí)行測試總結(jié)測試計劃同行評審里程碑總結(jié)SQA測試活動組間協(xié)調(diào)管理者 編寫測試計劃 內(nèi)容： 時間和人員安排 同行評審及同行評審負責(zé)人； 里程碑制定； 進度表； 風(fēng)險計劃的制定； 培訓(xùn)的計劃； 測試計劃需要進行評審；需求確認需求確認測試工作的介入1. 測試開始介入的時間和系統(tǒng)組的建立時間幾乎同時進行.2. 用充足的時間去分析用戶需求(在NEU-APN事業(yè)部的名稱為仕樣書)中可以測試內(nèi)容, 同時可以發(fā)現(xiàn)其中測試比較困難的內(nèi)容并及時考慮解決措施3. 根據(jù)不同功能考慮進行不同級別的測試,采用不同的測試方法. 需求學(xué)習(xí)的方法測試人員自己閱讀和分析仕樣書, 講解自己負責(zé)部分的

2、功能,并回答其他測試人員的提問.要求不遺漏仕樣書中的任何功能,在講解中追加自己對仕樣書的理解,以及對測試難點部分考慮的測試方法.需求確認 培訓(xùn)的展開 組內(nèi)的培訓(xùn) 功能測試方法和操作測試方法； 自動測試； 部門的培訓(xùn) 各模塊功能培訓(xùn)； 開發(fā)技能培訓(xùn)； 專業(yè)知識；需求確認測試設(shè)計Test PointFunction SpecTest Case開發(fā)人員參與同行評審內(nèi)部同行評審 編寫測試大綱1. 形成通用的功能測試集，包含詳細的測試點（以前是日方編寫測試點）；2. 要求追加對測試難點的測試方法或者測試用例.3. 對于二期開發(fā)的項目,要求包含以前項目的的全部功能；測試設(shè)計 測試大綱的同行評審 同行評審的

3、內(nèi)容：測試點的理解錯誤，測試用例的遺漏； 同行評審的類型：組內(nèi)的和開發(fā)人員參與的同行評審； 同行評審的過程：制定負責(zé)人，收集問題表，組織召開同行評審會議，跟蹤關(guān)閉已經(jīng)解決的問題。 測試設(shè)計測試實施版本測試New VersionComponentVersion ReportReleaseNoteSystem TeamQ&A 協(xié)助再現(xiàn)錯誤BugbaseComponent Team制定小計劃依據(jù)系統(tǒng)組的Release計劃； 一般測試的周期比較長，大約4-6個月，所以針對于每個版本提交的功能的不同以及每次測試時間長短的不同,調(diào)整和制定測試組小計劃.這樣的計劃只要在項目例會中傳達或者通過Emai

4、l通知相關(guān)測試人員即可測試實施 測試方法在測試過程中,要根據(jù)軟件產(chǎn)品的質(zhì)量情況以及功能提交的情況采用不同角度的測試方法.1. 在項目初期,提交的功能比較少,軟件產(chǎn)品的質(zhì)量還達不到性能測試和極限測試的要求時. 我們需要按照測試大綱進行測試,以保證提交的功能達到基本要求,然后再關(guān)注每個功能的細節(jié),這樣可以盡可能保證開發(fā)人員完成的功能達到一個滿意的質(zhì)量目標(biāo).測試實施 測試方法2. 當(dāng)軟件產(chǎn)品的功能大部分已經(jīng)提交時(也許這時軟件產(chǎn)品的質(zhì)量仍沒有達到性能測試和極限測試的要求). 我們在按照測試大綱進行測試的過程中,除了要對基本功能進行嚴(yán)格測試外,更要注意不同功能之間的接口以及會受到接口影響的部分功能,因

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

6、實施 測試報告 Day_Bug_Report：每個測試人員填寫； Bugbase：由登錄者負責(zé)把每個人的測試結(jié)果整理到Bugbase上，進行重復(fù)的過濾; BugbaseStatus :對于Bugbase作的一些分析圖表； 提交給日方的BugList：包括CheckList和Bugbase的內(nèi)容; 測試實施錯誤描述要求1. 錯誤現(xiàn)象描述清晰準(zhǔn)確,操作步驟簡單有效.操作步驟簡單有效,是要求測試人員在時間允許的情況下,可以把原來需要十幾二十步才能再現(xiàn),根據(jù)自己的分析和再現(xiàn)盡量縮短 (這樣開發(fā)人員根據(jù)操作步驟,可能不需要去再現(xiàn)錯誤,就知道錯誤發(fā)生的原因了)錯誤現(xiàn)象描述不清晰準(zhǔn)確,會造成開發(fā)人員的理解上

7、歧義.要求測試人員在填寫錯誤現(xiàn)象時不能寫象“某某功能錯誤”,“某某現(xiàn)象錯誤”這樣的文字,要說明錯誤現(xiàn)象是什么,最好附加說明正確的現(xiàn)象應(yīng)該是什么.測試實施 錯誤描述要求2. 要有充足的錯誤信息.我們的測試分為導(dǎo)航版和PC版兩個測試版本.導(dǎo)航版的錯誤,一般要保留錯誤現(xiàn)象發(fā)生時的錯誤圖片.有些錯誤不但要提供錯誤圖片,還要提供當(dāng)前的調(diào)試信息;死機的錯誤,除了提供錯誤現(xiàn)象圖片和調(diào)試信息外還需要提供死機堆棧以及寄存器中的內(nèi)容.PC版的錯誤,也與導(dǎo)航版類似.一般錯誤要保存錯誤現(xiàn)象圖片和調(diào)試信息;死機錯誤還要保存死機時的堆棧.測試實施調(diào)試信息mapdsp_ClearOrderOfDisplayRequest

8、MapSetNum=0 mapdsp_ClearOrderOfDisplayRequest MapSetNum=0 DisplayNumDisplayNum=1 =1 MAP_Center_Position MapsetNo( 0) MAP_Center_Position MapsetNo( 0) CenterPos(0 x4c9574f1,0 x13a0949b) DispNo( 0) CenterPos(0 x4c9574f1,0 x13a0949b) DispNo( 0) CurrentNoCurrentNo( 0)( 0) MAP_Clock_End (Y/M/D) 1900/ 1/

9、1 Week( 1) (H:M:S) MAP_Clock_End (Y/M/D) 1900/ 1/ 1 Week( 1) (H:M:S) 12:44:16 SysTime (0 x cd8160) MAP DRAW_Cancle 12:44:16 SysTime (0 x cd8160) MAP DRAW_Cancle CheckClear in MAPDRW_iFirstFail iMapSetNo,iLayerCheckClear in MAPDRW_iFirstFail iMapSetNo,iLayer ( 0, ( 0, 1) 1) MAP DRAW_Cancle CheckClear

10、 in MAPDRW_iFirstFail MAP DRAW_Cancle CheckClear in MAPDRW_iFirstFail iMapSetNo,iLayeriMapSetNo,iLayer ( 0, 3) ( 0, 3) 堆棧信息: _os_breakProgram+2(): _os_breakProgram+2(): _os_checkTaskStackSize+4E() : _os_checkTaskStackSize+4E() : _scrn_GroundInit+50() : _scrn_GroundInit+50() 和SP 0026907C : 0000000C f

11、bmem_AreaSizeSP 0026907C : 0000000C fbmem_AreaSize SP+ 400269080 : 0666DD24 _os_checkTaskStackSizeSP+ 400269080 : 0666DD24 _os_checkTaskStackSize SP+ 800269084 : FE000616 SP+ 800269084 : FE000616 _os_vAttachToStopRun+26_os_vAttachToStopRun+26 寄存器信息R10 001C6EBC R10 001C6EBC * *001C2AE0 HPR+184 001C2A

12、E0 HPR+184 R11 FFFFFFFF R11 FFFFFFFF * *0000000000000000R12 00000000 R12 00000000 * *00000000 check_find00000000 check_findR13 00005090 R13 00005090 * *00000000 SIT_INT_STACK+488E00000000 SIT_INT_STACK+488ER14 00E80234 R14 00E80234 * *00000000 _ghsbegin_bss+5ACE400000000 _ghsbegin_bss+5ACE4R15 00000

13、008 R15 00000008 * *FFFFFFFF tsk_countFFFFFFFF tsk_countR16 069D0736 R16 069D0736 * *C542180B _e_entfnc+AEC542180B _e_entfnc+AER17 00E80370 R17 00E80370 * *00005090 _ghsbegin_bss+5AE2000005090 _ghsbegin_bss+5AE20 提高錯誤的再現(xiàn)率這個問題,很多測試人員不重視,他們認為只要我測試出錯誤就可以了.其實不然,本來一些錯誤的再現(xiàn)率就很低,在測試人員這里不容易再現(xiàn)(至少測試人員還知道錯誤出現(xiàn)的大

14、概步驟),那么在開發(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的修改不會影響其他部分.

15、測試實施 測試評價 專門的評價組； 評價內(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ā)人員分析錯誤后,再與測試

16、人員討論的時間測試實施 組間協(xié)調(diào) 現(xiàn)場的調(diào)試 測試時發(fā)現(xiàn)嚴(yá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è)計軟件時主要考慮如何完成仕樣中說

17、明的功能, 到項目中后期正常的功能基本不會出錯,但是一些功能的細節(jié)和容錯的處理是開發(fā)人員容易忽略的地方.測試實施 自動測試工作 工具： SQA,只能進行PC版的自動測試； 操作Log:導(dǎo)航機上進行操作記錄的工具； 應(yīng)用： 靜態(tài)的，無自車走動的； 重復(fù)的，可以大大節(jié)省手動測試的內(nèi)容； 限制： 不適合檢驗結(jié)果；測試實施 里程碑總結(jié)及評審 如果測試執(zhí)行的時間比較長，不同的測試階段之間的跨越比較明顯，通常會作里程碑的總結(jié)；測試實施 SPTO 責(zé)任者：測試負責(zé)人 主要工作： 監(jiān)督工作進度； 檢查工作質(zhì)量； 進行信息反饋； 及時發(fā)現(xiàn)問題，提供解決措施； 風(fēng)險的跟蹤， 調(diào)整計劃；測試實施 SQA工作 由事業(yè)

18、部的SQA人員對于測試的各項活動和輸出進行檢查，填寫不合格問題； 測試組內(nèi)容設(shè)立QA人員，協(xié)助測試負責(zé)人進行一些工作的檢查和監(jiān)督，并填寫SQA周報；測試實施 SCM工作 配置項包括：需求文檔，和CheckList; 注意內(nèi)容： 1. 使用成為基準(zhǔn)的內(nèi)容，開始下一步的工作； 2.對于CheckList標(biāo)識版本，需要時進行翻譯； 測試實施 度量數(shù)據(jù)的收集 收集形式：測試組個人周報； 收集內(nèi)容： 時間的分配：包括測試設(shè)計時間，使用CheckList測試時間，隨機測試時間，確認測試，再現(xiàn)測試的時間等等， 規(guī)模：總的和本周的CheckList編寫數(shù)目； 確認工作的進度； 每個版本測試和確認的Bug數(shù)； 測試實施1. 總結(jié)經(jīng)驗市場上所有有關(guān)測試的書籍都是在講測試的理論,很少發(fā)現(xiàn)有講測試經(jīng)驗的. 因為經(jīng)驗只有從實際的測試工作中得到.每個項目完成后,我們或多或少都會有一些好的工作經(jīng)驗,積累這些經(jīng)驗才能使我們的測試能力逐步提高.測試工作沒有最好測試工作沒有最好