质量双周刊 第17期

YOUEDATA

质量双周刊

17

第17期

2022年12月

目录

CONTENTS

01

02

03

04

浅谈敏捷软件测试指标

需要改进的质量问题 

如何衡量软件项目的交付质量

新员工问题指引

质量双周刊--浅谈敏捷软件测试指标

 第17期  

浅谈敏捷软件测试指标

      敏捷活动中我们通常希望能通过一些量化指标进行度量。帮助团队跟踪和监控软件测试的进度、质量和生产力。各种测试指标的主要目的是提高整个软件和UAT测试过程（软件测试过程的最后阶段称为UAT。该UAT过程在发布实际产品之前验证是否满足了所有业务需求，因此扮演着重要而关键的角色https://www.testingxperts.com/blog/uat-testing）的效率。指标通过提供相关信息，帮助利益相关者就测试过程的进一步改进做出明智的决策。

      当前行业常用软件测试指标大致分为四类：

      软件的源代码至关重要，并使用已发布的源代码指标衡量其质量。这些已发布的指标根据其度量、大小、复杂性、耦合、内聚和继承因素分为五类。

质量双周刊--浅谈敏捷软件测试指标

第17期  

      衡量代码中缺陷的数量以及修复它们所花费的时间至关重要。应该更强调代码中的缺陷数量，而不是解决这些缺陷所花费的时间。假设代码中多次出现多个缺陷并且需要多次修复。在此情况下，描述了开发人员的技能差距或对需要充分解决的软件测试要求的误解。

      衡量产品的测试效率并评估软件的功能和质量。根据测量的内容，有两种主要的测试指标类别。一是测试覆盖率，二是缺陷去除效率。测试覆盖率指标衡量执行了多少测试用例，还有多少测试用例需要完成，测试了软件的哪些部分，还剩下多少测试百分比等。而缺陷去除效率指标衡量多少缺陷被识别，去除了多少缺陷等等，这些指标有助于提高软件产品的质量。

质量双周刊--浅谈敏捷软件测试指标

第17期  

      项目/计划级别指标

      该指标与项目质量相关，用于量化缺陷、成本、进度、生产力并估计各种项目资源和可交付成果。项目指标帮助团队评估项目的健康状况并做出明智的决策。与之前选择的 KPI 相比，这些指标揭示了项目的完成情况。它帮助项目经理评估项目的状态，预见可能的风险，评估团队的生产力和工作质量。

质量双周刊--浅谈敏捷软件测试指标

第17期  

      利用软件测试指标的好处

      测试指标有助于：

质量双周刊--浅谈敏捷软件测试指标

第17期  

质量双周刊--浅谈敏捷软件测试指标

第17期  

      1.流程指标

      该类指标用于衡量和提高软件测试过程的能力，例如，在测试中发现了多少缺陷，修复了多少缺陷，修复缺陷花费多少时间等。

      2.产品指标

      处理软件产品的质量并描述产品的特性，如大小、复杂性、设计特征、性能、质量水平等。这些指标的主要目的是提高产品质量。

      3.项目指标

      描述项目特征，如成本、进度、生产力，还衡量了项目效率，如项目进展情况、是否按计划进行、是否落后于计划等。

      4.人员指标

      衡量软件测试团队的能力和技能水平。如团队是否按计划工作，团队在规定时间内识别的缺陷质量，团队的生产力等。

质量双周刊--浅谈敏捷软件测试指标

第17期  

      管理者应关注的关键软件测试指标

      以下七种软件测试指标，管理者应该予以关注： 跟踪敏捷测试工作的指标，跟踪测试效率的指标，跟踪测试工作的指标，跟踪测试覆盖率的指标，跟踪测试有效性的指标，跟踪缺陷的指标，跟踪测试成本的指标。

      这些指标可以衡量敏捷测试团队为测试产品所做的测试工作。

      1.1冲刺燃尽

      该图表描绘了团队完成任务的速率的图形表示，并显示了在定义的 sprint 期内有多少工作尚未完成。通常在此图表中，冲刺日期在 x 轴上表示，使用剩余工作时间完成任务的理想工作时间在 y 轴上表示。

      1.2速度

      衡量团队在每个 sprint 中平均完成的工作量。它将完成的任务与团队的估计工作量进行比较。敏捷经理使用这些指标通过比较之前 sprint 中承诺的小时数和完成的小时数来预测团队实现目标的速度。

