本文是最近為公司所做的兩篇總計之一。主旨是為公司的開發人員提供一些做自測，界面設計時的思路。
關于開發人員自測
開發人員做好自測，是非常必要和也是大趨勢。Google公司里面，純粹的測試人員是很少的，前期都是開發自測（包含必要的測試），后期才是用戶體驗方面的測試；從成本上分析，BUG越晚發現修復成本越高；從修改的效率來講，越早處理會越快。另外，寫出高質量的代碼，是能力的體現，專業的體現，自身價值的體現。
開發人員自測的困難
就我自己接觸到開發人員來看，一般會遇到下面這些困難：時間、進度太緊（也許是由于潛意識里任務完成后滿足感驅使的）；對自己的代碼過于自信；認為測試是測試人員的責任；不知道如何有效的自測。
思維上
從上面的困難看來，思維上應該先需要轉變下。
● 代碼質量、項目質量都是自己的責任，提交代碼到代碼庫里，提交版本給測試給客戶，都應是經過自己測試的。否則拿出去東西影響其他人的工作，影響客戶眼中的印象和滿意度，這樣帶來的危害更大。
● 代碼達沒有達到效果，健不健壯，不試試，那怎么知道？憑感覺那是不靠譜，實踐是檢驗真理的唯一標準。
為什么開發人員不忍嘗試破壞自己的成果了？為什么不能讓自己的成果更加健壯？否則就相當于在溺愛自己的孩子。
測試世界的基本思想
● 測試與開發人員思考角度最大不同就是一個破壞軟件，一個建造軟件。所以想要測試，就應該是考慮怎樣才使軟件出了點問題？
● 對于任何功能都有基本流和備選流，或者說正面情況和反面情況。這些情況都應該是要需要去測試的。那如何選擇測試的數據和路徑？
● 有一個重要的概念叫做“等價類劃分”，大致可以這樣理解，由于測試數據和測試路徑理論上講是無窮盡的，那么就需要對這些數據和路徑進行分類，哪些能走到正常情況，哪些能走到異常情況。再從各個分類里面選一些出來完成測試即可，這樣覆蓋率就會更高，同時測試起來更快。
● 數據選擇，選一組正常數據（符合規定，用戶可能真正會用到的）；選幾組異常數據（特殊符號，不支持，長度大，空的，會觸發特殊邏輯的）。
● 路徑/場景選擇，選一兩組最普通的、最直接的、用戶最有可能的完成功能的；選幾組復雜一點、多次操作、間接完成功能的。
習慣上
改變習慣是非常困難的，堅持完成一個功能就測一個功能（真正帶點測試思路去測）；公司推行的規范，Checklist，Code Analysis或者自己總結出來的自測列表等等，也要堅持定期自己檢查檢查，再認真對待、改進結果。
多總結、反思自己的所犯的問題，這樣才能有所提高。測試會幫助你的思維變得更加全面和周到。
關于用戶體驗
界面設計、動作交互設計、用戶體驗，這塊的重要性應該不需要進一步闡述了吧。
這里也是從思路上簡單講講怎么考慮用戶體驗：
● 首先是學習。一般來講，我們做的東西都不是全球第一，全球首款。那么我們在做東西前，可以學習下模仿下前人已經做出來的效果（切忌只關心功能）。
比如，界面布局；頁面 margin，頁面中主體的對齊、留白；字體大小、粗細的使用；
其實看到的一切都是可以關注的。
● 平時還可以對自己使用軟件和網站進行觀察和體會，看看他們做得好的是在具體怎么做。
比如，操作成功、失敗的提示怎么表現；注冊流程、購物車流程、是怎么進行的；日歷控件、向導控件是怎么在用；圖片庫、視頻庫怎么放置的，怎么播放的。
● 當我們真正要做的時候，還可以看看那些規范、指南。看看其他人都建議怎么做，建議避免那些效果。
● 最后，我們做的時間，在界面設計上盡量風格統一（按鈕大小、顏色，邊距，Grid，表單設計等），動作交互設計上盡量和主流的效果一致（如何給出提示信息，如何彈出層，如何做表單的驗證）。
關于持續學習和追求精益求精
也是就我自己接觸到開發人員來看，很少人會在做之前或者做的過程中，跳出來暫別任務，看看工作任務的技術有沒有什么最佳實踐有沒有其他方案，或者和能力更強的開發人員進行討論和交流。很多人都喜歡過分獨立的解決問題，但問題就來了，一個方面是時間的消耗，另一個方面是容易閉門造車。
另一現象是很多人對其他的人建議反饋或者提出的問題，比較隨便，懷著防備的心情，戴著有色眼鏡，沒有認真考慮和對待，沒有考慮是不是自己真的沒有做好，真的有問題。
當然這些不是完成任務的必需品，但是我以為這些方面卻是一個人成長或者成就的基礎。
想要提高，這是你自己的責任，就該想想怎么去解決。態度決定一切，追求卓越。
版權聲明：本文出自 omg 的51Testing軟件測試博客：http://www.51testing.com/?166582
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。