云服务器内容精选
-
持续自动化测试 持续自动化测试是在持续集成和持续部署过程中运行自动化测试，快速反馈失败，最早源自开发人员在开发环境中通过单元测试获取快速反馈的思想。持续自动化测试是随着CI/CD（持续集成和持续部署）发展而逐步成熟的。现实需要开发人员能够越来越快的发布产品变更，修复在线问题。如果仍然依赖原来的手工测试或者开发和测试完全分离的方式，难以保障在很短的时间窗口中完成测试质量保障活动，因此需要在CI/CD过程中嵌入自动化测试“持续”保障交付物的质量。 持续测试意味着测试活动纳入到持续集成、持续反馈、持续改进循环中，持续不断的测试，贯穿了整个软件交付周期。持续测试提倡尽早测试、频繁测试和自动化测试。 “持续”体现在贯穿了敏捷、DevOps流程中交付物由小粒度逐步演变为软件成品的全过程，从代码白盒测试，到组件模块测试、接口测试、E2E（端到端）功能测试，甚至交付之后进行生产环境的在线测试。每个阶段正好映射了测试金字塔由下向上的各层，越下层的测试在越早的阶段执行，越上层的测试在越后的阶段执行。这类似于汽车制造流水线的各个环节，每个环节的组装结束后都会进行必要的检查通过才进入到下一个环节，在软件DevOps开发过程中Pipeline流水线承载了这样的组装、检查测试过程。 测试左移、测试右移 二者强调在持续测试过程中测试活动越过了传统测试的时间、角色、部门限制，将测试活动发展为连贯的持续性的质量保障活动。 测试左移强调测试活动尽早开展，测试人员更早地参与到软件项目前期的各项活动中，在功能开发之前定义好相关的测试用例，提前发现质量问题，开发人员参与到测试。 测试右移强调在生产环境中测试监控，并且实时获取用户反馈，持续改进产品的用户体验满意度，提高产品质量。 测试自动化 持续测试要实现快速流动和快速反馈，需要使用自动化的手段来提高效率，于是自动化单元测试、接口测试、E2E测试就应用嵌入到了DevOps流水线中。自动化测试提高了测试反馈效率，也降低了人为因素导致的错误。测试自动化不仅仅要完成测试用例脚本执行的自动化，还要实现其它所有可以减少人力投入的活动，例如自动化环境创建，自动化部署，自动化监控，自动化数据分析等。
-
测试金字塔 自动化测试金字塔最早是由Mike Cohn在2009年的著作《Succeeding with Agile: Software Development using Scrum 》（《Scrum敏捷软件开发》）中提出。最早提出来的时候是一个三层的金字塔，从上到下分别是UI界面/Service服务/Unit单元测试，随着敏捷测试的不断推进，测试金字塔出现一些变种。实际使用中不用太拘泥于每层的名字，在服务化软件架构中Service层也可以理解为API测试。 这种下宽上窄的三角形结构，代表在各层自动化的建议投入分配比例，越接近底层的单元测试建议的投入最多，接口测试居中，界面层建议的投入最少。
-
应用场景 随着云平台的功能日趋复杂，在设计测试用例时，经常会遇到一些相同的前置步骤或者测试逻辑。如果每一个测试用例中都编写这些步骤，重复工作量很大，并且难以维护。在接口自动化测试平台上，用户可以完成测试工程的创建，测试用例的编写以及测试用例脚本的自动化执行，支持将URL测试步骤设置为接口关键字，关键字库将接口关键字、组合关键字、系统关键字进行统一管理，可用于组件测试、系统测试等不同的测试场景，其优势体现在易用性、可理解性、可维护性、测试信息可复用。 本章节选择某电商平台的商品管理的功能为例作为阐述。
-
敏捷和DevOps 敏捷和DevOps转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈，新商业模式的创新和变现时间窗口越来越短，催生更多的企业采取精益创业的方式，捕捉市场需求后，尽量缩短TTM产品面世时间，快速推出MVP产品并快速响应客户需求迭代产品。 以华为为例，在2008年左右的时候，华为的项目还是采用传统的交付方式。例如，在年初开始一个项目，在项目立项之初就会把客户的需求全部收集好，包括一些用户的反馈，并把需求做了全年的排序。年中的时候发布产品给用户，两个月之后再出一个补丁，最终年底出一个正式的版本。当时版本交付的节奏还是比较慢的，但是对质量要求比较强。因为产品发布给客户以后，下一个补丁需要两个月，如果用户在这个期间发现产品问题，只能再等两个月，而在这期间如果用户不接受我们的产品，会导致项目前功尽弃，所以对产品的质量有严格的要求。 产品逐渐向敏捷方向发展，这时有一部分研发工具平台已经陆续转到上云，一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次，转型之后变成一个月，甚至两周发一次，但这时的转变并不彻底，与客户的交付过程仍然存在一些问题。后来越来越多的工具向平台化、服务化方向转型，这个时候一些商业模式发生了根本性的变化，也就是说当需求上云了以后，用户更加快速的介入进来。基于云平台，把一些功能快速的开发出来，然后频繁的和用户去商量，听取客户意见，牵引产品做快速迭代，这种交付方法使得交付周期变快了，之前是半年交付一次，现在是一周、两周，更有甚者，可能一两天就把功能发布出去了。从需求的角度来说发生了巨大变化，基本做到了小步快跑，快速试错。
-
测试的焦点：业务价值的质量 测试首先是一个质量活动，做测试就是要保证质量；其次是一个工程性的活动，即在有限的时间、人力、资源投入内获得尽可能大的产出价值。质量有多个维度，需要有一个焦点：业务价值的质量，也就是产品“对客户呈现的价值”的质量。测试围绕业务价值去做，确定质量在功能、安全性、性能、易用性、兼容性等多个维度上的权重和优先级，而不是说一个测试上来之后，就把测试相关的关系点、关联点全部做测试。 来看几个例子：例如现在正在做一个线上支付的功能，对这个功能最关心的方面肯定是安全，所以相关的测试用例关键点就应该围绕安全大做文章，一定把安全保证好；再比如，现在要做一个线上商城，面向用户是老百姓，不仅要让年轻人会用，也要让老人都会用，那么就要关注易用性；除此之外，电商举办大规模抢购促销活动，那就还需要关注性能。因此，测试要求瞄准产品本身的业务价值，确定产品的目标，相应的制定质量关键点，制订相关的测试策略，然后实践落地。落地之后还要基于一些不良的效果不断的进行反馈、循环，校验整体的测试过程是否达到预期结果，这就是测试焦点。
-
常规安全与弹性安全 在常规的设想中，通常是哪个地方不安全，就一定要把所有不安全的因素找出来、清除掉。这是常规的做法，但却偏向于理想，在实际工作中是不可能把整个系统中不安全的因子全部识别到的，这其中涉及能力、架构等各方面的原因。 因此，在此基础上演变出了弹性安全，即通过场景模拟的方式将不安全因素尽量展现出来，从而基于这种不安全场景，给出快速的修复方案弥补这个不安全因素，从用户角度来讲是感知不到的。从产品来讲，它的商业目的和质量目的都可以达到，这就是所谓的弹性安全，即便发生了错误，能够及时快速的修复漏洞或者自我修复，达到正常工作的目的。
-
产品发展不同时期的测试策略 是否在团队组建之初，就要把整个自动化测试的能力构建起来呢？其实这有一个过程，下面从软件成熟周期的角度，看如何构建测试自动化的能力。 在软件初期探索阶段，产品是一个不确定的状态，从前端的风格和整体的布局到后端的API都时刻在变化当中，而且变化比较频繁，由于自动化用例的生命周期比较短，所以在这个时候创建一些自动化测试用例是不太划算的。而这个时间段的产品，往往特性是可控制的，只有几个测试，因此可以以手动为主，不考虑自动化，让产品能够快速识别错误点，让用户能用起来。 到了产品扩张阶段，用户认可产品，这时候会出现两个现象：第一是用户量增长，第二是需求数量增长。这时候必须要考虑自动化，因为在这个阶段每一次迭代的全量验证成本会越来越大，而交付的速度也会越来越快。我们不可能每一轮上线的时候都全部用手工做测试，这时候旧的模块就需要自动化用例去保证。 到产品提取阶段，产品已经到了需求的饱和期，产品的利益增长也到了饱和期，这时候要严格控制产品需求，自动化用例的职责变成守护，不允许变动引入额外的风险点、大的特性变动，导致对成熟的用户造成攻击。
-
自动化测试和测试自动化 这里要澄清一个概念，就是测试自动化（Test Automation）。 测试自动化的目的是减少手工测试和手工操作。测试自动化不仅仅包括自动化测试执行（Automated Testing），还包括其它所有可以减人力投入的活动，例如自动化创建测试环境、自动化部署被测系统、自动化监控、自动化数据分析等。很多自动化测试只是测试的执行部分，例如把一些测试执行的人工测试手段做成自动化测试。但是测试自动化不仅仅是只是执行，还包括了从环境的获取到生成测试数据、执行自动化测试，最终生成结果。如果有问题，会自动推送给相关的人，对应的组织解决。自动生成测试报告，测试人员直接拿到测试结果。
-
测试债务 从瀑布到敏捷再到DevOps，在开发和测试生产率和需求交付效率提升的过程中，不同的组织或多或少面临一些积压问题没有解决，影响测试能力和测试价值的持续提升。 从对测试的重视程度上看，有的公司存在重开发、轻测试的情况，测试人员职业发展受限；手工测试人员不熟悉编程，开发人员对测试重视不足；测试工作量高，但人员配比低。 从部门组织和流程和文化上看，测试人员对需求理解不足，测试和开发之间的部门墙导致信息不透明、沟通协作滞后和不足，质量向速度过分妥协，以及忽视敏捷文化和价值观的培养塑造。 从测试和产品技术和方法上看，产品耦合度高、可测试性差，测试过于依赖黑盒功能测试，测试策略、方法不恰当，测试环境部署时间长，频繁升级等。
-
测试左移和测试右移 左移就是前移，尽量把活动向前移。例如BDD（Behavior Driven Development，行为驱动开发），基于场景直接设计出符合这个场景的用例，来匹配这个设计；契约测试，服务和服务本身之间有耦合，可以通过契约测试解耦，以防导致问题。 测试右移是指要把测试活动的覆盖范围尽量向后蔓延。通常的测试只进行到了版本发布之前，测好之后发布一个软件包，而测试右移要把软件包发布到生产环境，以及到线上运营环节，都要去做测试。 在这两个方面也有一些相应的实践，例如线上拨测，主动线上监控用户的一些行为，并从行为轨迹里面快速捕捉相应的问题，主动推送给相关的责任人，让他去关注并且解决。线上的过程可以通过一些测试手段，不断的反馈给真正的开发人员，让他知道当前产品的整体表现，开发人员就会快速的针对产品作出应对方案。
-
团队规模对测试建设的影响 当团队规模在5个人以下，团队处于探索阶段，这时质量活动可以仅仅局限于测试的自组织阶段，只是做一些基础类测试管理活动，把缺陷管理起来，做一些回归测试。在这个阶段主要是建立一个测试管理的流程和机制，并没有接触到自动化测试。 随着项目的进一步扩大，逐渐增长到5-10人的团队规模，这时测试工作量突然增加，可能会有专门的测试人员进来，这个测试人员会去和开发人员进行串联，把需求转化成自动化测试的用例，搭建持续集成，逐步演进一些测试手段。——这个阶段已经开始做一些自动化的尝试。 团队进一步增大，一个人可能搞不定工作量的时候，会招聘更多的测试人员，成立专门的测试团队，这个团队就从自动化测试转向测试自动化，把更多的管理工作做进来。在这个管理过程中，会做一些产品的对接，包括开发专门的工具，实现自动化的整体能力，不仅仅是自动化执行了。 经过上面几个演进周期之后，测试团队具备了很多的测试自动化经验，这个时候可以进行面向云化的转型，现在很多团队都在进行DevOps转型，最关心的方面就是组建DevOps的全功能团队。那么之前转型的这些人在做什么？原有10-15人的测试专项团队做什么？在这个阶段团队要把测试专项能力向服务化能力转型：测试专员会在团队创建初期进行赋能，包括测试工程搭建、早期的测试用例怎么写、标准化模板的编制、针对非功能性测试的专项能力的赋能；所有团队进行测试流程的评审，包括测试策略、测试计划、测试用例的评审，再看整个团队里面流程上还有哪些改进的；从各个方面整个专项测试团队向服务化进行转型，帮助所有团队完成自动化转型。
-
测试策略和方法描述 回顾测试策略和测试方案，如测试类型、测试场景、测试方法，策略性说明如何测试，介绍测试使用的方案，例如：集成步骤和顺序、测试步骤和顺序、测试方法、测试工具、测试用例设计和执行方法等。 描述测试环境，如测试所使用的硬件、软件、测试工具的名称、规格、数量、版本、账号等信息。 总结测试周期和测试人员投入，即测试的计划开始和结束时间，测试总体进度，关键的阶段性进度检查点情况，测试人员数目、分工、投入工时等。
-
测试指标统计和分析评价 测试关键性指标统计：某些专项测试，例如速度、吞吐量、温度、时间、资源占用率等被测系统质量可量化指标的测试结果统计。 缺陷统计和缺陷分析：统计缺陷总数、按级别统计缺陷、缺陷解决率、缺陷重启率、遗留问题单数目、按模块缺陷分布、缺陷来源分布等。应用缺陷正交分析、四象限缺陷分析等。 测试执行情况统计：统计设计的各类测试用例数量和比例、执行测试用例数量、测试用例执行通过率、回归测试次数，测试执行人力投入和测试执行周期等。 测试充分性和测试能力统计：统计需求和功能特性覆盖情况，测试执行完成率、代码测试覆盖率、测试自动化率、测试用例缺陷命中率等。
-
为什么要制定测试计划 确保测试活动围绕测试目的开展工作，服务于明确的测试目标。 确定测试对象的被测特性和需求清单，框定测试范围。 选取适合于团队技术能力和工具组合的测试策略和方法。 尽早识别测试活动开展中可能面临的风险因素，并及时解决。 合理预估测试工作量和人员、资源需求，编制测试项目计划。 帮助测试人员分解测试活动和任务，编排个人工作计划。 指导测试执行活动、及时纠正和补救执行偏差。 作为相关文档，与利益干系人汇报沟通。
-
什么时间做测试计划 测试活动包含测试计划、测试设计、测试执行等。一般而言，测试计划排在首位，在测试周期的早期阶段开展。实际上根据不同的项目使用的开发模式、团队组织形式等，测试计划可能在多个时间节点中开展，例如： 某企业面向客户的移动APP产品，在第一个版本发布前，测试部门在接收到产品的测试申请后，接收测试需求做上线前系统测试计划。 某内部软件项目，产品立项完成需求确认后，架构师已经设计出产品架构方案和设计方案，产品未进入实质开发阶段，开发组织制定开发计划，测试组长制定测试计划。 某对外商用产品，例行提交做专项安全测试，安全测试部门根据历史安全测试计划和测试报告，评估新增产品特性变更，制定新版本的安全专项测试计划。 某软件测试团队有明确的功能测试、性能测试、安全测试等分工，测试团队主管制定主测试计划后，各类型测试专家制定类型的测试计划。 整体来讲，建议尽早开始测试计划相关工作，因为测试计划制定时间越早，越容易在早期阶段指导、规范产品的质量活动，提高产品的可测试性，测试人员从攻击者的视角指导产品架构和设计中的质量要素，符合测试左移的思想。 但越在产品的早期阶段，测试计划的粒度越粗，缺少细节可执行层面的测试用例、可供使用的测试环境等，需要随着项目的推进不断细化。测试计划不是一成不变的，随着测试项目的开展，测试计划逐步详细，包含越来越多的信息。测试计划的细化和完善过程中需要注意审视初始的测试目的、测试范围和测试设计和策略等。
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
