一、有错不改，闰年问题
- 如何判定闰年，正确的判断条件应为
(year%400==0)||(year%4==0&&year%100!=0)，注意三个求余之间的关系。题目代码中对4求余和对100求余的条件应与在一起。
- 计算错误。
当输入天数恰好截止到某一闰年的最后一天时，days减为366以后，会从while开始执行三个判断条件，而days不会减少，year不会增加，进入死循环状态。应该把days>366改为days>=366或days>365。
学习到测试用例的设计方法，根据等价类划分测试集合，比如如果一个函数可以返回 true | false, 你至少得有两类测试集合, 让它分别返回 true | false；如果知道程序的工作原理，可以把等价类更详细的划分，针对每个函数都要设计；按边界值设计测试用例；从内部考虑看测试用例是否把语句覆盖掉（当然即使全部覆盖也不能保证程序不出错）。
- 没想到还有闰年。关于年份日期的变换，要想到有平年闰年的区别。出租车的闰年虫问题，提示我们不要图省事儿，回避特殊问题。
二、 侵官之害甚于寒
在开发过程中，不同角色相互合作、相互制约。大家不能越俎代庖，否则会“甚于寒”。比如测试人员再做验证测试时，需要做多方面、多平台的测试，这些工作量远远超过了开发人员的能力范围，因此必须要由测试人员验证并处理已经修理好的bug。
三、 测试经验交流
不放过任何可能的bug，会导致不少“As design”，但也不是绝对的坏事；测试人员不用研究，去找问题根源甚至去想修复问题，这些越过了开发人员的职责范围；保证测试方法的多样化；以用户的角度去想问题；举一反三，在出过问题的类似点上测试；在事先通知和安排好的情况下，可以交换测试；把比较稳定的测试写成自动测试，会减轻手工测试的压力。
四、 传说中的拐点
拐点是在大型复杂项目中，测试人员和开发人员全部通过一个系统管理bug才会出现的现象。对于日期驱动型的小项目，要人工干预，如推迟一些Bug，砍掉一些功能，慢慢升高“必须修复的小强”这个标杆等，主动让拐点发生。
五、 学习和使用多个平台上的测试工具
六、 历史上的20大bug(未完待续)
七、 历史悠久的bug（未完待续）
八、 TPS和并发用户数之间的关系
每秒事务数TPS是衡量系统性能的一个非常重要的指标。服务器端性能主要以TPS来衡量，与用户并发数没有多大关系。
单纯考虑单个脚本，用户并发数Vu与TPS的换算关系为 ，Rt是该脚本一次完成所有操作的时间。设每个脚本中有m个事务，共有n个脚本，则总的TPS是： 。（注：对此换算关系有疑问）
对于新系统，TPS和Vu的获取只能通过业务部门进行评估。对于旧系统，取高峰时段在线用户数的10%作为Vu，单位时间内完成的业务笔数作为TPS。
系统的最大TPS是一定的（在一定范围内），但并发用户数不一定，可以调整。性能测试的时候，不要设置过长的思考时间，以最坏的情况对服务器施压。在做负载测试时，一般按照梯度施压的方式去加用户数，大型系统5000个用户并发足够，中小系统1000个用户并发足够。