近做項目總是有一種凝滯的感覺，忙忙碌碌一整天，臨下班來檢驗自己的工作成功，不過編寫或者執(zhí)行了小一部分用例、提交了小于10個的bug，這跟以前在做項目時能寫很多TC，可以執(zhí)行很多模塊、提交二三十個bug的狀況，差距真的很大。

　　多次自問，究竟是什么緣故導(dǎo)致了這種情況，也問了部分同學(xué)，居然他們也有類似的感覺。那么究竟是在哪里出了問題？

　　按道理，現(xiàn)在測試可使用的工具越來越多，有一部分工作已經(jīng)被測試工具所替代，比如項目日報。那么我們使用工具節(jié)省下來的時間又消耗到什么地方去了？

　　我想了幾個不是很成熟的原因，權(quán)當(dāng)拋磚引玉，希望能夠讓更多的同學(xué)加入到這個話題的討論中來。期待發(fā)現(xiàn)問題所在，進(jìn)而解決問題，提高我們的工作效率。

　　測試設(shè)計方面：

　　現(xiàn)在的項目，都有N多個應(yīng)用。一個功能點涉及3-4個應(yīng)用的比比皆是，按照這個原則，幾乎每個功能點都需要產(chǎn)出一個系統(tǒng)時序圖，同時還需要一個流程圖，內(nèi)容基本重復(fù)，工作量翻倍。這樣的系統(tǒng)時序圖完全可以在流程圖中體現(xiàn)，看起來也會更直觀、清晰、準(zhǔn)確。建議時序圖還是從大局出發(fā)，不著眼于具體的功能點。

　　另外，UC整體框架圖還是有必要的。

　　測試用例方面：

　　過多的條條框框，反而限制了大家的思維。這不是說規(guī)范不重要，相反，規(guī)范相當(dāng)?shù)闹匾，正是有了?guī)范，我們才能保證用例的質(zhì)量，但是我們的規(guī)范要更多的注重邏輯的東西，而不是流于表面。TC，我們不僅要量，更要保證質(zhì)。

　　用例執(zhí)行方面：

　　項目伊始，所有的人都在執(zhí)行基礎(chǔ)模塊，而導(dǎo)致建立在基礎(chǔ)模塊上的功能點hold著，讓執(zhí)行者感覺效率不高，重復(fù)性非常大，資源在一定程度上是浪費的。

　　人員眾多，功能點的交互，實際上，在同一個時候，大家已經(jīng)在做部分相同的工作。但是又因為不是自己當(dāng)前執(zhí)行的模塊，只關(guān)注了界面上的，或者邏輯簡單的內(nèi)容，對深度問題不會去挖掘。

　　幾輪測試下來后，出現(xiàn)了這樣一個情況：簡單的功能被大家反復(fù)的測試了，而復(fù)雜的邏輯校驗，反而只投入了很少的時間。這一現(xiàn)象與我們測試中要求的復(fù)雜功能需要投入更多時間是想違背的。在一定程度上也降低了我們的效率。

　　現(xiàn)在的事情特別多，很難得有一整天是在安心的做一件事情。思路的打斷，在一定程度上也影響了效率。