如何在产品研发中控制质量

   本文主要阐述软件产品的研发的质量把控策略，如何规避软件产品的质量风险。产品质量需要在产品生命周期中的各个环节进行控制，各个环节的疏忽都可能导致最终产品的质量风险，每个节点都环环相扣，笔者通过十年的IT从业经验，将产品生命周期中的七大环节的质量把控策略进行分析，本文仅为个人经验积累，肯定有纰漏不足之处，有待进一步学习、优化。

        产品生命周期七大环节分别为：需求分析 → 业务设计 → 技术设计 → 编码实现 → 测试检验 → 实施部署 → 运维监控。

一、【需求分析】是产品研发实施阶段的“源头”，错误的需求分析会导致产品的失败，偏差的需求分析会导致产品的预算、工期超支。获取真实的需求有如下几个关键点： 

 

1.  

       “准备”  就如当学生上课前要预习功课一样做好准备，将要调研的内容提前列好，提前学习专研行业的术语、业务。有准备的沟通，能让对方感受到你的诚意，愿意跟你沟通，表达想法；有针对性地提前学习，能让双方的沟通在同一个专业水平层次上，互相沟通更顺畅。

           然后是沟通的对象，要找出用户方的关键干系人，一般关键干系人分为领导层和执行层，领导层决定了软件产品的定位及方向，项目背景是什么，为什么要做这个产品。执行层是实际的产品用户，这层面的用户更关注产品的业务流程是否合理闭环，交互体验，操作便捷。

          沟通调研的顺序要根据实际情况而定，如果跟领导层有过合作，比较熟悉，可以“以点带面”先跟领导层沟通，大方向把握后再跟执行层用户细化需求。如果对领导层的意图把控信心不足，可以先跟执行层用户做个摸底调研，心里有底后，再跟领导层沟通，以农村包围城市的方式。

2.  

       “沟通”  调研跟记者采访、访谈节目一样，需求调研的人员就是记者、主持人，要能挖掘用户的需求，引导用户提出他的需求。直接问用户你有什么需求，你需要什么功能，是需求调研的大忌，而是要提出你的方案，让用户去选择改进。比较常用的方法是绘制流程图、原型，把产品的流程、交互形象地图形化出来，让用户很有针对性地去提需求。

3.  

       “确认”  每个人的生成环境、知识水平不一样，你理解到的可能跟用户表达的意思是有出入的，站在客户的角度理解客户需求的描述，无论你觉得客户要求是否合理，都应当跟客户复述你的理解，判读你的理解是否跟客户所想的一致。

4.  

       “分析”  收集到用户的想法信息后，就需要进行分析，鉴别信息是属于“需求”还是“要求”，往往用户提的都是“要求”，我们要通过现象看本质，透过要求找出用户真正的内在需求。下面举一个简单的例子，说明需求和要求的区别：

           【要求】：有一个表单目前设计是仿报告模板(见下图)，让用户再上面填空，但客户觉得输入框太乱，要把布局进行调整，输入的文本框都集中起来，同时要求输入框加上提示。

           【分析】：对于客户的要求进行分析，把输入框集中起来，解决了输入框归集，但是原来仿造报告模板来做这个表单页面的效果就没了，仿报告模板的表单填写方式对于输入框的上下文非常清楚，不用那么多啰嗦的注释或者提示。

           【需求】：所以真正的用户需求，其实是“表单填写时，哪里是输入框需要填写，不够突出”，分析到最终的用户需求之后，就好办了，原来的布局不变，只要要一个底色，把输入框的白底凸显出来，用户使用时就直观了。改造前和改造后的表单编辑页效果如下：

    
   

二、【业务设计】有别于研发层面的技术设计，业务设计是对数据流、业务流的分析，进而对系统的整体逻辑有一个把控，只有逻辑清楚了，产品质量才能得到基本的保障。

 

1.  

       “信息化意义是什么”  在我目前的工作经历内，思考信息化根本目的是为了：规范和经验共享。 比如一个表单，可以用一段文字表达，不是更自由，为什么要分割成一个个输入框，实际是为了规范大家的填写内容，同时确定模板，大家填写时不用考虑要填写哪些字段，模板已经定好了。比如一个oa流程，之前线下签字，每个新人都要培训一次，先谁签字，然后谁签字，形成线上系统后，系统自动生成审批流。比如以前大家开车，记性好的方便，路盲就苦逼了，现在有导航，经验都可以共享了。

