? ? 時間飛逝，歲月如梭，2015/11/25號寄以厚望的用戶版1.4.3和專家版1.0終于準(zhǔn)備上線了撬腾。每次發(fā)布版本的前兩天都是非常緊張的節(jié)奏钓试，大家也是拿出了十二分的勁頭在拼装黑，上線結(jié)果也盡在掌控中。
現(xiàn)在將用戶版1.4.3和專家版1.0的測試結(jié)果匯報如下：本次測試組總共收到27個測試包弓熏，當(dāng)前禪道上仍處于未解決一級bug還有2條：
1. 手機內(nèi)存不足時恋谭，打開安卓用戶版APP會停止運行。（15%的機率挽鞠，涉及到首頁的架構(gòu)）
2. CRM提現(xiàn)金額與APP端不符箕别。其他等級狀態(tài)的bug有152條铜幽，分布如下：
11/25版本迭代我們測試組做了如下努力：1. 編寫詳細(xì)的專家版測試用例，與項目經(jīng)理串稀、產(chǎn)品組對接了理解有誤的部分需求除抛，并訂正修改。
2. 簡單的輸出了需求中基本功能的思維導(dǎo)圖母截。
3. 按照開發(fā)日報及時調(diào)整測試計劃到忽，跟進(jìn)主要功能的持續(xù)修改。
4. 推動TDD模式的測試開發(fā)方式清寇。
5. 推進(jìn)用戶版與專家版的聯(lián)測喘漏，發(fā)動開發(fā)人員與產(chǎn)品交互一起找bug。
11/25版本迭代我們存在的問題：
1. 仍然是上線前又開啟了邊改bug邊回歸的模式华烟。這種模式對于測試來說翩迈，我們是拒絕的。由于之前忙著開發(fā)新功能盔夜，遺留大部分的bug在上線前開始統(tǒng)一改负饲，結(jié)果就是邊回歸邊測試，效果不理想喂链。
2. TDD測試模式為了適應(yīng)快速開發(fā)模式返十，導(dǎo)致我們在短短一個月測試了20來個版本，我們要求可測試的版本是模塊邏輯可走通的椭微，此前版本按照項目經(jīng)理輸出的日報排的測試計劃洞坑，雖然計劃延期比較少，但是發(fā)布的測試包模塊并沒有真正的達(dá)到100%完成度蝇率，所以測試結(jié)果并不那么理想迟杂。
3. iOS與Android交叉測試不夠此項問題的出現(xiàn)是由于測試機器過少，研發(fā)與測試在同時間段均需要測試機本慕，導(dǎo)致測試到最后逢慌，發(fā)現(xiàn)部分iOS與Android實現(xiàn)的功能不一致。4. 團隊人員對自己開發(fā)的功能不重視有不少初期發(fā)現(xiàn)的bug修改后间狂，在后期又經(jīng)常反復(fù)的出現(xiàn)攻泼，或者是修改一個bug卻引發(fā)其他多個bug，致使后期的每一個版本都不敢保證模塊功能的正確性鉴象，需多次花費時間驗證和回歸忙菠。
下一版改進(jìn)的方式：
1. 時間的問題排計劃的時候請各位開發(fā)能好好估量一下自己完成模塊的時間，也應(yīng)實事求是的匯報模塊的完成度纺弊。我們可測試的標(biāo)準(zhǔn)是項目經(jīng)理日報上的完成度牛欢。
2. TDD模式TDD模式保證了項目在研發(fā)中，每個工種在項目周期內(nèi)的工作盡量并行淆游。這種模式要求每個人員對自己的工作進(jìn)行較準(zhǔn)確的評估傍睹，以保證其他部門的無誤配合隔盛，也是目前最適合我們的測試開發(fā)模式。我們需要做的努力就是合理的評估工作時間拾稳，每一個模塊或功能完成后吮炕，相關(guān)開發(fā)人員能自覺及時的將測試包放至svn上，以便讓需要配合的部門能主動的介入到當(dāng)前項目中访得。
3. 測試機型過少的問題目前已經(jīng)在采購龙亲，此問題在下一版本的研發(fā)階段會有較大改善。
4. Bug描述與有效溝通之前趕時間悍抑，禪道上有些bug描述得比較簡短鳄炉，結(jié)果得不償失，增加了很多溝通成本搜骡。下一版本中拂盯，每一個bug要求把步驟和期望描述準(zhǔn)確，每一偶現(xiàn)或必現(xiàn)的問題都盡量附上截圖记靡，開發(fā)人員疑惑的bug也及時溝通還原助理解谈竿。
這兩天在看《不懂項目管理，還敢拼職場》這本書簸呈，里面介紹了合理評估時間的方法有“最樂觀的時間*1.5”榕订，我們目前的迭代進(jìn)度做不到如此評估店茶，但是也不可以改為 “恰恰好的時間*0.8”蜕便，這樣子做的結(jié)果就是夜夜加班，質(zhì)量保證不了的情況下贩幻，實現(xiàn)的效果也未達(dá)標(biāo)轿腺。
最后給大家來碗雞湯：人要學(xué)會愛自己，何為愛自己丛楚？把自己想象成自己的父母族壳，愛人，兒女趣些，你不想讓他們做的壞事情仿荆，你自己也不要做，這就叫愛自己坏平！
愿我們都少加通宵班拢操，好好愛自己！
測試人員
