前段時間，被公司派去臨平市民之家駐場測試，待了大概半個月時間，一開始是存在情緒的，畢竟就我乙個女生，加上女生出差要帶的東西很多。但後來實際工作後，發現其實也沒想象的那麼糟糕，在現場工作的優勢體現在，產品需求上的變更自己都能全部知曉，不至於在測試的時候那麼被動（在公司測試的話，都不知道他們到底在現場對產品做了什麼改動……）。其次，業務能力提公升的很快，可以接觸到產品最終的使用群體，不懂的也可以問現場的業務人員，雖然出差的時候，感覺一天也沒幹什麼事情，但是業務能力真的是提高的很快，之前在公司一直搞不明白的問題現在都理清楚了。對於房產稅方面的乙個實際工作流程也知道是怎麼回事了。回公司後，還給相關開發人員、測試人員、市場人員搞了個培訓。
現在對於自己出差的情況做乙個自我總結（畢竟人要定期的作總結才知道自己的問題，更何況是作為乙個測試人員）。
對「客戶是上帝」這個詞存在誤解，一開始接觸客戶，基本是客戶提什麼要求、優化建議，我都是一股腦兒的記下來帶回去給開發經理。後來，開發經理說這個提的是什麼奇葩要求，不改。我開始反思，客戶是不懂程式的實現原理的，所以有時候提的要求是實現不了的，那麼我就應該先做乙個初步的判斷，如果不合理我可以直接說明理由，去和他們解釋清楚，沒必要帶回給開發經理，如果判斷不了可以帶回去給開發經理。對於使用者提的需求，自己需要做初步判斷，俗話說，和使用者交流，要帶腦子！
業務人員在做業務測試時，發現bug，做好總結文件發到每個開發人員手中，但同時，也切記提到bug管理系統中，有時候會為了方便，覺得有文件作為回歸的依據就不提到管理系統裡了，其實還是建議提到bug管理系統中，規範、到時候查詢變更記錄的時候也有記錄可查。
和開發溝通的技巧。有些開發就比較個性化，就有些推動一兩次他是不會理你的，作為女孩子的我，臉皮又比較薄，不好意思一直問。後來，練就了厚臉皮~~~時不時去問問，聊聊天。其實，開發人員不是故意的，可能就是性格就是那樣，所以有時候就需要你突破下自己，比如我厚臉皮的去催。。。
測試覆蓋率：由於測試的時候，有個場景（買賣雙方的產權人屬於不同的家庭，計稅方式選擇不同）未測試到，導致產品上線試執行的時候出現了問題。在測試的過程中，要不斷的優化測試用例，將之前未考慮到、新發現的場景補全。測試覆蓋率的高低，不是一時半會或者是多看看書就可以提公升的，需要不斷的實踐和經驗的積累才得以提高。慢慢來。
對回歸測試的誤解。我們都知道開發修改bug的時候，有時候會改出新的bug來。所以，我們回歸測試時需要把之前提的bug看看是否有解決掉，再看看有沒有新的bug產生。那麼我之前理解的是，把之前提的bug回歸掉，然後將整個系統全部重新再測試一遍。可想而知，是不現實的，假如你目前的專案模組很多，很龐大，那麼每輪回歸都把之前的全部功能都測試一遍是不可能的。因此，我們需要搞清楚bug產生的原因，這樣的話，也知道開發修改的是哪一塊的**，是否會影響到其它模組，大致上會有乙個判斷，對於回歸測試是極有幫助的。
測試思路不要隨便被開發打亂。其實，很多人都認為測試是不需要邏輯的。大錯特錯，測試也是有一定的測試思路的。
專案測試總結
1 測試活動路線 2 測試初衷 1 專案規劃明確 2 需求設計文件充分 3 系統整合環境部署簡易 4 測試流程規範 5 測試目標清晰 3 測試變更 1 開發環境與測試環境不同 2 開發模組與專案計畫不同 3 開發準備工作有出入 4 測試進度變更 5 測試環境的可控性 4 測試應對 搭建多套測試環境 ...
android專案測試
1 單元測試 又稱為 模組測試 是針對 程式模組 軟體設計 的最小單位 來進行正確性檢驗的測試工作。程式單元是應用的最小可測試部件。在 過程化程式設計 中，乙個單元就是單個程式 函式 過程等 對於物件導向程式設計，最小單元就是方法，包括基類 超類 抽象類 或者派生類 子類 中的方法。單元測試的步驟如...
C S專案測試
1.c s的特點 c s架構的介面和操作可以很豐富，能充分滿足客戶自身的個性化要求 安全效能可以很容易保證，c s一般面向相對固定的使用者群，程式更加注重流程，它可以對 許可權進行多層次校驗，提供了更安全的訪問模式，對資訊保安的控制能力很強。一般高度機 密的資訊系統採用c s結構適宜 由於只有一層互...