boss問我們對于公司當前功能測試是否有完善意見,突然覺得這個話題離我們很近,卻總來沒深入總結過。還好要求明天上交報告,先在此做些總結,到時候拼裝下給boss.

  接觸測試三年了,從測試工程師到測試組長兼sepg,然后跳槽繼續測試工程師。一路下來都在跟需求跟業務打交道。做好測試首先要做好需求、理解業務,這個不用多說了,相信很多人都總結過。當然也聽到過一些言論“換單位了,那業務不是沒用了”,換單位后,業務沒用這是必然的,我也是從易制毒換到當前的稅務,但有一點都是跟政府行業,其實我們要做的是摸索和總結如何快速獲取和掌握新業務,內容不同,但方法是可以通用的。

  對于需求處理,我接觸的有以下三種情況。

  A、有需求說明,無設計文檔。

  B、有需求分析文檔,快完成時臨時補充設計文檔。

  C、有需求分析文檔和設計文檔。

  A這種情況一般分工不是很明確的小團隊都會出現,需求來源為客戶或者區域客服(特點是太簡單了沒經過提取,或者太自我了,很難實現),這時候在不規范的過程也會弄一次需求討論。這個時候測試務必要做到這點??爭取參加需求討論會議,不用發言,只要聽可以。因為這里沒有寫文檔的習慣,很多測試標準、需求處理細點都會在口頭上體現,你得眼疾手快,參加會議很好的一點是測試過程中,碰到不一致的地方,可以有足夠的重語氣讓開發修改,因為你有證據,而不用去問開發這點是不是要改,如何實現。

  B這種情況其實是頭痛的,在時間緊和維護項目中經常出現。軟件需求功能在界面上都實現了,但開發只是考慮實現需求,卻沒有把需求與當前業務(其他模塊的邏輯),后臺數據處理(例如某個字段更新)這些弄好。因為功能測試時,測試人員大都會跑流程或者數據庫測試,這時候模糊無標準的問題來了,頭痛。另外一些開發人員會以功能實現,進入測試、或者邊設計邊改,測試大工作量了。這個時候測試有這些可以扭轉一些局面??版本驗收流程、開發人員給測試人員培訓。版本驗收:像前面提出的,設計不全面等,很容易導致只完成需求,破壞了原有功能或流程功能,在拿到版本后,進行初步的重要流程驗收,可以減少很多測試工作量。開發人員講解培訓:這個很好的解決了由于沒設計文檔導致的測試不了解內部,被動,另外也是給開發壓力,逼他們做單元和集成自測,從中測試也可以提問,不要覺得這是浪費時間,好處你試了才知道。我很壞,呵呵。

  C這種情況一般實行Cmmi3之后的企業都很規范。這里我講下自己的幾個方法,更好的理解需求:模塊間邏輯圖、數據流向圖、需求用例矩陣。模塊間邏輯圖:其實usecase圖、流程圖,只要能讓自己摸清楚模塊間的業務聯系即可,為自己的業務測試用例做準備。數據流向圖:目的是搞清楚,該某塊功能涉及哪些表、存儲過程,數據表見關系如何,其實有點像數據庫模型的小型版,很多問題在界面上實現了,但后臺sql處理卻有錯誤。例矩陣這個主要是對覆蓋率進行校驗,其實是一個execl,針對某個需求點有哪些用例。這些文檔我稍后上轉。另外在閱讀需求時,多寫一些為什么(例如:文檔上寫著某輸入框有默認值,那你注明下:默認值可以修改嗎?)

  或許你們覺得讓測試參加會議,讓開發講解這些有點難,但記住一點:做測試的一定要“主動”。

  在做功能測試過程中,經常會碰到其他的問題。例如:對于web,所用控件的ie兼容性,標簽值顯示格式、長度,提示信息風格、內容,按鈕大小,名稱等這些,當前項目和開發人員都習慣后處理。更多時候測試跟開發還不能達成一致,維護時還有“這是以前開發人員弄的,當前不予修改這些。” 一些通用的界面要求可以定個標準并維護,這個初步難的話,在項目測試計劃里能注明下,并達成統一。這樣避免項目后期,開發人員改動,測試人員由于對工作負責又得全部測試一遍,減少工作量。

  功能測試,先抓主干,在測分支這是恒定的原則。但如何完善功能測試這個值得討論,測試前如何分析需求,編寫用例,測試通過準則。測試中確定測試版本,選擇用例,測試優先級。項目后期的測試分析,用例優化等等。