定制开发软件如何保证质量

• 定制开发软件如何保证质量？有没有标准的质量保障体系。

定制软件开发的质量保障是一个较为复杂的过程，需要从多个方面进行确保。以下是一些常用的方法：

1. 软件开发生命周期管理：采用软件工程领域的常用方法，明确需求、设计、开发、测试、验收等各个阶段，并设立相应的审核、测试和验收机制。

2. 规范开发流程：在每个阶段中按照标准化的流程进行操作，以确保代码的正确性和健壮性，并记录开发过程中的问题及其解决方案。

3. 单元测试和集成测试：通过单元测试和集成测试对软件进行多轮测试，从而能够识别出潜在的问题并及时解决，提高软件的可靠性和稳定性。

4. 强制代码检查：遵循代码规范和标准，使用合适的工具，强制要求代码质量检查和统计分析。

5. 客户反馈和不断改进：与客户充分沟通，及时了解客户需求和客户的看法，进行有效的反馈和处理。

下面就以重庆诺怀软件开发公司为例为大家讲解一下如何做软件开发的质量体系，接下来会介绍诺怀的质量保证体系以及诺怀是如何确保这些措施执行的。

诺怀有着重视质量的企业文化，诺怀软件认为质量保证不仅仅是测试阶段的工作，而是在项目的整个生命周期中内建的，每个环节都做好质量保证措施，最终质量才能得到保障。

因此从公司层面的组织架构、项目管理方法、测试管理方法等各个方面，都为质量保证提供支持。

• 重视质量的企业文化

诺怀除了传统的项目团队外，还配置了PMO项目管理办公室和质量圈，为质量保证提供监管。从公司层面重视质量保证，推进各项质保措施，确保措施得到有效执行。

1. 质量圈

诺怀特别重视质量，因为诺怀坚信，即使是按时或者提前提交了产出物，但是如果质量有问题，也不算按时提交。

在项目进行中，质量圈会每周评估项目质量是属于绿星、黄星、橙星还是红星等级，如果是质量糟糕的等级，必须把问题纠正后再继续，防止越来越偏离最初的目标。

举例：把软件开发比作流水线，如果到了流水线末端再去发现问题和纠正问题就偏晚了。我们的QA就是去检查流水线是否正常，把问题扼杀在摇篮里。

1. PMO

为了提高整体管理水平和协调资源，更好的为客户服务，诺怀专门增设了项目管理办公室（PMO）。项目管理办公室是独立于各个项目组的监管部门，从项目启动、计划、执行、监控、收尾各个阶段进行协助和检查，及时排查问题。

1. 企业知识库

诺怀经过10余年的软件开发经验，积累了完善的知识体系和技术框架，这些内容都记录在公司的Conflunce知识库中，供所有团队查阅，减少走不必要的弯路。各个项目组也会建立自己的项目知识库，作为项目的统一工作平台。

以下是部分内容截图：

• 项目管理体系

诺怀的项目管理有一套完整的项目管理体系，从项目范围、质量、时间、成本、风险、沟通、采购、人力资源、干系人以及整体，全方面保证项目顺利平稳开展。

除了传统的项目管理知识外，诺怀还吸收、灵活运用了敏捷和精益的思想，裁剪为适合诺怀和客户的项目管理体系。

以下简单介绍项目的流程。

1. 需求阶段

需求澄清确认（原型）

诺怀会根据客户需求，绘制原型和书写需求说明书，需求澄清和确认是非常重要的环节，这个环节确认清楚可以减少很多后期不必要的返工，不仅为客户节约预算，对质量稳定也是大有裨益。如果需要UI设计，在需求确认后就会安排UI设计。

 

任务排期

根据项目组的排序规则对项目需求进行排序；确定要做的需求，并且需求已经澄清后，就转到开发流程中，放到项目的sprint backlog中。

通常关键路径的任务以及有风险需要调研的任务，会优先安排处理，降低项目风险。

需求变更管理

项目中的变更，遵循变更控制流程，对每次变更都进行评估，确认要做的变更，则会更新需求和分发到位，确保其影响范围被充分考虑。

1. 开发阶段

1. 开发团队：开发团队的成员坐在一起集中办公，方便高效的面对面沟通；诺怀十分强调及时沟通。
2. 挑选任务：项目团队从 sprint backlog中挑选任务，规划到sprint中；下图是诺怀的Sprint Backlog示例；（诺怀的任务管理工具主要为jira）
3. 