质量双周刊--浅谈敏捷软件测试指标

第17期  

      1.3代码复杂度

      指标计算通过程序源代码的一些线性独立路径。它是通过称为圈复杂度的度量得出的。这些指标帮助敏捷团队确定不稳定或容易出错的代码的风险。通过利用这些指标，敏捷团队确保代码符合既定的行业标准，例如缩进、内联注释和正确使用间距。

      测试效率是一个需要有效评估的重要属性。它描述了软件测试过程的质量水平。常用于测试跟踪并了解其效率的指标：

      2.1通过测试用例百分比

（通过测试数）/（执行测试总数）×100

      2.2失败测试用例百分比

（失败测试数）/（执行测试总数）×100

      2.3阻塞测试用例百分比

（阻塞测试的数量）/（执行的测试总数）×100

      2.4平均修复时间（MTTR）

（总纠正性维修时间) / (维修次数)

质量双周刊--浅谈敏捷软件测试指标

第17期  

      量化测试团队为测试产品所付出的努力的重要指标。它帮助利益相关者评估和比较测试团队的预期与实际测试工作。

      3.1测试执行覆盖率

   （运行的测试次数）/（要运行的测试总数）×100

      3.2每次测试的错误总数                                   （缺陷总数）/（测试总数）

      3.3测试错误修复的平均时间

   （缺陷修复和所有缺陷重新测试之间的总时间）/（缺陷总数）

      4．跟踪测试覆盖率的指标

      描述测试过程的真实场景和情况。测量执行的测试用例总数与需求总数。仍然等待执行的测试用例。

      4.1需求覆盖率（覆盖的需求数）/（总需求数）×100

质量双周刊--浅谈敏捷软件测试指标

第17期  

      4.2自动测试覆盖率

（自动化测试覆盖率：该指标衡量通过利用自动化实现的测试覆盖率百分比测试。随着时间的推移，测试覆盖率应该会显著增加，从而提高软件质量。自动化测试覆盖率越高，软件中出现缺陷的机会就越低。）

      为了测试效率指标，测试有效性指标测量和评估错误并确定测试集的质量。

使用缺陷遏制效率的测试有效性：

（在测试中发现的错误数）/（发现的错误总数）×100

上式中：发现的错误总数 =（在测试中发现的错误数+在发布后发现的错误数）

      测量缺陷百分比、缺陷密度、缺陷严重程度以及与缺陷相关的所有其他方面。这些指标有助于评估有多少缺陷及其严重程度，以确保软件测试过程的质量。

质量双周刊--浅谈敏捷软件测试指标

第17期  

（开发团队接受为有效的缺陷数量）/（报告的缺陷总数）×100

      6.2被拒绝的缺陷百分比

（被开发团队拒绝为无效的缺陷数量）/（报告的缺陷总数）×100

      6.3延迟缺陷百分比

（延迟到未来版本的缺陷数量）/（报告的缺陷总数）×100

      6.4固定缺陷百分比

（固定缺陷总数）/（报告的缺陷总数）×100

      6.5关键缺陷百分比

（关键缺陷）/（报告的总缺陷）×100

      6.6缺陷密度

（缺陷总数）/（模块总数）

      6.7检测时间

（发现的缺陷数量）/（总执行时间（以小时为单位））

      6.8缺陷严重程度指数

（（严重缺陷数量×8）+（严重缺陷数量×6）+（中等严重缺陷数量×3）+（低严重缺陷数量×1 ）） / （缺陷总数）

质量双周刊--浅谈敏捷软件测试指标

第17期  

     6.9 缺陷年龄（严重性分布）

     该指标反映了有多少打开的 bug 长期打开以及相应的严重性。

      该指标有助于计算 sprint 中由用户而不是敏捷开发团队发现的逃逸缺陷的总数。敏捷团队计算每单位时间、每个 sprint 或发布等的缺陷泄漏百分比。

      缺陷泄漏百分比 = （UAT中发现的缺陷总数/Production）/（UAT前发现的缺陷总数/Production）×100

      6.11缺陷类别

      软件缺陷可分为多种类别，例如：

