-
暫時沒有公告
軟件測試和VSTS 測試工具
發布: 2009-5-31 10:56 | 作者: 不詳 | 來源: 測試時代采編 | 查看: 314次 | 進入軟件測試論壇討論
1.12Alpha Test, Beta Test
在開發軟件的過程中，開發團隊希望讓用戶直接接觸到最新版本的軟件，以便從用戶那里收集反饋，這時開發團隊會在開發過程中讓特定的用戶（alpha/beta用戶）使用正處于開發過程中的版本，用戶會用特定的反饋渠道（email, BBS）與開發者討論使用中發現的問題，等等。這種做法成功地讓廣大用戶心甘情愿地替開發團隊測試產品并提出反饋。最近有些開發團隊增加了反饋的密度，不必再等到Alpha或者Beta發布，而是不斷地把一些中間版本發布出去以收集反饋，美其名曰“技術預覽版本”或“社區預覽版本”。
1.13Usability Test可用性測試
小燕問：作為測試人員，我們是不是也要作可用性測試?
答：測試人員，以及其他的團隊成員都可以對軟件的可用性提出意見，包括用bug的形式放在在TFS中。軟件的可用性不神秘，就是讓軟件更好用，讓用戶更有效地完成工作。
但是我覺得“可用性測試”似乎更多地用來描述一套測試軟件可用性的過程，這個過程一般不是由測試人員來主導的，而是有對軟件設計及可用性有很多研究的“可用性設計師”來實行。網絡上有許多關于這方面的文章，大家可以參考。
1.14Bug Bash
問：我們已經講得太多的測試了，好像微軟還有一個叫“bug bash”的活動，是啥意思？
答：簡而言之，就是大家一起來找小強的活動–小強大掃除。一般是安排出一段時間（一天），所有測試人員（有時也加入其他角色）放下手里的事情，專心找某種類型的小強。然后結束時，統計并獎勵找得最多的，和最厲害的小強的員工。這種活動，如果運用得好，有下面的作用：
當然，小強大掃除也有一些副作用：
- 擾亂正常的測試工作
- 如果過分重視獎勵，會導致一些數量至上，濫竽充數的做法。
兩個細節是：
1．一定要讓“小強大掃除”有明確的目標，明了的技術支持。
2．一定要讓表現突出的人介紹經驗，讓別人學習。
要記住，最好的測試，是能夠防止小強的出現。
2 總結和思考
2.1 十八般兵器
阿毛：超總,我的腦袋好像裝不下了! 聽了這么多，我感覺像是身上扛著十八般兵器，累得半死，但是不知道什么時候，對哪一種敵人用哪一種兵器，能不能總結一下!
阿超：好，我們用軟件開發的生命周期來說明一下不同的測試在不同階段的使用：
遠景和計劃階段：
測試只是處于計劃階段，同時要收集用戶對于軟件非功能性的需求，如效能，可用性，國際化等。一些“小強大掃除”的類型也可以在這個時候初步安排。
開發階段：
開發人員要寫單元測試，測試人員要寫BVT。
隨著軟件功能的逐步完善，測試人員要進行集成測試。這時，團隊可以開展對程序非功能性特性的測試，如效能/壓力測試，國際化/本地化測試，安全性測試，可用性，適用性測試等。在這個時候，可以考慮分析各個模塊的代碼覆蓋率，以增加測試的有效性。根據計劃，各種類型的“小強大掃除”會以適當的頻率發生。
穩定階段：
到了一個開發階段的尾聲，這時測試團隊就可以依據以前制定的驗收標準，對軟件逐項進行驗收測試。按照測試計劃，各個方面的測試都會宣布“測試完成”-所有想到的測試都做了，所有問題都發現了。在此階段，團隊也可以把軟件發布給外部進行alpha/beta測試。
一般情況下，測試隊伍要把迄今為止發現的所有小強都從新試一次，確保它們都在最后的版本中被清除了，沒有一個“回歸”出現。
發布階段：
測試隊伍要把盡可能多的測試用例自動化，并為下一個版本的測試工作做好準備。
2.2 構建的質量
1．編譯失敗
2．可測/不可測
3．可用/不可用
2.3 問題
2.3.1 如果連續幾天都不能產生“可測”版本，怎么辦？
提示：可以在下一個構建版本中限制簽入的數量，只接受那些高等級的修改，在一般的做法中，導致“不可測”的小強的嚴重性是1，必須在下一個構建開始的時候得到改正。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
領測軟件測試網最新更新
