說一說軟件測試的原則

關於軟件測試的原則，有如下五點：

第一，測試應儘早進行，最好是可以在需求階段就開始介入。

千里之堤毀於蟻穴，對於測試，若是越早介入，問題就能越早被發現，修改或者調整方向的成本就會越小。

測試在需求階段就介入，最嚴重的錯誤，無外乎是系統不能知足用戶的需求，可是若是按照傳統的瀑布模型，等到軟件開發完成以後再進行測試，那麼，萬一偏離了方向，糾正過來的成本將是巨大的。

 

第二，負責軟件開發的人員應避免檢查本身的程序。

當局者迷旁觀者清，本身犯的錯誤，每每意識不到。

當咱們仍是學生年代的時候，本身寫的做文，若是是本身檢查，很難找到錯誤。主要是受到思惟慣性的影響，以爲這樣表達並無錯，甚至是錯別字也沒法辨別出來。而若是交給其餘同窗或者老師來幫你檢查，效果就不同了。

這時候，有人就有疑問了，單元測試不是由開發人員測試的嗎？

對的，這就至關於自檢。每個模塊的代碼實現什麼功能，具體是怎樣的實現邏輯，開發者自身是最清楚的。由開發人員作單元測試，可以高效地修正一些低級錯誤。

另外，也是由於測試人員的編碼能力不足，開展單元測試效率低。因此，須要開發人員進行自檢，這樣的代碼纔有質量保證，而測試人員的做用就是，在代碼已有的質量上，提高一個質量級別。

第三，設計測試用例既要考慮到合法狀況，也要考慮不合法狀況。

 

開發界有一句話：永遠不要相信用戶的輸入。

關於微信紅包的金額，雖然已經指定了輸入範圍是0.01-200元，可是，有時候，用戶會有意無心就會輸入不合法的內容。更況且，黑客會專門找轉件的漏洞進行攻擊。因此，合法與不合法的輸入，都要兼顧考慮，作好限制管控。

第四，在測試程序時，不只要檢驗程序是否作了該作的事情，還要檢驗程序是否作了不應作的事情，多餘的工做中會帶來反作用，影響程序的效率，甚至帶來潛在的危害和錯誤。

這一項檢驗工做，主要是按照需求文檔進行檢測的，包括程序代碼考慮是否周全，邏輯是否嚴密等。

第五，應長期保留全部測試用例，有助於之後修改程序後進行迴歸測試。

軟件會長期進行迭代更新、升級，可是沒法保證更新、升級的內容不會對原有的功能形成負面影響，所以，須要進行迴歸測試。

若是從新設計開發測試用例，將會耗費巨大的人力成本。

微信在開始階段，是沒有紅包功能的，而增長這一項功能後，會不會對原有的聊天功能形成影響呢？這就須要進行迴歸測試了。

由於之前已經編寫過聊天功能的測試用例，若是保留下來，就能夠直接拿過來開始測試，不然，就須要從新編寫。

以上就是本篇文章所要分享的內容，歡迎各位大牛指正。你的指正，能讓我在測試之路上快速成長。

Leo Never Stop Fighting！

 

微信搜一搜【程序員一凡】關注這個文縐縐的程序員，關注後回覆【面試】有我準備的一線大廠面試資料和簡歷模板，但願你們都能找到心儀的工做，學習是一條時而鬱鬱寡歡，時而開懷大笑的路，加油。若是你經過努力成功進入到了心儀的公司，必定不要懈怠放鬆，職場成長和新技術學習同樣，不進則退。若是有幸咱們江湖再見！