關於
測試的規範性與重要性，結合以往經驗，做了幾點簡單的思考，現記錄如下
1、bug修改之後，在轉測試回歸之前，開發內部要自行驗證。
這個是傳統了，不過建議不要只依賴現有的readmine系統（公司的乙個bug管理系統），因為其內建的流程，只支援乙個人審核問題，這樣往往不夠準確，有可能回歸不通過。所以建議自行用excel進行跟蹤，關鍵是進行兩輪甚至多人審核，這樣可以降低回歸不通過的概率。
這裡有2點值得總結，首先是2輪審核的流程，其次是不依賴現有的bug管理系統。這個是有道理的，如果沒有bug管理系統，bug是否不跟蹤了呢？所以任何系統只是工具，起到輔助的作用，關鍵還是對bug進行跟蹤管理的意識
2、bug修改之後，在dts中填問題單處理過程，要注意規範。
這點我有些不是很認可，因為我還沒有認識到規範填寫問題單的價值。不過從另外乙個角度想，對於已經比較成熟的團隊，可能可以不依賴這種管理手段。但是鑑於目前我們開發團隊還比較年輕，這些管理手段是必要的。姑且不論規範填寫問題單，給bug管理本身可以帶來多大價值，至少通過要求員工規範填寫問題單，可以培養員工的執行力，這對促進團隊的成熟是很有幫助的。
團隊越成熟，配合越默契，管理成本就越小，所需的管理手段就越少。反之，當團隊還不成熟，員工普遍能力較弱的時候，這些管理手段也就是必要的
3、關於轉測試
測試文件，包括「版本說明書」、「安裝/公升級指導書」、「測試建議」、「冒煙測試結果」、「遺留問題說明」
這些文件，涉及到轉測試流程的管理，請看
測試驅動開發——我們要的不僅僅是「質量」**51testing）
4、版本發布規範
版本規範中提到一點，未經測試的版本，不允許發出。這點很關鍵，值得單獨記下來。
未經測試的版本不能發布，這個原則是很簡單的，但是可以引申
4.1、版本a已經轉測試了，測試過程中發現了乙個問題，這個時候能不能用***.class替換掉呢？
肯定不行，所謂的版本，應該是乙個完整的包。如果直接替換檔案，那麼已經不能保證包的完整性，這個替換後的版本，就等於是乙個新的未經測試的版本。在替換之前的測試，嚴格來說等於是無效的。要發出去，就要重新測一遍。
正確的做法，是把這個問題作為乙個遺留問題，評估其影響，寫在遺留問題列表中。版本還是正常發出去，這個問題可以在之後修改，合入下乙個版本進行測試。如果問題很嚴重，是版本的嚴重缺陷，不能外發，那麼可以增加一輪測試，回歸之後再發布
4.2、版本a轉測試，測試結束之後，測試可以找開發要乙個新的包，發布出去嗎？
不可以，因為這個新的包，不能保證和測試的版本完全一致，那麼這個新的包，也就是乙個未經測試的版本
正確的做法，應該是把測試的版本發出去。即：轉測試時是什麼版本，測試結束之後就發什麼版本
4.3、現場發現了幾個問題，開發提供的補丁只有幾個檔案而已，可以不打標籤，直接發出去嗎？
不可以，所謂的版本，除了「完整性」之外，還需要乙個「可標識性」，就像資料的主鍵一樣，能夠唯一標識乙個版本。沒有「可標識性」，就稱不上是乙個版本。乙個版本只要發布了，就存在需要定位問題、回退的可能。如果沒有打標籤，當需要定位問題，或者日後需要回退的時候，就做不到了
正確的做法，是只要發了版本，就一定要在**庫上打上標籤。可以是用版本號打標籤，比如b010，spc001；也可以用時間打標籤，比如tag_20120719
打了標籤之後，在任何時候，無論是要搭建現場的映象環境，或者回滾，或者比較兩個版本的差異製作公升級包，都可以做到了
pragma的重要性和規範性
example1 pragma pack 1 include struct scmdhead head char sz systemid 36 char sz systemkey 40 int nauthoritycount 提示authority個數 std listauthoritylist s...
規範編碼的重要性
頁面中有乙個store如下 ext grid用來獲取並處理資料的控制項 在呼叫unitstore的load 方法進行重新整理時，控制台有時會顯示頁面跳轉到了乙個在此js中不存在的url中去 當然有時也可以成功重新整理 自己排查了此js頁面確實不存在這個url後，感到有些不知所措。分析 由於jsp頁面...
軟體測試的重要性
最近接手乙個新的任務 在公司產品的現有基礎上做修補.面臨的主要困難有 1.專案較大,vs的解決方案裡18個專案.雖然我只須維護其中的一兩個專案 3.某些 實現較複雜,如執行緒通訊,wmi等.這些函式的相互依賴,也就是平時說的藕合度高,現在我要將它分離,分到單獨的專案裡.但是這樣又要求我對這些複雜的函...