1. 规划Sprint：Sprint持续时间通常为2-4周，在诺怀，我们通常选择2周的sprint；
2. SCRUM Kanban（Kanban）：通过看板，可以看到Sprint的总体情况。下图是我们一个正在进行中的Sprint示例。

• 

1. 任务评估标准：在诺怀，任务是以理想人时为标准进行评估的；（也可以选择story point）
2. 开发与测试并行：在诺怀，非常强调开发人员的自测，并且测试人员的工作与开发共同进行，这样可以尽早发现问题并改正，避免同样的问题反复出现，提高项目质量；
3. 每日站会：每天团队一起总结每天做得好的，做得不好的部分，并提出改进建议；（这个会议不谈论具体的任务）；
4. 日报、周报：如果客户需要了解项目进展，通常可以直接看jira看板，也可以要求团队发送日报周报；诺怀也将日报和周报视为督促项目团队持续改进的一个工具。

1. 开发流程

一个开发任务通常是从 场景（Scenario） 和 质量服务（Requirement of Quality） 中派生出来的，包括给系统增加新的功能、修改Bug、系统性能的改进等内容，目前公司的开发任务通常是以新的功能（feature），Specification（or functionality list），Bug，重构等形式出现的。一旦一个开发工作完成了，就意味着它已经通过了单元测试，代码检查，系统整合，并且被嵌入到代码库中，可以交付给最终用户使用；

诺怀开发人员完成一个开发任务的实践，必须包括以下活动：

1） 熟悉需求评估任务；

开发人员接到任务时，首先要对任务本身的含义和范围有清晰的理解和认识；在这种理解和认识的基础上，要做出工作量评估，承诺需要多久能完成这个任务，完成的任务应该要达到什么样的质量标准；通常情况下，这个评估都会成为我们向客户报价和承诺的依据，所以项目经理也要对此进行审核和沟通；值得注意的是，对需求的理解如果有不清楚的地方，一定要事先得到澄清，一定要尽量弄清楚客户的质量标准在什么level上，这些都对工作量有很大影响；

2） 创建自测Checklist - 功能自测列表；

借鉴测试驱动开发（TDD）的最佳实践，开发人员在实现具体功能之前，先要罗列出如何检验这个功能是否正确的Check Points，其中也可以包括界面和性能方面的检查，具体内容要视该项目在这些方面的要求而定；当然，这个check list也可以是该功能的一个use case；

3） 创建或者更新单元测试；

单元测试是我们每个项目都要求努力执行的实践，尤其是在没有测试人员的团队；开发人员在开始编码之前，要添加单元测试，具体做法是：设计一个单元测试，编写该单元测试的代码，验证该单元测试的有效性；

4） 编写该开发任务相关的代码 --- Coding;

开发人员在对任务有了足够的理解，做出了时间的评估，制定了自测checklist，创建或更新了针对这个任务的单元测试；这些条件都满足的情况下，可以开始编写对应的代码了；请注意，编码只是完成一个开发任务的其中一个步骤，而不是全部；

5） 对已经完成的编码部分，进行单元测试；

开发人员编写完代码以后，应该去执行前面创建的单元测试；确保编写的每个单元都能通过单元测试；对单元测试的覆盖率越高，就越能保证系统的质量。

6） 进行代码重构工作；

至此，可以说要实现的功能已经编码实现了，但是还不能说实现X功能这个任务已经完成，因为对Job Done的定义，不仅仅是编码完成，重构也是Job Done其中必不可少的一部分；开发人员在此时应该审视刚完成的编码工作对系统架构、现存代码、系统维护性等方面的影响，识别出导致系统复杂性增加的代码，然后选择合适的重构方法进行重构，注意重构后还需要更新单元测试并且执行；重构是维持代码可维护性的必不可少工作，只需要花一点点时间就会得到长远的收益；通常的重构工作包括：拆分超长的类、消除重复代码etc.

7） 进行代码分析；

代码分析是开发人员自己对新近编写的代码进行检查的活动，完成了以上所有工作时，开发人员还不能完全脱离代码，要自己Review所有被改动的代码；自己检查这些代码是否符合相关的开发规范，命名规则是否遵守，类库的设计，本土化等是否进行正确处理，安全性和性能等问题是否达到系统总体要求。请记住以下事实：80%的Bug都可以通过自我检查代码被发现；在后期发现Bug、修复Bug的代价，相对前期成指数倍增长；

