現代軟體工程 第十三章 【軟體測試】 練習與討論

標籤：des   使用   ar   sp   問題   代碼   amp   工作   時間   

一、有錯不改，閏年問題

1. 如何判定閏年，正確的判斷條件應為

(year%400==0)||(year%4==0&&year%100!=0)，注意三個求餘之間的關係。題目代碼中對4求餘和對100求餘的條件應與在一起。

1. 計算錯誤。

當輸入天數恰好截止到某一閏年的最後一天時，days減為366以後，會從while開始執行三個判斷條件，而days不會減少，year不會增加，進入死迴圈狀態。應該把days>366改為days>=366或days>365。

學習到測試案例的設計方法，根據等價類別劃分測試集合，比如如果一個函數可以返回 true | false, 你至少得有兩類測試集合, 讓它分別返回 true | false；如果知道程式的工作原理，可以把等價類別更詳細的劃分，針對每個函數都要設計；按邊界值設計測試案例；從內部考慮看測試案例是否把語句覆蓋掉（當然即使全部覆蓋也不能保證程式不出錯）。

1. 沒想到還有閏年。關於年份日期的變換，要想到有平年閏年的區別。出租車的閏年蟲問題，提示我們不要圖省事兒，迴避特殊問題。

二、 侵官之害甚於寒

    在開發過程中，不同角色相互合作、相互制約。大家不能越俎代庖，否則會“甚於寒”。比如測試人員再做驗證測試時，需要做多方面、多平台的測試，這些工作量遠遠超過了開發人員的能力範圍，因此必須要由測試人員驗證並處理已經修理好的bug。

三、 測試經驗交流

    不放過任何可能的bug，會導致不少“As design”，但也不是絕對的壞事；測試人員不用研究，去找問題根源甚至去想修複問題，這些越過了開發人員的職責範圍；保證測試方法的多樣化；以使用者的角度去想問題；舉一反三，在出過問題的類似點上測試；在事先通知和安排好的情況下，可以交換測試；把比較穩定的測試寫成自動化的測試，會減輕手工測試的壓力。

四、 傳說中的拐點

    拐點是在大型複雜項目中，測試人員和開發人員全部通過一個系統管理bug才會出現的現象。對於日期驅動型的小項目，要人工幹預，如延遲一些Bug，砍掉一些功能，慢慢升高“必須修複的小強”這個標杆等，主動讓拐點發生。

五、 學習和使用多個平台上的測試載入器

六、 曆史上的20大bug(未完待續)（未完待續）

七、 曆史悠久的bug（未完待續）

八、 TPS和並發使用者數之間的關係

每秒事務數TPS是衡量系統效能的一個非常重要的指標。伺服器端效能主要以TPS來衡量，與使用者並發數沒有多大關係。

單純考慮單個指令碼，使用者並發數Vu與TPS的換算關係為                         ，Rt是該指令碼一次完成所有操作的時間。設每個指令碼中有m個事務，共有n個指令碼，則總的TPS是： 。（註：對此換算關係有疑問）

對於新系統，TPS和Vu的擷取只能通過業務部門進行評估。對於舊系統，取高峰時段線上使用者數的10%作為Vu，單位時間內完成的業務筆數作為TPS。

系統的最大TPS是一定的（在一定範圍內），但並發使用者數不一定，可以調整。效能測試的時候，不要設定過長的考慮時間，以最壞的情況對伺服器施壓。在做負載測試時，一般按照梯度施壓的方式去加使用者數，大型系統5000個使用者並發足夠，中小系統1000個使用者並發足夠。

現代軟體工程 第十三章 【軟體測試】 練習與討論