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