1、如何保證測試的結果是正確的？
最終結果是正確的，沒有錯誤日誌？這樣只能測試到開發者已經**到的異常，並不能保證程式是沒有bug的。
我們不僅要關注最終結果是否正確，還要對關鍵步驟進行跟蹤。
比如，假設有10個連線，每個連線上的包有序列號。那麼我們不僅要看每個連線上的包的序列號是公升序就ok了，
還需要確認所有連線上的包的總數，和返回包的序列號的總數也要一致，除此之外，還需要確認，每個連線上的包
的序列號和返回包的序列號是一致的，排除將這個連線上的包由於錯誤，處理的時候變成了另乙個連線的包的可能性。
此外，由於連線是有狀態改變的，我們也要關注狀態的變換，防止由於狀態轉換的錯誤，導致本來處理後結果應該是
錯誤的，但是，最終結果卻變成了正確的。
2、對於多執行緒的公平性的測試。
不僅僅只看每個執行緒內對每個連線處理的是否公平，還需在乙個大的絕對軸上進行比較。因為，可能出現每個
執行緒對每個連線的處理是公平的，但是，多個執行緒處理後的結果在時間軸上累加的結果可能就不是公平的。
3、測試時連線的資料，也要根據線上的實際資料進行測試，或者是實際資料乘乙個係數進行測試。防止，測試資料沒有參考價值。
同時，也能防止由於資料的量級不同導致的程式的處理結果不同。
對測試這事的一些看法
4年的測試職業經歷讓我對測試 這件事 和 做這件事的人 有了較明朗的認識。測試這件事 既然是一件事，那麼就幾個問題 目的是什麼？目的就是保證被測系統的質量。這沒什麼可說的，測試的職責就是這個，一切都圍繞這個主題進行。幹些什麼？說到幹些什麼，這裡就出現了很多任務作，不同的組織環境裡有不同的工作，我見過...
對產品初期測試的一些認識
對於乙個剛弄出來的新產品雛形，會有很多這樣那樣的問題，比如很多功能點沒有按照既定的需求加以細化 很多流程只是粗略的調通，在系統聯調時會有很多調不通的問題。一般都是由於專案週期有限，為了能盡量按期完成指定的目標，我們會盡快的讓產品早點切入到測試中，一邊測試，一邊修復bug，甚至讓一些小的功能點在測試過...
對測試轉開發的一些想法
首先需要引兩個外鏈 其實我這兩天，重新審視了一下我的內心，我想從乙個測試轉開發的真實動機到底是什麼？那絕對不是因為我愛開發技術愛的痴狂，雖然我確實適合做技術。根本原因就是，我受夠了做乙個功能測試。功能測試對乙個人的成長沒有任何幫助。產品經理去了解業務，設計系統流程，然後與開發討論實現的問題，然後開發...