乙個函式有兩個輸入量，乙個算術複雜度高，乙個算術複雜度低，你會把哪個放到外迴圈，哪個放到內迴圈？
想想也知道應該把算術複雜度低的放到內迴圈，因為每次外迴圈迭代，內迴圈就要計算一次。
如果是用array型別，那麼內迴圈就省了（可以直接計算數值），那麼應該迭代複雜度高的量，還是複雜度低的量？
但是剛剛睡午覺的時候，我怎麼想怎麼不對，即使是array型別，也應該與兩層迭代的原理相同，於是寫了個指令碼測試了一下。
brucesair:py-develop bruce$ python test.py
func_x win:20
func_y win:80
brucesair:py-develop bruce$ python test.py
func_x win:38
func_y win:62
brucesair:py-develop bruce$ python test.py
func_x win:31
func_y win:69
brucesair:py-develop bruce$ python test.py
func_x win:33
func_y win:67
brucesair:py-develop bruce$ python test.py
func_x win:37
func_y win:63
brucesair:py-develop bruce$ python test.py
func_x win:31
func_y win:69
func_x是迭代複雜度低的量，也就是每次迭代都計算複雜度高的量
func_y是迭代複雜度高的量，也就是每次都計算複雜度低的量。
發現優勢並不明顯。但是結論依然是：盡量把計算複雜度低的量放到內迴圈（或者用array直接計算出值）。
源**：
github主頁：
e-mail：
如何衡量測試效率
以系統測試發現缺陷的數量來衡量測試人員的系統測試效率，就好像拿開發人員的 行數衡量開發人員的開發效率一樣，無法客觀有效的反映測試人員的工作質量和工作效率。優點 以bug數量為基礎，有乙個明確而清晰的度量標準 缺點 欠缺力度和有效尺度，不能真正反映當前系統的質量狀況 原因 1 乙個點型的例子，主業務流...
如何提高測試效率
1.盡早參與到專案中 測試盡早介入專案詳細了解專案的業務需求，做好測試的前期準備 目前來說，可能大家都有類似的感受，接觸到的大多數的專案，都是測試週期比較短，開發人員耽誤了時間，為了不拖延專案進度，留給測試人員做測試的時間都非常緊張。如果專案測試的前期了解業務需求 了解產品屬性和準備測試資料不充分，...
如何提高測試效率
背景 措施 1，規範測試流程 從產品需求到設計，全程參與，在原型圖出來之後，寫測試用例點，建議使用xmind寫測試用例點，標好級別 用xmind寫用第乙個好處是可以理清業務邏輯，第二個是能提高編寫用例的時間，方便管理維護 2，自測 開發人員在開發產品過程中，有些功能先開發完成，在這個階段測試人員可以...