质量双周刊--浅谈敏捷软件测试指标

第17期  

      6.12缺陷循环时间

      这指标衡量敏捷团队从团队开始修复错误到解决错误所花费的时间。它可以借助图表来表示，其中 x 轴代表时间，y 轴代表解决缺陷所花费的小时数。

      软件测试过程中，有几个组成部分会影响测试成本，例如所涉及的资源、工具和基础设施成本等。跟踪和评估测试成本并比较预期与实际测试支出是很重要的。以下指标可以跟踪：

      7.1测试的实际成本

   （实际测试预算）/（测试需求或测试用例或测试小时数）

      7.2预算差异

      实际成本－计划成本

      7.3进度差异

      完成测试的实际时间－计划时间

质量双周刊--浅谈敏捷软件测试指标

第17期  

      1．将软件测试指标与业务目标联系起来

      2．分析趋势，而不仅仅是数字

      通常情况，只要满足测试指标目标，软件团队就会宣布它是成功的。但简单、可量化的目标并不能代表整个故事。软件测试背后还有很多工作要做，因此需要不时分析趋势，以确定测试工作的开展方向以及最终结果的进步程度。

      3．将测量周期分成更短的时间框架

      这样有助于软件开发团队不时分析软件指标和趋势。借助更短的时间框架，团队可以有效地确定软件测试过程的进展。

      4．向利益相关者通知进展

      软件测试指标用于在简单数字的帮助下向管理层和利益相关者表示复杂的过程。这些指标不应被视为判断个人性能的手段，因为软件测试过程涉及大量工作和其他不可量化的方面。因此，指标应始终用作讨论的起点，团队和经理可以通过它讨论必要的改进。

需改进的质量问题 

    项目：目前已核验的项目未按照项目计划要求输出各阶段文档，未按要求归档至项目罗盘。

      大部分项目缺少有效沟通机制：没有定期召开项目周例会或项目沟通会。另外平台和研究院的项目周报更新不及时。

第17期 

质量双周刊--需改进的质量问题

    产品：近期根据重新梳理出的各一级事业群的产品线，盘点出以下尚未完成立项的产品。

质量双周刊--如何衡量软件项目的交付质量

第17期

如何衡量软件项目的交付质量

      如何衡量一个软件项目的交付质量，这是当前很多软件产品交付遇到的普遍问题。下面举例说明。

      某部门开会讨论项目的完整规范交付流程，参会的涉及项目相关的人员。把客户的干系人、自己的干系人对项目的影响做了一个排名并打分，结果很有意思：客户的领导和我们的领导的满意程度被排在了第一位，最终用户排在最后一位，中间是项目经理啊、关键用户啊、客户经理、服务经理、安全经理啊等等，感觉是不是有点不太正常？

      讨论核心问题：如何衡量一个项目的交付质量？关于这个问题大家吵得不可开交，最终也没有一个结果，每个不同角色的人看到的角度是不一样的，对于领导层，可能就只有一个指标：领导是否满意？ 但这是完全凭感性的，而且影响判断的因素很多，比如客户关系好不好，而且满意、十分满意完全是随口一说，从理性角度来看或者说从技术角度来看，如何给一个项目进行比较客观的评价呢或者更精确的定量呢？

质量双周刊--如何衡量软件项目的交付质量

第17期

      1.稳定性：（官方解释，指软件在一个运行周期内、在一定的边缘条件下，软件的出错概率、性能劣化趋势等。）但稳定性本身的定义也比较模糊，目前只能以可运行时间来衡量，如果项目没有出现宕机或者不能访问的情况，可以认为稳定性是100%？ 但系统访问慢算不算？？慢到什么程度算可以接受，什么程度算不可接受？

      另外，如果有部分人说正常部分人说不正常，这又如何去算？？如果只有少数人访问不正常，可能影响的因素也比较多，比如局部网络，比如用户电脑本身的问题。

      2.可用性：（官方解释：指的是产品对用户来说有效、易学、高效、好记、少错和令人满意的程度，即用户能否用产品完成他的任务，效率如何，主观感受怎样，实际上是从用户角度所看到的产品质量，是产品竞争力的核心。） 这又是一个很主观的因素了，同样的东西，有人觉得好用有人会觉得不好用，每个人的操作习惯不一样，咱们又不是像apple那样的东西，大家都说好，而目前如何定量评价可用性呢？？估计只有满意度调查了，但满意度调查本身就不是一个严谨的东西。

