測試是什麼
軟體測試本質上和其他測試沒有區別，通俗的說法，就是試試軟體產品好不好使，具體的說來就是選擇輸入到軟體，看看輸出結果是否達到預期，就這麼簡單，所謂各個級別的測試、各測試技術，只要是測試，都是選擇輸入，判斷結果。
測試的侷限性
絕大多數情況下，僅僅通過測試，無法確保被測的軟體沒有缺陷，這種侷限性是由測試本身天然注定，因為測試不是證明。這就如同想表明勾股定理是正確的，即使舉了不計其數的服從勾股定理的例子也不能否定存在意外的情況，這裡的例子就如同軟體測試的測試用例，因此對於軟體測試，即使執行通過了不計其數的測試用例也不能否定存在意外的情況，而存在這種意外情況就表明軟體存在缺陷。這種侷限性如此簡單以至於很少有測試書籍直接指出來，倒是有不少書說測試是門藝術，顯得高階大氣上檔次，但是我覺得跟中文字面上的藝術沒有半毛錢關係。正是由於測試的侷限性，不得不採取一些啟發式技術來確保測試的充分性，例如測試要達到95%的分支覆蓋就可以給人足夠的信心。也正是因為啟發式技術，達到同樣的95%分支覆蓋，有的測試人員能夠給人測試充分的信心，有的卻不能，這就取決於測試人員的能力、責任心等等。
自動化隨機測試是個好想法
編寫自動測試框架，有效自動隨機選擇測試輸入，自動判斷測試結果，持續不斷的反覆執行並記錄結果。現在無論是個人pc還是機群，**不貴，效能很好，完全有能力執行自動測試。問題的關鍵在於編寫自動測試框架，而這不亞於一般的軟體開發，不過如果你希望得到高質量的軟體，這絕對是不二選擇，看看微軟的windows作業系統系列，現在為何漏洞越來越少，高效的自動化隨機測試肯定功勞不小，其他的如adobe reader，軟體測試也採用了這個技術，軟體質量也明顯提公升。因此如果你想從事軟體測試，了解一下自動化隨機測試，很有必要。
你的軟體你最懂
當前，國內流行第三方測評，我認為最最關鍵的軟體測試人員就是開發人員自己，因為只有他才最了解自己軟體實現的弱點，前提當然他必須認真負責。而其他測試人員只能作為補充，這種補充是需要的，智者千慮，必有一失。但是將其他測試人員尤其是那些根本不了解具體實現的測試人員作為關鍵測試人員，是極不明智的。
是不是不可以將軟體測試的任務完全交給第三方呢？也不是。有些重要場合是可以完全交給第三方測試，但必須有詳細的各種文件，從需求到設計到實現，當然這種成本高了去，誰能承受？
軟體測試追求的不是覆蓋率，不是花哨測試技術，終極追求還是軟體質量，永遠不要把手段當成目的。
Postman api介面自動化侷限性
以下為通過postman進行api介面自動化測試遇到的問題，記錄下來若有哪個解決了回來更新 1.環境是否dev會影響異常message和detail輸出 2.是否分su，rpc本地呼叫和遠端呼叫存在不一致，例如服務端異常輸出 rpc超時配置 3.返回值中時間戳無法與當前時間一致比較 4.返回值jso...
ICT測試侷限性分析
在實際的電路板上,大量各式主,被動元件通過串,併聯方式連線起來.下述情形,ict無法測試或無法準確測試.1 探針不可即的零件 一般來說,每個零件的兩端 或各引腳 所在的銅箔面均有探針觸及才可測試.目前,本廠smt零件,ic腳 包括懸空引腳 少數因沒有相應的test point而未取探針,致使這顆零件...
關於 jmeter 效能測試的 侷限性
這兩天做壓測，用了constant throughput timer 來限制qps。被壓測介面最大tps 為110左右，在qps達到110前，qps tps，而 qps 110後，介面tps會穩定在110。如下圖 再增加執行緒和timer配置都只會導致響應時間的增加，tps 卻不會增加，並且無報錯 ...