测试人员视角浅谈软件质量

        项目质量是靠项目组所有成员共同构建的，需求的不清晰是质量隐患，项目经理对项目进度的监控不到位是质量隐患，开发人员责任心不强只看需求表面不深挖业务逻辑是隐患，测试人员焦头烂额捋不清测试过程节点是隐患……。

        作为一名功能测试人员，最直接的感受是来自单元测试结果，如果单元测试的提交物不能满足需求描述，集成测试就变成了“单元测试+集成测试”，测试人员需要重新进行单元测试，并对单元测试中发现的bug进行回归测试，之后才能进行真正意义上的集成测试。实际情况中往往是测试人员集成测试已完成，但是仍存在严重的或影响业务逻辑的bug，在回归测试过程中有可能还会引发新的bug，最终开发疲于改bug还会抱怨这样的问题怎么早没发现呢，而测试已是疲于单元、集成、回归的循环中，对于探索性测试更是提不起兴趣（有些场景，可能在根据需求写测试用例的阶段想不到，而对系统实操后可能会有更多的测试场景出现在测试人员的脑海中）。

       个人拙见之测试过程应该明确划分界限。单元测试结束后，测试人员进行冒烟测试，先整体后局部，如果功能模块主体功能有缺失或走不通，则需果断以严重bug指派给开发，而不影响主体业务逻辑的页面样式及模块内部的普通bug可以遗留到集成测试阶段；集成测试结束后，需要将所有普通bug都解决并回归后才能进入到系统测试阶段，建议性或优先级最低的bug可遗留到系统测试阶段。测试各阶段的时间点严格把控，模糊不清的时间节点不利于软件质量。

       个人拙见之测试与开发。对于团队成员相对稳定的项目，建议测试人员创建一个开发人员与严重bug数量关系的列表，记录开发人员在测试各阶段中对应严重问题的数量。对于严重问题较多的开发人员的提交物需要重点关注，冒烟测试覆盖尽量多一些；对于严重问题不多，提交物能让测试人员做更多的探索性测试的开发人员，邮件发送表扬信至其主管领导。