2.  

       “数据流”  数据是系统的灵魂，一个业务系统最底层，最核心的就是数据，一个业务系统能产生什么数据，这些数据之间又有什么联系，以及数据实体之间是如何进行流动，数据的源头是什么。可以使用E-R图也称实体-联系图来对数据进行表达，从而为后续的原型设计、技术设计打下基石。

3.  

       “业务流”  如果说数据是食材，业务就是菜谱。业务流将数据的操作，数据的变换进行集成，比如一条请假申请，先通过员工申请提交、再到主管审批、再到人力确认等。一系列业务流，把数据进行一步步加工出口。

4.  

       “原型设计”  有了数据流和业务流的基础，就可以进行具体用户交互界面的原型设计，类似造一个汽车前，先话一个设计图。软件产品开发也有设计图，就是原型设计，可以通过简单的画图工具，或者成熟的原型工具BalsamiqMockups、axure进行设计的快速实现，把交互的想法和软件的思路快速绘制出来，进行设计的落地并跟客户有效地交流确认。

   END

三、【技术设计】软件系统是连接需求、硬件以及使得系统实现的桥梁，好的软件的设计才能让业务顺畅的运行表达，好的软件设计才能让硬件得到合理的规划，技术设计是质量保障的重要一环。

 

1.  

       “可靠性原则”  软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。

          保障策略一：【低耦合高内聚】。讲应用进行业务拆分，拆分后的每个服务都是独立的，可单独维护和扩展，服务之间的调用通过接口约定进行通信。对比早期系统的设计都是单体架构，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本，存在的问题是一旦某个环节出现性能问题，整个应用跟着一起连累，更新某一个小功能，可能导致所有应用都被传染，一荣俱荣一损俱损。

          保障策略二：【不在一棵树上吊死】。主备机制，重要的环节要有双通道，运用分布式技术，对重要的服务进行多台负载均衡。对于重要的第三方服务，如短信服务，要申请至少两个不同厂家的接口，一旦某一个运营商由于网络攻击等原因停服，另外一个接口服务就可以提供应急服务。

          保障策略三：【事前诸葛亮】。系统运行过程中，都会产生各式各样的故障，报错，往往都是平台事故的前奏，如果能事前感知到系统的生命体征，就需要构建一个预警体系，给系统的重要接口、重要服务进行24小时定时自动检测，一旦出现服务不可用，第一时间通知处理。

          保障策略四：【保护现场痕迹】。理想情况下，每个用户操作都是可追溯的，每个数据记录变更都是可还原的。出现接口异常、用户操作报错、用户质疑平台数据时，日志库就会起到重大的作用，它默默地记录着系统操作的所有变更，为破案提供重要的线索。

   
2.  

       “安全性原则”  道路千万条 安全第一条。特别是涉及金钱交易的系统，安全尤为重要，要么都没事，一出事可能就是灾难性的。登录、用户信息等加密传输肯定是要的，sql注入等安全性检测也是必须的。

3.  

        “可测试性原则”  对于可测试性原则我个人没有太多的经验，也在学习中，引用《

   如何提升研发的可测试性架构设计

   》中的一句话https://cloud.tencent.com/developer/news/309024：测试是软件开发过程中很重要的一部分，会占用大量的时间和人力。如果想要高效的测试和获得高质量的软件产品，我们必须在软件项目的启动初期就开始关注软件质量。

   END

四、【编码实现】代码就像是高楼大厦的一砖一瓦，没有高质量的代码，可信的产品就是空中楼阁。 

 

1.  

         “健壮性”  对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。

           第一层判断：前端的输入的有效性控制，不能让非法的文字传入后端，比如报价金额填一个中文，最终可能导致统计报错。

           第二层判断：前端与后端的接口约定，接口对数据类型要有一个判断，后端对于前端传过来的数据进行鉴别，有异常的要进行抛出。

           第三层判断：数据库字段类型约束，对于关键的数值型字段，后续还会针对这个字段进行统计、计算、分析的。在数据库层面进行字段类型约束。

2.  

       “编码规范”  引用《任正非公开信：全面提升软件工程能力与实践，打造可信的高质量产品》https://news.cnblogs.com/n/616385/中第一句话：我们要优化并遵循公司各种编程规范，遵从架构与设计原则，熟练使用各种编程库和 API，编写出简洁、规范、可读性强、健壮安全的代码。

