關于軟體測驗的原則，有以下五點：
第一，測驗應盡早進行，最好是能夠在需求階段就開始介入，
千里之堤毀于蟻穴，對于測驗，如果越早介入，問題就能越早被發現，修改或者調整方向的成本就會越小，
測驗在需求階段就介入，最嚴重的錯誤，無外乎是系統不能滿足用戶的需求，但是如果按照傳統的瀑布模型，等到軟體開發完成之后再進行測驗，那么，萬一偏離了方向，糾正過來的成本將是巨大的，
第二，負責軟體開發的人員應避免檢查自己的程式，
當局者迷旁觀者清，自己犯的錯誤，往往意識不到，
當我們還是學生年代的時候，自己寫的作文，如果是自己檢查，很難找到錯誤，主要是受到思維慣性的影響，覺得這樣表達并沒有錯，甚至是錯別字也無法辨別出來，而如果交給其他同學或者老師來幫你檢查，效果就不一樣了，
這時候，有人就有疑問了，單元測驗不是由開發人員測驗的嗎？
對的，這就相當于自檢，每一個模塊的代碼實作什么功能，具體是怎樣的實作邏輯，開發者自身是最清楚的，由開發人員做單元測驗，能夠高效地修正一些低級錯誤，
另外，也是因為測驗人員的編碼能力不足，開展單元測驗效率低，所以，需要開發人員進行自檢，這樣的代碼才有質量保證，而測驗人員的作用就是，在代碼已有的質量上，提升一個質量級別，
第三，設計測驗用例既要考慮到合法情況，也要考慮不合法情況，
開發界有一句話：永遠不要相信用戶的輸入，
關于微信紅包的金額，雖然已經指定了輸入范圍是0.01-200元，但是，有時候，用戶會有意無意就會輸入不合法的內容，更何況，黑客會專門找轉件的漏洞進行攻擊，所以，合法與不合法的輸入，都要兼顧考慮，做好限制管控，
第四，在測驗程式時，不僅要檢驗程式是否做了該做的事情，還要檢驗程式是否做了不該做的事情，多余的作業中會帶來副作用，影響程式的效率，甚至帶來潛在的危害和錯誤，
這一項檢驗作業，主要是按照需求檔案進行檢測的，包括程式代碼考慮是否周全，邏輯是否嚴密等，
第五，應長期保留所有測驗用例，有助于以后修改程式后進行回歸測驗，
軟體會長期進行迭代更新、升級，但是無法保證更新、升級的內容不會對原有的功能造成負面影響，因此，需要進行回歸測驗，
如果重新設計開發測驗用例，將會耗費巨大的人力成本，
微信在開始階段，是沒有紅包功能的，而增加這一項功能后，會不會對原有的聊天功能造成影響呢？這就需要進行回歸測驗了，
因為以前已經撰寫過聊天功能的測驗用例，如果保留下來，就可以直接拿過來開始測驗，否則，就需要重新撰寫，
以上就是本篇文章所要分享的內容，歡迎各位大牛指正，你的指正，能讓我在測驗之路上快速成長，
Leo Never Stop Fighting！
微信搜一搜【程式員一凡】關注這個文縐縐的程式員，關注后回復【面試】有我準備的一線大廠面試資料和簡歷模板，希望大家都能找到心儀的作業，學習是一條時而郁郁寡歡，時而開懷大笑的路，加油，如果你通過努力成功進入到了心儀的公司，一定不要懈怠放松，職場成長和新技術學習一樣，不進則退，如果有幸我們江湖再見！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/68322.html
標籤：其他
上一篇：[TryHackMe]-[Google Dorking]
下一篇：《軟體測驗常見面試題十二》