测试人员在项目中

对测试的几点看法：

 

1、测试何时介入项目？

   个人看来，在初步讨论需求的时候，测试负责人员就需要介入。目的：1、对整个项目的宏观了解（主要）；2、在需求阶段，从测试的角度，提出相关看法，尽量避免不合理流程进入下一步。   （建议：测试负责人定下来后，中途尽量不换此人。在以前的工作中，负责测试的人员听完需求后，案例编写、测试工作全都由其他人员来完成。测试负责人起的作用仅仅是一个了解的作用。这样一来，导致的结果是：资源的严重浪费。案例编写人员需要从头仔细阅读需求，对需求中的不确定点一一找相关人员核对，极其浪费时间。）

 

2、关于案例的编写

   需求确定下来后，测试负责人进行测试计划的编写。由于有前期对项目的宏观了解，此过程可较顺利的完成。在测试计划的编写过程中，将项目进行相应的模块划分，抽取出各模块的测试点（测试点可按重要性再进行一次划分，重要的测试点尽量写得详细一些）。测试计划完成后，请需求、开发人员、项目负责人进行一次评审，告诉大家，这个项目，测试这边看到的是这样个样子，我们将进行哪些测试。每个功能点，我们会关注哪些问题，等等。如果大家都认可此方案的话，再根据，此测试计划中的测试点进行相应案例的编写（如果测试计划中，测试点分得较细的话，测试案例会叫好编写）。如果大家觉得有漏掉点，需要询问具体漏掉点，进行相应补充。----------此过程可以和开发并行。

 

3、测试

   开发提交开发成功到测试这边，测试人员可按测试测试点的重要性进行分层次的测试：先进行流程上的测试，保证流程上没有问题，这样也类似于冒烟测试，系统能跑起来。然后进行相关功能上的测试，再进行界面层面、用户体验层面的测试。这样，测试出来的bug也是分层次的，先找出来的是影响系统流程的bug，然后是功能上的，最后是界面层面、用户体验层面bug。开发看到的是严重级别的bug逐渐减少，对后期的用户体验层面的bug就不会有太大的心理抵触情绪，觉得你测试只会找一些提示语上的错误了。（一般情况下：测试初期，开发对bug的接受心理是较强一些的。）

 

补充一点：关于测试版本的控制，在项目测试的过程中，开发环境与测试环境一定要区分开来，每一个版本测试完毕，再更新新的版本。