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