這部分其實不難處理 一時之間要補完全部測試是不可能的 但初期針對修改的地方撰寫測試即可 首先譬如我打算修改 關於會員紅利下的某個方法 那我在修改前 就先撰寫此方法的測試檔 測試盡量周全 甚至是功能性測試也撰寫一份 修改後此方法的測試要能通過 如果此方法無法通過修改前 那有可能造成功能損壞 長久慢慢累積下來就能漸漸的補齊測試 然後將測試檔案分享給隊友 特別是功能性測試部分 多數修改者都至少想測一下功能有沒有被改壞 養成風氣漸漸的讓測試完善 不要想一步登天 測試覆蓋率本來就是慢慢的拉大的 當隊友慢慢感受到測試檔的方便性時 漸漸的會願意跟進撰寫 測試檔的很大好處就是 當跑在不同環境時發現問題的速度很快 如果有stage環境能先使用測試檔測試過 那風險是會降低很多的 ※ 引述《joycegirl (じゅんさん)》之銘言： : 想請問除了大型公司外，大多的軟體公司 : 都是如何看待開發及測試的 : 目前的公司規模比較小，所有人都是自行開發 : 無測試人員，所以自己寫的程式都需要自己測試 : 測試都是使用人工測試法，就是上線點系統看有無BUG跟資料是否正確 : 自己建立資料，自己測試系統 : 但這樣下來真的很消磨心智 : 如果要修改重要的模組，感覺大家有股越來越不想碰的氛圍 : 因為碰了就是要測很多次、很久，牽扯的範圍也大 : 即使在你的開發環境上，測試OK，也不能表示上線了就會可以 : 即使自己已經很用心在測試了，但使用者總會有超乎你想像的操作 : 所以想請問一下，有經驗的前輩們， : 在軟體開發上有類似的經驗都是如何處理的? : 補充說明: : 重要的模組像是牽扯禮券、金錢、點數、會員紅利...等的模組 : 一出包就很麻煩，但是每個月系統都在更新，覺得測試總是不完全 : 有考慮自己寫測試程式，但就是要花自己的時間去處理 : 而且也不知道從何下手 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.136.38.3 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1511073934.A.D9F.html