移山 - 軟件測試討論(5)

　　用一個數字照片編輯軟件為例，這個軟件的各個模塊都是獨立開發的，可是用戶有一定的典型流程，如果這個流程走得不好，哪怕某個模塊的質量再高，用戶也不會滿意。

　　1.把照相機的儲存卡插入電腦

　　2.程序會跳出窗口提示用戶導入照片

　　3.導入照片

　　4.對照片進行快速編輯

　　a.調整顏色

　　b.調整亮度，對比度

　　c.修改紅眼

　　5.把其中幾幅照片用email發送

　　這里面每一步出了問題，都會影響用戶對這一產品的使用，同時這里面各個模塊的用戶界面如果很不一致(即使是ok/cancel按鈕的次序不同)，用戶使用起來也很不方便。這些問題都是在單獨模塊的測試中不容易發現的。

　　1.10Performance Test 效能測試

　　用戶使用軟件，不光是希望軟件能夠提供一定的服務，而且還要求服務的質量要達到一定的水平，軟件的效能， 是這些“非功能需求”，或者說“服務質量需求”的一部分。

　　效能測試要驗證的問題是：

　　軟件在設計負載內能夠提供令用戶滿意的服務質量。

　　1.在設計負載內 – 我們要定義什么是正常的設計負載

　　2.令用戶滿意的服務質量 – 我們要定義什么樣的質量是令用戶滿意的

　　設計負載 – 從需求說明出發，得出系統的正常負載。例如，一個購物網站，客戶認為正常負載是每分鐘20次客戶請求。

　　用戶滿意的質量 – 同一個購物網站，如果客戶定義滿意為：每個用戶的請求都能在2秒鐘內返回結果。

　　我們可以逐步細化 –

　　設計負載的細化，上面我們只提到“20次客戶請求”，那這些客戶請求到底是什么，我們可以按照請求發生的頻率來分類：

　　1. 用戶登錄 (10%)

　　2. 用戶查看某商品詳情(50%)

　　3. 用戶比較兩種商品(10%)

　　4. 用戶查看關于商品的反饋(20%)

　　5. 用戶購買商品(5%)

　　6. 所有其他請求(5%)

　　服務質量的細化 – 有些請求，是要對數據作“寫”操作，可以要求慢一些，比如“用戶購買商品”，這一服務質量請求可以放寬為3秒鐘。

　　除了用戶體驗到的“2秒鐘頁面刷新”目標外，效能測試還要測試軟件內部各模塊的效能，這要求軟件的模塊能報告自身的各種效能指標，通過perfmon? 或其它測試工具表現出來。

　　和別的測試不同，效能測試對硬件要有固定的要求，而且最要每次測試在相同的機器和網絡環境中進行，這樣才能避免外部隨機因素的干擾，得到精準的效能數據。

　　同時，效能測試的結果應該成為“發布指南”的一部份，給客戶發布和改進系統提供參考。

　　在VSTS中如何進行效能測試在以后會詳細講解。

　　1.11 Stress Test壓力測試

　　壓力測試嚴格地說不屬于效能測試。壓力測試要驗證的問題是：

　　軟件在超過設計負載的情況在仍能夠返回正常結果，而沒有產生嚴重的副作用或崩潰。

　　問：為啥不要求軟件在這種情況下仍然在2-3秒鐘內返回結果?

　　答：因為我們做不到。

　　注意，我們在這一部分要求“正常結果”，啥叫“正常”?我們也要和客戶達成一致。比如，同一個購物網站，所有請求都能在網絡返回“超時”錯誤前返回，就可以認為是“正常”。 或者網站返回“系統忙，請稍候”，也是正常結果。但是，如果用戶提交的請求一部分執行，另一部分沒有執行;或者用戶信息丟失，這些都是不正常的結果，應該避免。

　　那我們怎么增加負載?對于網絡服務軟件來說，主要有下面兩個方面：

　　1. 沿著用戶軸延長

　　我們用剛才的購物網站為例，正常的負載是20請求/分鐘，如果有更多的用戶登錄，怎么辦?那么負載就會變成30，40， 100請求/分鐘，或更高

　　2. 沿著時間軸延長

　　做過網絡服務的同事都知道，網絡的負載有時間性，負載壓力波峰和波谷相差很大，那么如果每時每刻負載都處于峰值，程序會不會垮掉?這就是我們要作的第二點，沿著時間軸延長。

　　與此同時，我們可以減少系統可用的資源，來增加壓力。

　　注意，壓力測試的重點是驗證程序不崩潰或產生副作用。在超負載的情況下，我們的程序仍然能夠正確地運行，而不會死機。在給程序加壓的過程中，程序中的很多“小”問題就會被放大，暴露出來。 最

　　常見的問題是

　　內存/資源泄露，在壓力下這會導致程序可用的資源枯竭，最后崩潰。

　　一些平時認為“足夠大/足夠好”的算法實現會出現問題。

　　進程/線程的同步死鎖問題，在壓力下一些小概率事件會發生，看似完備的程序邏輯也出現了問題。

　　在VSTS中如何進行壓力測試在以后章節中會詳細講解。

　　1.12 Alpha Test, Beta Test

　　在開發軟件的過程中，開發團隊希望讓用戶直接接觸到最新版本的軟件，以便從用戶那里收集反饋，這時開發團隊會在開發過程中讓特定的用戶(alpha/beta用戶)使用正處于開發過程中的版本，用戶會用特定的反饋渠道(email, BBS)與開發者討論使用中發現的問題，等等。這種做法成功地讓廣大用戶心甘情愿地替開發團隊測試產品并提出反饋。最近有些開發團隊增加了反饋的密度，不必再等到Alpha或者Beta發布，而是不斷地把一些中間版本發布出去以收集反饋，美其名曰“技術預覽版本”或“社區預覽版本”。

　　1.13 Usability Test可用性測試

　　小燕問：作為測試人員，我們是不是也要作可用性測試?

　　答：測試人員，以及其他的團隊成員都可以對軟件的可用性提出意見，包括用bug的形式放在在TFS中。軟件的可用性不神秘，就是讓軟件更好用，讓用戶更有效地完成工作。

　　但是我覺得“可用性測試”似乎更多地用來描述一套測試軟件可用性的過程，這個過程一般不是由測試人員來主導的，而是有對軟件設計及可用性有很多研究的“可用性設計師”來實行。網絡上有許多關于這方面的文章，大家可以參考。

原文轉自：http://www.kjueaiud.com