APP開(kāi)發完成以後，測試流程是怎麽樣的？

來源：銘碩網絡   日期：2020-09-16 11:01:46

一(yī)款APP産品在上線之後的穩定性，取決于上線之前的軟件測試，也就是說在上線之前，能找出更多的軟件問題并解決，那麽上線以後，APP軟件自然就很少出現問題，系統性能自然就更加的穩定。那麽正規的測試流程是怎麽樣的呢？

1、測試工(gōng)作準備

測試負責人在軟件項目的需求階段開(kāi)始介入，逐步深入了解該項目的需求、設計過程，從而有針對性的編制測試計劃和測試大(dà)綱（測試方案、測試用例）。

2、測試計劃的制定

測試計劃的制定要與項目開(kāi)發的總體(tǐ)計劃相吻合；測試計劃中(zhōng)要充分(fēn)考慮資(zī)源計劃（人員(yuán)安排，設備分(fēn)配、與其它部門的協調配合以及其它不确定的因素）等；測試計劃的制定還要考慮測試版本計劃，與開(kāi)發協調，按照版本生(shēng)成計劃（多長時間出一(yī)個版本），制定測試計劃。

3、時間節點的控制（與開(kāi)發協調控制）

提測的時間是否在規定的時間内，如果未按照計劃的時間提測，則需要分(fēn)析是否會對項目造成影響，會不會存在風險。在計劃的時間内，保證測試用例全跑一(yī)遍，如果未按預計時間将所有的用例走一(yī)遍，則需分(fēn)析原因。

4、需要評審

策劃完成的需求文檔必須讓開(kāi)發、測試、運營進行評審，提出異議意見并最終改掉。這種評審能發現需求的漏洞并提早改掉，提高整個研發過程的效率。

5、用例評審

測試人員(yuán)針對需求寫出粗略的用例之後，讓産品、開(kāi)發、測試、運營評審一(yī)遍、目的是發現需求的遺漏點，根據我(wǒ)(wǒ)們的經驗，由于測試人員(yuán)已經思考了測試點，所以相當于是對需求的細化和剖析，這個評審環節還是能發現很多需求的漏洞。

6、開(kāi)發提測

測試人員(yuán)事先發出冒煙測試用例，開(kāi)發完成後，讓開(kāi)發人員(yuán)先根據冒煙用例進行自測，自測通過了以後才提交給測試，然後測試再根據相同的用例做冒煙測試。這樣能提高開(kāi)發提測的質量。

7、測試反饋

将測試中(zhōng)發現的Bug反饋給該項目負責人，由負責人對該Bug進行定位，并由響應的開(kāi)發人員(yuán)進行修改，如果測試人員(yuán)發送的Bug并非該測試模塊的Bug，由該負責人轉發給相應的負責人，并指派給對應開(kāi)發人員(yuán)修改。測試結束後，測試過程中(zhōng)發現的所有Bug，都應将其統計彙總，标識出當前狀态，其中(zhōng)經過再次測試已經關閉的不再說明，其它所有未關閉的均應說明理由，并與開(kāi)發部門讨論，由技術負責人給出結論（是否解決或延期解決），并要經過技術副總審批。

8、測試分(fēn)析

測試完畢，整理測試文檔，需要讓測試人員(yuán)發一(yī)份測試報告，重點指出測試過程中(zhōng)發現的問題，以及上線以後可能會出的質量問題，并說明告知(zhī)這些風險，如果有因爲時間不足，或者因爲客觀條件限制導緻測試不足的情況，一(yī)定要在這個環節說明，這樣，如果上線以後出現問題，大(dà)家也能理解測試。

9、質量目标

通過測試管理工(gōng)作的加強，力求在測試階段盡可能多的發現軟件錯誤與缺陷，盡可能少的将問題帶給用戶，确保軟件的質量及其可靠性，提高用戶滿意程度，使作爲質量管理中(zhōng)心的質量管理部真正的把好産品的質量關，盡量在測試階段發現軟件錯誤和軟件缺陷。

10、線上問題

對于線上發現的Bug，先重點分(fēn)析這個線上Bug産生(shēng)的原因、線上Bug的影響範圍，然後大(dà)家一(yī)起決定可以有哪些改進措施可以避免同類線上Bug再犯。這種改進措施需要能真正落實的，如果是可有可無的改進措施，就不要提了。這個措施可以讓大(dà)家一(yī)起剖析線上Bug的産生(shēng)原因，一(yī)方面可以避免項目組認爲都是測試的錯導緻線上Bug，一(yī)方面，也發揮了測試人員(yuán)質量保證的角色，推動流程讓質量更好。

總之，一(yī)款性能穩定功能強大(dà)的APP軟件産品，離(lí)不開(kāi)各個環節專業人士的參與，産品經理、UI設計、web前端、Android、IOS、Java、PHP、軟件測試，無論哪一(yī)個環節不專業，都可能影響APP産品的質量。