质量双周刊--如何衡量软件项目的交付质量

第17期

      3.可维护性：（官方解释：可维护性是指理解、改正、改动、改进软件的难易程度。）这个也是类似的问题，做开发的当然都明白这个道理，但是不是我们把所有的文档都补齐、所有的代码注释都加上就是一个好的可维护性？软件的理解改动涉及很多，比如你的架构设计，你的数据库设计，你的代码质量（关于代码质量又是一个可以讨论的话题了），这些东西没有一个标准去衡量，同样的架构，你可能认为不错，换成另一个人未必就觉得好，客户也没有能力到检查到代码层面，所以这个指标完全在于交付方怎么忽悠了。

      4.可扩展性：（简单地说，可扩展性就是关于如何处理更大规模的业务。）同样，道理都明白，但如何衡量？如果过度考虑这个可扩展性，又存在一个过度设计的问题，如果是自己的项目，你可能会尽心尽力地想得比较多，如果是乙方项目，你是否在设计时考虑得那么长远而且又不影响项目的正常交付？而且可扩展性的做法很多，比如分布式部署、集群、数据库分隔等等，但这样对当前来说都是理论上可行的，真的做起来还要考虑实施成本、复杂度的问题。总而言之，什么叫可扩展性高，什么叫不高？又是一个无法评估的东西。

质量双周刊--如何衡量软件项目的交付质量

第17期

      5.安全性：非常重要的指标，但大家看看各自的项目，有几个项目把安全性考虑得非常周到，物理安全、帐号安全、功能性安全，数据库安全，这些都不是一两句话说得清楚的，有一本书《白帽子讲web安全》里面讲解得比较多，但如果真的要做到那种程度，是不是自己把自己做死了？

      6.bug：这个不是指标，但是却是最直观的体现，最可以量化的东西，我们可以统计出bug的数量，但存在两个问题，一是bug如何分级？二是如何根据bug的数量来判断系统的好坏？ 第一个问题，bug的分级，bug肯定要分级的，不能所有的bug一视同仁，那么就要有一个分级标准，而这个标准是什么呢？举一个比较极端的例子，以前做一个财务系统，写错了一个文字，从程序角度来说，很小的一个bug，但是造成了客户几万张银行对账单作废，全体财务员工加班两天解决。所以客观地讲应该是给用户造成的影响来判断bug的严重程度，但很多时候其实也是人为拍脑袋的；好，现在假设这个bug数量出来了，也分级了，那么怎么算可以接受的？这与系统本身的代码量、复杂程度是有关系的，一个1万行的代码与10万行的代码，同样都是3个bug，那评判标准肯定是不一样的。

质量双周刊--如何衡量软件项目的交付质量

第17期

      从上述几点问题可以看出，软件项目交付质量如何量化，是个无法忽视的问题。否则就无法科学衡量交付质量，全凭主观，无法有理有据，使人信服。根据前面几个问题归纳，其实软件交付质量中心问题无非就是要及时响应客户需求，快速发现和处理软件存在问题。通俗来说也就是软件产品交付的速度和稳定性。

      衡量软件产品交付的速度和稳定性对于确保软件的高质量具有至关重要的意义。那么，对于一个比较成熟的软件产品，如何去衡量交付性能？

      Nicole Forsgren博士的《Accelerate》一书中介绍了四个软件交付性能指标，来衡量和可视化我们应用程序交付的速度和稳定性。eBay公司据此做出了尝试。

质量双周刊--如何衡量软件项目的交付质量

第17期

      部署频率–你的组织多久一次将代码部署到生产环境？

      变更准备时间–从提交代码，到在生产环境中成功运行要花多长时间？

      变更失败率–部署中有多少次回滚，修补等？

      平均恢复时间–出现问题时，需要多长时间恢复正常？

质量双周刊--如何衡量软件项目的交付质量

