测试阶段的思考

        在迭代周期内编码内测完成后，通过测试人员给的冒烟测试用例后，可以转测给测试人员。测试人员通过手动和自动化测试，测试通过后进行交付。测试的目的不仅仅把控交付产品的质量，还要尽量协助开发人员解决问题。

        测试的主要流程。首先进行安装测试，测试人员按照开发给的安装部署手册，在测试环境中部署升级，从而测试安装升级过程中是否存在的问题。如果测试用例有自动化，那么先跑自动化测试用例，跑完后再手动测试没有覆盖到的功能。测试过程中发现了缺陷，如果是无法确定是缺陷的先找相关的程序员确认，如果不知道是谁负责的，那么找主管来确认。还有偶发性缺陷，很难复现的，保留现状立刻去找负责的程序员来定位问题。通过缺陷管理工具来提交缺陷，缺陷内容先是缺陷名称、操作环境、复现的操作步骤、产生的问题、期望的结果和解决建议，问题描述最好要有截图，复杂的用视频，一个缺陷单只能针对一个问题现象，不能描述多个问题。提交缺陷还是有许多辅助信息，缺陷所属功能模块、迭代的版本、缺陷严重级别、优先级等，缺陷严重级别和优先级一定要慎重，不要不经思考的把所有缺陷都定为严重和优先级高，会影响解决关键问题的效率。研发主管收到测试的缺陷单后，会转发给相关开发人员，开发人员会优先解决缺陷优先级高、问题严重的缺陷。开发对缺陷单有疑问时，会和对应测试人员详细沟通了解。开发人员解决完问题后，在缺陷单上面描述问题原因和解决方案，并附上自测正确结果的截图，然后提交完成，测试人员再进行回归测试，测试通过后就关单，如果不是，就得重新打开缺陷单。测试人员除了功能性测试外，还需要进行安全测试、性能测试、压力测试和可用性测试，安全测试和性能测试需要相关测试工具来辅助，可用性测试需要找一些和项目不相关的人员使用开发的应用系统，来观察和分析用户使用中的问题，作为后面待解决的任务。

        测试完成后，开发人员不可能解决所有缺陷，必然有所遗留。一般情况下，对严重级别以上或优先级高的缺陷必须解决，一般缺陷解决成本不是很高或复现的概率很低的都要解决，优先级低或缺陷是提示类型的尽量解决。要决定哪些缺陷要遗留，需要项目组开会，共同讨论决定。

        在测试和开发协作中，经常会发生一些矛盾。很多公司的研发用测试出的缺陷数量来衡量测试人员和开发人员的绩效，测试出的缺陷多那么测试人员的绩效好，而开发人员所负责的模块缺陷数量多则绩效差，目标产生了冲突，因此会让两者产生对立。测试人员希望尽量测出更多缺陷问题，而开发希望尽量少提缺陷单，因此经常对这个是不是缺陷，以及缺陷的严重级别和优先级产生冲突，从而协作上往往也就不好。我觉得不要用测试测出的缺陷数量作为测试人员的绩效，应该用交付后，用户使用中的问题作为对整个研发团队的绩效考量。发布后出现的缺陷的第一负责人是该功能对应的开发人员，其次是测试人员，这样两者的目标统一都是为了提高交付质量。测试人员就更关注发现并协助开发人员解决缺陷，同时开发人员也知道测试是协助研发来解决问题的，合作起来更加融洽。缺陷率仍然是开发人员的绩效的一个重要指标，不过一旦发布出去后，暴露的缺陷对绩效的影响是测试阶段发现的很多倍，如果测试人员能测出更多的问题，那么也就是协助开发人员更减少遗漏到发布后缺陷数。测试人员的绩效也是按发布后所暴露的缺陷情况来衡量的，这样也会促使测试人员积极地测试，同时对测试出缺陷的误差率也要衡量，避免测试人员经常提出一些不是问题的问题，浪费大家的时间。 

        项目质量不是测试保证的，它只是最后一层重要保障。项目交付的质量是需要从需求、架构设计、开发和测试共同保障的，只有高质量地做好每一步，才能交付出高质量的项目。