※ 引述《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 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 39.9.40.18 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1569686909.A.2E9.html ※ 编辑: samuel1988 (39.9.40.18 台湾), 09/29/2019 00:10:27