3.  

       “单元自测”  《信息系统项目管理师》教材中提到一个名称：质量成本，它包含：预防成本 → 鉴定成本 → 内部损失成本 → 外部损失成本。预防成本是最小的，随后的成本逐步增加，一旦发生外部损失成本，可能造成索赔、信誉等重大影响。

           预防成本包含：代码规范、培训、代码审核、自测等测试之前的阶段。

           鉴定成本包含：测试人员投入、测试环境投入、测试报告输出阶段。

           内部损失成本包含：测试之后的返工修改。

           外部损失成本包含：一旦预防和鉴定都没有修复存在问题，上线后事故造成的损失成本，包含人力的投入、补救措施的投入、索赔等。

           所以代码的质量不能完全依赖于测试来保障，自测是代码质量保障的第一道关卡，也是成本最低的一个环节。

   END

五、【测试检验】是产品上线前的最后一道关卡，是质量控制的底线。

 

1.  

        “提测范围”  如果是黑盒测试，测试不涉及研发代码，对于代码修改影响到的功能、接口，一般是通过UI交互操作进行检验。所以提测范围的约定尤为重要，研发人员修改需求后，影响到的流程、功能等内容一定要描述清楚。

2.  

        “测试要点”  测试人员针对提测范围，结合历史总结的测试功能要点总结，进行本地提测范围的测试规划，初步形成测试要点初稿。

3.  

        “测试评审”  测试要点初稿，要经过主要研发人员和测试组长进行评审，避免漏测试、理解错误情况。

4.  

        “测试报告”  针对产品测试bug形成总结报告，分析各产品质量，统计研发-测试投入比，从而推动开发团队加强自测，从源头上把控产品质量。

   END

六、【实施部署】线上系统的更新落地。

 

1.  

       “版本把控”  系统发布前和发布后的新旧版本文件都要进行备份，这个是实施的基本规范。发布目录一般会分为“实施目录”、“更新目录”、“备份目录”。

2.  

       “更新后验证”  根据以往的经验，实施人员更新后，经常会出现几种情况：配置文件漏了、配置文件改错地方、数据库漏更新、整个文件目录更新错了等情况，所以更新后的线上系统验证是非常必要的，可以防止低级的系统级别错误。

3.  

       “分布式部署”  网站服务分布式部署，多套实施目录同步更新，最好要借助自动化工具进行更新，避免遗漏，一旦分布式系统，有些节点更新了，有些节点没更新，可能造成严重的数据混乱和不可挽回的数据后果。曾经有一家上市公司，就由于更新部署问题，导致公司倒闭：《

   比删库还惨！45分钟搞垮一家上市公司，只因一次失败的部署？

   》https://mp.weixin.qq.com/s/NlcuW-5ahkE4dmjcUPv98g

   END

七、【运维监控】上线后的系统运维保障。

 

1.  

       “安全保障”  首先是服务器、数据库资源安全管理，

   近期的微盟“删库事件”就是超严重的事故。https://3g.163.com/news/article_cambrian/F6OUCNSS0519DTSV.html

2.  

       “巡检制度”  分人工和自动，类似域名过期时效、服务器资源过期时效、服务器磁盘空间、内存、cpu、网站是否可访问等都可以形成自动预警。人工操作就是一些数据库或者服务器的定期维护重启等。能形成程序自动预警的尽量做成程序自动预警。

3.  

       “性能分析”  对于服务器和数据库资源的监控巡检，上面以提到，这里讲的性能分析主要包括数据库性能分析和网站的性能分析。

         数据库性能分析，可以通过数据库的慢日志进行查询时间的排查，如果有使用阿里云数据库实例的话，阿里云的后台自带有慢日志的统计查询和索引推荐。

         网站的性能分析，可以通过网站记录的详细请求日志进行分析，针对请求用时比较长的数据进行判断，是否需要优化。

4.  

       “备份机制”  包括定期的数据库备份、服务器硬盘的快照，以及研发内部的源码备份等。要进行模拟演练，一旦发生重大病毒事件，或者硬盘坏道，如果能快速恢复保障业务化运行。

5.  

       “风险防控”  每月针对线上已发生的产品问题进行总结复盘，明确后续保障措施。同时分析排查隐患，明确下月质量保证实施计划。