我如果說有一天我靈機一動想到去執行這個做法，那就是在裝。這個方法大家都知道，但是不一定會去做，我們立馬去做了，主要也是受了些刺激，被別人找到一些問題。於是我們就在想，我們部門有好幾個測試小組，為什麼我們不自己來個左右互搏呢？
正好雙11剛結束的時候有點時間，那好，我們就做做看。最後的結果遠超我的預期，在幾天的時間裡，我們累積發現了63個問題，確認的有效問題47個。有25個模組參與，14個發現了問題。當然這些問題有多種型別，包括一些體驗類的問題，有很多是非常有價值的。這結果真是讓人又喜又憂，不過從這個方法的角度，是完全的被證明了。
我稱這個方法為「換人如換刀」，實際操作中也有一些思考和考慮，不妨拿出來**。
1. 很多時候，我們為了工作的效率，深入的了解業務，以及和對口產品和開發的協作，很長一段時間，每個功能點會有乙個比較固定的test owner。
這樣的好處顯而易見，但是缺點也很明顯：
- 會有審美疲勞，一些問題可能覺得不是問題
- 每個人有自己思維的盲點，很多路徑考慮不到，測試用例評審也只能幫到一部分。
- 團隊成員間對功能模組互相的了解不夠，遇到邊界的問題容易遺漏
2. 如何來劃分範圍？
完全的散打，每個人隨意挑選自己感興趣的模組？ or 逐個的制定owner，事先完全的分好？
最後我們選取了中間路線，首選做跨地域（正好我們有兩個地域的團隊）的切分，兩地呼喚，在這個基礎上，每個人來挑選對方的模組，先到先得。
背後的思考是需要有一定的覆蓋度，但是又有一定的趣味。
3. 按地域切分會引起一些不好的氛圍嗎？
我其實擔心過，但很快不是很擔心。異地團隊的溝通和融合確實不容易，不過之前已經有了比較好的基礎，而且大家都是站在乙個比較堅實的想把事情做好的基礎上，另外我們的導向上也是完全正向的。
另外， 其實有一定的競爭是乙個良性的張力，就像前一篇（
）提到的，是乙個發現更多bug的動力。
實際的結果證明，這方面也沒有出現問題。
就在剛剛寫的時候，我在想，其實還有更多的玩法，就是可以從不同的維度劃分，比如m，ipad，android，ios等等。
4. 需要feedback。
收到問題的同學需要像開發接到bug一樣，給出是否是問題，如何處理等反饋。這樣是跟進問題本身，也是對發現問題的人的尊重，對別人勞動的尊重。
5. 我們還設立了乙個獎，發給發現bug最多的人，「樂於助人獎」，幫助別人發現ta的模組的問題，其實就是在幫助別人。 這是個導向的問題。
6. 不要求全
很難每個人都那麼徹底的參與，可能因為不理解，可能因為手頭有別的事情，可能真的發現不了問題。看大的方面。
7. 不用去挑戰
每個正常的被別人發現問題的人都應該會有一些動力去做得更好。
下次再嘗試一些不同的細節的操作，這個應該可以作為乙個保留曲目。
測試工作小結
從 dev轉做 tester 一段時間了，稍微總結一下。首先說tester 的思維方式與 dev完全不同，我一度經常陷入到原來 dev的考慮問題的老路上去，對一些缺陷總是覺得不安，但實際上軟體產品總是有缺陷的，只要它達到可接受的質量程度就行了。我做tester 的工作主要是 get cases 通常...
測試工作 XPath
xpath 是一門在 xml 文件中查詢資訊的語言。xpath 可用來在 xml 文件中對元素和屬性進行遍歷。xpath 是 w3c xslt 標準的主要元素，並且 xquery 和 xpointer 同時被構建於 xpath 表達之上。因此，對 xpath 的理解是很多高階 xml 應用的基礎。其...
測試流程 測試工作的展開
一 測試的流程 測試貫徹在產品生命週期中的每乙個環節，從需求提出開始到測試計畫 測試設計以及測試用例設計與評審及執行，最後進行回歸測試。產品發布上線後跟蹤使用者使用的反饋，週而迴圈直到產品不在維護。1 參與需求的評審 評審內容主要分為功能性 準確性 完整性 可測性 優先順序和約束性。當然還有其他的效...