項目終于結(jié)束了，這次經(jīng)歷的項目規(guī)模應(yīng)該是來這里之后的最大型的項目。又經(jīng)歷了一次項目之后的感想，下面針對需求分析階段（RPD）和測試分析階段來分別進行總結(jié)：
項目類型：大型重構(gòu)型項目。大部分是老大業(yè)務(wù)規(guī)則，小部分的新業(yè)務(wù)需求（這部分內(nèi)容是少不了的）
PRD階段：
先說說本次prd的缺點在于：新老邏輯區(qū)分不清晰，需求描述跳躍性很大，需求沒有完整的描述，沒有做好后續(xù)的跟蹤，沒有更新。我希望的prd文檔：
1、prd的結(jié)構(gòu)要清晰。（文檔的目錄結(jié)構(gòu)中提現(xiàn)）
曾經(jīng)看過一篇文章中有說到，系統(tǒng)功能是將人工操作過程搬到軟件系統(tǒng)來實現(xiàn)，那么任何的人工操作肯定都會有一條主流。那prd文檔里需要體現(xiàn)這條主流，讓人家一看就很清晰
2、prd僅包含本次需要實現(xiàn)的內(nèi)容
我們這個項目是改造型項目，很多老的規(guī)則不變。有些老的規(guī)則會有所變動，也會有新增加的功能。只要本次系統(tǒng)需要實現(xiàn)的都需要羅列出來，而本次系統(tǒng)要改造掉的東西那么只需要說本次需要改造成什么樣子即可，而無需將老的邏輯再描述一遍，會給看的人產(chǎn)生誤導(dǎo)和干擾，如果真的要去了解原來老的邏輯，到時候可以自己再去老系統(tǒng)里面去看。
3、prd要有業(yè)務(wù)流圖和實際業(yè)務(wù)說明
這個點，本次的prd里是有做到的。業(yè)務(wù)流圖可以主流，也可以是主流上某個節(jié)點的細化流程圖。并且配合文字說明，將流程圖和實際業(yè)務(wù)背景結(jié)合在一起做個說明。
4、PRD的粒度問題
測試用例有粒度的問題，prd同樣應(yīng)該有粒度問題。我覺得我們以前的prd文檔肯定是粗粒度的，所以我們才有了測試分析這么一個角色，去分解這些粗粒度的需求。但是實際上prd應(yīng)該是細粒度的。但是越細pd花費的時間越多，那針對有些項目，前期時間比較短，那么需要明確prd的一個粒度問題。prd要細到什么樣的程度，也是作為prd評審的依據(jù)之一
5、prd的迭代問題
開發(fā)過程有迭代，prd同樣需要迭代的過程。prd文檔并不是prd評審?fù)ㄟ^之后就沒事了的，我們不能要求prd文檔覆蓋的需求點是100%的，我們也允許后面的需求增刪改，但是每一次的變動，都需要實時更新prd文檔，并且及時通知到整個項目組。開發(fā)過程中，有的時候是業(yè)務(wù)方有需求要增加，有的時候因為開發(fā)設(shè)計的問題也會影響到需求變更，所有的這些pd都要及時做好跟蹤。
測試分析階段
1、測分的介入時間：
測分的介入時間應(yīng)該和系分是一樣的。越早越好，越早介入對于需求分析和理解都是很好的保住，對于比較復(fù)雜的需求在前期就可以使得PA，測分和系分的理解保持一致。
2、測分到底做什么事情？
理想中的測試分析階段應(yīng)該是制定測試計劃和測試用例編寫階段了。但是目前現(xiàn)狀，我們的測試分析需要做的事情是需求分析的一個補充。把所有的點都分析到位。不要去看系分是如何實現(xiàn)的，測分階段就是要把所有需要實現(xiàn)的測試需求點羅列出來。
3、測試計劃的制定
假設(shè)主體業(yè)務(wù)流程分以下幾級1->2->3->4 ，那么在每一級估算的計劃執(zhí)行時間應(yīng)該是數(shù)據(jù)準備時間+用例執(zhí)行時間+buffer時間。
1）數(shù)據(jù)準備時間：1級1小時，2級2小時，3級3小時，4級4小時（舉例類推）。
用例個數(shù)×每一級的數(shù)據(jù)準備時間。
2）用例執(zhí)行時間：用例估算個數(shù)×平均用例執(zhí)行時間。
3）buffer時間：這個時間是無法提前預(yù)計到的一切情況而預(yù)留的時間。比如bug修復(fù)時間，溝通的時間，會議時間等等。
注：大型項目在測分階段無法完成所有的用例，所以在這個階段制定測試計劃不
可能是精確的。我們只能盡量準確的去估算。
測試計劃分：項目測試計劃（大型項目，這個計劃是細化到某個階段的）；第一輪測試執(zhí)行計劃（在階段內(nèi)每個人細化到天的）；第二輪測試執(zhí)行計劃；集成測試計劃。每個階段都要有相應(yīng)的測試計劃，而且隨著需求的變更，設(shè)計的變更，測試計劃也要及時跟著調(diào)整。