下面是工作了两年以后的一些想法，自己只是一介职员，纯属YY。

　  TX的软件质量究竟怎样，看看bbs里的bug贴和315用户的投诉知道了，而我所在的互娱又是质量的重灾区。公司一直致力优化却始终恶名在外，到底是为什么？经过了两年的工作，我自己的观点来分析下：

　  首先，测试人员脱离项目组。XX业务系统??研发中心??下的测试组，各业务系统都是这样的架构。可能是因为早期的测试人员很少，也不专业，大都是一个人承担多个项目的测试工作，这样是一个不稳定且兼职的工作，因此专门成立出来一个小组。

　  测试人员独立于项目组，我认为这是现在影响公司整体测试质量的大原因。

　  将测试??原本应该是项目内部的工作搞成跨部门合作，将测试人员变为项目组的“外人”，从而无法和项目组保持良好深入的沟通。常常不能参加策划会议，没有代码查看的权限，没有和项目组固定的沟通渠道，需求和架构变更不通知……

　　在这样的情况下，测试人员的信息极度匮乏，测试的质量变得依赖于文档、PM的规划、测试接口人的沟通能力。

　　且测试人员在公司的地位很低，甚至低于运维。运营部至少是部门级别的，而测试组竟然只是研发中心下的一个组，这边100多人团队的总监，接近互娱大的team leader无法参与BU级的决策。总监如此，可况下属？

　　测试接口人完全处于“无授权领导”状态，这样的情况在组内还能勉强应付。但在这个处处讲级别的，对项目组沟通上显得极度缺乏话语权，无怪乎hanson直呼测试人员是公司地位低的工作。

　　其次，TX的测试专业素质很差。测试人员本身的二流，导致开发和管理层的不屑，测试的地位是这样决定的。因为看不懂代码，对软件开发知之甚少，测试对项目的了解常常于策划文档，设计的用例往往面大而粗糙，缺乏深度测试的能力。

　　而一些测试团队匪夷所思的宣称他们的bug漏测率只有1%，我真是感到好笑，在没有严格编码标准和代码审查，没有单元测试，没有集成测试，只依靠黑盒测试的情况下，版本质量可想而知。这样的成绩可能么？

　　我们都是做工程的，要脚踏实地。软件中任何一处的空指针引用或堆栈溢出都可能导致程序崩溃。微软在测试多于开发、单元测试覆盖达到70%的情况下，都有30%的漏测，何况TX这种级别的。

　　再次，项目伪敏捷。时下敏捷大行其道，TX内部亦是如此，但因为不重视质量，只依赖后的黑盒测试，任何项目都终变成了半敏捷/半瀑布的项目，严重影响了开发速度和产品质量。

　　后，压抑的氛围和较低的收入。在TX，开发、和美术的收入是相当高的、其次是产品，后才是运维和测试。基本上开发是测试的1.5~2倍。在这样的环境下，大家都只是把测试当作产品和其他部门的跳板，人心不稳，谈何上进？

　　说了这么多，其实我觉得要想改善质量，需要做的是尊重测试、善用测试、专业测试。

　　一、区分功能性测试和专项测试职位，各司其职。测试开发工程师，专司单元测试、协议测试。其实TX内部有这个职位，只是人数很少，现在要做的是加大这个职位的人数，提升待遇，以高水准的素质和技能、更好的待遇来招人，通过新建一支高素质的队伍来改善现在的人员能力。通过追求测试品质，打造超级团队来吸引更多的人才加盟，进行滚雪球式的发展。

　　对于，功能性测试的人员可以通过转化和学习来提升素质，学习一般的人继续执行功能性测试，少部分的人晋升为测试开发工程师。

　　二、在新的项目中设立测试经理，从产品架构的设计开始引入测试。测试经理只管代码级的测试，他不隶属于现在的测试组，而是直接隶属于PM。主要管理刚才说的新的测试开发团队。负责监督单元测试、引入代码审查、使开发过程更重视质量，测试的深度越高，产品质量和开发进度越可控，产品和PM可见度越高，项目更敏捷。

　　三、原有的功能性测试人员具备发布把关的能力，建立bug追究责任制。

　　一些粗浅只见，也算有感而发吧~