我這個人做完一件事情喜歡反思和總結，這個習慣一直保留著。在測試部做了兩個月，雖然我對測試還是門外漢，只做了一些具體工作，但忍不住把自己的想法寫了個系統文章，其實提意見我的看法是領導一般不反感，只要你的意見系統，有建設性，不針對個人攻擊就好。
下面就是我當時寫的對測試工作的反思，有些是參考了一些資料，結合自己總結寫的。
對軟件測試工作的反思
測試人員的配置：測試人員必須包括三類人，專業測試人員，熟練測試人員和對軟件完全不熟悉的新人。專業測試人員主要負責測試規劃和測試大綱，極限測試環境設計，熟練測試人員主要負責按規定完成大綱測試，屬收斂性測試，新人主要負責易用性和界面合理性測試，屬發散性測試，發現的各類問題由專業測試人員分析并給出解決對策。
測試文件的準備：提前準備好軟件測試需要的圖、工藝文件，OFFICES，TXT，其它CAD設計文件測試標準文件，而不是臨時去找
測試軟件的準備：應該提供不同的操作系統和數據庫平臺測試環境，必要的話提供多臺測試機器，減少人工浪費在安裝環境上的時間。
測試機器的準備：應給測試人員配置相對好的機器，以提高測試速度和效率，同時一定要配置相對差的機器，模擬在用戶現場極端運行環境和速度。
業務測試的準備：（針對當時軟件測試主要是功能測試的情況）應該設計大量的業務測試流程，流程可以從開發，市場，實施部門配合，給予解決。
測試階段的劃分：應該分開發測試（非常反感開發不懂操作，也不自行測試就提交測試人員驗證的模式），功能測試，極限測試，BUG測試（主要是測試歷史環境下有記錄的BUG），現場測試（主要是易用性和測試業務流程）
對測試大綱的意見：
1、測試內容不全面，缺少測試文件樣例，測試軟件版本號
a）很多軟件存在的功能測試大綱沒有涉及，我自己把只要能夠用的功能都測試了一遍，超出了規定測試大綱的內容，發現了很多新錯誤，當時公司測試水平也確實有限，所謂軟件測試就是兩個臨時員工負責。
b）軟件功能之間組合連續測試不完善，很多功能單獨是好的，但如何把管理軟件功能串合起來用的測試流程不清晰，需要測試人員自己發揮
2、極端環境測試得不夠
對空數據，大數據，大量網絡并發等環境下測試很不夠，往往這個時候能測試出很多問題，例如軟件運行效率
3、對誤操作或非法操作給系統帶來的影響測試大綱無體現
測試大綱都是要求你如何如何操作，應得到何種結果，但問題是用戶不一定會這樣操作，但我這里隨意操作常常造成死機，這也是我對測試大綱很不滿意的，軟件應該做到即使是用戶誤操作系統有提示或者沒反應，而不是死機，更不是要求實施人員去培訓正確的操作。
4、測試動作量化不夠
例如同一功能測試次數，測試頻率，測試速度都應有規定，例如某一功能測試100次，可能才出現一次BUG，如果只測試10次可能就是OK的，或者連續使用10次就會出現BUG，但單獨使用沒問題，這些應該也體現的測試大綱，而不是讓測試人員自己去測。
5、測試中對開發人員的開發功能邏輯了解不夠，無法自覺測試潛在的功能缺失和沖突或干擾（后來我才曉得這叫白箱測試）
6、對軟件的宜人性，友好性，WINDOWS下程序風格一致性，簡潔性沒有任何評估
7、沒有以用戶層面對設計的功能和動作進行挑剔。
8、缺乏軟件測試質量保障體系（后來開目花了大力氣建設了測試體系，通過CMM3級評估）
9、沒有單位時間內任意測試過程中死機紀錄，只測功能的實現性，沒有系統穩定性指標，實時性，同步性等效率量化指標
10、沒有參照軟件的對比測試
11、沒有前期積累的測試文獻
12、測試工作不應該僅僅成為開發的完善工具，還要承擔一部分探索開發方向的作用，甚至一定程度上和開發交融（這個觀點我現在不支持，要求太高了，主要是當時我對自己測試太有信心了）
測試目的：
1）檢查出軟件中的功能設計不足或BUG以保證能滿足用戶正常使用
2）在說明書中明確一些常見錯誤操作以防止用戶誤操作或給出解決方法
3）對一些一時難以解決的難點，導致的問題給用戶一個解釋或變通的方法
根本目標：
保證開目軟件的易學易用穩定的優勢，以優質產品占領市場，贏得口碑。