主动地进行测试

    测试在软件开发流程中似乎处于下游，在执行和操作上看以处于被动地位。于是乎，很多时候，测试人员就会产生如下一些疑问(摘自某位网友的疑问，其实也是很多普通测试人员共有的疑问)：
    1、测试不知道自己在测试什么
    2、测试人员的依据不对
    3、测试人员是完全黑盒的，没有关注开发怎么实现
    4、测试人员没有充分测试
    5、测试人员完全被动

    结合我个人的一些实践，谈谈以上问题。
    首页，对1、2、3个问题，其实归结起来还是对需求分析的不透彻导致的。因为对需求分析不足，不知道当前版本开发人员做了哪些修改，所以也就无法在测试设计时，设计出很好的针对性用例来；同样因为对需求分析的不足，对客户不了解，对客户需要什么不了解，也就自然没有了测试依据！ 在软件能力成熟度模型(CMM)中，特别强调评审的工作，其实，测试人员需要参与到需求、设计的评审去中，这也是一个需求分析的过程。 当然，不否认现在很多企业，根本就还不存在这种过程规范，那么这就需要我们测试人员去推动它。推动开发提供需求、设计文档，推动参与到需求、设计文档的评审中去。
    在一些比较标准流程的软件企业中，测试其实也有专门的测试需求分析这一阶段的，这些工作由专门的TSE(相对于开发的SE来说,也都是一些技术牛人)来进行，充分说明了对这一块的重视。

    另外，对第4点，更多的应该是对系统、对业务使用的熟悉不够导致的。在居于测试已经确认的开发的修改范围后，测试用例的针对性和覆盖度，那么就在于你对系统结构的熟悉了，以及你对系统的业务应用场景的熟悉。就像经典的三角形的测试案例一样，因为你对三角形、等边、等腰的概念熟悉，那么很容易就设计了针对的用例,结合数字方面常见的错误，也就可以做出很好的覆盖来。

    对最后一点,我并不认同。主动与否，不是你的岗位决定，而是你个人决定的。如果企业在过程管理比较规范的话，那么规范应该不会让你被动的；如果没有规范的话，测试人员也可以主动起来。就像需求、设计文档，测试人员可以主动参与；另外，在版本参与上，也需要提前介入，而不应该等到版本转测试以后才匆忙介入， 这样就会导致在需求分析、开发实现特性、测试计划、测试设计等方面都被动。 测试人员也需要对项目全局掌控，特别是在需求变更上;再有一点，测试人员应该是站在用户角度上的(需求一端的)，是帮用户验证软件的。
    其实，对于一些流程操作不规范的企业，测试人员更应该本着软件质量保证的目的出发，去主动地推动相关过程的规范化。流程的规范不是一朝一夕的，需要不停地去总结和改进。