最近一直在想
敏捷測試
如何實施的事情，敏捷測試在敏捷開發中貫穿始末，涉及到了多種角色的參與：客戶、開發、設計、專職測試等等，每個角色承擔著不同的測試任務，客戶與設計可以進行驗證需求實現的測試，而開發進行
單元測試，專職測試人員進行詳細測試。
我們這裡主要是來談談專職測試人員如何開展敏捷測試，其實這個問題也是很多軟體公司在研究的問題，我們公司也在摸索之中，今天就來介紹一下目前的一些情況。
首先介紹我們公司的情況，我們自己開發產品，大致主要有二條產品線，一條用敏捷方式，另外一條還是用傳統的瀑布方式，今天當然是介紹敏捷那條產品線。
在敏捷中，測試是從頭到尾一直參與的，而對於專職測試人員該從何時開始介入測試呢？各個公司都有自己的想法，對於我們公司而言，當乙個功能已經設計好並且決定在這個迭代週期中開發時，測試人員就應該開始介入了。
怎麼介入呢？
1、先從設計文件著手，參考客戶需求看看設計文件是否已經實現客戶的要求，對有疑問的地方與設計人員溝通清楚。當搞清楚整個設計思路以後，用腦中已經存在著的這個概念功能來寫測試用例。
這個測試用例需要共享給設計人員與開發，特別是給開發人員，因為他們開發的時候就能參照到這些測試點，避免出現未考慮到的地方。
2、當開發人員開發完成後，測試人員開始測試前或者測試中，需要進行討論會，討論什麼呢，討論這個功能的測試覆蓋點。之前測試用例已經寫完了，但是這個 測試用例是基於乙個想象中的功能的，實際的功能怎麼樣子，誰都不知道。而現在實際功能做出來了，對於乙個測試人員而言，就能得到基本的測試點了。而開討論 會的目的就是盡可能全的把測試點覆蓋，畢竟乙個人的思維總是有侷限性的，眾人拾柴火焰高。
不過，在敏捷中，功能是不定時做完的，可能今天做完2個，明天又做完3個，後天可能乙個都沒有，所以這種討論會不是固定間隔的，一般情況下，累積幾個功能以後開乙個討論會。
開討論會之前必須做好準備工作，也就是參與者需要提前看過這個會議中需要討論的功能，可以會前給大家乙個小時或者半個小時研究一下。而在會議中，功能的實際測試者需要將大家對於這個功能的討論測試點記下來，之後更新之前寫好的測試用例。
通過這個討論會的方式，可以有效地提高測試覆蓋面，從而提高產品質量。
當乙個功能開發完成以後，測試人員就可以開始按照設計完成的測試用例來進行測試了。在測試過程中，我們也需要注意很多地方：
1、首先，雖然測試可以根據測試用例來測，但是乙個產品如果需要覆蓋很多環境，比如資料庫，瀏覽器，作業系統等， 你要全部覆蓋到，我相信幾個sprint都沒法測完，所以怎麼解決的呢？我們是按照迭代測試的方式來解決，簡單而言，就是把乙個功能的測試分成幾輪，第一 輪可能在sql+ie+win7上測，第二輪呢，則在oracle+firefox+w2008上測，第三輪。。。。。。這個方法相對於我們現在的人力資 源來說比較合適，因為理論上你要測試全的話，測試的組合個數就是各個環境個數乘在一起，db（sql+oracle+access）×瀏覽器 （ie+firefox+chrome）×作業系統（win7+w2008+w2003）=27，這個是窮盡測試，的確可以測得很全，但是耗費的資源太 多，一般都不太可能採用。我們實際測的時候，只需要考慮三個組合： sql+ie+win7，oracle+firefox+w2008， access+chrome+w2003，這種方式有個好處就是既覆蓋了所有測試點，又兼顧了時間與人力資源。
2、既然只有三個組合，那為什麼還要分成不同的輪次測同乙個功能呢？這個裡是很有考慮的，首先，我們測試第一輪的時候，必然會發現bug， 開發修bug可能會導致其他bug產生，這些需要我們再做回歸測試；第二，敏捷歡迎變更，功能的變更是家常便飯，所以一旦乙個已經做完的功能發生變更，就 需要我們重新測試過；第三，對於乙個功能的測試，我們知道每個人總是有思維定式，如果能有不同人來測試同乙個功能，可能會發現很多不一樣的bug。基於這 些方面的考慮，我們設計了乙個功能需要經過起碼三輪的測試，第一輪是最主要的測試，測試完畢這個功能就應該是基本可用了，後面兩輪屬於回歸測試，確保修復 bug和做過變更過的功能依然可靠，並且用不同人的角度來測試同乙個功能。
3、分成三輪，其實還有另外乙個也很重要的考慮，由於是敏捷 方式，所以對於時間的把握很重要，我們希望每個sprint都能產生乙個可用的產品，可以讓客戶來體驗新做的功能，而測試往往是個攔路虎，因為既然要測， 我們就像測得仔細，覆蓋很多地方，那這個就需要時間，時間是敏捷的敵人，所以我們就在想，既要能快速得到build，讓客戶去看，又要保證質量，只能採用 分步的方式來做，先在最常用的環境裡進行測試，保證基本功能正常，可以給客戶評估測試，然後接下來再通過幾輪測試保證這個功能的質量。
採用了這種方式來進行敏捷測試，其實給整個測試團隊帶來了很大的壓力，我們需要更快的反應速度，更高的責任感，更強的掌控能力，一旦某一環失控，之後都是 乙個連環失控的局面，比如這個sprint有功能來不及測完，下乙個sprint已經開始，新的功能又開始過來，你得先測完上個sprint的，因為有客 戶等著看，但是這個sprint又在大量累計功能，最後越堆越多，而且在測試理論上，bug如果在早期發現，修復成本最低，一旦早期沒有發現，之後又在 bug的基礎上做了其他功能，最後導致了連環bug，修復成本會高得離譜。所以如果更高的要求能帶來產品更好的質量，當然是很值得的，而且對於員工個人能 力的提高也非常有幫助。
敏捷測試的實踐其實很多公司都在研究，但是真正能成功的可能還不多，其實我們已經試驗過很多方法，這次也是乙個經驗總結後的繼續嘗試，相信很快能找到敏捷測試的真諦。
***********************************=分割線******************************==
DPI適配之實踐篇
使用如下方法來獲得當前縮放係數 float getdpifactor return s ndpi define multiplydpi nlen int nvol getdpifactor 對話方塊使用對話方塊字型大小來決定控制項之間的布局，它們通常不需要進行特殊修改，就能在高dpi裝置上工作。對話...
字元編碼之實踐篇
windows字元終端 cmd 內部已支援unicode，另外終端還可以顯性地支援設定另外一種編碼，中文作業系統中預設為gbk，可以通過chcp命令修改，也可以修改登錄檔設定預設編碼。兩種修改方法 chcp 65001 設定終端編碼為utf 8 如果只輸入chcp則顯示當前編碼 chcp命令即是ch...
lambda表示式之實踐篇
之前對lambda 表示式的基礎進行過總結，現在就從實踐上進一步對它進行了解。看看它與委託 匿名函式的區別，以及它有什麼亮點！傳統的呼叫委託的示例 static void finddelegate predicatefindpredicate new predicate isbookcategory...