本文主要阐述软件产品的研发的质量把控策略，如何规避软件产品的质量风险。产品质量需要在产品生命周期中的各个环节进行控制，各个环节的疏忽都可能导致最终产品的质量风险，每个节点都环环相扣，笔者通过十年的IT从业经验，将产品生命周期中的七大环节的质量把控策略进行分析，本文仅为个人经验积累，肯定有纰漏不足之处，有待进一步学习、优化。
产品生命周期七大环节分别为：需求分析 → 业务设计 → 技术设计 → 编码实现 → 测试检验 → 实施部署 → 运维监控。
一、【需求分析】是产品研发实施阶段的“源头”，错误的需求分析会导致产品的失败，偏差的需求分析会导致产品的预算、工期超支。获取真实的需求有如下几个关键点：
-
“准备” 就如当学生上课前要预习功课一样做好准备，将要调研的内容提前列好，提前学习专研行业的术语、业务。有准备的沟通，能让对方感受到你的诚意，愿意跟你沟通，表达想法；有针对性地提前学习，能让双方的沟通在同一个专业水平层次上，互相沟通更顺畅。
然后是沟通的对象，要找出用户方的关键干系人，一般关键干系人分为领导层和执行层，领导层决定了软件产品的定位及方向，项目背景是什么，为什么要做这个产品。执行层是实际的产品用户，这层面的用户更关注产品的业务流程是否合理闭环，交互体验，操作便捷。
沟通调研的顺序要根据实际情况而定，如果跟领导层有过合作，比较熟悉，可以“以点带面”先跟领导层沟通，大方向把握后再跟执行层用户细化需求。如果对领导层的意图把控信心不足，可以先跟执行层用户做个摸底调研，心里有底后，再跟领导层沟通，以农村包围城市的方式。
-
“沟通” 调研跟记者采访、访谈节目一样，需求调研的人员就是记者、主持人，要能挖掘用户的需求，引导用户提出他的需求。直接问用户你有什么需求，你需要什么功能，是需求调研的大忌，而是要提出你的方案，让用户去选择改进。比较常用的方法是绘制流程图、原型，把产品的流程、交互形象地图形化出来，让用户很有针对性地去提需求。
-
“确认” 每个人的生成环境、知识水平不一样，你理解到的可能跟用户表达的意思是有出入的，站在客户的角度理解客户需求的描述，无论你觉得客户要求是否合理，都应当跟客户复述你的理解，判读你的理解是否跟客户所想的一致。
-
“分析” 收集到用户的想法信息后，就需要进行分析，鉴别信息是属于“需求”还是“要求”，往往用户提的都是“要求”，我们要通过现象看本质，透过要求找出用户真正的内在需求。下面举一个简单的例子，说明需求和要求的区别：
【要求】：有一个表单目前设计是仿报告模板(见下图)，让用户再上面填空，但客户觉得输入框太乱，要把布局进行调整，输入的文本框都集中起来，同时要求输入框加上提示。
【分析】：对于客户的要求进行分析，把输入框集中起来，解决了输入框归集，但是原来仿造报告模板来做这个表单页面的效果就没了，仿报告模板的表单填写方式对于输入框的上下文非常清楚，不用那么多啰嗦的注释或者提示。
【需求】：所以真正的用户需求，其实是“表单填写时，哪里是输入框需要填写，不够突出”，分析到最终的用户需求之后，就好办了，原来的布局不变，只要要一个底色，把输入框的白底凸显出来，用户使用时就直观了。改造前和改造后的表单编辑页效果如下：
二、【业务设计】有别于研发层面的技术设计，业务设计是对数据流、业务流的分析，进而对系统的整体逻辑有一个把控，只有逻辑清楚了，产品质量才能得到基本的保障。
-
“信息化意义是什么” 在我目前的工作经历内，思考信息化根本目的是为了：规范和经验共享。 比如一个表单，可以用一段文字表达，不是更自由，为什么要分割成一个个输入框，实际是为了规范大家的填写内容，同时确定模板，大家填写时不用考虑要填写哪些字段，模板已经定好了。比如一个oa流程，之前线下签字，每个新人都要培训一次，先谁签字，然后谁签字，形成线上系统后，系统自动生成审批流。比如以前大家开车，记性好的方便，路盲就苦逼了，现在有导航，经验都可以共享了。
-
“数据流” 数据是系统的灵魂，一个业务系统最底层，最核心的就是数据，一个业务系统能产生什么数据，这些数据之间又有什么联系，以及数据实体之间是如何进行流动，数据的源头是什么。可以使用E-R图也称实体-联系图来对数据进行表达，从而为后续的原型设计、技术设计打下基石。
-
“业务流” 如果说数据是食材，业务就是菜谱。业务流将数据的操作，数据的变换进行集成，比如一条请假申请，先通过员工申请提交、再到主管审批、再到人力确认等。一系列业务流，把数据进行一步步加工出口。
-
“原型设计” 有了数据流和业务流的基础，就可以进行具体用户交互界面的原型设计，类似造一个汽车前，先话一个设计图。软件产品开发也有设计图，就是原型设计，可以通过简单的画图工具，或者成熟的原型工具BalsamiqMockups、axure进行设计的快速实现，把交互的想法和软件的思路快速绘制出来，进行设计的落地并跟客户有效地交流确认。
END
三、【技术设计】软件系统是连接需求、硬件以及使得系统实现的桥梁，好的软件的设计才能让业务顺畅的运行表达，好的软件设计才能让硬件得到合理的规划，技术设计是质量保障的重要一环。
-
“可靠性原则” 软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。
保障策略一：【低耦合高内聚】。讲应用进行业务拆分，拆分后的每个服务都是独立的，可单独维护和扩展，服务之间的调用通过接口约定进行通信。对比早期系统的设计都是单体架构，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本，存在的问题是一旦某个环节出现性能问题，整个应用跟着一起连累，更新某一个小功能，可能导致所有应用都被传染，一荣俱荣一损俱损。
保障策略二：【不在一棵树上吊死】。主备机制，重要的环节要有双通道，运用分布式技术，对重要的服务进行多台负载均衡。对于重要的第三方服务，如短信服务，要申请至少两个不同厂家的接口，一旦某一个运营商由于网络攻击等原因停服，另外一个接口服务就可以提供应急服务。
保障策略三：【事前诸葛亮】。系统运行过程中，都会产生各式各样的故障，报错，往往都是平台事故的前奏，如果能事前感知到系统的生命体征，就需要构建一个预警体系，给系统的重要接口、重要服务进行24小时定时自动检测，一旦出现服务不可用，第一时间通知处理。
保障策略四：【保护现场痕迹】。理想情况下，每个用户操作都是可追溯的，每个数据记录变更都是可还原的。出现接口异常、用户操作报错、用户质疑平台数据时，日志库就会起到重大的作用，它默默地记录着系统操作的所有变更，为破案提供重要的线索。
-
“安全性原则” 道路千万条 安全第一条。特别是涉及金钱交易的系统，安全尤为重要，要么都没事，一出事可能就是灾难性的。登录、用户信息等加密传输肯定是要的，sql注入等安全性检测也是必须的。
-
“可测试性原则” 对于可测试性原则我个人没有太多的经验，也在学习中，引用《
如何提升研发的可测试性架构设计
》中的一句话https://cloud.tencent.com/developer/news/309024：测试是软件开发过程中很重要的一部分，会占用大量的时间和人力。如果想要高效的测试和获得高质量的软件产品，我们必须在软件项目的启动初期就开始关注软件质量。
END
四、【编码实现】代码就像是高楼大厦的一砖一瓦，没有高质量的代码，可信的产品就是空中楼阁。
-
“健壮性” 对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。
第一层判断：前端的输入的有效性控制，不能让非法的文字传入后端，比如报价金额填一个中文，最终可能导致统计报错。
第二层判断：前端与后端的接口约定，接口对数据类型要有一个判断，后端对于前端传过来的数据进行鉴别，有异常的要进行抛出。
第三层判断：数据库字段类型约束，对于关键的数值型字段，后续还会针对这个字段进行统计、计算、分析的。在数据库层面进行字段类型约束。
-
“编码规范” 引用《任正非公开信：全面提升软件工程能力与实践，打造可信的高质量产品》https://news.cnblogs.com/n/616385/中第一句话：我们要优化并遵循公司各种编程规范，遵从架构与设计原则，熟练使用各种编程库和 API，编写出简洁、规范、可读性强、健壮安全的代码。
-
“单元自测” 《信息系统项目管理师》教材中提到一个名称：质量成本，它包含：预防成本 → 鉴定成本 → 内部损失成本 → 外部损失成本。预防成本是最小的，随后的成本逐步增加，一旦发生外部损失成本，可能造成索赔、信誉等重大影响。
预防成本包含：代码规范、培训、代码审核、自测等测试之前的阶段。
鉴定成本包含：测试人员投入、测试环境投入、测试报告输出阶段。
内部损失成本包含：测试之后的返工修改。
外部损失成本包含：一旦预防和鉴定都没有修复存在问题，上线后事故造成的损失成本，包含人力的投入、补救措施的投入、索赔等。
所以代码的质量不能完全依赖于测试来保障，自测是代码质量保障的第一道关卡，也是成本最低的一个环节。
END
五、【测试检验】是产品上线前的最后一道关卡，是质量控制的底线。
-
“提测范围” 如果是黑盒测试，测试不涉及研发代码，对于代码修改影响到的功能、接口，一般是通过UI交互操作进行检验。所以提测范围的约定尤为重要，研发人员修改需求后，影响到的流程、功能等内容一定要描述清楚。
-
“测试要点” 测试人员针对提测范围，结合历史总结的测试功能要点总结，进行本地提测范围的测试规划，初步形成测试要点初稿。
-
“测试评审” 测试要点初稿，要经过主要研发人员和测试组长进行评审，避免漏测试、理解错误情况。
-
“测试报告” 针对产品测试bug形成总结报告，分析各产品质量，统计研发-测试投入比，从而推动开发团队加强自测，从源头上把控产品质量。
END
六、【实施部署】线上系统的更新落地。
-
“版本把控” 系统发布前和发布后的新旧版本文件都要进行备份，这个是实施的基本规范。发布目录一般会分为“实施目录”、“更新目录”、“备份目录”。
-
“更新后验证” 根据以往的经验，实施人员更新后，经常会出现几种情况：配置文件漏了、配置文件改错地方、数据库漏更新、整个文件目录更新错了等情况，所以更新后的线上系统验证是非常必要的，可以防止低级的系统级别错误。
-
“分布式部署” 网站服务分布式部署，多套实施目录同步更新，最好要借助自动化工具进行更新，避免遗漏，一旦分布式系统，有些节点更新了，有些节点没更新，可能造成严重的数据混乱和不可挽回的数据后果。曾经有一家上市公司，就由于更新部署问题，导致公司倒闭：《
比删库还惨！45分钟搞垮一家上市公司，只因一次失败的部署？
》https://mp.weixin.qq.com/s/NlcuW-5ahkE4dmjcUPv98g
END
七、【运维监控】上线后的系统运维保障。
-
“安全保障” 首先是服务器、数据库资源安全管理，
近期的微盟“删库事件”就是超严重的事故。https://3g.163.com/news/article_cambrian/F6OUCNSS0519DTSV.html
-
“巡检制度” 分人工和自动，类似域名过期时效、服务器资源过期时效、服务器磁盘空间、内存、cpu、网站是否可访问等都可以形成自动预警。人工操作就是一些数据库或者服务器的定期维护重启等。能形成程序自动预警的尽量做成程序自动预警。
-
“性能分析” 对于服务器和数据库资源的监控巡检，上面以提到，这里讲的性能分析主要包括数据库性能分析和网站的性能分析。
数据库性能分析，可以通过数据库的慢日志进行查询时间的排查，如果有使用阿里云数据库实例的话，阿里云的后台自带有慢日志的统计查询和索引推荐。
网站的性能分析，可以通过网站记录的详细请求日志进行分析，针对请求用时比较长的数据进行判断，是否需要优化。
-
“备份机制” 包括定期的数据库备份、服务器硬盘的快照，以及研发内部的源码备份等。要进行模拟演练，一旦发生重大病毒事件，或者硬盘坏道，如果能快速恢复保障业务化运行。
-
“风险防控” 每月针对线上已发生的产品问题进行总结复盘，明确后续保障措施。同时分析排查隐患，明确下月质量保证实施计划。