常见的窘境：
这也许是大多数软件公司面临的一个老大难的问题，即送测的程序版本质量差——甚至会出现连冒烟测试都不能通过的情况——面对这样的版本，作为测试人员的我们，也常常陷入两难的境地：如果投入测试，会浪费大量的时间；如果不投入测试，项目的交付时间在那里卡着......所以这就让测试人员陷入一个两难抉择的窘境。
对这个问题，我说一下自己的看法。
我觉得如果想解决问题，首先得认清楚问题，掌握问题的本质。
拿这个问题来说，导致版本质量差的原因许多，比如开发没时间自测、不懂测试，又或者不重视质量，但归根究底总结起来，无法也就那么几大类：管理的问题、客观现状、人的问题等。下面针对这些原因，我一一进行阐释，也给出自己目前想到的应对措施，希望能成为抛砖之举，引出更多金玉良策。
一、人的问题：
（1）开发人员能力不足
一般来说开发人员的能力越强，开发出来的程序质量就越高。不过开发人员的能力也可以说是可遇而不可求的东西，难以在短时间内得到很大提升。我的看法是可以在项目启动前，针对有必要的技术、工具做好培训，同时在项目技术后做好项目总结和分享——为下次项目做准备。
（2）不够细心、细致
说话说“人无压力轻飘飘”， 针对这一点我觉得可以通过增加一些考核指标来进行应对，比如增加bug率的考核，通过制造压力的方式，让开发人员更加的小心、细致。
（3）不知道如何测试
确实存在一些开发人员不知道如何测试才能更好的交付高质量的送测版本，毕竟术业有专攻嘛。这一点上可以通过让小组搭配的方式进行交叉测试，或者进行code review进行适当的提升。同时测试人员可以在全公司范围内组织一些测试方法的培训（最好提供一些测试框架和模板），帮助开发人员提高自测水平。
（4）责任心不足
人都是有惰性的，在很多公司里也常常会有开发人员对测试人员有依赖心理，觉得版本开发完了随便测测（甚至不测）就扔给测试人员。应对这种情况，测试人员可以在冒烟测试/回归测试不通过后，把不通过的原因以邮件的形式发送给项目全员，抄送相关领导。人都是好面子的， 这样的做法可以让开发人员有意识的更认真的对待送测版本。
我很少遇到责任心特别差的开发， 如果真有，可以用数据“批斗”一下，实在不行，淘汰吧。
二、项目管理方面
（1）风险分析不足
我遇到过一些项目，版本在送测后bug频出，甚至开发改bug都改不完，更不用说去开发新的功能了，最终项目被迫中止，造成巨大损失。后来做项目总结的时候我才了解到这个项目采用了一个不太成熟的新技术。。。！ 这件事就是典型的风险分析工作做得不充分。特别是大型或者重要的项目，是不应该应用一些不成熟的新技术的（这岂不是拿这个项目做小白鼠么？）。 若有新技术出现，可以在小项目进行试点，等掌握了熟悉了再运用到大型项目中。
（2）bug预防工作做得不足
bug预防工作包括几大方面：制定开发规范、测试规范、总结常见缺陷并制定应对措施，制定产品测试框架并培训，开发人员质量意识灌输等。
（3）开发流程
敏捷开发中有种开发方式叫“测试驱动开发”，这种方式若能推行，倒是可以很好的提升送测版本的质量。
三、客观现状
（1）自测时间不足
我经历过的项目中，很少有哪个项目能留给开发留充足的时间做自测。 大多数情况都是开发草草自测，然后交给测试人员，然后导致双方花很多时间在bug的沟通和维护上。这个项目本身也会有大量的返工。如果给开发相对充足的时间进行自测，送测版本的质量会有不错的提升。
（2）开发不重视质量
现在不重视质量的人相对很少了吧？ 我遇到的开发人员，他们不是不重视质量，只是不知道自己的行为会对质量产生什么样的影响。
下表是对以上问题的总结，为了看起来更清晰，我将应对措施分成了事前和事后两类：
总结到这里，那作为测试人员我们能做什么呢？
- 测试流程中加入冒烟测试，收到送测版本以后安排一个人投入1小时对主要功能点一点看看是否有问题，若有问题把问题用邮件通知相关责任人并将版本驳回；
- 测试结束后，统计每个开发的bug率，并将该数据给到项目经理（视情况可以抄送更高层）
- 在版本测试中、结束后总结归纳版本问题，选择适当的时间给开发人员做一些培训分享。尽可能跟项目经理达成一致，推动bug预防的工作；
- 给开发人员宣贯bug修改成本，在公司层面做一些测试技术培训，让开发掌握一些测试手段和工具
- 自动化测试：送测前保证自动化测试脚本执行成功，或者推动测试驱动开发的开发模式。
- 在调研和分析阶段考虑风险（这不单是项目经理或者需求分析、设计人员的责任）；
当然，质量是全员原流程的事，后续再跟大家讨论作为项目经理和开发能做什么吧。
下面是我的微信号：
