基于度量分析程序结构
第五次作业
第六次作业
第七次作业
分析自己程序的 Bug
经过了前三次作业的“教训”，我尝试不看任何的 issue 和微信群答疑，只看指导书来完成本次作业。
第五次作业失误了，没有正确处理括号的输入，错了两个公测点。
第六次作业 IFTTT 对于文件夹的监控理解不够到位。
第七次作业做得比较完美。报告书也写得很漂亮。
分析未通过的公测用例和被互测发现的bug：特征、问题所在的类和方法
特别注意分析哪些问题与线程安全相关
关联分析bug位置与设计结构之间的相关性
从分类树角度分析程序在设计上的问题
分析未通过的公测用例和被互测发现的bug：特征都是指导书没说的。
与线程安全相关的问题我是没有的。
bug位置与设计结构没有什么太大的相关性，就是指导书可能没说。
程序在设计上没有充分考虑指导书意外的问题。
分析发现别人 Bug 所采用的策略
code-review 或者说测试的代价是很高的，在大公司中通常他们都由技术比较好的人来完成，并且薪酬很高。我因为时间比较少，就（根本）没有做测试。
列出自己所采取的测试策略及有效性，并特别指出是否结合被测程序的代码设计结构来设计测试用例
分析自己采用了什么策略来发现线程安全相关的问题
我采取的测试策略叫做摸鱼，这是个比喻，区别于钓鱼。在知名网站编程 codeforces 上，如果你 hack 别人的代码失败，那么你会被扣分，于是有许多人采用了“钓鱼”的方法，例如， #define int long long，然后在程序中使用 int。如果你没有发现这个宏定义，而冒然地认为它没有使用 long long，那你就被钓鱼了。
与之相反，“摸鱼”指的是我们把拿到的测试代码，放在那里，不管它，就好像虽然我们的目标是去捉鱼，但是我们只把手伸进水里，摸一摸就行了。
心得体会
从线程安全和设计原则两个方面，我得到的体会是：这三次作业我仍然是在周三的凌晨写完的，我觉得这样对我的身体不是太好，以后还是周二写完吧。