公司大力提倡 代码检查 的最佳实践，对所有项目的代码都会进行抽查。

开发人员必须使用Code Analysis进行代码自动检查，公司为此设定了代码检查的最小规则集。

8） 自测

如果前面七个步骤都通过了，基本上意味着代码相关的工作已经完成了；但是此时并不意味着整个任务就完成了，因为在提交之前，还有一项非常重要的工作，就是开发人员自测。自测的重要性是怎么强调都不为过的；诺怀软件要求所有的开发人员在Check in代码之前，都要进行细心的自测；自测的主要参考依据就是进行编码之前（如上步骤2）设计的Check list或者use case；开发人员必须确保这个任务所有被要求的层面都得到满足，包括性能，UI方面的要求。

记住：在没有专门测试人员的团队中，系统的功能性测试几乎100%依赖于开发人员的自测保证，若这点做得不到位，就意味着提交给客户的程序漏洞百出，这很可能会让你丢掉这个客户。

9） 进行代码整合 --- Check in & Merge；

代码整合的时机是在完成一个编码工作之后或者修改完一个Bug之时，Check in相当于提交这个开发任务，向其它人宣布以上所有步骤都通过了；

具体步骤为：首先要从代码库中获取最新代码，跟本地代码进行合并并且解决冲突，要确保合并后的代码可以完整编译成功；要执行所有的单元测试，确保他们都能通过；（最好还能运行下，确保程序正常工作）；然后才Check in到代码库中。

提交之后，相关代码和功能就处于等待客户验收状态；

10）标记编码完成

若开发人员对某一个任务完成了上面所有的步骤，就意味着这个任务在开发人员眼里，已经是Done状态了，此时需要通知项目经理或者相关人员Job Done，可以让他们开始进行后续的工作。大多数项目中，都会由项目经理和测试人员检查这个任务的完成是否满足要求，是否从项目的角度来说，能真正的认为Done了。

进行代码检查（验收代码，通常是架构师进行）

代码检查的目的是发现代码中潜在的问题并解决；通常包括如下几个步骤：验证命名的正确性，验证代码之间的关联性，验证代码的可扩展性，验证代码复杂性，验证算法是否最优，检查代码中潜藏的安全性问题等等；检查的焦点应当在于编译和代码分析时无法发现的问题，比如性能，代码可读性，对系统架构的遵循等；

Git是用于管理多人开发的成熟工具，目前诺怀所有项目均成功切换到git管理。

使用Git的审核功能啊，只有被审核人审核过后的代码才能提交带代码库，降低风险。

相关原则

1） Coding Completed != Task Done, Coding只是Task的其中一部分，真正的Task Done意味着功能几乎可以发布，可以被客户验收；

2） 每一行代码都要经过检查，By yourself或者Architect，80%的Bug可以在自我检查时被发现并避免，而此时解决Bug是所用时间最短，成本最低的；

3） 重构是日常工作的一部分，每天都应该重构；

1. 编码规范和检查

开发人员除了要遵守开发流程以外，在编码时，还必须遵守一定的编码规范和数据库开发规范：如果客户有自己的代码规范要求，那么则应该仔细阅读和学习，并且严格遵照客户的代码规范要求进行编码。如果客户没有自己的规范要求，那么就应当遵守公司的"编码规范"、 "数据库开发规范"和"软件开发界面规范"，每位新入职的开发人员，都应该仔细学习这几个规范。

代码规范检查，应该利用代码检查工具，必须遵循如下规则：

• 所有项目，所有开发人员，都必须使用Code Analysis来进行代码规范的自动化检查；
• 所有项目，所有开发人员，对于公司推荐规则中提到的55条代码检查规则，都必须全部应用；这55条规则是公司从所有几百条规则中筛选出来的，最最基本的规则，相当于代码规范的底线，所以大家必须掌握；
• 所有新写的代码，必须满足这55条规则的要求，遗留代码的规范问题，参考下方规则；
• 对于规则检查出来的遗留代码中的问题，首先要跟客户沟通，之后，要么解决掉，要么经客户同意，暂时在工程文件中增加忽略条款。但是不能修改规则文件；
• 项目经理有权在这55条规则的基础上，继续添加项目组内部的规则，一旦作为规范，具有同等效力；
• 公司将对个人或者项目组进行抽查，若被发现代码不满足规范要求，又不能拿出跟客户协商一致的忽略证据，将按严重程度进行处罚；轻则罚款，重则降级；
• 在Check-in代码时，必须添加有意义的Comments；
• "Check-in之前，首先要从代码库中获取最新代码，跟本地代码进行合并并且解决冲突，要确保合并后的代码可以完整编译成功才check in"；

