今天參加乙個故障的修改。
每天都參加故障修改。
故障的特點是：針對非常特殊的情況的修改，在使用者使用過程中幾乎不可能發生，而且即使發生了也不會造成太大的問題；
專案的情況：專案的版本馬上就要發布給使用者使用了；
故障發現的過程特點：
針對測試用例a進行測試，非自動化測試的情況，只靠手動敲命令來測試功能：
乙個測試人員a君，如果此人相對比較懶，但是也能滿足測試部門的要求，對這個測試用例測試就不可能發現問題；
另乙個測試人員b君，如果此人相對比較勤快，對相同的測試用例，就有可能發現問題；
我的疑問是：對同乙個測試用例，如果專案組都是a君程度的，就不能發現問題；如果都是b君程度的，就發現，很多在外場幾乎不可能發生的問題；這就無疑增加開發人員的負擔，增加**流程，修改已經測試穩定的流程；而且開發人員也有怨言，天天修改這種故障，幾乎就是在出力不討好，因為針對這個修改要出人力，而且如果這個開發人員沒有處理好新的流程，引入故障，還要被領導批評。其實對測試人員要增加了測試負擔。
我認為深層次的原因是：
1、測試人員為了測試而測試，測試人員沒有乙個目標，就知道一味蠻力測試。
2、測試用例有問題，大部分的測試用例都是幾句話，最重要的是沒有對測試結果有乙個量化標準，如一秒鐘建立多少tcp鏈結；但測試用例沒有乙個標準的時候，測試人員就無法衡量什麼樣測試符合要求的；就只能任由發揮。
3、測試經理、專案經理分析故障的能力，是不是所有的故障都要解決，是不是要分清楚哪個故障是應該解決的，哪個是下個版本解決，或者根本不用解決。這就考驗經理們的技術能力了。但是大部分的經理都是有故障都要解決，不分輕重的。
目前的感覺就是：專案越大，人越多，如果沒有嚴格的培訓程式，管理，測試和開發只能走向歧途。
6年測試工作的思考
前言 在公司已經幹了6年的 測試 了，幹測試經理也 5年了。眼看就要離開奮戰了 6年的崗位，還真有點兒捨不得。但沒辦法，該離開的時候就要離開，光傷感是沒有用的。正好趁此機會把自己 6年來一直想寫但沒寫的東西寫出來。這篇檔案純粹是對自己工作的回顧。由於時間倉促基本上是想到什麼些什麼，有點兒亂，也請大家...
工作原則之深層次思考
問題 錯誤 遇到問題 功能缺陷 設計方案時，急於解決 適配 表面上的問題，不能看清問題背後本質的原因。例子某個需求全域性都是通的，到最後的b端賬單環節發現某個欄位不符合預期。此時發現前置交易流程中有一些一開始就有的為實現需求而做的妥協 便利。此時有幾種解決方案 1 交易流程實現不變，在與賬單 結算流...
工作總結之測試
2018年年底，接手了先後兩個質控同事都跟進過然後因故沒做的功能模組，回顧這麼多年的工作經歷，很多經驗都沒有形成文字形式儲存，而這次的測試出現的問題也比較能涵蓋之前的工作總遇到的問題，故總結文字記錄之 一 應用端委託成功，生產了委託單，方向 資金扣減了 業務理解 解除業務是t 1日返回成交確認，當日...