在進行項目管理過程中，每個迭代或每個階段的任務功能驗收是一個必不可少的環節。

特別是項目團隊成員較多，任務功能分散的情況中。

本文就個人工作中情況，技術上介紹下功能點驗收流程遇到的小問題。

本司有一套對feature、story進行管理工具。迭代結束時亦是基于上面的feature、story由QA進行驗收。

功能驗收標準，主要有以下幾條：

輸出	具體要求	是否必要
單元測試用例	提供UT，代碼行覆蓋率>=60%	是
功能測試用例	提供RF，目前只要求運行通過	是
系統測試用例	由測試部測試人員提供	N/A
接口文檔或使用說明書	作為功能開發輔助輸出	否

單元測試用例在開發過程中起著舉足輕重的作用，相信每一個專業的開發者，必定也會重視。所以目前團隊中針對單元測試用例行覆蓋率才有了60%的硬指標。這里需要吐槽也就是60%的指標。

團隊采用的是IDE環境中的runCoverge進行驗證，如圖：

QA關注的重點，即line的百分比，超過60%則通過。

但現實是，存在一些模塊由于輔助代碼較多，較難達到60%的情況的（換句話說50%已經足夠了）。由于一刀切的緣故，測試用例的原來本意出現了偏差，開發人員開始想法設法提供行覆蓋率，而不是提高用例本身的質量。這邊列舉了幾個：

• 將低覆蓋率的代碼暫時注釋掉，先通過驗收，再恢復
• 寫一堆反射方法，測試用例中觸發調用無測試意義的代碼
• 將一些功能代碼直接刪除，先把數據提高再說

哎，上有政策下有對策。而其帶來的不好影響也顯而易見。如占用開發大量時間、無用測試代碼占用編譯時間，版本構建時間超長、代碼質量下降等。（剛剛遇到的問題是一次代碼gerrit提交，模塊編譯時間達20分鐘以上，也曾經花費一天才完成一個commit的提交，心力交瘁）

?

項目以前也使用過jacoco進行檢查，但不知為何沒有推廣。由比上面的驗收方法來說，jacoco顯得專業的多，插件自身功能就不說了。列了幾個管理上的好處：

1、每次編譯都會產生覆蓋率報告，QA隨時查看、監控數據。避免開發人員動手腳。（每日構建通過UI進行數據展示，不知小伙伴知不知道有什么好的軟件）

2、通過plugin配置，過濾掉無測試意義的代碼，如BEAN對象。給足開發人員空間。

3、QA通過檢查2中配置，把控測試用例質量。

?

附上配置：

? <plugin><groupId>org.jacoco</groupId><artifactId>jacoco-maven-plugin</artifactId><version>0.8.0</version><configuration><excludes><exclude>**/com/x/x/x/sal/compat/postgre/impl/NN*.class</exclude><exclude>**/com/x/x/x/sal/compat/postgre/impl/*Test.class</exclude><exclude>**/com/x/x/x/sal/compat/SchemaContextHelper.class</exclude><exclude>**/com/x/x/x/sal/compat/postgre/impl/cli/*.class</exclude></excludes></configuration><executions><execution><id>report</id><phase>prepare-package</phase><goals><goal>report</goal></goals></execution></executions></plugin>

?

? ? ? ? ?

總結

以上是生活随笔為你收集整理的项目功能验收阶段的小问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。