1. 提交阶段：

1. 增量交付

迭代时间到了之后，当前迭代结束，交付迭代产出。这样可以确保团队一直在做最重要的事情，持续不断的为客户交付价值。而不是等到项目结束了，客户才发现不是自己想要的东西。

1. 验收确认

迭代完成后，团队会给Product Owner演示迭代做了些什么，看看是否有差异。比如诺怀的云物管项目，我们每个迭代会给老板和市场人员演示，看看做得内容是否与计划一致，如果有偏差，则可以快速的调整。

1. 迭代回顾会

每个迭代完成后，团队会组织起来开迭代回顾会，重点是为了找到做得好的部分继续坚持，积累最佳实践，改进做得不好的部分。

诺怀特别强调持续改进的力量，因此，回顾会中提出的改进建议，要求是符合SMART（明确、可衡量、可实现的、相关的、有时间限制）原则，并且会不断去跟踪执行情况。

如果只是得出结论而不去执行也失去了回顾的价值。

• 测试和QA

诺怀对测试人员的要求非常高，他们不仅要执行测试工作，还兼任“纪委”工作，配合PMO和质量圈监督项目团队的流程规范。

1. 总体原则

项目的质量需要把“符合要求”（产出预定的结果）和“好用”结合起来，达到让客户满意的目标。

符合要求：承诺做什么，做出来就是什么，不偷工减料。

好用：包含了“能用”，“有用”的意思。

• 产品能正常运行，不出错；
• 产品功能满足客户需要，能解决实际问题；
• 容易学习，不用客户费心思考；
• 方便快捷，提升工作效率；
• 美观精致，赏心悦目；

1. 明确不同岗位的质量责任

1）项目经理

• 质量意识

1. 项目经理重视质量，团队才有可能提交质量高的产出物；
2. 设置团队代码规范，检查执行情况，并且安排代码检查；
3. 对团队成员的质量，奖惩分明；
4. 遇到问题及时“拉灯”，不欠新账，还清旧账；
5. 控制半成品
6. 尽早让测试人员加入项目组中，提前预防问题，及时验收，减少半成品；
7. 确保迭代划分合理，每次提交都有可使用的成品；
8. 如果进度确实很紧，可协商增量提交，保证逐步提交经过验收的、可用的成品，而不是半成品；

• 提高质量成本投入

1. 多花时间在前期需求分析，输出原型和确切的需求，而不是在做的过程中再确认，这样可以在源头上避免问题，提高一次性做对的概率。
2. 强调开发阶段的自测，避免明显的Bug流入测试阶段；（Bug越早发现，修改成本越低）

• 客户满意度

1. 除了努力完成功能清单中的功能外，还需要思考我们工作对客户产生的价值，不仅强调“符合要求”，还要强调“好用”；
2. 已知的问题，一定要提前告诉客户，而不是等客户测出来了再说，这样会浪费客户时间，引起客户不满；
3. 每个发布给客户的版本，一定要经过内部验收，不能把客户当做测试人员；

2）测试人员

• 对质量的坚持

1. 对于质量差的版本，可拒绝测试，责令整改后再提交测试；
2. 确保每一个发布给客户的版本，都严格把关，即使有问题，也已经罗列出已知问题，告知客户；

• 对过程的监控

通过QA清单等工具，监控项目过程，推动从根本解决问题以及预防问题，有问题及时“拉灯”：

1. 如果项目一直没有提交可测试的产出物，说明半成品堆积，需要“拉灯”；
2. 提交的功能相对功能清单，有很多遗漏，需要“拉灯”；
3. 如果项目总是很多低级的Bug，说明管理流程出问题了，需要“拉灯”；
4. 如果遇到无法推动的问题，需及时抛出，“拉灯”；

3）开发人员

• 认识误区

