軟體測試的原則

關於軟體測試的原則，有以下五點：

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

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

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

第二，負責軟體開發的人員應避免檢查自己的程式。

當局者迷旁觀者清，自己犯的錯誤，往往意識不到。

當我們還是學生年代的時候，自己寫的作文，如果是自己檢查，很難找到錯誤。主要是受到思維慣性的影響，覺得這樣表達並沒有錯，甚至是錯別字也無法辨別出來。而如果交給其他同學或者老師來幫你檢查，效果就不一樣了。

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

對的，這就相當於自檢。每一個模組的程式碼實現什麼功能，具體是怎樣的實現邏輯，開發者自身是最清楚的。由開發人員做單元測試，能夠高效地修正一些低階錯誤。

另外，也是因為測試人員的編碼能力不足，開展單元測試效率低。所以，需要開發人員進行自檢，這樣的程式碼才有質量保證，而測試人員的作用就是，在程式碼已有的質量上，提升一個質量級別。

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

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

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

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

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

第五，應長期保留所有測試用例，有助於以後修改程式後進行迴歸測試。

軟體會長期進行迭代更新、升級，但是無法保證更新、升級的內容不會對原有的功能造成負面影響，因此，需要進行迴歸測試。

如果重新設計開發測試用例，將會耗費巨大的人力成本。

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

因為以前已經編寫過聊天功能的測試用例，如果保留下來，就可以直接拿過來開始測試，否則，就需要重新編寫。

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

Leo Never Stop Fighting！