注意丨測試系統&軟件需要重視哪幾點？
導讀
2007年5月18日，衆多使用諾頓防病毒軟件的中國個人用戶和企業用戶在重啓系統後出現藍屏，系統不能正常使用。即便諾頓當日下午便給出瞭解決方案，但他作爲專業安全公司的信譽依舊受到了嚴重影響。
該事故源於諾頓當日在更新中將兩個簡體中文版的Windows系統文件誤當成病毒。這個本該在實驗室測試中輕易發現的問題，卻由於技術或管理種種原因被疏漏了。
因軟件缺陷而導致重大負面影響或巨大損失的例子數不勝數，業內頂級廠商也不能倖免究其原因，幾乎都歸入軟件測試不夠充分。由此可見，一方面是軟件測試的重要性，另一方面是做好軟件測試不是一件容易的事情。
▐ 如何做好軟件測試？
軟件測試流程圖
❶ 需求分析，發揮主動性
正常的需求在產出時，產品要分析該需求的價值，影響範圍和實代價的。
可是目前大多情況屬於有需求就組織評審，然後開發測試與上線。
產品主導型的開發模式非常常見，作爲測試我們無法主導需求和項目。在需求評審時，作爲一個測試人員必須瞭解這次需求的內容，影響到哪些現有的功能，涉及到的操作系統或是類別等，然後準確的評估出工作量，防止因評估不足造成後期測試不充分。
再者，關注開發和產品的討論，如果開發說哪一部分比較難實現，最後如何實現？其中做出的變動和難點就是測試時必須重點關注的部分。不能因爲這些暫時和你沒有聯繫就忽略，後期會帶來很大的麻煩。
❷ 用例設計與評審，做到不遺不漏
測試用例是每個測試人員工作過程中必須要完成的工作。在測試工作中用來指導測試工作，而且是相關業務的一個文檔沉澱。
► 測試用例要素：
測試用例名，執行步驟，預期結果這三點是必須要寫清楚的。再者就是測試方案選擇必須全面，作爲測試人員必須能根據需求想到要實施哪方面的測試。
► 設計用例時，要設計兩類：
一類是開發自測和驗收提測試標準的冒煙測試用例，一類是針對需求的全面測試用例。
寫完用例要主動聯繫相關人員進行用例評審，強調開發自測，在評審過程是及時修改不合適的用例。
❸ 測試流程，注重項目控制
其實項目的流程控制在需求開始的時候就應該重視起來，只是很多時候我們沒有意識到這是測試的工作。有的是產品來控制，有的是專門的項目經理來控制。測試人員是一線的工作人員，必須具備關注整體項目的意識。
需求一旦明確就要時刻按排期來關注項目的情況。中間變更需求的時候，要評估是否影響項目進度，如果影響了重新進行排期。如果開發提測試晚了，是否影響上線時間，如果可能會影響，馬上就要給相關的人員發預警郵件，通知大家詳細的情況。
同時在測試過程中，發現了bug必須詳細描述問題，不管是jira，禪道或是其他的bug管理方式，一個bug要寫清楚以下幾點：Bug問題描述，bug重現步驟，是否有前置條件，預期結果，實際結果，以方便開發去進行修改。同時給bug準確分級，實時跟蹤進度，保證項目按期完成。
❹ 上線迴歸與項目總結
一個需求上線完成後，要及時進行線上迴歸，提醒相關的人員進行自動化線上迴歸或是監控工作。同時必須迴歸我們在需求評審的時候考慮到的可能影響到的原有的功能，以確保新功能的完全上線成功。
而作爲測試人員，在一個項目完成後，不管公司是否要求，需要對項目做相應的文字總結。總結整個項目過程中遇到的問題，最後的解決辦法或是當時討論的處理辦法，有哪些需要注意的問題？有什麼可以借鑑的方案或是改進策略？項目中有沒有通用性的問題等等。
如果公司有相應的項目總結方案，那測試時需要多關注一些數據。如冒煙測試是否一次通過，Bug數及不同級別的bug數，參與開發人員對應的Bug數，提測試次數，上線次數等等。而後藉助於第三方工具進行圖表化相應的數據，然後相關問題的總結，改進方案都需要進行詳細的總結。
總結：
測試，從來都不簡單，也容不得半點馬虎，只有知行合一，踏踏實實把每個環節做到極致，才能通過用戶應用的最終考驗。
關於我們
▼
如果您感興趣，歡迎加入PUSHI AI社羣，共同探索AI。關注普適極客►申請「入羣」，不定期還有福利活動噢~
導讀
2007年5月18日，衆多使用諾頓防病毒軟件的中國個人用戶和企業用戶在重啓系統後出現藍屏，系統不能正常使用。即便諾頓當日下午便給出瞭解決方案，但他作爲專業安全公司的信譽依舊受到了嚴重影響。
該事故源於諾頓當日在更新中將兩個簡體中文版的Windows系統文件誤當成病毒。這個本該在實驗室測試中輕易發現的問題，卻由於技術或管理種種原因被疏漏了。
因軟件缺陷而導致重大負面影響或巨大損失的例子數不勝數，業內頂級廠商也不能倖免究其原因，幾乎都歸入軟件測試不夠充分。由此可見，一方面是軟件測試的重要性，另一方面是做好軟件測試不是一件容易的事情。
▐ 如何做好軟件測試？
軟件測試流程圖
❶ 需求分析，發揮主動性
正常的需求在產出時，產品要分析該需求的價值，影響範圍和實代價的。
可是目前大多情況屬於有需求就組織評審，然後開發測試與上線。
產品主導型的開發模式非常常見，作爲測試我們無法主導需求和項目。在需求評審時，作爲一個測試人員必須瞭解這次需求的內容，影響到哪些現有的功能，涉及到的操作系統或是類別等，然後準確的評估出工作量，防止因評估不足造成後期測試不充分。
再者，關注開發和產品的討論，如果開發說哪一部分比較難實現，最後如何實現？其中做出的變動和難點就是測試時必須重點關注的部分。不能因爲這些暫時和你沒有聯繫就忽略，後期會帶來很大的麻煩。
❷ 用例設計與評審，做到不遺不漏
測試用例是每個測試人員工作過程中必須要完成的工作。在測試工作中用來指導測試工作，而且是相關業務的一個文檔沉澱。
► 測試用例要素：
測試用例名，執行步驟，預期結果這三點是必須要寫清楚的。再者就是測試方案選擇必須全面，作爲測試人員必須能根據需求想到要實施哪方面的測試。
► 設計用例時，要設計兩類：
一類是開發自測和驗收提測試標準的冒煙測試用例，一類是針對需求的全面測試用例。
寫完用例要主動聯繫相關人員進行用例評審，強調開發自測，在評審過程是及時修改不合適的用例。
❸ 測試流程，注重項目控制
其實項目的流程控制在需求開始的時候就應該重視起來，只是很多時候我們沒有意識到這是測試的工作。有的是產品來控制，有的是專門的項目經理來控制。測試人員是一線的工作人員，必須具備關注整體項目的意識。
需求一旦明確就要時刻按排期來關注項目的情況。中間變更需求的時候，要評估是否影響項目進度，如果影響了重新進行排期。如果開發提測試晚了，是否影響上線時間，如果可能會影響，馬上就要給相關的人員發預警郵件，通知大家詳細的情況。
同時在測試過程中，發現了bug必須詳細描述問題，不管是jira，禪道或是其他的bug管理方式，一個bug要寫清楚以下幾點：Bug問題描述，bug重現步驟，是否有前置條件，預期結果，實際結果，以方便開發去進行修改。同時給bug準確分級，實時跟蹤進度，保證項目按期完成。
❹ 上線迴歸與項目總結
一個需求上線完成後，要及時進行線上迴歸，提醒相關的人員進行自動化線上迴歸或是監控工作。同時必須迴歸我們在需求評審的時候考慮到的可能影響到的原有的功能，以確保新功能的完全上線成功。
而作爲測試人員，在一個項目完成後，不管公司是否要求，需要對項目做相應的文字總結。總結整個項目過程中遇到的問題，最後的解決辦法或是當時討論的處理辦法，有哪些需要注意的問題？有什麼可以借鑑的方案或是改進策略？項目中有沒有通用性的問題等等。
如果公司有相應的項目總結方案，那測試時需要多關注一些數據。如冒煙測試是否一次通過，Bug數及不同級別的bug數，參與開發人員對應的Bug數，提測試次數，上線次數等等。而後藉助於第三方工具進行圖表化相應的數據，然後相關問題的總結，改進方案都需要進行詳細的總結。
總結：
測試，從來都不簡單，也容不得半點馬虎，只有知行合一，踏踏實實把每個環節做到極致，才能通過用戶應用的最終考驗。
關於我們
▼
如果您感興趣，歡迎加入PUSHI AI社羣，共同探索AI。關注普適智能►回覆「入羣」，申請加入普適智能社羣，不定期還有福利活動噢~