讀移動APP測試實戰的幾點總結

　　對於移動APP的測試，我以爲本身仍是有必定討論資格的。畢竟有三年多的開發經驗。而測試經驗的話，主要體如今本身的產品使用了。這本書確實是一本寫得挺實用的軟件測試書籍。裏面的不少經驗很是值得學習，這個也是我以前深有體會的。

　　對於目前國內的如今而言不少app的測試仍是以手動爲主，我想主要緣由有如下幾點：一、移動端平臺比較多，而對應的自動化測試軟件卻不多。並且相應自動化測試的穩定性也不佳。二、移動端升級變更頻繁，作自動化成本很高。你們都知道，通常的APP半年、三五個月就一個新版本。有的更頻繁的一個月一個版本，甚至是一個週一個的也有。若是用自動化工具來作，維護成本和週期可能比手工成本高不少並且效果還很差。三、產品變化快。不少APP都是屬於輕小型的，這樣可使產品的更改比較方便。可以及時應對市場的變化。這樣就致使產品的不少功能不可以穩定的執行，自動化測試通常須要相對於較爲穩定的產品功能。因此這一點也不太適應於自動化測試。

　　那麼對於APP的測試現狀又沒有能夠提高的地方呢？固然有，《移動APP測試實戰》這本書就介紹了不少實用的方法。下面就總結一下軟件測試自我提高的方法和策略。

　　一、仔細閱讀需求文檔，熟悉產品。固然是在有文檔的狀況下，若是沒有文檔呢？那就只能看開發給的App了。在測試以前必定要對產品有個總體的把握和了解。知道哪些是重點功能，哪些是輔助功能。開始前必定要有全局觀，不要走入本身的思惟誤區。測試是一份永遠完不成的工做，並且永遠都是時間不夠的。因此必定要把握好產品的重點、關鍵點。要把測試時間和用例分配作好。要作到這些對產品的把握就很重要。咱們要儘量的熟悉產品，作好能作到比開發、比產品還要熟悉產品。

　　二、繪製測試思惟導圖，理清測試思路。這個也是很是重要的。不論是產品型的公司仍是項目型的公司。測試不可能一次只接手一個項目。那麼爲了保證測試的思路不被打亂，咱們必需要及時的記錄和管理咱們的測試思路。甚至有些公司對於測試用例的編寫也不作強制性要求。因此寫測試的思惟導圖對於及時的整理咱們的測試思路很重要。

　　三、及時整理測試用例。不少時候咱們的測試用例並無足夠的時間來編寫。又些項目甚至要先作測試，作完測試之後纔有空閒時間。對於這種先作後寫的，咱們也要認真的作。不少時候測試的工做是看不到成果的。因此，要想人家承認測試的工做，文檔話的工做是必須的。測試的文檔對於一個產品實際上是很是重要的。甚至不少的時候，測試的文檔能夠用來做爲產品的說明文檔。開發文檔通常重在技術，而產品的文檔則重在需求。測試文檔則應該將技術實現的需求作產品化整理。同時附帶一份產品質量評審報告。

　　四、及時與開發溝通。不少時候開發給我版本和開發正在進行的版本確定不是同一個，因此不必等到產品測試完之後再開發交流產品bug。尤爲是一些較爲嚴重的問題，儘可能作到及時反饋。這樣能過保證產品問題的修復。每次產品測試完之後最好可以同開發作一次當面的產品bug反饋。當面的溝通和反饋能過有效的條件測試和開發之間的關係。溝通時要注意語氣和態度，不要將本身放在開發的對立面而是要同開發一塊兒站保證更好的產品的角度。每輪測試結束，也已定要整理測試分析結果，最好可以保證因此相關人員都能知道產品文同的文檔。

　　五、及時瞭解各類測試工具。不少時候每一個工具都有本身的特色，可以解決的也只是某一方面的問題。因此做爲測試人員必定要及時學習新的工具和測試思想。不斷跟新本身的知識和理念，這樣才能保證與時俱進。

　　六、每隔一段時間要整理一下測試流程的問題。對於質量的問題，不少時候咱們須要流程來保證。因此對於流程中間不規範的地方須要及時的更改。

　　七、熟悉測試產品平臺的開發環境。這一點是不少測試人員不肯意作的。對於開發，很測試以爲很頭疼。做爲測試咱們常常須要和開發打交道，而開發最討厭的就是測試什麼也不懂。跟你解釋都解釋不清楚。因此瞭解相關產品開發平臺的語言也是很重要的。至少這樣可以保證你跟開發流暢的溝通，這樣工做起來天然更順手。

　　八、閱讀一些架構和交互方面的知識。這樣能過是咱們更加有能力提出一些有關產品和技術方面的問題。也可以在跟開發、產品交流時更流暢。這樣測試也才能更佳發揮重要的做用。

　　九、作後一點不是最重要的，可是卻很難作到的。就是多寫寫技術博客。不少的開發人員都會寫技術博客，可是測試人員卻不多。有些人是以爲沒什麼好寫的，有些人是以爲難以堅持。因此測試方面的優秀博客確實不是不少，可是堅持是一件很不用一的事情。因此堅持寫博客，無論目的是傳播知識，總結自我，提高自我仍是什麼的。只要能過好好堅持下來，收穫確定是不小的。

好了，以上就是個人一點總結。但願對你們有幫助。