溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
最近在infoq上讀到一篇討論測試自動化的文章。雖然自己是一個開發工程師，
還是想談談對測試看法。
1.測試的分工
測試的分工上講，我想可以分為：技術測試，業務測試，這兩類測試各有所長。
從目前公司現在情況，或者國內測試的分布來講，更多的是業務測試。但是從公司對
測試的發展規劃來看，越來越看重測試在技術方面的認知水平。懂得技術實現的原
理，同時懂得測試技巧的測試，在工作中發揮的作用，確實是比較大。
個人認為，對測試技術能力進行強制的要求，是不太合理的。需要針對公司的技
術，業務場景；個人的技術，測試特點，進行綜合的考慮。
業務測試，是通過不斷積累的業務業務知識，測試技巧進行測試，對于業務模式
固定的產品，這類測試時不可或缺的；但是從另一個方面講，業務模式固定的產品，
也應該能很好的進行自動化測試。
技術測試，對技術的掌握能力，能讓測試在更多細節把握。技術測試能用比較
簡潔有效的方式進行測試，而這種方式，往往高效。對于技術復雜對稍高的公司，比
如互聯網公司，對穩定性要求較高的公司，對質量要求高的公司，懂得技術的測試往
往能更細節的關注業務流程和業務實現。
2.測試自動化
測試自動化，不僅僅是測試完成的自動化。為何這樣講呢？自己也感受過公司
的測試自動化，總體感覺自動化測試還是很苦逼。能用的自動化總是容易實現，好用
的自動化總是很難。個人覺得要實現自動化：
3.TDD
有些人在嘗試這個，也有把自己搞的很苦逼。TDD的粒度一定不能太小，對一個
類或者小的功能點進行TDD，不太現實，而且耗時耗力。使用TDD一定是在比較成型的
業務功能點或者業務流程上面。
4.集成測試，單元測試
概念上面不講了，也有很多文章講怎么寫好單元測試。單元測試時我們質量保
證的一個重要方法，當然這個是建立在寫的好的單元測試上面。
個人認為，單元測試，更應該在基礎模塊，復雜實現功能點上進行。而在業務
流程的編程上面的測試，則不要使用單元測試。
個人更傾向于使用集成測試，集成測試需要在更好的高度對測試用例進行規劃
和管理，只有這樣，我們的測試才有效，能持續，有生命力。
不要為了覆蓋率，而覆蓋，這樣開發很苦逼，更重要的測試沒效果；但是好的
測試，可以通過覆蓋率反向的分析代碼：那些代碼多了，那些代碼可以重構等等。
暫且想到這么多。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
