昨日看《神探狄仁傑》，看到曾泰（乙個縣令）差點使用大刑來逼嫌疑人招供。突然對「屈打成招」這四個字有了興趣。所謂屈打成招，表面上是使用重刑，讓受刑人，因為忍受不住刑訊，而最終將隱瞞的「實情」全部透露出來。可是大家都知道的事實在於，所有人都承受不住重刑！一旦冤枉好人，後果不堪設想。
屈打成招的背後，隱藏的是縣官對查案中搜尋證據能力不足的表現（當然了，那種因為**，強制受害人認罪的，咱們不考慮）。縣官往往在一些表面證據的指引下，直接認定嫌疑人就是罪犯。因而動用大型！所以現在法律上一般都是重證據而不重口供。
上面是乙個用例圖。縣官往往容易忽略自己的搜尋證據的職責，所以才導致很多嫌疑人大呼冤枉的事情發生。所以說「搜尋證據」和「屈打成招」正是截然不同的兩種審案方式！
我們平時除錯軟體的時候，也經常有忽略方法，盲目上重刑的現象。最典型的情況是因為有多個模組，而錯誤出現在不同人實現的模組呼叫上。
你就是那個被呼叫的模組的實現者，現在讓你來修改bug，你第一懷疑的是什麼？稍微經驗豐富的人，有一句話會告訴你：先懷疑自己！可是很多人剛開始都會選擇懷疑別人。可能懷疑基礎模組出問題了，也可能懷疑呼叫者錯了，還有甚者懷疑編譯器錯了。我和一位同事因為這個打過好幾次賭，基本每次都是我贏。可每次他都先懷疑其他地方出問題了。
在那種錯誤場景能反覆出現的情況還好，如果是偶現的bug，那就更容易冤枉人了。在沒有錯誤的模組裡反覆找來找去。當發現不了問題的時候，還是繼續找。這種冤枉時間一般能搞個2天左右。2天之內能放棄跳出來已經很不錯了。好在經過這2天，他一定能夠吸收到足夠的教訓了。
我們繼續說說除錯。我以為，除錯和查案是一樣的。
第一、需要反覆地審查案發現場。不要一開始就直接猜測什麼地方有問題。現場是最好的開始。
當然了，和真正的案發現場一樣，很可能你發現的不是第一案發現場。這種情況在訪問記憶體越界的情況下，時有發生。由於記憶體資料發生了錯位，等到真正丟擲異常的時候，已經不是真正案發的時候了。大家經常懷疑編譯器出錯的時候，大部分也是這種情況，經常發現，明明2×2應該等於4，可偏偏結果不是！所以這個時候，關鍵在於找到第一現場。
如果一條線索不行了，再回過頭來，從現場尋找另外的線索。
第二、線索要重證據。證據是什麼？證據就是程式執行過程中留下的狀態。將中間狀態的資料記錄下來，進行對比，看看到底什麼地方出問題了。這才能真正發現問題。
第三、排除法很有用。將一些認為沒有可能的線索放棄。這樣大部分時候可以節省時間。但是如果最終行不通，需要重新拿起這些被放棄的線索。
第四、推理加證據的方式很多時候可以加快速度。有些時候，並一定能夠第一時間發現證據。但是，可以憑著經驗，先假設某種情況的發生，然後再順著這條路去找證據。這樣往往能夠加快速度。充分利用程式設計師的經驗。
第五、定案要重視證據鏈。證據往往不是孤立的。很多時候，如果我們只關注某乙個證據，而忽略了很多其他不合理的地方，那麼我們最後的結果往往就是沒有修改徹底，最經常的結果就是，遺漏罪犯！將每個細節解釋完整，bug才能修改徹底啊。這個時候，可以進行現場重演的方式來進行驗證。
除錯，就是在軟體中查詢bug的罪魁禍首，並給其定罪。在這過程中，最關鍵的兩點是：問題解決、效率要高。盲目地屈打成招的方式只能讓我們迷失方向。好在軟體的除錯，以最終的測試為監督，就算屈打成招也沒用。可是，這當中失去的時間，誰來彌補呢？
除錯與審案 切勿 屈打成招
2007年01月07日 13 27 00 昨日看 神探狄仁傑 看到曾泰 乙個縣令 差點使用大刑來逼嫌疑人招供。突然對 屈打成招 這四個字有了興趣。所謂屈打成招，表面上是使用重刑，讓受刑人，因為忍受不住刑訊，而最終將隱瞞的 實情 全部透露出來。可是大家都知道的事實在於，所有人都承受不住重刑！一旦冤枉好...
usb除錯與adb除錯
之前沒有太注意二者的區別，這裡簡單記錄一下。usb除錯，android應用開發或許經常會用到，之前我也是用這個方式來除錯程式的，android裝置如果是手機的話就很方便，裝置開啟usb除錯，並用資料線連線電腦與android手機，你的android studio就能看到控制台有手機的日誌輸出了。如果...
測試與除錯
管理員成績管理頁面的測試 測試與除錯 使用以介面為基礎的測試。以介面為基礎的測試僅僅依靠軟體與其執行環境之間的介面來選擇和產生測試資料，而不管軟體的具體需求和具體實現細節。包括軟體輸入，輸出資料的型別取值範圍以及取值的概率分布等等。功能測試，在程式介面進行，只檢查程式功能是否能夠按照規格說明書的規定...