－这个很显而易见。但不幸的是，我参与过的很多项目测试小组都是在很晚才开始测试的。由于公司在成本上的考虑，导致了在开发后期或系统测试时才开始测试。出现了开发人员在项目晚期还在加班改bug的情况，甚至由于错误太多拖延了交付时间。在其中，还有可能发现整体设计和构架上的缺陷，导致明知会有很严重的后果都不敢改动代码的事情。
计划完成的测试工作量
◆测试的工作量和功能测试有偏离
◆低估了配置测试
◆把压力和负载测试放在最后进行
◆不测试文档
◆不测试安装过程
◆过分依赖beta测试
◆在转移到下一个任务之前必须完成现在的测试任务
◆未能正确地识别风险区域
◆固执地遵从测试计划
◆利用测试作为新开发人员的过渡工作
◆从不合格的程序员中招募测试人员
◆测试人员不需要是领域专家
◆不从客户服务人员或技术文档人员中挑选测试人员
◆坚持测试人员必须能够编程
◆缺乏多样性的测试小组
◆认为测试和开发人员有本质的区别
◆相信开发人员不能够测试他们自己的代码
◆开发人员既没有受过培训，也没有激情测试
工作中的测试人员
◆比设计测试更注重运行测试
◆不审核测试设计
◆非常详细地描述测试的输入和过程
◆没有注意并探测到“不相关的”怪事
◆检查产品应该执行的和期望的一样，但没有检查它不应该执行的是期望不应该执行的一样
◆测试套件只有他们的作者才可以理解
◆只通过用户可见的界面测试
◆拙劣的错误报告
◆当发现错误后，只是增加了回归测试
◆没有为下一此测试工作量做笔记
测试自动化
◆尝试自动化所有的测试
◆可以立即减少工作量或人力
◆期望重新运行手工测试
◆使用GUI捕获/回放工具以减少创建测试的成本
◆期望回归测试可以发现更多的新错误
测试覆盖
◆只是追求一个简单的关于测试覆盖率的数据
◆只是因为有些测试不能增加覆盖率，就把它们从回归测试包中移除掉
◆把覆盖率作为测试人员的绩效目标
◆彻底地放弃覆盖率
文章来源于领测软件测试网 https://www.ltesting.net/