第17期

      此外，该系统还允许访问历史趋势，以识别每个级别上四个指标的改进或降低。团队还可以使用过滤器来查看特定时间段内的指标。

      为了跟踪该指标，我们从构建和部署系统中查找部署事件。在新版本的应用程序被部署到生产环境后，部署计数器会递增。这包括好和坏的应用程序版本。

质量双周刊--如何衡量软件项目的交付质量

第17期

      准备时间，指的是从变更创建时间到部署第一个服务实例过程中耗费的时间。

      部署到生产环境中的单个功能修改，可能有多个提交，从而导致要计算多个交付周期。为了计算单个变更准备时间的总体指标，我们将这些准备时间的中值用作该部署的“变更准备时间”。

      该组织，团队或应用程序的所有部署的“变更准备时间”的平均值，就是我们想要的“变更准备时间”。

      当前，我们将变更失败率衡量为给定时间段内所有部署中的回滚百分比。如果实例正在为流量提供服务，即使来自单个实例的回滚也算作失败。

质量双周刊--如何衡量软件项目的交付质量

第17期

      例如，如果将构建N（不良构建）部署到生产中，然后团队发现了一个问题，要求他们通过部署N-1（最新已知的良好构建）来回滚N，直到将N-1部署到生产环境为止的时间花费就是恢复时间（TTR）。所有TTR的平均值为MTTR。

      总结

      作为eBay内“ Velocity Initiative ”的一部分，eBay的各种平台和产品团队正在共同努力以实现一个共同目标：提高所有团队更快地交付高质量软件的能力。

      可见，测量和可视化上述四个指标，有助于团队了解交付速度和稳定性方面的优势，还有助于确定整个团队在软件交付过程中需要改进的地方。

      当然每个公司的情况不一样，因为我们要自己交付，自己来运维，所以从自身角度来说，我们肯定会更多关注可维护性的问题。即努力实现更快的部署频率，更少的变更准备时间，更小的变更失败率，更小的平均恢复时间。

      平均恢复时间（MTTR）

第02期

质量双周刊--新员工问题指引

第17期

新员工问题指引：

质量双周刊--新员工问题指引

第17期

新员工问题指引

      新员工入职时由人力安排统一进行开通，OA开通后需要项目负责人及时开通项目权限。

质量双周刊--新员工问题指引

第17期

  登录网址： http://nc.youedata.com/portal

NC账号登陆：四川优易的同事入职时间在 2018 年 7 月 1 日 前的，用户名是 10400+员工号后三位 ；入职时间在 2018 年 7 月 1 日后的 ，用户名是 11800+员工号后三位。

如果未登陆 ，密码都是初始密码 123qaz ！@

以上系统或是工作中遇到问题请联系韦尚志

4、加班报销注意事项（报销单需在 NC 网页端提报）

    加班餐费及打车费的报销有效期限为费用发生日期起三个月 ，超期报销由报销人自行负责，不予支付。

报销提单所需资料 ：餐饮发票、打车滴滴发票（纸质发票、定额发票、电子发票均可）、滴滴行程单

详细报销步骤及NC操作说明 请大家查看本期刊27页网址。

登录网址：

http://service.edos.youyishuju.com/seve-492/dolphinpage/dolphin/#/client

6、SVN申请

   SVN网上自行下载即可，账号需要发邮件进行申请，登录名和密码会邮件形式回复。

7、产品标配输出文档需按照公司统一模板，统一模板参见：

http://uway.youedata.com/uway/projects/foxcore/dmsf?folder_id=793或在易道-格物致知-优易知识宝库-产品荟-快捷模板中查找并下载

8、产品管理规范、质量管理规范统一在“易道-格物致知-优易知识宝库-产品荟”和“易道-格物致知-优易知识宝库-质量星球”中自主查询。

质量双周刊--新员工问题指引

第17期

浅谈敏捷软件测试指标编写：杨海鑫

如何衡量软件项目的交付质量编写：杨海鑫

质量问题编写：黄毅  邱红梅  马超

新员工问题指引编写：程方

校验：程方

版面设计：侯思燃

国信优易数据股份有限公司

质量双周刊

国信优易数据股份有限公司-—质量管理部