測試計劃以及ACC介紹

      測試計劃是最先出現,最早被遺忘的測試產物.在項目早期,測試計劃表明了對軟件功能的預期.可是,除非獲得持續的關注,它會很快隨着新代碼的完成,功能特性的改變以及設計的調整而過時.伴隨着計劃內或計劃外的變動,維護一份測試計劃是要花費大量精力的,除非多數項目的成員會按期查看,不然測試計劃並無什麼價值.

      後面這一點是測試計劃真正的殺手:試問在產品的整個生命週期中,測試計劃能在多大程度上做爲測試活動的指導?測試人員會不斷參考計劃來安排一個應用的測試嗎?會要求開發人員在功能增長或修改時去更新測試計劃嗎?在開發經理管理todo列表的時候,他們會在桌面上打開一份測試計劃嗎?在進展溝通會議上,測試經理會常常參考測試計劃的內容嗎?若是測試計劃真的重要,那麼全部這些事情應該天天都會發生.

     理想狀況下,測試計劃應當在項目執行中發揮核心做用,應當在軟件的整個生命週期中持續有效:隨着代碼庫的更新而更新,時刻表明最新的產品功能,而不是停留在項目開始階段時的樣子.他應該能夠幫助一個新加入的工程師迅速跟上項目進展.

    下面是咱們但願測試計劃中具備的一些特性.

• 及時地更新
• 描述了軟件的目標和賣點
• 描述了軟件的結構,各類組件和功能特性的名稱
• 描述了軟件的功能和操做簡介
• 沒必要花過多的時間去撰寫,必須隨時能夠被修改
• 應該描述必測點
• 應該能在測試中提供有用的信息,從而幫助肯定進展以及覆蓋率上的不足.

   ACC(Attribute Component Capability,即特質,組件,能力.這是一種測試計劃的替代方法)分析是一個從許多Google測試團隊的最佳實踐中總結出來的,並被專業人士在各類產品領域裏倡導的流程.

   ACC的指導原則以下.

• 避免散漫的文字,推薦使用簡明的列表.
• 沒必要推銷.
• 簡潔
• 不要把不重要的,沒法執行的東西放進測試計劃.
• 漸進式的描述
• 指導計劃者的思路
• 最終結果應該是測試用例

    最後一點很是重要:若是測試計劃沒有把測試用例應該怎麼執行描述的足夠詳細,它就沒有達到預先設定的幫助測試的本義.對測試的計劃而言,他顯然應該讓咱們清楚地知道須要編寫哪些測試用例.當你正好處於"徹底瞭解須要編寫哪些測試"這一點時,纔算完成了測試計劃.

   ACC經過指導計劃者依次考察產品的三個維度達成這個目標:描述產品目標的形容詞和副詞;肯定產品各部分,各特性的名詞;描述產品實際作什麼的動詞.這樣,咱們經過測試完成的就是驗證這些能力能正常運做,產品各組件能知足應用的目標.

1.  A表明特質(Attribute)

• 簡單
• 精確
• 變化
• 短小

    2. C表明組件(component)

     組件是系統的名詞,在特質被識別以後肯定.組件是構成待建系統的模塊,例如在線商店的購物車和結帳系統,Word處理器的格式化和打印功能等.組件是使一個軟件之因此如此的關鍵代碼塊.實際上,他們正式測試人員要測試的對象.

    3. C表明能力(capability)  

    能力是系統的動詞,表明着系統在用戶指令之下完成的動做.他們是對輸入的響應,對查詢的應答,以及表明用戶完成的活動.事實上,這正是用戶選擇一個軟件的緣由所在:他們須要一些功能而你的軟件提供了這些功能.

 

參考書籍:Google的軟件測試之道