本次阅读了第十三 软件测试 十四章 质量保障
在软件发布前基本没有进行测试，直到上台讲述的之前的一段时间才发现了一些问题，甚是着急
第十三章中excel计算1900闰年错误的例子给了我一个全新的概念——要服务于最主要的功能.
传说中的拐点
小飞： 我听说在软件项目中，有这样一个拐点存在——在这一点之前，新的Bug产生的数量大于Bug解决的数量；在这一点之后，Bug的解决数量大于新的Bug产生的数量。这样Bug的曲线就向下移动。我们移山项目的拐点到了么？
阿超： 我也听说过，不过这是在大型复杂项目中，测试人员和开发人员全部通过一个系统管理bug才会出现的现象。我们不能等待拐点的到来，对于我们这样的日期驱动型的小项目，拐点必须在发布日之前的若干时间发生，如果我们的Bug数量还是继续向上攀升，则无法保证以后曲线会像悬崖一样掉下来。我们就得主动让拐点发生，例如推迟一些Bug，砍掉一些功能，慢慢升高“必须修复的小强”这个标杆，等等。
这个拐点至今还没有深刻体会，不过在一段时间内完成超额或者超出预期任务的情况到是有发生。
今后会在大小bug无法取舍的情况下选择有限解决影响主要功能的bug
由于专业的QA工作没有深刻了解，暂时先不写