軟體測試經驗談——5個大於
文章版本歷程
v1.0 2013-04-10
v1.1 2013-06-15
v1.2 2013-09-23
從一名軟體實施人員，經過研發人員、需求分析人員、測試人員的歷練，一路來到測試主管兼專案主管的位置，實屬不易。回首往昔，深覺經歷的重要，也感嘆實事造就人的真理。既感謝領導，也感謝同事。身為一名從事應用系統軟體開發十餘載的技術人員，今天相談一些對於軟體測試的感想。
一、計畫大於執行
這是我第一件感慨的事情。經常見到手下新人對測試充滿激情、興致盎然，拿到測試任務，草草看過需求文件或說明書，一頭扎程序式和用例當中裡，戲耍個天翻地覆，找bug樂此不疲。但這與真正的軟體測試還差得很遠，我一問why？說出都是「與需求相呼、與設計相應」的大道理。其實，他/她不解，我想問的是：需求為何如此？設計為何如此？計畫為何如此？用例為何如此？執行為何如此？
要回答這些問題，就要知道軟體工程的終極目標：完全的控制能力！乙個軟體從知道意向開始到交付運維，方案、技術、工具、人員、資金、進度所有的一切都受控，才是軟體工程的目標。那麼，只有在軟體工作的所有環節中都貫穿這一思想，整件事情才是受控的，軟體測試也不例外。
那麼如何獲得控制能力，就是在進行每項工作時都以那個「戴明環」（pdca：plan-do-check-action）為方**，開展具體工作。這個pdca就是以計畫為開端的，因此所有的執行都應當是計畫的遵照、調整、刪補，甚至是推翻重建，但是前提是必須有計畫作參照。
既然計畫這麼重要，大家就不要以「我發現了多少多少bug」自居了。如果測出的bug都在計畫中，而且測試覆蓋率計算標準科學，你才算會測試！這時我會說「你是在做測試，而不是在玩測試。」換句話說，在沒有計畫時，你只是圖個新鮮，與小孩子遇到遊樂場是一樣的，但從某種意義上說（經濟結果），在遊樂場中的你分明是被設計者玩的。
最後，回答一下開始我提的問題。1、需求為何如此？是因為業務背景（使用者、受眾、政策、環境）業務範圍如此，這些是非常軟性的，但又是客觀存在，不可違反的（在一定程度上是），這部分是新鮮力量最缺乏，也是最不願意接觸的。2、設計為何如此？因為需求和實現代價如此。需求就不說了，代價是你的團隊賴以生存的條件，如果乙個軟體做10年能達到極高質量，但是人家要2個月交付，你怎麼辦？讓對方等10年嗎？所以10年有10年的設計，2個月有2個月的設計，說到底還是需求——隱性需求。3、計畫為何如此？因為需求、設計如此。4、用例為何如此？因為計畫和軟體成品如此，用例必然不能天馬行空，「計畫給指導，軟體來執行」。5、執行為何如此？因為計畫、用例和制度如此。很多人都會忽略制度約束，找一些不必要的麻煩。如果你非要在沒有許可權的情況下驗證涉密邏輯或資料，那你不是在測試軟體，而是在測試組織制度和領導處罰人的堅定性。這些問題我也只是簡要回答，肯定不全面，但原於實踐，到底對不對，還請您用實踐檢驗。
這些問題回答完後，如果你能自覺地制定計畫、執行計畫、修訂計畫，你就開始向真正的測試領域邁進了。
二、覆蓋率大於執行效率
這是我做具體測試工作的總結。俗話說「治病除根」，而不是「治病除症」。人如果頭疼了，是的只吃止疼片，讓頭不疼呢，還是應當把頭疼的原因消除呢？實際上兩個都要做，先臨時止疼，然後看病除根。「除病根」是長遠目標，「止疼」只是短期目標。
作為測試工作，測試覆蓋率是乙個很關鍵的指標，經常看到一些測試計畫中動不動就寫覆蓋率100%，但是根本不提覆蓋率的計算範疇，是需求層面、設計層面，還是**層面的。如果都考慮全了，這個100%是比較難達到的（尤其是需求層面）。
關於覆蓋率和執行率的關係，我舉個例子。我們要烙芝麻燒餅了，需要準備灶火、餅鐺、盆、盤、麵粉、油酥、芝麻、鹽、水等；覆蓋率相當於把每樣東西大致檢查一遍，雖然不細緻，但是如果馬上要開始烙燒餅就可以了（可能質量不高），不耽誤大事；執行效率相當於在檢查芝麻、油酥每種原料時的細緻程度和速度，可是如果沒有先檢查所有的原料齊不齊，就開始挨著粒的查芝麻，我只能說您很可愛了（可能等芝麻查完了，發現沒有鹽，那可就糗大了）。
測試工作也是如此，測試人員應當時刻記著遠期目標，操作時關注短期目標。可是很多人，包括我自己在開始做測試時，都是有了短期目標，就完全忽略遠期目標，測著測著不知道該幹什麼了，才想起看看遠期目標？這是不好的習慣，而且說明對於將要進行的測試，沒有乙個清晰的思路和整體目標，業就無法形成你自己的執行策略，總體執行效率必然不高，很有可能要漏掉某些測試方面。
三、記錄大於操作
我看到的很多研發人員都有乙個毛病：急於實現，而不喜歡記錄。這一毛病在很多測試人員身上也有，只是出現的形式不同罷了。在一般的開發工具中都會有兩個輔助工具：todolist和日誌。乙個是要做什麼的記錄，乙個是做了什麼的記錄。前乙個類似於計畫（不過只是給自己看的），後乙個類似於操作記錄。有了記錄保證了很多事情：
1、計畫性——就是給自己乙個比較明確的指導，第一部分囉嗦得夠多了，不多說了。
2、描述性——可以通過簡單的文字看出要做什麼和做了什麼，做完這件事本身就是把思路和頭緒理清了。
3、可追溯性——可以在結項一段時間以後，看出自己做了什麼（當然看用例也能做到），但有些時候需要查問題，最重要的是自己當時怎麼想的，具體怎麼操作的，甚至能夠想起為什麼，這一點是非常重要的。
4、任務的中止與恢復能力——如果測試專案中止了一段時間，恢復測試專案時，你可以快速地知道做過什麼了，該做什麼了。
5、多工併發能力——有了記錄機制，就有了上一種機制，內麼任一乙個任務都可以方便地中斷和恢復。
6、回顧與總結——文字是人類的寶貴遺產啊！有了回顧的資料，才能總結進步，是吧？
說了這麼多好處，有什麼不好的呢？
1、麻煩——肯定要寫東西嘛，不過這只是因為沒有習慣這種方式。
2、容易忘記火化——年輕人經常閃現「火花」，但是有什麼火花非要先試試不可（如果是火燒眉毛或人命關天的事除外），而不能先記下來呢？
再多囉嗦一點，這裡的記錄更重要講的是「養成思路成文，文字指導、記載的習慣」，大家不要教條於記什麼、怎麼記、何時記等等的事情，最終要的是通過這種習慣彌補質量控制和記憶力的不足。可能有些東西只是給自己看的，也只有自己才看得懂，有時記事本上的一句話頂得上一周的工作量。
四、再現大於發現
發現bug是軟體測試的天職，而且發現的越多，說明測試越成功。很多測試人員都在努力鍛鍊發現bug的能力，的確，這確實是軟體測試人員的重要能力之一，但是在發現bug的背後。有一項更重要的能力：bug的可再現性。
當然，如果一切都記錄的非常完美，環境受控，可以說測試環節沒有什麼不可再現的。但這是夢想，我們不可能擁有生產環境，也不能掌握所有人的操作習慣、相容性測試也不可能完整、沒有那麼多資源準備足夠的系統和硬體平台。所有有些問題就是急難再現，那麼「發現了不能再現的」bug應當稱為問題，幾乎不可能修復，至少不能從本質上修復。
提出這一點，我是想強調，軟體測試人員應當關注測試過程。如果測試人員一味關注測試結果，而忽略機理、過程，那麼測試就不是受控的，不是做測試，而是玩測試。很多情況下，只知道按用例執行，而不知道如何設計、分解用例，測試人員的可再現能力就會大大下降。
五、評估大於總結
最後這一點是我在接觸專案管理後的體會。軟體測試專案一般會在結項時給出統計數字，覆蓋率、執行時間、bug情況、修復情況、人員情況、工作量計算等等指標。這些指標對於軟體能力的度量固然重要，但是企業的專案是鮮貨的，這些冰冷的數字只代表歷史，是一種客觀結果。而專案還要繼續「活」下去，那麼測試工作就應當為活著做出盡可能多的努力和貢獻。
通常測試通過後，就是面臨著系統上線、客戶確認、市場推廣等發布環節。測試報告中應當至少「工程實施建議」和「風險評估」方面的建議，並且交給專案經理。其中應當描述諸如：系統在哪些環節還存在問題或不足（可能是短期技術上解決不了的）、工程實施或技術演示時應當注意什麼、建議如何規避問題。這種描述應當客觀（實際情況）、善意（給出建議），而且應當事先作為一種工作策略與專案組其他人員溝通一下，不要讓研發人員認為測試是在宣揚他們的不足，而是要從專案或工程的角度避免專案惹麻煩。
當然，測試的核心目標仍然是提高質量，這是不能動搖的，評估並不是讓測試為軟體質量缺陷找藉口，而是要在工作問心無愧的情況下（例如時間不足了），對結果給出一定的評價，幫助專案更好的推進。
六、有感
最後，我寫了一首小詩表達一下做測試的心情，結束這段感談。
迷叢樂千絲萬縷亂叢紛，願作彩蝶探精深。
叢中自有叢中樂，甘苦相纏感最真。
陰陽格物由心起，莫教迷津擾此身。
從來不變應萬變，跳出叢中自成神。
軟體專案經驗談
軟體專案經驗。自己總結自己記錄，見笑了。剛寫完手賤誤刪，因太重要，復記一遍。2017.5.12 1.介面 a.樣式及布局 無論客戶端還是網頁，介面配色彩色不超過3種，字型大小不超過3類，字型不超過3種。功能用色彩不限制。選單布局注意行距，介面文字注意行距。b.易用性 考慮到大齡使用者和視力較差的弱勢...
利用免費軟體測試CRM經驗談
大公司肯定是不屑於利用免費軟體了，但中小企業或者個人在正真引入crm之前卻可以利用免費軟體建立個crm來測試下效果跟員工的反應。要知道crm雖然說不上相當貴，然而 也便宜不到那去。如果當企業購買了crm卻發現根本不實用或者用不著，豈不是被氣死。我就以我們公司的經驗跟大家說說，前不久，由於客戶管理分散...
軟體專案測試管理經驗談
一 軟體測試員自身素質培養 1 首先，應對軟體測試感興趣和對自己有自信，如果具備了這兩點，那麼在開發過程中不管遇到什麼樣的困難，我相信你一定能克服。2 善於懷疑，世界上沒有絕對正確的，總有錯誤的地方，具有叛逆心理，別人認為不可能發生的事，我卻認為可能發生。別人認為是對的，我卻認為不是對的。3 打破砂...