上周遇到了6天都是22點(diǎn)～23點(diǎn)下班，實(shí)在是累～
今日終于有空了，得趕緊趕上進(jìn)度才行。

第一次分享思考
關(guān)于測(cè)試流程的思考：

第一次分享有提到測(cè)試流程中有幾個(gè)必備的流程
1.需求評(píng)審
2.用例評(píng)審
3.UI評(píng)審
4.迭代總結(jié)
5.迭代報(bào)告
現(xiàn)公司測(cè)試流程：
web端：1.需求評(píng)審(會(huì)出需求文檔，文檔出來(lái)后開(kāi)始寫(xiě)測(cè)試用例)2.開(kāi)發(fā)確定任務(wù)點(diǎn)和出版本時(shí)間3.出版本提測(cè)4.回歸測(cè)試5.上線（上線前會(huì)開(kāi)發(fā)會(huì)提測(cè)N次，回歸測(cè)試N次）6.迭代總結(jié)
android端：1.開(kāi)發(fā)出版本提測(cè)（提測(cè)是會(huì)告訴我新增了那些功能，要測(cè)哪些，log怎么看）2.測(cè)試通過(guò)上線3.迭代總結(jié)

這周工作中遇到的情況：
1.web端和android端同時(shí)出版本，兩邊都在催，一會(huì)android一會(huì)web，根本沒(méi)有時(shí)間看用例，中途還要來(lái)幾個(gè)線上問(wèn)題，亂套了。
2.一會(huì)android一會(huì)web，次數(shù)多了大腦根本切換不過(guò)來(lái)，懵b了。
3.開(kāi)發(fā)對(duì)需求的理解不清，導(dǎo)致大量功能不全BUG，功能設(shè)計(jì)和需求對(duì)不上。
4.提測(cè)版本質(zhì)量粗劣，動(dòng)不動(dòng)就404，500的。
5.設(shè)計(jì)文檔的缺失。
6.android端零文檔，只能憑借經(jīng)驗(yàn)和之前自己總結(jié)的舊測(cè)試用例去測(cè)。
7.android的需求都是口頭說(shuō)，事情一多就忘。
目前的解決方案：
1.web端和android端同時(shí)出版本的情況必須有先后次序，一件一件事情來(lái)。
2.開(kāi)發(fā)必須出設(shè)計(jì)文檔（web和android都是），這樣能及早發(fā)現(xiàn)功能設(shè)計(jì)和需求對(duì)不上問(wèn)題。
3.增強(qiáng)自己的web技術(shù)水平（包括接口測(cè)試方面），這樣更能快速定位問(wèn)題和描述清BUG。
4.提升看log能力
5.回看老徐之前關(guān)于web測(cè)試的文章，把常規(guī)用例寫(xiě)出來(lái)

7月5日
今天聽(tīng)了老徐的分享，問(wèn)下關(guān)于web端和android端同時(shí)出版本的情況
下面是聽(tīng)完回答后的新想法
1.代碼管理有問(wèn)題
2.開(kāi)發(fā)一定要指明測(cè)試重點(diǎn)在哪里，而不是隨便改個(gè)東西就全回歸。

后續(xù)有新想法再修改。