这部分其实不难处理 一时之间要补完全部测试是不可能的 但初期针对修改的地方撰写测试即可 首先譬如我打算修改 关於会员红利下的某个方法 那我在修改前 就先撰写此方法的测试档 测试尽量周全 甚至是功能性测试也撰写一份 修改後此方法的测试要能通过 如果此方法无法通过修改前 那有可能造成功能损坏 长久慢慢累积下来就能渐渐的补齐测试 然後将测试档案分享给队友 特别是功能性测试部分 多数修改者都至少想测一下功能有没有被改坏 养成风气渐渐的让测试完善 不要想一步登天 测试覆盖率本来就是慢慢的拉大的 当队友慢慢感受到测试档的方便性时 渐渐的会愿意跟进撰写 测试档的很大好处就是 当跑在不同环境时发现问题的速度很快 如果有stage环境能先使用测试档测试过 那风险是会降低很多的 ※ 引述《joycegirl (じゅんさん)》之铭言： : 想请问除了大型公司外，大多的软体公司 : 都是如何看待开发及测试的 : 目前的公司规模比较小，所有人都是自行开发 : 无测试人员，所以自己写的程式都需要自己测试 : 测试都是使用人工测试法，就是上线点系统看有无BUG跟资料是否正确 : 自己建立资料，自己测试系统 : 但这样下来真的很消磨心智 : 如果要修改重要的模组，感觉大家有股越来越不想碰的氛围 : 因为碰了就是要测很多次、很久，牵扯的范围也大 : 即使在你的开发环境上，测试OK，也不能表示上线了就会可以 : 即使自己已经很用心在测试了，但使用者总会有超乎你想像的操作 : 所以想请问一下，有经验的前辈们， : 在软体开发上有类似的经验都是如何处理的? : 补充说明: : 重要的模组像是牵扯礼券、金钱、点数、会员红利...等的模组 : 一出包就很麻烦，但是每个月系统都在更新，觉得测试总是不完全 : 有考虑自己写测试程式，但就是要花自己的时间去处理 : 而且也不知道从何下手 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.136.38.3 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1511073934.A.D9F.html