敏捷測試（3） 基於story的敏捷基礎知識

基於story的敏捷基礎知識----story編寫

為什麼使用Story？

軟體行業40年多來，需求分析技術已經很成熟了，但是MRD驅動的過程不堪重負。因為往往MRD編寫會佔去很多時間，MRD評審又會佔去大量時間，編碼完成過後提測，壓力又全部傾注在QA身上，往往臨計划上線時間，或者體驗還差，或者bug還太多，或者項目延期。

使用story，項目完成時間會大大縮短，上市時間大大縮短。主要原因：

A． 採用story模式，將大需求拆為可獨立交付的小story，需求清晰明了，節省了大量的需求評審時間。

B． story足夠小，設計難度較低，並且改之前的書面詳細設計及其評審為“口頭溝通為主，文檔為輔”，詳設環節的時間也大量節省。

C． story足夠小，驗收標準更明確，測試設計環節簡化，評審環節改為口頭溝通，節約了大量設計時間。

D． story間並行，不是之前的所有需求評審完成，才開始詳設，詳設沒問題之後才開始編碼和測試，因此將需求階段PM的瓶頸，開發階段RD的瓶頸、測試階段QA的瓶頸都被打破。

E． 將RD從文檔和評審中解放出來，RD更有時間也更願意去自測和寫單測，bug量減少。

什麼是Story?

整個項目:

story:

story 包括三部分：使用者故事卡片、詳細描述、驗收標準。

（1）使用者故事卡片

三要素：使用者、任務和活動、目標

架構：

作為	xxx
我想要	xxxxx
以便	xxxx