快過年了，畢業也有半年了。在公司從事了半年的軟體測試工作，總容易被說到對測試的理解高度還不夠，於是仔細地思考了目前工作的情況和收穫，做個紀念吧。
現在在推進什麼？兩個字：敏捷！其實不止部門，整個公司的技術部都在推行敏捷！
敏捷是什麼？概念有很多，我理解簡言之就是有效的人與人溝通勝過流程與文件，快速交付版本並迭代之。為了實現這一目標，測試工程師能做的主要有：
1.測試向前：盡早熟悉需求，提高全程把控質量能力，與業務方及時和溝通與反饋（如成立專案室pd、開發、測試甚至業務方等在一起做專案）；
2.持續整合：持續整合主要可用於每日構建。其技術的基礎是自動化測試，而技術的點有單元測試、介面測試、ui測試自動化三個方面。這三個方面的測試用例豐富性、合理性能極大提公升持續整合的效果。而這三方面又以單元測試最為重要，其發現問題並修復的成本最小，介面次之，ui自動化發現問題並修復問題的成本在三者中最高。為提公升測試用例的合理性，因此需要進行bug分析，同時需要測試範圍鑑定進行輔助。
3.測試技術的研究，測試工具的開發與推廣。
上面這些，也是公司一直在推進的。看以上3點，前者是對開發流程的改進，需要開發、測試、pd、業務方甚至dba及架構等都願意積極參與，並且專案的pm要有較強的慾望以敏捷方式組織專案流程，qa能發揮的作用相對較小。後者是測試技術發展部在主導。因此我們部門最能發力的部分總結起來就四個字：持續整合！（同時兼顧流程的點滴改進）。
持續整合與效能測試
效能測試是諸多測試手段的一種，只對效能需求較高的場景，才可能使用這一測試方式。效能測試主要用來發現潛在效能問題，尋找效能瓶頸以及評估系統效能指標。在上述的自動化測試中，效能測試似乎是個特例，因為效能測試要做持續整合，我認為至少兩三年內不太容易做到。難點主要有幾個方面：第一是資料準備問題，除了資料庫中的資料準備，還需要有引數化的資料準備等；第二是指令碼的版本管理，對於apache指令碼可用svn進行版本管理，但核心有許多效能測試用loadrunner方便許多，這類指令碼的執行結果收集，歷史結果對比有難度；第三是執行時間問題，乙個系統需要做效能測試的點幾十個並不算多，如果算上介面效能測試，功能不斷增加的情況下，執行所有的case耗時也將是很可觀的。
效能測試能做的
儘管不能像單元測試一樣自動化並持續整合，但效能測試還有很多東西可以做，除李沛年度效能review中所說的，還包括：
1.讓部門有更多的同學能夠執行效能測試，定位簡單的效能問題，包括介面效能測試。
2.讓效能測試與專案流程更加緊密結合。
3.將各產品線的效能測試歷史資料收集起來，包括方案及報告等。
4.web前端的效能測試技術研究。
等等。我11年的目標
我的下乙個專案，除了在各層次自動化方面的介入和case積累，還將利用現有的自動化成果，在專案中跑現有自動化case或專案中新增的自動化case來驗證主幹功能，同時借鑑之前同學的經驗，進行一些bug分析工作，真正近距離的實踐持續整合。並且在專案中兼顧專案效能測試需求！
上半年在持續整合方面加強實踐的同時，也會對平台的**結構有一些初步了解，做一些web前端效能測試技術方面的學習與探索。持續關注並參與效能測試虛擬組一些活動與技術推廣工作。
然而對於11年下半年，我現在感覺計畫還有點模糊，也許在上半年工作開展之後，目標會清晰起來。也許上半年的工作也會因為自己認識的不斷進步或其它原因而調整計畫。
一些想法，記錄一下，算是給自己到公司半年對測試技術認識上的一點總結吧！等來年再看，必能看到自己現在認識的盲區和自己那時的進步！公司給我的回報和機會遠遠大於我對公司的貢獻，我愛這份工作，也愛公司。
軟體測試工作規範
為了規範測試工作 減少開發與測試之前的溝通成本 保證專案進度 提高軟體質量，測試組起草了這份軟體測試工作規範。軟體程式開發需要遵守編碼規範，一是可以減少 的維護成本，提高開發工作效率 二是有利於開發工作的延續 傳承，減小專案風險。好的 應該是自描述的，讓人費解的地方加上注釋。規範很多，要讓別人和乙個...
再談軟體測試 工作感悟
軟體測試，乙個即將要崛起的行業，卻也是乙個充滿著爭議性的行業。談到崛起，是因為我們發現，我們身邊的客戶開始越來越關注軟體的體驗性了，如果你的軟體還有功能問題，他們可就不那麼待見你了。同樣，在國內的公司也是越來越開始重視軟體測試，這幾年，測試的職位需求量越來越多了，各種外包 培訓機構，爭先恐後而至 說...
軟體測試工作的原則
軟體測試的工作應該遵循的原則大家可以參考iso質量的八大原則，其實這八大原則也是我們工作中需要遵循的規則，那麼接 原則1.以顧客為關注焦點 組織依存於其顧客。因此組織應理解顧客當前和未來的需求，滿足顧客並爭取超越顧客期望。原則2.領導作用 領導者確立本組織統一的宗旨和方向。他們應該創造並保持使員工能...