首先，我想的是，什么是“技術(shù)含量”。我覺(jué)得，一般指的有“技術(shù)含量”的，就是你能做別人不能做，或者你完成目標比別人快的多的事情，如果隨便一個(gè)人很快能上手完成你所做的工作，就不算有技術(shù)含量。就好像只把偽代碼轉換為語(yǔ)言的程序員，有多少“技術(shù)含量”?從這個(gè)角度上看，很多人覺(jué)得“手工測試沒(méi)有技術(shù)含量”就不足為奇了，因為如果按照用例去執行，給出明確的預期結果，誰(shuí)都應該知道用例執行是通過(guò)還是沒(méi)有通過(guò)。那如果不是用例的執行而是去設計，而是編寫(xiě)用例呢?給出一個(gè)功能點(diǎn)，每個(gè)人是否都能快速的設計出有效的測試用例呢。答案一般是否定的，最少同一個(gè)公司，有的人寫(xiě)的快，有的人寫(xiě)的慢;有的人考慮的周全，思路很清楚，有的人寫(xiě)用例和不寫(xiě)用例一樣，想到哪寫(xiě)哪。測試用例的設計總該算是有“技術(shù)含量”了吧，不懂業(yè)務(wù)的，熟悉業(yè)務(wù)要很長(cháng)時(shí)間，不曉得邏輯方法的，肯定先要把邏輯弄清楚。
再次，不管什么工作，什么事情，只要能持續的做的深入，總會(huì )有能力上的提升。(個(gè)人認為，能力包含技術(shù)，還有技術(shù)以外的東西)對于測試來(lái)說(shuō)，如何定位一個(gè)問(wèn)題，就可以做的很深。上次參加那個(gè)交流會(huì )，會(huì )上某公司的主管就說(shuō)了一個(gè)例子：“假設我們測郵箱發(fā)送4M的附件發(fā)送失敗，一種做法是直接把附件給開(kāi)發(fā)，說(shuō)這個(gè)附件不能發(fā)送;還有一種做法就是將問(wèn)題進(jìn)行細化，是文件格式的原因，文件大小的原因，還是最后只是文件里包含了不合法的字符�！比绻呛笠环N，問(wèn)題解決起來(lái)也快，開(kāi)發(fā)也愿意配合，自己也能提升技能。的確，一開(kāi)始細化問(wèn)題的時(shí)候，會(huì )很費力，但是“火車(chē)剛發(fā)明的時(shí)候比馬還慢”，當你能力提升了以后，會(huì )發(fā)現處理問(wèn)題會(huì )越來(lái)越順手。(如果碰到無(wú)法理解的問(wèn)題，肯定要給開(kāi)發(fā)，不能自己轉牛角尖，但是開(kāi)發(fā)修正后，可以去問(wèn)是什么問(wèn)題，怎樣修復的。)說(shuō)句比較考張的話(huà)，把平凡的測試變?yōu)椴黄椒驳姆治鋈プ鰚
最后，說(shuō)其他方面的成長(cháng)。我們肯定很明白一點(diǎn)，測試不是憑想象，想怎么測，就怎么測的，總是在開(kāi)始測試之前，先把思路理清楚，測試的策略想清楚，于是鍛煉了思維。我們總是在描述bug的時(shí)候，擔心開(kāi)發(fā)看不懂，每次以他人的眼光來(lái)審視寫(xiě)的bug，是否有歧義，復現的步驟是否更直白，語(yǔ)句是否更簡(jiǎn)練而清楚，順帶著(zhù)，是否有截圖和圖上重點(diǎn)的標示，于是鍛煉了文字描述。我們總是會(huì )和需求人員確認需求，和客服人員確認客戶(hù)問(wèn)題，和開(kāi)發(fā)確認缺陷問(wèn)題，于是我們鍛煉了溝通。也許有人會(huì )不認同這也是一種收獲，那可以問(wèn)問(wèn)自己，我們有沒(méi)有測試到一半，發(fā)現漏了功能點(diǎn)，重新回頭進(jìn)行測試的情況;我們有沒(méi)有寫(xiě)bug后，開(kāi)發(fā)看不明白，打回的情況;我們有沒(méi)有根本沒(méi)有了解到客戶(hù)的真正問(wèn)題，就馬上去解決的情況。。。。
任何工作，當想有沒(méi)有前途前，想想自己為此付出了多少。如果做自動(dòng)化或性能，只會(huì )簡(jiǎn)單的入門(mén)，而不去深入，我想也不會(huì )有“前途”吧。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
