這幾天居灯，沒有參與到具體的項目中祭务，就靜下來總結總結。
最近在項目中怪嫌，自己的一些體會吧待牵。
首先說是 每個項目都會說自己是特殊的，所以我們現(xiàn)在沒辦法按照規(guī)范來實施喇勋，畢竟特殊場景特殊對待嘛缨该。
客觀原因，確實是不可以忽視川背，實際上贰拿，每個項目都會有“沒辦法”蛤袒、“不可控”的因素。比如膨更，客戶就要妙真、客戶一直在變、客戶說不能拖荚守、客戶不管珍德，就要這樣實現(xiàn)；是的矗漾，以客戶來作為借口锈候，這個時候我就覺得我沒辦法反駁，但是敞贡，客戶要的是這樣嗎泵琳？是客戶一直在變，還是我們一直沒有抓到客戶的點誊役，是客戶催的急還是我們沒有提前想到获列？
我一直和測試成員說，要懂業(yè)務蛔垢，要知道做這個功能真正的原因击孩，是解決了什么問題，是基于客戶什么需求去實現(xiàn)的或者說是為了實現(xiàn)某個需求必須做的基礎功能鹏漆。
但現(xiàn)實是溯壶，有時產品需求人員都不知道客戶的需求時什么，更甚者就直接說甫男，客戶自己都不知道自己要什么，我們怎么知道验烧。這句話貌似沒問題板驳，但潛在的問題就多了，客戶不知道自己要什么碍拆，就意味著我們做出來的永遠是草稿而非定稿若治，同時，客戶不知道自己要什么感混，那是不是知道自己不要什么端幼？
說句題外話，我一直都覺得弧满，我是一個不知道自己要什么的人婆跑，不論是購物還是什么。但我知道自己不要什么庭呜，比如買衣服滑进，我不知道自己究竟是想買什么風格犀忱，但我知道，什么風格是我絕對接受不了的扶关，這樣在去掉自己不想要的之后阴汇，繼續(xù)選擇，就可以比較快的選擇出自己要什么了节槐。
繼續(xù)回歸到我們的項目上搀庶，在項目里面，對于測試人員的要求铜异，也是比較高的哥倔。測試人員需要在快速迭代的情況下，完成需求的解讀熙掺、需求點提取未斑、測試點轉化，編寫測試用例币绩，完成測試蜡秽，跟進bug的修復。這需要有強的責任心缆镣，要主動積極芽突，而不是被動等待，遇到問題要敢于提出來董瞻。
其實寞蚌，我個人理解，作為測試钠糊，重要的點就在于 業(yè)務理解能力挟秤，用例編寫能力，測試風險的預知能力〕椋現(xiàn)在越來越多的人不重視測試用例艘刚，特別說 我們是敏捷，我們不需要寫用例截珍，想想真是xxxx攀甚。測試用例的編寫是為了指導你以及他人進行測試，但這并不是說一味按照用例去執(zhí)行岗喉，因為我還聽到有人說秋度，我寫了10條，在測試過程中發(fā)現(xiàn)自己漏寫了幾天钱床，那這幾個還要不要執(zhí)行荚斯？你是怎么問出來這些問題的，要不要執(zhí)行？你作為測試心里沒數么鲸拥？不僅要執(zhí)行還得補上去拐格，然后分析，為什么你寫的時候沒發(fā)現(xiàn)刑赶，在測試的過程或者測試的最后時間點才想起來捏浊。
然后，說一下測試和開發(fā)的關系撞叨。我最近在項目上發(fā)現(xiàn)金踪，來自開發(fā)小伙伴的投訴：測試總是在上線到生產環(huán)境后才提bug，在測試階段就沒有發(fā)現(xiàn)牵敷。
我也觀察了一下胡岔，確實，在上線后測試會提出一些問題枷餐，我總結一下：
1靶瘸、因為環(huán)境問題，也是因為數據覆蓋不到位毛肋，比如生產環(huán)境出現(xiàn)的一些特定的數據才會觸發(fā)的一些問題怨咪；
2、因為緊張润匙，面對的是生產環(huán)境诗眨，所以大家就更加小心，生產上發(fā)現(xiàn)的一些小問題會無形中被放大當作重要的問題看待孕讳；
3匠楚、歷史問題，存在一些歷史版本遺留的問題厂财，可能是在其他版本有修復芋簿，但沒有同步到生產；
4璃饱、業(yè)務關聯(lián)的模塊与斤，比如修改了一個小功能，但對其他一個非直接關聯(lián)的模塊造成了影響帜平，恰巧是測試未覆蓋到的點，屬于漏測梅鹦！
5裆甩、生產環(huán)境本身臟數據問題，因為刪除生產環(huán)境數據不完全導致的bug齐唆。
關于以上這些問題嗤栓，建議在可行的情況下，使用生產庫同步到測試環(huán)境，同時在測試用例評審時加上開發(fā)和產品茉帅，大家都要提出有效建議叨叙，才起到一起評審減少漏測風險的作用。再者對于測試環(huán)境發(fā)現(xiàn)的問題堪澎，無論大小都要進行跟蹤記錄擂错，避免遺漏。
