很多人都認為「手工測試沒有技術含量」，「做測試，還是自動化測試，效能測試比較有前途」等等。
首先，我想的是，什麼是「技術含量」。我覺得，一般指的有「技術含量」的，就是你能做別人不能做，或者你完成目標比別人快的多的事情，如果隨便乙個人很快能上手完成你所做的工作，就不算有技術含量。就好像只把偽**轉換為語言的程式設計師，有多少「技術含量」？從這個角度上看，很多人覺得「手工測試沒有技術含量」就不足為奇了，因為如果按照用例去執行，給出明確的預期結果，誰都應該知道用例執行是通過還是沒有通過。那如果不是用例的執行而是去設計，而是編寫用例呢？給出乙個功能點，每個人是否都能快速的設計出有效的測試用例呢。答案一般是否定的，最少同乙個公司，有的人寫的快，有的人寫的慢；有的人考慮的周全，思路很清楚，有的人寫用例和不寫用例一樣，想到哪寫哪。測試用例的設計總該算是有「技術含量」了吧，不懂業務的，熟悉業務要很長時間，不曉得邏輯方法的，肯定先要把邏輯弄清楚。
再次，不管什麼工作，什麼事情，只要能持續的做的深入，總會有能力上的提公升。（個人認為，能力包含技術，還有技術以外的東西）對於測試來說，如何定位乙個問題，就可以做的很深。上次參加那個交流會，會上某公司的主管就說了乙個例子：「假設我們測郵箱傳送4m的附件傳送失敗，一種做法是直接把附件給開發，說這個附件不能傳送；還有一種做法就是將問題進行細化，是檔案格式的原因，檔案大小的原因，還是最後只是檔案裡包含了不合法的字元。」如果是後一種，問題解決起來也快，開發也願意配合，自己也能提公升技能。的確，一開始細化問題的時候，會很費力，但是「火車剛發明的時候比馬還慢」，當你能力提公升了以後，會發現處理問題會越來越順手。（如果碰到無法理解的問題，肯定要給開發，不能自己轉牛角尖，但是開發修正後，可以去問是什麼問題，怎樣修復的。）說句比較考張的話，把平凡的測試變為不平凡的分析去做~
最後，說其他方面的成長。我們肯定很明白一點，測試不是憑想象，想怎麼測，就怎麼測的，總是在開始測試之前，先把思路理清楚，測試的策略想清楚，於是鍛鍊了思維。我們總是在描述bug的時候，擔心開發看不懂，每次以他人的眼光來審視寫的bug，是否有歧義，復現的步驟是否更直白，語句是否更簡練而清楚，順帶著，是否有截圖和圖上重點的標示，於是鍛鍊了文字描述。我們總是會和需求人員確認需求，和客服人員確認客戶問題，和開發確認缺陷問題，於是我們鍛鍊了溝通。也許有人會不認同這也是一種收穫，那可以問問自己，我們有沒有測試到一半，發現漏了功能點，重新回頭進行測試的情況；我們有沒有寫bug後，開發看不明白，打回的情況；我們有沒有根本沒有了解到客戶的真正問題，就馬上去解決的情況……
任何工作，當想有沒有前途前，想想自己為此付出了多少。如果做自動化或效能，只會簡單的入門，而不去深入，我想也不會有「前途」吧。
sql注入 手工注入
表示式 描述union 將查詢結果進行聯合輸出，追加在列尾 union all load 檔案讀取 into outfile 檔案寫入 datadir 資料庫檔案存放路徑 user 當前使用者 version 資料庫版本 database 資料庫名稱 表示系統變數 資料庫 表名描述 informat...
SQL注入（手工篇）
開發人員在開發web系統時對輸入的資料沒有進行有效的驗證及過濾，就存在引發sql注入漏洞的可能，並導致檢視 插入 刪除資料庫的資料，甚至可以執行主機系統命令。1.可能出現asp？id x的 2.漏洞測試 1 單引號測試 在頁面中執行命令時使用成對單引號和單個單引號進行測試，檢視是否有sql注入 2 ...
sql 注入手工實現二
這一節沒有什麼用，就是用來熟悉命令的 目標 1.order by 18 訂購18 存在18個表 2.聯合查詢，判斷可回顯資料位置,結果，可回顯位置為2，9，14 3.user 檢視當前使用者，version 檢視版本，database 檢視庫名 當前使用者為root使用者具有最高許可權 當前資料庫為...