1、没按照测试例进行测试，因为测试例条目实在太多，况且测试时间短，人力资源少，所以只是对基本测试例过一遍而已。这样对于撰写测试例来说纯属浪费，这点我觉得既然实行了走测试例就要严格执行，统一管理，执行结果应总结，并进行对该次测试给个评分。每个测试阶段应有一定的改善。

　　2、测试例应有两种版本，一种是给程序员执行的，（一般在20条测试例之内，并且是基本的，不会耗很多时间。保证版本的有效率，降低出版本次数。）在每次编译程序之前，程序员都应先自己执行一遍。另一种是给测试员执行的，测试例要详细，平常要及时更新，一人分两个模块，测试一周左右，对测试例进行交叉测试。并在一定时间内测试任务也要替换，避免反复测试的烦恼。有任务则有效的制约了空闲的测试人员，增强时间性及工作氛围。在最后一次回归测试应对测试例全部过一遍，这将是必要的。

　　3、建议增加测试人员，一个成功的项目，它的开发人员与测试人员比例应为1：2。在当前我们比例都少于1：1/2，这样对于一个项目的开发进程及质量是起抑制作用的。

　　4、开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一平台，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。

　　5、在系统测试阶段，有时会碰到很多低级缺陷，说明测试对象是不合格的，没有达到测试标准。如果系统阶段发现的简单缺陷（也就是不应该有的缺陷）较多，最好停止测试，转由开发人员进行测试，发现问题立刻修改，因为这种由测试人员进行的成本较高，反复交互还会耽误进度。建议建立预测试制度：系统测试前对核心模块进行抽查测试，如果问题较多（例如平均每个核心模块发现10个以上缺陷），就可以停止本次测试，直到抽测后发现问题较少才可以启动系统测试。

　　6、对测试人员的培训少，建议设立一个日常培训机构，并分别由各组来组织，时间为每天下班前半个小时（这段时间总是没心情测试的），利用这时，来对各组进行总结每天的测试成果，并开展组与组的座谈交流，有利于提高测试技能。

　　7、避免特有技能在单人手中掌握，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。

　　自己的缺点：

　　我喜欢测试新平台新项目，因为能发现很多问题，有一种快感，越测也有激情，总会回味无穷。但这就是我的缺点所在，这就意味着当我碰到稳定的项目的时候，我却不能发挥那种测试激情，反而感到无从下手，觉得软件稳定，没什么问题。就会下意识的向这个目标靠拢，测试不出问题来，结果不能很好的完成测试任务。