※ 引述《EricTCartman (阿ㄆㄧㄚˇ)》之铭言：
: ※ 引述《jas1123kimo (杰森)》之铭言：
: : 2. 要怎么Debug及测试
: : 因为小弟我之前都在学校，写的程式不会这么庞大?
: : Debug就是设定很多的Pritf看运作的参数
: : 或者丢各种测资，而且要每个Function都要跑到
: : 但每次这样回答完
: : 面试官都露出应该还有其他的方法的脸看着我。
: : 请问还可以怎样测试或Debug呢
: 1. 测试
: 单元测试 集成测试 重点应该是要能自动化
: 测资从正常数值开始抓 接着抓极端值
: 对于可逻辑产生的数值 也会自动化产生测资
: 会考虑输入内存配置失败 或外部资源无效时的案例
: 如果是performance-critical的区段 还会加上时间测量
: 测试时会将bug的情况作为test case追加
: 讲完要反问一下面试官 你们覆蓋率几%
: 2. Debug
: 首要工作是是要确立重现的流程
: 并且将重现bug的流程做到最精简
: 原因：过于繁复的重现步骤表示涉及的程式码越多 则越难找到bug的出处
: 对于我不熟悉的专案，我会从操作步骤的UI层开始追踪
: 且如果是资料的错误，我会利用watcher监看资料实体是在哪个时机点被改变
: 如果是偶发的错误，我会利用conditional breakpoint增进debug的效率
: 莫名的资源无效或内存错误 我会检查有无多执行续或重复释放、destruction
: 等可能的行为
: 如果是第三方library或dll的bug，我会先阅读文件确认使用方式无误，如还是
: 无法发现问题则会到官方的bug tracker查询有无类似情况。若以上均无解且与
: 该公司无合作关系或状况急迫，我会以组合语言的形式下断点并观察memory变化
: 试图出可能的原因，并从input或使用方式解决此问题
: 解释完自己如何进行debug
: 如果之前面试官说公司测试覆蓋率不高或根本答非所问打太极的话
: 记得要反问面试官 贵公司修正bug后
: 如何确保不会产生其他bug 以及如何落实code reivew
先分清楚是production or UAT
若是production
先去windows 事件检视簿调阅log
Or
/var/log/messages
调阅，从log中分析问题。通常9成可以马上抓到问题。剩下一成是特殊案例。
若是UAT直接docker image 抓下来测试发生错误流程。若没有docker先了解有没有文件定
义业务流程，或者unit test，若覆蓋率太低或者文件不齐全则要trace code 一层一层追
。
确认好所有商务逻辑才能debug