企业官网建设流程全解析

wordpress本地网站上传,深圳惠州网站建设,网站开发程序制作域名备案,重庆建网站cqiezscom“测完了吗#xff1f;” 是系统测试岗位同学经常被问到的问题#xff0c;提问的人可能是合作的研发#xff0c; 合作的产品经理#xff0c;甚至是项目的业务方#xff0c;也有可能是测试自己。 这个问题至少有两层意思#xff0c;不仅问新功能测试进度是否完成#xf…“测完了吗” 是系统测试岗位同学经常被问到的问题提问的人可能是合作的研发 合作的产品经理甚至是项目的业务方也有可能是测试自己。这个问题至少有两层意思不仅问新功能测试进度是否完成更重要的是想知道测试的结果怎么样测试同学如何回答这个问题背后反映出来的是对本次测试工作的信心。软件工程理论认为受限于时间、资源、外部输入、测试人员经验等主客观原因对一个系统完全测试是不可能的 但是也正是由于上面的原因导致了不同的测试人员或者团队在执行测试的效果上参差不齐。但是作为有追求的测试人员我们要努力靠近“完全的测试”。本文基于申通的业务和技术现状申通技术质量团队尝试回顾项目测试的全过程从测试设计新功能测试回归等方面给出自己的答案。01准备工作在正式开始之前请允许我花一些时间介绍一下申通技术质量的工作模式。在软件项目管理中对质量的关注部分往往放在用例的完成情况以及缺陷的修复情况等结果方面从一些常见的项目管理工具如jira、teambition等产品设计上也有所体现。但是为了回答本文问题光靠这些结果是不够的因为关键的用例设计测试执行过程往往缺乏标准化导致结果的可信度大打折扣。因此我们需要对测试过程做精细化的管理。从实际情况出发目前我们着眼在最常见也是最重要的功能测试方面。我们对常见的项目测试过程进行了抽象从测试设计、新功能测试、回归等方面进行了标准细化并且自研了一套“质量管家”系统实现了测试工作流的在线化。不同于市面上的项目管理工具质量管家在“工具”的基础上融入了流程标准的概念。除了在测试过程中给测试同学提供帮助之外还可以对测试过程进行标准化管理。比如我们通过设定了一些测试流水线对不同类型的项目需求测试进行了流程规范确保关键的测试动作执行到位同时也通过比如测试评审纪要功能对评审待办事项进行自动跟踪避免待办被遗忘测试完成自动发送报告节省测试同学书面工作时间。产品示意得益于质量管家实现的过程量化我们具备了回答“测完了吗”问题的数据基础能力可以基于此做质量过程和结果量化。下文我们从几个关键点展开论述。02人工测试有效性虽然自动化测试是很多测试团队追求的方向但是从申通的产品特性出发综合考虑测试ROI传统手工测试人工测试还是占据了绝大多数的时间。所以我们把重点放在人工执行的功能测试其中的几个关键点包括了用例设计完整性新功能测试完整性回归充分性以及对上述环节的不断优化迭代。2.1 用例设计传统的测试用例设计基于经典的软件工程理论大致上包含8要素用例编号、所属模块、测试标题、重要级别、前置条件、测试输入、操作步骤、预期结果。规范的测试用例通常会用一个表格的形式来展现我相信很多从事软件测试时间比较久的同学都经历过。经典的实践结合测试用例设计理论等价类边界值等可以一定程度上确保测试用例设计的完整性但这是前互联网时代的经验。在当前我们很多时候要求快速迭代快速上线技术团队包括测试没有办法在前置的书面分析工作上投入足够的时间加上很多测试团队没有在测试用例方面下功夫做管理于是很多互联网技术团队的测试用例就简化到了一句话甚至没有大纲。这样导致的结果就是很多测试需要关注的细节由于开始没有被书面记录到用例中导致真正在测试执行的过程里用例执行凭感觉缺陷发现看经验甚至看运气很多经典测试中好的实践被抛弃导致测试遗漏的问题常常出现。那么如何平衡完整性和效率之间的关系更好地适应互联网的开发模式经过思考我们吸收了部分经典实践中的关键部分摒弃了一些无关紧要的部分形成测试用例模版比如用例步骤和预期结果以及正常、异常、以及非功能用例在用例设计环节作为约束最大程度上保证用例设计全面同时结合工具进行用例编写提效最后通过导入质量管家实现用例在线化。根据不同的业务在质量管家上面可以设置不同的模板在经典实践的基础上可以附加业务特性比如资金专项兼容性专项等以满足不同的测试需要。整体的用例编写基于xmind适应当前很多测试同学的习惯同时也比WordExcel的编写效率要高。用例导入之后可以在线修改查看和执行保证用例执行过程留痕。同时用例还支持一键转回归用例减少用例用完即抛造成的浪费有利于测试经验沉淀。2.2 代码覆盖用例设计完成研发提测之后就要开始执行。这一部分我们重点关注代码测试覆盖度。为什么要看代码覆盖度它可以直观地反映这次测了多少代码有多少没有被测试我们知道代码覆盖100%测试可能也不完整但是代码覆盖面不到100%测试肯定不完整。很长一段时间我们的测试代码覆盖面是个黑盒从抽样结果和历史线上问题来看这部分存在很大的漏洞。度量代码覆盖技术已经有比较久的历史以往通常是应用在单元测试等自动化测试环节用来度量自动化测试的有效性。业界开源的或者基于开源技术二次开发的技术也比较多。我们采用的同样也是基于jacoco的技术二次开发申通自己的覆盖率度量插件并且基于此配备了一整套的代码覆盖率度量底座SCC。原生的jacoco和单元测试配合比较好如果要应用在更大范围的项目测试上还存在一些问题需要解决。一些关键的对比如下。绿色部分为原生支持红色部分为不支持关键问题1数据持久化原生jacoco的数据存储在被测服务器上在云原生的情况下一旦应用重新构建和部署相关的数据也随之消失同时也存在容器重建、迁移等情况导致数据丢失。由于自动化测试持续的时间比较短测试中一般不会存在上述情况导致的数据丢失的情况即便丢失了重跑自动化测试的成本也比较小这也是自动化测试的优势。但是在人工测试的情况下 测试周期需要持续数天甚至更长的时间的而且由于缺陷修复代码提交等情况一定会出现被测服务重新部署的情况。数据丢失之后大多也不能为了跑覆盖率数据进行重复测试这样数据可靠的持久化就变成了刚需。这个问题的解决方案如下完成覆盖率插件的接入之后测试人员无需做更多的关注正常执行测试即可。在测试的过程中 测试覆盖率的数据持续被生产并且存储在被测服务器上。当应用重新部署的时候SCC集群启动任务下发命令去对应的被测服务器上dump相关的测试覆盖率数据。完成之后在SCC上完成覆盖率的聚合计算。完成覆盖率计算之后 上传到文件存储服务上供后续使用。关键问题2类冲突代码清零问题原生的jacoco存在一个比较严重的问题 就是在多个分支同时部署的时候在流水线上会合并为release分支本质上jacoco agent的计算的是release的覆盖率假如被测分支feature1修改了classA并且此时测试已经完成了classA中的全部测试覆盖如果此时同样部署在测试环境的分支featureB同样往classA提交了代码会导致原本已经测试完成完成的featureA中的classA的覆盖率被清零。如下图其中绿色部分的是测试需要负责的项目黄色部分是测试未参与的其他分支。这个问题的影响是如果被测分支中大量的测试工作已经完成并且发生冲突的类新增代码需要重点测试比较多的话会导致覆盖率数据会大幅度下降。因此我们也投入大量时间是花了大量的尝试解决此问题。从jacoco的设计来看 一个类中的一行代码 发生变更就意味着这个类需要重新测试有一定的合理性。但是如果按此原则实际在项目过程中落地存在困难。我们的解决方向是把“冲突清零”的范围控制到方法层面也比较符合实际情况。技术方案如下在存储原始覆盖率数据的同时将需要把覆盖率数据依据方法维度进行切割在计算的时候按照方法维度做清零计算避免整个类的覆盖率被清零。项目测试落地应用有了比较可靠的覆盖率统计方案之后还需要处理一些在实际应用中的问题才能实际在项目测试中发挥作用最典型的问题是有些代码通过常规的测试手段无法覆盖或者没有必要覆盖的情况对于这些情况我们在覆盖率报告的基础上于质量管家中增加了覆盖率分析的节点要求测试人员对为覆盖的代码进行标注说明进一步防止漏测情况的发生同时对于一些没有测试必要的代码比如打印日志等做了排除处理以免影响最终的测试通过性检查。报告汇总未覆盖分析标注研发自测有效性管控在实际的研发工作中由于一些客观原因很多需求其实没有经过测试团队测试验收 都是由研发自测之后完成上线很长一段时间质量部门对研发自测的关注或者是管控的力度较弱可能是缺乏相关的流程规范或者是有流程规范但是落地效果无法把握。由于上述原因自测导致的线上问题占比也比较高。之前的一系列测试能力建设加上覆盖率度量的能力我们现在有能力科学的对研发自测的质量有一个客观的评估。整套方案上尽可能做到了对研发过程的少打扰通过综合单元测试、 自动化测试、以及研发或者产品自测的结果数据产出融合覆盖率避免单一维度的测试覆盖率导致的不客观问题。这套方案也帮助开发在无测试帮助的情况下对自己的发布质量有了一定的底气。落地效果提升测试覆盖面当前覆盖率系统每天计算产出覆盖率报告100份以上。2023年的测试任务中有8成以上需求的代码测试覆盖率都超过了80%以上有效减少了线上问题漏测的情况而且通过对代码覆盖率的关注大大提升了测试团队的白盒测试能力帮助发现业务逻辑漏测后门代码无效分支等各种异常。线上问题中由于测试不完全导致的线上问题整体降低50%以上。03回归与精准测试3.1 背景出于测试成本考虑覆盖率上我们主要关注增量覆盖率这样就有另外一个问题没有解决一些增量的代码对原有代码的影响其实是没有能力反映出来的。这类问题也是线上比较常见但也是比较难以通过测试发现的。这需要我们思考其他的解决方案。3.2 思路常规的思路一般有两种1.通过投入大量时间做全面的回归大水漫灌式的做法我们也尝试过类似的实践这样的方案对于产品规模较小的业务比较合适比如功能比较单一的APP但是如果涉及到一个全链路的复杂系统这样的回归方案变得很难落地。2.通过自动化的方式尽量覆盖更多的代码逻辑通过高效的自动化方式进行回归。但是在实际的生产中自动化用例往往不太成熟无法实现有效地回归覆盖。当然有些公司的自动化建设比较成熟但是带来的其他问题是自动化的维护成本和运行成本高企。上述两种方式在申通不同的业务上也有实践在此的基础上我们产出了另外一套精准测试的方案期望能够准确识别变更的影响面做到回归测试有的放矢给人工回归和自动化回归提供有效支撑。要达到这一目标解决方案中至少要具备两部分能力1.识别影响基于变更识别关联影响影响了什么2.测试评估基于影响识别测试范围测什么对于第一部分以最常见的业务逻辑代码变更举例常规有两种做法动态方法采取如java字节码技术通过动态收集代码运行时的调用关系建立代码之间的调用链这样的方法好处是只要采集的数据足够全得到的调用链相对比较真实可以屏蔽一些无效的调用产出的都是真实发生的调用关系缺点就是技术成本高包括接入、采集、存储和计算。静态方法业界有一些开源的解决方案如java-callgraph这样的技术好处是技术成本较低能够通过静态扫描的方式短时间内得到代码之间的调用关系缺点是给出的数据颗粒度往往比较粗需要对开源包进行二次开发来真正达到准确识别变更所影响的调用入口的效果。基于综合成本考虑申通采用静态方法结合开源能力做了二次开发解决了在插件部署的效率问题以及结合研发流水线实现影响面自动测算我们可以通过对被测代码进行静态扫描产出一次变更所关联的所有入口。通过对变更的分析得到被影响的代码入口也基本得到了测试入口。第二部分基于影响识别测试范围。这一部分的解决方案需要提前建立测试用例和代码之间的关联关系并准备一套“录制系统”基于录制系统测试人员一条条的执行用例系统后台记录在用例执行过程中所经过的代码以此来建立用例和代码之间的关系。这样的做法可以建立比较精准的关联关系不足是维护的成本巨大以申通举例 上万条测试用例一条条的通过录制回放的关系会耗费大量的时间等一轮关系建立完成之后可能系统又发生了较大的变化导致所有的关系都要重来。在目前的情况下这样的成本无法接受。我们需要解决成本的问题 经过思考我们决定仅从测试用例入手建立到服务层的关系这样可以避免底层业务逻辑代码变更带来的关系维护成本同时在建立关系的时候也可以比较快速地完成。方案示意如下对于人工测试1.对页面测试的人工用例用例集合我们先通过手工绑定的方式建立人工用例和页面的关系。2.然后在对应的页面中通过抓包的方式全量的抓取该页面所调用的后台服务。3.然后反过来我们就得到了用例页面API之间的关系图谱。对于自动化用例相对来说比较容易通过静态分析的方式可以自动得出自动化用例所调用的后台服务。也就建立了自动化用例API的关系图谱。完成结合第一部分的能力使得我们通过变更的代码可以得到影响的API 通过影响的API可以得到相关的用例包含自动化和手工部分。在实际的测试过程中测试人员只需要输入对应分支后台就可以推荐出对应用例实现精准的范围评估和回归测试。3.3 扩展应用由于识别影响和测试评估的能力是互相独立的 严格来说识别能力作为能力单独对外提供服务。比如识别到某次变更影响的入口之后发现相关的入口没有自动化用例或者人工用例后可以自动生产待办任务督促相关测试完成用例补充。又比如在Code Review的环节可以提供更多的输入给代码审核人做更加全面的代码审查等等。还有一些定制化的应用比如某些接口协议发生变更的情况下可能要触发对应的前端或者依赖方的回归测试。基于这些能力可以进一步的提升测试的完整性。04自动化测试有效性申通技术部现在有上万的自动化用例每天在运行自动化的应用渗透在从提测到线上巡检的各个环节。如何保证这些自动化用例能发挥效果是一个需要关注的问题。常规的做法是从手工的用例出发选取一些关键的业务用例进行自动化实现申通也有类似实践相比有些公司有专门的自动化测试工程师来负责此工作在申通并没有如此细致的分工同时手工用例编写的细致程度以及选取要实现自动化的用例存在很大成分的人为判断因素导致在所谓核心用例的覆盖面的基础上无法提供更多有效的支撑来进行自动化用例建设。我们的做法除了从用例出发还会从以下几个方面关注。4.1 接口覆盖顾名思义就是从应用接口看那些需要实现自动化的服务。第一个要解决的问题是接口列表从哪里来与一些大厂可能有比较完整规范的接口文档服务注册机制来识别服务列表不同在现有的条件下申通是通过线上监控的数据来拉取服务列表。从监控平台拉取的数据除了有服务地址之外还有服务调用量等信息通过这些信息结合业务重要性的综合判断我们在全量的服务列表基础上可以对服务进行分级那么接口自动化目标也就有了优先级基于这些优先级去进行服务自动化覆盖就变得有的放矢。4.2 代码覆盖上文提到了我们有一套代码覆盖率度量的基础能力SCC 基于此能力我们可以衡量出在自动化集中运行期间的代码全量覆盖率借此可以对自动化的有效性和接口覆盖的层面上更加深入。4.3 场景覆盖场景是什么往往是基于业务的描述在测试方面可以抽象为外部调用进入到系统的不同入参组合以及这些入参所经过代码调用链路那么基本可以认为场景是入参决定的简化来说我们可以认为是经典的“等价类”“边界值”的实际生产应用。不同于“设计”各种测试用例 在场景覆盖的命题下我们更多是通过获取线上数据来进行有效的组合形成不同的自动化场景用例所谓“有效组合”是指的我们基本不会去臆造一些实际生产中不存在的数据这样的做法更加贴近实际同时也保障技术资源不会被浪费。对于场景自动化的落地大厂的做法可能是通过引流或者是链路分析来识别需要较大的数据存储和计算成本申通的做法成本更低一些通过线上数据完成各种场景的组装之后将被测系统的业务抽象为流程相对于单接口自动化用例通过类似数据驱动的方式输入到流程用例中完成业务系统的场景自动化覆盖。4.4 问题反馈上述的做法都是问题事前的方法 对于事后的方法判断测试有效性主要是通过线上问题的反馈来回溯验证这部分下文展开。05基于问题做优化申通技术团队已经完成了将原“技术支持”团队升级为“技术服务”团队在更加规范化地给用户处理产品使用上的问题过程中积累了大量的服务数据其中一部分就是产品线上问题和建议。现在技术服务团队基本上涵盖了申通技术部提供的所有产品和系统相关的线上问题都可以得到比较及时和完整的收集。基于这些线上缺陷技术团队可以回过头去看在研发测试过程中出现了哪些遗漏比如是否测覆盖率不足是否回归不全面等等。研发测试上线服务四个环节有机协同给系统优化提供方向形成PDCA良性循环。技术服务补全了从研发到上线的质量体系06未来计划上述的一系列措施便是现在申通测试如何回答“测完了没”这个问题的答案当然测试的范围非常广我们只是基于现阶段的业务特点和技术质量要求把重点放在了功能测试层面对于非功能测试领域的关注还是相对较少。对于未来我们计划在下面的几个方面进行一些探索。6.1 前端代码覆盖率识别对于覆盖率目前我们能识别后端代码的测试覆盖率对于前端代码的测试覆盖率需要和前端研发团队深入合作制定标准通过埋点等定制化的技术方案来实现。6.2 数据配置变更影响识别对于精准测试目前我们的关注点放在了后端代码的变更上未来还可以通过识别前端代码变更数据结构变更配置变更的影响来扩展更多的应用场景和访问使得质量风险的评估更加全面。6.3 AI测试助手AI的应用尤其是生成式的大模型在各领域都有不错的实践在技术方面之前我们有看到AI编程AI做代码扫描的实践对实际的工作也是非常有帮助在质量领域方面AI至少可以在测试分析自动化测试代码缺陷分析方面做一些有效的辅助。基于现在的“小模型”技术我们可以用更低成本对模型进行部署和训练基于申通现有的质量要求以及历史上的质量数据训练出更加贴近申通业务的质量AI。感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取