概述
在項目管理流程中成洗，有幾個關鍵階段：
需求階段擅编、開發(fā)階段、測試階段胶惰、上線階段
其中的需求階段和開發(fā)階段是最為重要的惦界，一個是設計挑格，定義這個功能如何運作，一個是執(zhí)行與實現(xiàn)沾歪，這兩個階段把控好了漂彤，往下走就會順利很多。下面重點講一下開發(fā)階段中的提測步驟，在提測前應該準備什么東西挫望，以保證提測的質(zhì)量立润。
首先關于提測這個動作，我自己是這么理解的：
提測了媳板，就說明開發(fā)人員認為功能就長這樣了桑腮，已經(jīng)完全按照產(chǎn)品
PRD完整的實現(xiàn)了，是個嚴謹蛉幸、負責破讨、認真的動作。
理論上巨缘，研發(fā)人員一旦提測添忘，就可以開始處理其他需求任務了的。
為啥要注重提測質(zhì)量
在剛才提到幾個項目管理階段中若锁，越早認真越好搁骑，早發(fā)現(xiàn)問題早解決，如果到了測試階段又固，還出現(xiàn)各種各樣的問題仲器，基本都是要付出慘痛的代價的。
你有沒有遇到過仰冠，功能提測后乏冀，還出現(xiàn)如下情況：
功能跟產(chǎn)品
PRD里的不一樣，走偏了洋只；
前端BUG幾百個辆沦；
嚴重阻塞性BUG幾十個；
測試環(huán)境極度不穩(wěn)定识虚，測試人員一直來讓開發(fā)人員定位肢扯。
這些問題都會造成極大的溝通成本、執(zhí)行成本担锤，也會占用很多資源蔚晨，直接影響了整個部門對需求處理的吞吐量，而這些本身是可以盡量避免的肛循。解決的辦法就是狠抓提測這個步驟铭腕。下面列一下我自己實戰(zhàn)過且發(fā)揮了作用的一些手法。
<font color="orange">注意：這里著重強調(diào)的是多糠，提測這個動作執(zhí)行前累舷，要做的事情，關注的是夹孔，測試人員接手后笋粟，是否能順利走下去怀挠，像架構方案、技術設計害捕、壓測绿淋、回滾方案呀，這些是另外的動作尝盼，是必做的吞滞，不會在文章里強調(diào)。</font>
提測前要做的事情(不分先后)
完成端到端聯(lián)調(diào)
自己負責的部分再完美也是沒用的盾沫，端到端一聯(lián)調(diào)裁赠，可能就出問題。
端到端聯(lián)調(diào)的重要性再怎么強調(diào)都不為過赴精，它可以整體性的驗證功能模塊是否符合產(chǎn)品預期佩捞。像UI問題、體驗問題蕾哟、后端接口數(shù)據(jù)問題一忱、兼容性問題等，都可以在這個階段發(fā)現(xiàn)谭确。
另外有兩個小技巧可以用上：
- 如果開發(fā)環(huán)境不太穩(wěn)定或者數(shù)據(jù)不全帘营，建議直接在測試環(huán)境里做開發(fā)聯(lián)調(diào)，把環(huán)境調(diào)順了逐哈，完成后芬迄，測試人員可以在同一個測試環(huán)境里做功能測試，可以避免提測后昂秃，一大堆環(huán)境問題禀梳，而測試人員又不知道如何處理，只能找開發(fā)定位肠骆，造成的資源浪費出皇。當然如果測試人員有能力獨立維護測試環(huán)境的話，就不建議這么干哈哗戈。
- 根據(jù)測試人員提供的冒煙用例，有目標的進行開發(fā)聯(lián)調(diào)荷科，提高聯(lián)調(diào)效率唯咬。如果開發(fā)人員很有耐性，能按照產(chǎn)品
PRD里提的點畏浆，逐個驗證胆胰，那當然更好了。
執(zhí)行冒煙用例
測試人員在需求評審完后刻获，就需要開始進行測試用例設計了蜀涨，其中的冒煙用例是一個子集，是基礎的用例，這些用例如果無法通過厚柳，測試人員就可以將提測的模塊打回(<font color="red">會有一封大大的同時又抄送老板的主題為xxx功能冒煙不通過氧枣，打回的郵件發(fā)出來</font>)，因此開發(fā)人員需要認真的執(zhí)行冒煙用例别垮。
另外測試人員提供的冒煙用例必須要有質(zhì)量便监，能準確覆蓋基礎的重要的功能點。
列出改動點
這里的改動點碳想，說的是烧董，你當前開發(fā)的模塊，改動了哪些已有的且在線上穩(wěn)定運行的模塊胧奔。你需要列出來逊移，讓測試人員更有目的性更有效率的去做回歸測試。
準備好上回歸環(huán)境的清單
像配置文件變更龙填、數(shù)據(jù)庫變更胳泉，MQ配置，這些在提測前觅够，都需要準備好胶背，要不然就可能出現(xiàn)功能模塊在測試環(huán)境或者回歸環(huán)境無法順利運行的情況，缺胳膊少腿的喘先，像大一些的模塊钳吟，涉及到的服務很多，每個服務都有自己變更窘拯，不及時記錄起來红且，很容易忘記。這樣會極大的降低功能測試的效率涤姊。
我之前遇到過好幾次暇番，一個功能模塊周一晚上提測，隔天測試人員開始介入思喊，但是直到隔天下午功能模塊才順利的在測試環(huán)境里運行壁酬，這是多么的不應該，浪費開發(fā)人員和測試人員的時間恨课，嚴重一些的舆乔，還可能導致項目延期。
必要時剂公，產(chǎn)品經(jīng)理提前驗收
像大一些的功能模塊希俩，涉及到的點非常多，這個時候纲辽，如果產(chǎn)品經(jīng)理有時間的話颜武，可以讓其在功能提測前驗收一把璃搜，這樣可以及早發(fā)現(xiàn)功能模塊是否走偏了，也可以發(fā)現(xiàn)很多的前端體驗問題鳞上，及時讓開發(fā)人員解決掉这吻。
我是遇到過，一個項目因块，提測后橘原，測試人員提了幾百個前端體驗或者UI問題，單單是測試人員寫BUG描述涡上，就花費了很長時間趾断，然后還需要讓開發(fā)流轉(zhuǎn)BUG，這些都需要時間吩愧。
想對測試人員說的
如果開發(fā)提測前芋酌，上文提到的那些動作沒有準備好，測試人員是可以不進行測試的雁佳，因為提交給測試人員的脐帝，是一個極度不穩(wěn)定的東西，一旦進入測試環(huán)節(jié)糖权，就開始坑測試人員了堵腹。因此寧愿按住它，不開始星澳。另外這也是保護測試人員的一種方式疚顷，畢竟隊列就這么長，別隨便給測試扔一些不靠譜的功能禁偎。
另外腿堤，測試人員可以理直氣壯挑戰(zhàn)開發(fā)人員的，其實只有一處如暖，就是提測質(zhì)量笆檀，如果功能模塊都上線了，但是出問題了盒至，那么老板第一個找的就是測試人員酗洒，因為功能是否能上線，是測試人員決定的枷遂，相當于跟老板說：
功能經(jīng)過嚴格的測試了樱衷，可以交付了。
而事實上登淘，上線后卻是一堆問題。因此測試人員一定要死磕開發(fā)人員的提測質(zhì)量封字，冒煙不過的黔州，打回耍鬓，再冒煙不過，嚴肅警告流妻，還是冒煙不過牲蜀，那就狠一點，可以直接不測試某些開發(fā)組提測過來的模塊绅这，因為一提測過來涣达，進入到測試環(huán)節(jié)后，就又開始各種不順利证薇，各種浪費度苔。
小結(jié)
流程有了，就要開始考驗執(zhí)行力了浑度，這是個難題寇窑，一開始的話，比較建議的方式是箩张，項目指定一個懂項目管理流程的技術負責人甩骏，授予他/她臨時權力，由它全程統(tǒng)籌先慷，到處督戰(zhàn)饮笛，誰不配合，可以直接指出论熙。按照這種方式福青，實施幾個項目后，大家就會開始慢慢適應赴肚。
