天天看點

《笑傲測試》筆記(第五式:浮雲遮日)

  所謂開發過程中的正規化,核心就是科學的定義流程和嚴格的執行流程。一個測試項目成功的關鍵是各個環節能夠環環相扣和緊密配合,這就要求測試流程必須定義的清晰科學。

  一、柔性要求:流暢的測試流程

  測試的所有活動能夠被組織和定義的平滑高效,實施起來沒有阻滞和混亂。

  一個普通的版本測試過程中,會經曆的一些活動:

  新版本釋出說明(release notes)

  測試任務書(task description)

  更新測試版本(release update)

  問題驗證(error verification)

  新功能測試(new feature test)

  壓力測試(stress test)

  自由測試(free test)

  問題報告(error report)

  進度報告(progress report)

  二、剛性要求:嚴格的測試規程

  組織中的每個人能夠充分了解自己工作的輸入條件和輸出準則,大家既有檢查上一步工作是否到位的權利,又有按時保質保量地完成工作的義務。

  輸入條件:

   測試用例必須簡明扼要,分布均勻,不能有太多重複的用例,又不能有明顯的疏漏。這些都需要在測試項目開始之前得到保證,指望測試執行階段的自我修複是靠 不住的。是以需要根據需求跟蹤矩陣來設計測試用例,同時建立定期評審的機制來彌補被忽略的功能點和根據實踐中遇到的各種情況來更新補充測試用例。

  (2)輸入之二:測試分工

  測試分工是為了讓每個測試的執行者清楚地了解自己在何時應該做什麼,有哪些具體的要求。測試經理在每輪測試之前進行詳盡的任務細化并通過有效的溝通機制傳達給團隊中的每個成員,最正規的途徑是下達書面的測試任務書(測試計劃)給團隊的每一個成員。

  (3)輸入之三:測試工具

  對于測試工具的要求有兩個。

  第一是好用,在選擇測試工具的時候要慎重和廣泛的比較,要保證我們即将使用的工具确實能夠幫助我們——可以制定一個規範的測試工具評審表,按照測試的需求把測試工具的表現做定量的評估。

   第二是大家都會用,每個測試人員都必須了解自己需要用到的測試工具及其使用方法。——要制定完備的教育訓練計劃,讓每位項目成員通過教育訓練來學到工具的使用方 法和各種規則,同時測試的管理者應該能夠一目了然的看到教育訓練的組織和參加情況(簽到表),避免因新加入的成員教育訓練不及時而影響工作的品質。

 (4)輸入之四:送出物的模闆(bug送出工具)

  子產品化是讓工作步調一緻的捷徑,它能讓一個即使經驗不夠豐富的項目成員也能夠在很短的時間内送出出品質不錯的輸出物。是以模闆必須要簡單清晰,盡量避免給使用者過多的自我發揮的空間,用形式來限制内容。

  輸出準則:

  (1)輸出之一:測試結果(用例執行結果)

  測試結果的意義并不在于有沒有人看,它的意義主要展現在,當測試的粒度均勻的情況下,能夠定量地描述出目前軟體的穩定程度。而且多輪測試的力度相同,那麼可以從測試結果的通過率上可以看出軟體功能實作的變化趨勢。

  要降低用例的“不可測率”,測試團隊需要制定有針對性的工作流程來監控“不可測”的測試用例;對于長期“不可測”的測試用例即使封殺,使之不再占用測試人員的時間;對于短期“不可測”的測試用例,要及時快速的創造測試的條件,把測試的黑洞及時修補上。

  (2)輸出之二:問題報告(送出bug的描述資訊)

  問題報告是測試工作最主要的輸出物,必須做到清晰、詳盡,提供盡可能多的資訊。包括問題出現的軟體版本、日期、測試人員的姓名和聯系方式、問題的概要描述、重制機率、重制步驟、和先決條件、期望的輸出和實際的輸出等。

  (3)輸出之三:調試資訊(log日志)

  調試資訊是必不可少的,它能夠幫助開發人員了解問題發生的時候系統在做些什麼事情。在測試開始之前要對測試團隊進行深入的教育訓練,需要每個人都明确哪一類問題需要送出哪一類調試資訊,擷取調試資訊的手段、工具、配置等。

  (4)輸出之四:子產品測試報告

  子產品測試報告是很有價值的開發文檔之一。第一條就是,報告的完成要及時,不能等新聞成了舊聞才看到事後諸葛亮似的報告。另外内容要既粗且細,粗 是為了迎合層次比較高的管理者;細是為了當讀者有興趣的時候,能夠從報告中了解到足夠詳細的内容。此外子產品測試報告中應當盡量提供:子產品的穩定程度 (case通過率)、子產品的穩定趨勢(與上一個版本的case通過率做比較)、嚴重問題的清單。

  (5)輸出之五:修改驗證(bug修改驗證)

  對一般的開發團隊來講,衡量其績效的一個重要名額就是改bug的反應速度,而一個bug的終結一定是以通過測試人員驗證的時間為準。修改驗證的 優先級永遠都應該是測試人員案頭優先級最高的任務。因為遲早對于此bug的修改一定是會進入到産品基線中的,是以與其晚驗證不如早驗證,這樣我們可以有更 多的時間測試那些可能由此修改帶來的風險。

  及早對修改進行驗證,這一方面是對開發人員的支援,另一方面如果此修改不解決問題甚至帶來了其他問題,及早驗證能給開發人員更多的時間做進一步檢查。

  三、自我限制:測試過程評估

  在測試過程中要對測試的過程有定期嚴格的評估,以便及時發現并糾正測試過程中出現的問題。

  組織一個兼職的監督小組,成員包括測試項目組長,若幹測試工程師和獨立的軟體qa,由他們按照事先約定的項目和内容定期評估測試過程。對測試品質的評估不僅僅要停留在一兩個測試用例執行的結果上,更高層次的評估重點是評估測試過程的合理性和效率。

  三張圖表:測試工作流程圖、宏觀測試流程、項目評估方法

====================================分割線================================

最新内容請見作者的github頁:http://qaseven.github.io/

繼續閱讀