項目中遇到的問題

　産品總算上線了，曆時兩個半月的時間，出了内測，公測，beta版本，1.0.1版本，中間有段時間累得夠嗆，但上線之後，感覺努力還是值的。

　　1. 提測品質差

　　問題分析

　　a. 版本提測品質差，但基于釋出時間已在，是以，在提測差時就開始測試

　　提測品質差的點：- 基于上每項功能的完成度都不高 - 有些功能均未實作 -

　　b. 新的團隊，團隊處于磨合期

　　c. 在提測時，對提測要求不明确，在時間點到後，匆忙提測

　　解決方式：

　　明确版本提測要求，并且開發得到了足夠的時間。

　　2. 版本控制

　　問題描述：

　　最初階段，每天出一個版本，基于新版本測試，記錄每個版本上測試的功能。版本過于頻繁，品質把控不好

　　問題分析：

　　a. 基于版本提測品質差，而且每天出一個版本，差上加差，

　　b. 雖然記錄每個版本上測試的功能，但仍然無法把控目前版本的品質狀況。

　　解決方式：暫停每天釋出一個版本

　　前期：将全功能版本作為下一個版本釋出目标，但由于一些功能并沒有完成，因而，全功能版本分成了好幾個階段

　　後期：以測試一輪周期，釋出最新版本

　　3. 功能反複

　　問題描述：在上一個版本是ok的功能，在新版本中功能失常

　　功能反複分兩點：一是大功能反複， 二是小功能（如：某個bug）反複

　　大功能反複：情況主要發生成項目前期和中期

　　a. 功能未完成，在完善功能時，未考慮到與該功能相關的點

　　b. 在提測之後，發現一些問題，導緻了整個子產品重構，重構後導緻了問題的反複

　　小功能反複：這個情況主要發生在項目中後期

　　a. 因為項目裡的部分開發是外援的，在項目中期時，撤出了團隊，新接手的人員，對代碼不熟悉，在修改bug時，經常出來顧此失彼

　　b. 開發小一在修改代碼時，動到了小二的代碼，導緻了小二出了問題

　　對大功能反複，是這麼處理：冒煙測試由開發來完成，冒煙通過後，再交由測試

　　對小功能反複 ，沒有有效的處理方式，測試這邊可以做的是，加強測試，這個問題，在釋出前夕好了很多，但問題仍然存在　　4. 需求不明确，前後不一緻

　　問題描述：需求不明确，特别在一些邊界，各端統一上

　　a. 互動文檔經曆6任互動，最後一任互動隻參與兩個子產品的定義，現任互動對于以往互動了解不夠深入

　　b. 産品提測時，互動驗證不足

　　由于項目已提測，是以在整個周期裡，對于互動需求方面的疑問直接找相關人員去确認。

　　在後期的小版本中，我們把這類問題盡量控制在提測之前（詳見小版本裡的改進與問題）

　　5. 測試和開發資訊不對稱

　　問題描述：測試擷取到的消息，與産品實作的方式不一緻，如：有的功能定義了，但産品并未實作或實作方式與定義不一緻

　　a. 在開發階段，測試并未參與讨論需求，還在其他項目裡

　　b. 需求重新确認後，沒有及時通知測試

　　強調消息需要通知到測試，現在階段，如果因這種類型而引起的問題，将建ticket，指派給相關人員

　　小版本裡的改進與問題

　　現存在問題：

　　1. 現對release版本會做rc checklist, 進行最後版本的品質控制，

　　但會存在一些問題，在小版本提測時，就已經存在，而冒煙測試是測不到的，在最後做checklist時，才發現

　　改進點：

　　1. 需求疑問在提測之前盡量提出，并且通知到開發，在開發階段便把該問題解決

　　測試在開發階段跟蹤産品進度

　　在寫測試用例時，就把問題抛出。

　　2. 提測流程：

　　對功能方面的ticket，互動在提測之前便在開發機器上驗證，通過後再提測

　　把不符合互動預期的問題，在提測之前更改，節約了時間，避免問題在提測後才提出

最新内容請見作者的github頁：http://qaseven.github.io/