遇到的緊急事件：

Q: 

1. 突然需要交付單元測試用例和單元測試報告；

2. 需要交付介面測試用例和介面測試報告；

3. 平時測試沒有維護過用例，造成交付時時間緊急，不能及時交付；

4. 不能很好的激勵同事去學習新東西，導致很多問題需要自己親手處理，造成工作量增加；

5. 不能合理規劃好時間，隨時掌握專案動態，不能及時瞭解專案的進展，造成測試局面很被動；

6. 對測試質量，沒有辦法評估，沒有形成測試體系；

7. 如何管理好測試用例質量？

8. 如何進行測試分享

9. 每個人都要在成長中，學會讀程式碼、寫程式碼，擁有自動化測試的能力

A:

1。 每個專案在最開始介入時，就會給出一份需求文件，也許需求文件內容不是很完整，但可以粗略的提煉出需要涉及到的測試內容，比如：功能測試、介面測試、效能測試、單元測試等等，對於管理者而且，需要明確測試內容和需要的人力，比如要用到的測試技能，需要誰才是最合適的，如果恰當技能人員的時候，需要及時的提醒或者給出相應培訓和要求，要成員在相應的時間內達到某種水平。比如上面提到的單元測試和介面測試，成員中，沒有人曾涉及到相應的測試內容，在短時間內給出結果時，會造成壓力和反感，何不每週給予成員一點工作內容，讓 他在週報或者哪裡體現他所學習到的技能呢。在專案從需求介入研發時，總在某個時間段內，測試處於沒有太多事情的階段，這個時候要把握好測試資源的分配，在工作和技能培訓中合理、同時進行，合理利用人力資源。不要過分覺得成員是否學習、是否提升是他自己的事情，人都具有惰性、沒有很好的自律性，從某種程度上來說 ，需要一定的監督。

2. 在測試過程中，對於用例是需要維護的，每一週測試人員進行了哪些模組、哪些專案進行了測試，需要進行羅列，涉及到了多少的用例和bug,最好也有所體現，這其中產生了什麼問題，測試後，用例是否維護，用例的維護最好在測試過程中進行，不能完全脫離實際的軟體。畢竟，想完全按照需求完成的軟體，是少之又少的。

3. 測試用例質量。每份用例，曾經也許是直接copy ,或者直接在網上摘抄，很多都不能構成自己測試的思維，導致測試水平沒有一個明顯的提高，停留在初級的測試水平，只會墨守成規的點點，沒有新鮮的血液。在編寫測試用例的時候，要融入自己的思路，也就是 測試思路。設計測試用例採用了什麼方法。寫出的測試用例有什麼漏洞，自己可以多閱讀，多思考，並將測試用例進行等級劃分，那些是嚴重的，哪些是不嚴重，嚴重的測試用例設定為優先順序高，不嚴重的設定為優先順序低。

4. 在專案一開始，可以給程式設計師或者專案經理告知，程式設計師常犯的bug，並希望程式設計師在寫程式的時候可以避開類似的情況。比如：必填項校驗、邊界長度、超長字串校驗、介面的美觀整齊等。

5. 每個測試專案完成之後，最好是測試人員能進行一些技能分享或者心得體會的總結，也許這樣的分享留於表面，但是確能在某些方面能刺激到願意學的人去嘗試，從而挖掘一些人力資源。

注：所有暫時的不測試，不代表不進行測試，要保持能進行相應測試的能力