不知不覺，在網際網路已經跨入了1個整數的年頭了。逃避荒廢過，也把自己當壓縮餅乾一樣，瘋**活了幾年。這些年我換了好幾個崗位，程式，測試，策劃，產品。這點我自己也比較糾結，還好測試是做的最久的，也給我帶來一些乙份耕耘必然有乙份收穫滿足感。這些年做遊戲，也並沒有荒廢掉網際網路的一些知識。也是因機緣巧合，在潛心研究下，算是學習力大漲，因此有了一些小心得。
先談下測試的形式：
國內的測試地位無論是軟測中的富有高產品附加的（通訊，銀行等），還是普遍的，都存在乙個認識上的問題。遊戲測試比軟測還低一檔，二類測試早期都從國外引入，遊測的模式也在一路探索中，那也就難免出現了一些移植上的斷章取義，或者沒有經過太多的驗證就做為法則。其實二類測試本一家，在方法和原理上並沒有太大的差異，主要差異在遊測業務量根據**量級來恆定則內容較多，但容錯略高於傳統軟測。軟測則體現於協議類較遊戲測試多，部分技術性內容做的更深，容錯性略低，電信業理想資料約為99.99%，但同樣存在成本高（備機）。
當軟體測試的地位也在國內一些先驅（如朱少民老師）的發展下，有了突破性的發展。部分網際網路企業好像用上了寬頻薪酬的制度，這樣可以比較直觀的去評定測試的級別，也可以讓同行看到乙份工種的價值。
遊戲測試像個後輩一樣，也是在最近3年才慢慢重視起來，但引用的模式還是存在一些偏差。這裡要感謝一本叫《遊戲測試精通》的書，雖然裡面內容不完全準確，但也有了乙個依據。
在「困難發展期」
1.明確缺陷根源，缺陷定向和提交；（多年來測試關係和程式不是很融洽，主要存在內部和外部反覆浪費時間的地方）
2.不是生產部門。（在國內企業的觀念中，不帶來效益的部門，都屬於花錢部分，而測試是附加在研發身上的，省錢的成本核算項，在遊戲產業基本不存在，只有人力需要核算的）
3.垂直貫穿制度。（這點要推行還是比較難的，無論是驗收還是交付，還是打斷回贖需要對軟體工程有較深的理解）
4.驗收的部門。（在大部分公司都走瀑布和w模型的情況下，測試只是在驗收，在人力資源學科中明確定義了哪幾類崗位是含金高的，驗收的詞彙是乙個流水的）
5.遊戲產業測試流動性大。（體現在轉策劃最多，轉美術，運維，程式一部分，大部分是因為薪酬問題.這部分很關鍵，人才流失之大）
6.只掌控到灰盒較多，方法上的落後。（灰盒做到執行調式**跳轉，日誌檢查，其他大部分內容程式設計師都做了。）
7.在專案組裡位置尷尬。（部分公司會做雜活，同時兼顧好多事情，不知道做什麼提公升自己和測試組位置）
8.沒有明確的指導方向。（不知道該做什麼，因此閒的時間較多，選擇發呆和玩的人還是居多的，測試要混日子還是比較好混的，這點我不得不承認。）
9.自己會看不起自己，然後地位不重視。（※測試進門門檻低，測試算是在歷經專案對專案最了解的人之一，但部分公司封鎖對方向上不知道，導致消極的情緒日漸滋生，從而轉了策劃，其實專案會有優化和變更的階段，如果是由其他崗位做過的人在轉測試，遇到這類問題，就出現較少了。一怒轉策劃，回來為難測試的，也是存在的。）
10.過程的守舊。（乙份**用4~5年時經常見，別不信，2023年的至今依然大把人檢到寶當模板，當然作用是肯定有的，而且成熟，但對於質量的幾個關鍵領域來說，會浪費你的時間。）
11.思維混淆和停下來思考。（測試圈子的術語名詞至今也是沒有完全統一，工作中停下來思考是很關鍵的，及一些消極的情緒左右測試）
12.部分測試知識沒有普及。（什麼是測試行業的體驗，如何做出乙份平衡性報告，類概率和概率是可以不借助改表和程式來測試的）
13.配置管理。（也是因為掌握技術的還是少部分的人，大部分配置管理還都做的比較單一，更新維護環境搭建只是配置管理一部分。）
14.效能部分缺乏模型的支援。似乎沒有什麼公司把風險模型，容量測試，占用測試和效能測試其他幾種全做全了；採集的許可權；
15.遊戲開發環境因素，使得自動化較難施行，我的嘗試下也只能部分自動化。例如介面不支援，協議支援過舊。自動化較難施展，也降低了「含金量」。
16.缺乏高階資料庫語句的支援。（缺少在設計資料表時的參與，也沒有讀所有**中的資料庫許可權，使用高階資料庫語句作用也不大。這部分也和程式的重合了，使用資料庫這部分測試人員是個空缺的，需要配合，然後乙個公司能匯集多員情況不多）
其中關鍵影響點，數字前面有1個下劃線。
直到敏捷的概念進入，又進入了乙個「混亂的年代」,還好開發-測試迭代的意識也越來越強了，期待將來能走到螺旋型的專案流程中。
測試知識回顧
輾轉幾年過去了，學習都是日積月累的，抽時間複習一下基礎知識。一.什麼是軟體測試。1.發現缺陷 2.節約成本，減少風險。3.以使用者需求為基準 二.6大特性 1.功能性2.效率性 3.可移植性4.可維護性5.可靠性 6.易用性 功能性 1.適應性2.準確性3.互操作性4.保密安全性5.依從性 可靠性 ...
回顧測試和測試方法
軟體生命週期 測試過程 記住開發模型 測試模型 v w h模型總結 v模型適用於中小企業。w模型適用於中大型企業，因為對於專案組成員要求高。h模型對專案組成員要求非常高，很少有公司採用。測試分類 按照手工 自動化來分 按照測試物件來分 單元測試 被測程式的最小單元，函式或者類 整合測試 有若干單元組...
C 線下測試回顧
題目位址 首先我們要明確下格式規範，寫函式內容的時候，最好使用this指標 this width width this height height 而非 width width height height 為什麼要這樣寫？這樣寫的好處是什麼呢？我們應該知道當區域性變數名與全域性變數同名時，全域性變數...