對於
軟體測試與
軟體開發之間的關係，一直以來都很微妙，大型、制度健全的公司或許不那樣明顯但在中小型、制度尚不健全的公司，則變成為了老大難的問題。
軟體需求、軟體開發、軟體測試是軟體公司技術部門的三大主力，今天我們要說的是軟體開發與軟體測試。
軟體開發與軟體測試即是乙個統一體，也是乙個矛盾體。
為什麼說他們是乙個統一體？因為他們有著同乙個目標：產品或專案的質量、使用者的滿意度、公司的利益。
為什麼說他們是乙個矛盾體？因為表面上他們的工作內容是相互對立的，在心理上，往往呈現出這樣乙個現象：如果一方做得好，則很大程度上顯示出另一方做的不好。
我覺得問題產生的原因在以下幾個方面：
首先，公司的制度、團隊的風氣很重要
不能否認，現在仍然有許多公司以缺陷的多少、重要級別來作為衡量乙個軟體開發人員或測試人員的工作成績的主要標準，如此大錯特錯的方式卻仍然在許多公司存在。不是說不可以作為衡量標準，缺陷可以作為衡量軟體開發人員或測試人員工作成績的乙個方面，但這應該只是很小的乙個方面，僅供參考，而不應該是主要評價標準！更有甚者與員工的薪水掛鉤，這樣的標準一旦施行，必然使軟體開發人員與測試人員陷入一種勢不兩立的局勢。記住，惟一衡量這一切的標準是產品或專案最後的使用質量。
就像當年的國共合作，表面一致，實際卻各有算盤，兩個敵人之間除了相互猜疑、相互攻擊，能有多少合作的份量？團隊之前的默契如何培養？感情如何維繫？
公司的制度同時也會直接影響到團隊成員之間的關係。因為某個測試人員或開發人員的工作「優秀」，導致某個開發個員或測試人員的工作「失職」。如此，情何以堪？
然後，開發人員、測試人員的職業修養很重要
開發人員、測試人員在工作中要有絕對的職業道德作為準則，工作中對事不對人，至少應該努力去這樣做。
在其位，謀其職，遇事冷靜，得饒人處且饒人。
開發人員：寫好自己的code，認真對待測試人員提出的每乙個bug，即是一種對自己負責任，也是對公司負責任的一種體現。謂之，在其位，謀其職；遇到不是自己的code導致的bug，冷靜的分給相應的開發人員或打回給測試人員，並詳細的寫明備註，遇到誤報的缺陷，冷靜的思考、討論。若確實屬於誤報，無需動怒，誰不犯錯，冷靜的打回缺陷，備註中註明原因。謂之，遇事冷靜，得饒人處且饒人。
測試人員：認真測試開發人員寫的每一行code、每乙個功能，仔細確認每乙個即將上報的bug，同樣是對自己、對公司負責任的一種體現。謂之，在其位，謀其職；遇到低階錯誤、重複或多次開啟的bug，無需不爽，這就是你的工作，冷靜的報告給相應的開發人員，備註中註明原因。遇到某個開發人員寫的功能缺陷比較多，詳細測試找出其中每乙個缺陷並報告給他，其他什麼也不要做。謂之，遇事冷靜，得饒人處且饒人。
其次，團隊之間的溝通很重要
很多時候誤會的產生，只是因為一句話沒有說完，半句話沒有聽懂。
在軟體行業團隊成員之間的溝通也顯得尤為重要：通過周例會、月度例會、時不時的十分鐘短會、頭腦風暴、各種評審會議等等，都是團隊之間溝通的方式。
要及時表達自己的想法和理解，如及時溝通需求、表達自己對需求理解、對實現的設想等，保證開發人與測試人員之間需求理解的一致性，避免出現各種不必要的誤會。
再次，團隊之間的相互理解很重要
要能理解各自工作的性質，站在對方的角度想問題。
測試人員要理解開發人員，他們每天有很多的code的寫，他們的壓力也很大，孰能無過焉？
開發人員要理解測試人員，找出你們程式中的缺陷就是他們的工作，他們的工作量很大，錯誤尚難避免。
最後，個人素養很重要
應該感謝那些找出你程式中缺陷的人，因為他們使你在不斷進步，不斷完善。
如果你還在為測試人員找出你程式中的缺陷而對某個測試人員耿耿於懷，不能虛心接收他人的意見，那麼你只會被你的缺陷所牽制。
不必為今天沒有找到缺陷而心煩，因為即使是這樣你的價值也已經體現；更不必為每天要報告大量的缺陷而苦惱、煩躁，因為這就是你的工作。
以上觀點僅代表我的個人觀點，若有失言之處，請指正。
希望大家都能有乙個和諧、高效的研發團隊！
敏捷軟體開發 測試
test driven development 測試驅動開發 如果我們遵守了以下的規則進行開發，那麼這就是測試驅動開發 在編寫任何產品 之前先寫乙個會執行失敗的單元測試。編寫乙個單元測試，使其剛好能夠執行失敗或者編譯失敗。編寫的產品 應該剛好能夠使失敗的單元測試執行通過。如果按照這種開發方式進行開發...
python 軟體開發測試
在軟體開發中我們要經過顧客需求，設計，程式設計，測試，而測試就是我們最後一步要做的。1.而在軟體開發中有幾種模型 瀑布模型 按照固定的要求依次進行，如同瀑布一樣。優點 能夠穩定發展。缺點 要求的時間太長，使用者不能很快的看到產品。快速原型模型 可以迅速的建造乙個客戶要求的產品原型，可以很快的理解和處...
軟體開發模型和軟體測試模型
瀑布模型在軟體工程中占有重要地位，是所有其他模型的基礎框架。瀑布模型的每乙個階段都只執行一次，因此是線性順序進行的軟體開發模式。適合需求變更小，比較穩定的專案。優點 缺點 瀑布模型的乙個大缺陷在於，可以執行的產品很遲才能被看到。這會給專案帶來很大的風險，尤其是整合的風險。如果在需求引入的乙個缺陷要到...