因为时间很紧，匆忙提交未经自测的半成品，以为这样是按时完成了任务，但实际是不负责任的态度，后期的返工成本非常大。

如果任务时间不够，可以申请投入更多的时间来保证质量（及时沟通）；

• 问题到我为止

1. 拿到任务，首先判断任务是否明确，不明确的任务，做的过程中极可能导致返工，应申请推迟处理（及时沟通）；
2. 开始编码之前，应该先熟悉、分解需求，理清思路，而不是做一步看一步；（不理解的一定要及时沟通）
3. 编码完成后，必须自测，把自己力所能及可发现的Bug及时的解决，而不是等着测试反馈；
4. 修改Bug时，写明Bug产生的原因，避免自己再犯类似错误，还能对测试人员有所帮助。

1. 测试流程

诺怀的项目中测试流程通常如下，这些工作会与开发工作并行，融入到迭代的计划中。

确保尽早的参与，尽早验收，预防问题出现胜于找到bug改正。

1. Bug规范和bug处理流程

关于提交Bug的质量问题，测试人员提交的Bug必须满足以下质量要求

• 必须准确地区分Bug的Priority（优先级）

---报告出来的Bug在Description中必须能清楚准确地描述问题；

---标准是客户和开发人员能看懂、不会产生歧义和误解；

• 报告出来的Bug必须可以重现，如有必要，重现步骤要写在 Steps to reproduce这一栏里面；如果不能重现，请及时找开发人员沟通；
• 必须要准确地定位Bug，要求Summary中的描述直接指向问题所在处；
• 关于Severity至少要明确区分feature、minor、crash这三者：
• 关于Attached files，尽量附上截图或者录屏；
• 报告Bug时应尽量把相关联的地方一次性全部报告出来，一个现象在两个不同的模块中都有，就应当报告为一个Bug；
• 新旧Bug之间有关系的，关联最好加上;
• 验证已解决的Bug时，须确保在指派给客户前，该Bug已经被彻底解决，经过测试人员验证的Bug被客户打回来，就是测试人员的责任；被测试人员打回给开发人员的Bug，测试人员有权根据严重情况提出批评；
• 关于修改Bug的质量问题，开发人员修改的Bug必须满足以下质量要求
  • 必须按照Bug的优先级顺序来修改Bug；（如果出现特殊情况，要及时和客户沟通说明情况）
  • 尽可能一次性把相关联的Bug全部解决；比如几个List都存在同样的问题，那么即使客户没有全部报告出来，解决时也应当全部解决掉；
  • 跟客户反馈时，尽可能一次性把客户关心的问题说清楚，反馈次数越少，说明你的沟通效率越高，花在解决这个Bug上面的时间相应越少；
  • 自己负责的模块，when the specification has been completed or issues have been fixed不应当出现异常或者明显的功能错误；若是由于关联模块被他人修改而导致异常或者明显的功能错误，则可以谅解，但必须马上解决；
  • 代码和界面必须是符合开发规范的，一些关键算法和SP必须是高效的；
  • 要尽量避免由于修改这个bug而产生了新的bug

1. 质量周报（拉灯）

项目启动后，测试团队每周会对测试情况进行报告，质量报告会体现项目的质量情况，当有问题时，及时拉响警报，避免质量问题蔓延，使项目持续得到改进。

• 项目质量星级：绿色正常，黄色警告，橙色、红色是更严重的警告；
• 项目的质量数据：Bug原因分析、return情况、Bug增加和修复情况、Bug maker情况等；
• 对成员质量情况的点评：对于质量差的同事，一定要指出来，提醒其改进（不用担心会得罪人，实事求是的指出问题是帮助其成长的方法）；
• 分析项目总体质量情况；有哪些执行不到位的情况等；分析原因；
• 给出改进的建议，督促PM和团队成员改进；
• 跟踪改进的决议；

1. 清单工具

软件开发就像开飞机，可能会出现各种异常的情况，比如发布版本时会出现各种环境、第三方等异常，为了确保不遗漏一些重要的检查项，核验清单是非常有用的工具。

诺怀在十余年的开发中，积累了大量的清单可供复用。

如：项目技术自检清单

总结

以上是诺怀质量保证措施的部分阐述，诺怀始终坚持为客户提供高质量、高价值的服务，我们也乐于听取客户的建议，持续改进，帮助客户成功。