今天就说说近期大家比较关心的话题，根据自己多年的测试经验，对于一个企业能否很好的生存下去，有四个核心指标，产品质量Q、服务质量S、产品价格P、响应时间T，在我看来，属于技术范畴的2个最核心的指标是：一是产品质量、二是响应时间，怎样更好的保障产品质量，为一线的销售保驾护航好产品，就显得尤为重要了；
下面我们就从一些方面探讨下如何更好的把控产品质量：
1、 产品需求设计的合理性，一个失败的产品设计上线后会经常性的变动需求，导致整个团队频繁的修改和测试，尤其是上线前还在修改产品逻辑的场景，相当的影响研发测试团队、继而影响产品质量，上线后产品设计与用户使用场景相悖、影响用户使用习惯等等，因此产品需求设计的合理性非常非常的重要，需要PM前期做很充分的需求调研，走在一线多与用户接触，深度了解用户最常用的场景、站在用户角度思考产品逻辑、解决用户痛点问题；
2、 技术架构设计、逻辑实现（设计）要合理，如果技术大的框架设计都存在很大的问题，即使后期再往上累加功能，都会显得摇摇欲坠，技术实现逻辑的设计合理性也相当的重要，我接触到很多公司的研发小伙伴为了赶时间只是不停的实现功能，不会过多的去考虑实现逻辑的合理性或效率、性能等，等到了线上或用户量达到某个量级时，就会爆发很严重的问题；
3、 开发编码规范，其实有些时候代码逻辑并没有那么复杂，但是bug却很多，很大的程度上都是由于代码不规范所致。比如说：对变量的定义的不规范、忘记对边界的处理，对输入输出参数的不规范，对异常处理的不规范，对日志处理的不规范等等，导致总是出现类似空指针、数组越界、崩溃这样低级的bug而且还很难找到引起bug的原因。相反，在特别规范的开发中，bug不但可以有效减少，查找bug也变得轻而易举。规范不是对开发的制约，而是更有助于提高开发效率的；规范的代码还可以降低维护成本、极大的提高团队对代码的可读性，而且还有助于代码review；
4、 需求评审，正确而有效的进行需求评审，不要流于形式，应提前将评审内容发给团队所有相关的小伙伴，提前查阅，记录好问题，带着问题去评审，效率更高、效果更好；
5、 测试流程的规范，流程是为了提高效率，跨团队协同更顺畅的目的来制定的，要根据自己公司的实际情况来制定；测试流程制定合理，可以有效的提高效率，避免pm、rd、qa来回扯皮、一起更好的把控产品质量，在GSX，我们有PC、APP测试流程，大致分为测试需求分析、case编写、case评审、接口测试、冒烟测试、test4轮测试、beta测试、monkey测试、提交testin进行兼容众测，线上环境回归测试、发布版本后安装卸载升级主流程测试；每个阶段都会有相应的成果物产出和管理，每一步的策略和侧重点都大不相同，这里不再展开细说；
6、 开发流程的规范，根据公司目前所处阶段制定，如果是多个研发同步在开发多个功能，代码需要分支开发，测试环境无bug后，再合并主干，提交代码时进行必要的review，sql上线一定要进行必要的review，避免一条sql引起全站瘫痪的问题；
7、 上线流程的规范，有很多公司研发的分支团队很多，对公共代码库的维护很乱，随意提交代码到主干，不小心就会引发较大的线上事故，也会给测试同学带来庞大的测试工作量，需要一轮一轮的多次测试，所以很有必要约定好一个规范的上线流程，要保证分支没问题的代码才能合并到主干，再做主干整体回归；
8、 优化功能测试的范围界定，有时候rd优化一个功能，qa在一个端测试没有问题，但是有可能会引发其他端的问题，比如支付功能，在app上测试ok，但在pc上就可能存在问题；再比如：有时候上线a功能，但是上线后b功能出现bug，底层服务端代码变动影响导致；再比如：上线一个功能对历史版本的影响，有些功能上线后需要兼容历史老版本（避免不升级的用户出现问题），我们也要对历史版本进行有效的测试，选择历史几个版本进行回归测试，要根据项目实际情况来定，所以科学准确的、恰到好处的选定测试范围也是一门很深的学问；每一次上线一定要对高频功能、核心功能、用户最关心的功能做最充分的回归测试；
9、 进行静态代码检查（Checkstyle、FindBugs、PMD、Jtest、php depend、PHPMD等）统计证明，在整个软件开发生命周期中，30%至70%的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的；做静态代码分析无需运行被测代码，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用、错误的变量定义等等。使用静态代码分析工具自动化执行代码检查和分析，能够极大地提高软件可靠性并节省软件开发和测试成本。
10、 接口测试、单元测试，一般情况下后端完成接口开发，就可以提前提测给QA小伙伴，开始服务端的接口测试，这样可以让隐含的Bug提前暴露出来，让开发人员在第一时间修复Bug，让功能测试人员在测试的时候更加顺手一些，最大限度得减少底层Bug的出现数量，让产品研发的流程更加顺畅，进而很大程度上缩短产品的研发周期，提高效率；
11、 UI走查，很多时候产品上了beta，或者上了线，才发现UI与设计不一致，所以UI的检查也显得非常的重要，更需要在关键的时间点就介入走查，最好在冒烟测试时就走查一遍，在test环境测试完毕走查一遍，确保不因后期修改bug带来的UI问题；
12、 bug的度量与预防，定期进行bug的分布分析，线上bug的分析，找到出现该bug真正的原因，bug频发的功能、场景，以及机型等；找出来一些预防避免的措施，可以提醒其他QA、RD的小伙伴，遇到这种情况可能会出现bug等；
13、 运维监控：运维层面也要做到非常完善的监控体系，分别从网络层、操作系统层、应用层、接口层、做到端口存活、进程存活、页面级别的监控，如果能做到行为级别的监控最好，包括后期根据业务发展进行扩容，参数调优等，都需要很小心翼翼，监控测试，通过这些方面的严格监控和操作，为产品保驾护航，并适应业务快速且稳定的发展；
14、 必要的复盘和总结，每次项目结束都要及时的进行复盘和总结，针对项目过程中出现的问题，及时的做出调整，避免团队小伙伴下次再犯同样的问题；
15、 沟通机制的建立，有很多时候，都是沟通不到位产生的bug，比如RD和PM的沟通不到位，实现的逻辑不是PM想要的，比如跨团队rd之间沟通不畅导致的bug（a研发团队修改了公共字段未通知到所有使用该字段的其他团队成员出现的bug），PM和QA沟通不到导致的问题（PM需求变更，直接找RD修改完后上线了，没有通知到QA出现的bug）等等等等，在实际做项目过程中，会遇到很多很多，所以我们尽量要保持畅通的沟通环境和方式，可以组织每天站会的形式，快速无边界沟通，做到信息同步，遇到问题及时沟通解决，提高效率；
16、 团队的稳定：无论是产品设计、研发，还是测试团队，人员的稳定因素也会非常影响产品质量，较稳定的团队，产品质量就非常好，人员经常调整的团队，产品质量就无法保障，新调整过来的人员，要对现有逻辑完全熟悉也是需要时间的，一般情况下是不会给员工非常充分的时间，了解清楚所有的细节再上手工作的，所以在做的时候就很难把影响范围考虑的非常全面，问题自然就会频出；
17、 人的培养：一切问题都是人的问题，对人的培养大致需要从这些方面，技术水平、做事方式（做事考虑的周全性）、沟通协作能力（涉及到协作的各端，友好高效沟通，及时同步信息，通报问题和进度），主动沟通意识（比如修改底层字段、考虑影响范围，主动通知用到该字段的所有人注意）、责任感（对自己负责的事情跟进到底，并及时反馈进度）、执行力（有再完美的想法和计划，如果执行不到位，一切为0）、学习力、有效的时间管理、积极乐观、乐于帮助他人、乐于分享、并且从不抱怨，可以将积极向上的一面，感染带动他人，做一个正能量的使者；通常在项目团队中，积极负责的人做的产品，质量问题就较少，因为他们对自己有较高的要求，追求极致；
以上影响产品质量的分析，无论从哪一方面，无论是需求缺陷、设计缺陷、软件程序bug，还是人的沟通问题，一定要尽早发现尽早提出，因为尽早暴露修复的代价是最小的；
愿每一次上线后都能从容和轻松，提前做足了充分的准备，享受上线后一切安好带来的愉悦；
如何有效的推动规范的流程，用什么样的策略和方法，可以找我私聊哈
（微信:clij2011）；
