• 敏捷测试漫谈


    在聊敏捷测试之前,有必要先聊聊敏捷。最近几年,XXOps不断的提起,被不断的赋于新的含义,DevOps,TestOps,SafeOps等等。现在的软件工程不说敏捷都不好意思提。在早期的瀑布式研发模式下,软件工程定义好了研发环节的各种要求,引入了比如PMP项目管理,比如CMMi成熟度模型等内容,这是很明显的“工程思维”。工程思维要求我们必须按既定的规划(需求文档),根据工程设计图(概要设计、详细设计)进行施工(编码),然后进行严格的验收(测试),最后交付(发布运维)。看着好像没有什么问题,也一直执行了好多年,对吧(类比如下图)。

    但是,软件研发和工程研发是不一样的。比如建筑工程,必须严格按照设计图纸来施工,出现偏差后果很严重,但是软件一定要按概要设计来么?在编码过程中如果发现了更好的设计模式,更优秀的框架,为什么不能引入呢?后来,有一群开发人员聚在一起讨论和研究这个问题,倒腾出来了敏捷宣言(本文不展开讲,有兴趣的自行查找),以服务的思维重新梳理了研发模式。服务思维的核心是:用户满意。在服务的过程中,我们需要的是拥抱变化、持续反馈并加以修正。最终让用户满意,让市场满意。需要注意的是,敏捷的最终目标不是快,而是持续反馈(一个典型的例子,就是之前有人说汉武建方仓,是敏捷实践的最佳案例,看完就想打人,那是标准化的威力)

         回到敏捷测试,敏捷测试并不是一种新的测试方法(白盒测试、性能测试之类的),也不是一种新的测试技术(探索性测试)。在我看来,敏捷测试更多的是一种思维上的转换,而不是实施层面的问题。原来的测试方法和测试技术,在敏捷测试中一样可以应用,并没有区别。我对敏捷测试的理解有以下三点:

    Vol.1 敏捷测试是一种有效的反馈,越早越好

         我们都知道问题越早暴露越好,所以我们提倡测试左移,推行ATDD,BDD等等,都是为了更早的发现问题,并快速反馈,让团队减少返工和浪费。

    在需求澄清阶段,需要注意:以终为始,确保需求输入质量,首先要讲解业务目标,其次操作及操作流程,再次是业务规则。需求不是方案,而是用户的价值。只有我们从价值开始,层层分解,从业务到实现层面充分沟通,才能保证后面交付的质量。有人会觉的测试人员无法接触到真正的客户,无法理解什么真正的用户价值,认为这是产品经理需要做的事。在这个阶段,测试人员可以做两件事:

    1.    尽可能多的参与产品的规划,了解需求背后客户真实的想法(用户群反馈、竞品分析、自己真实使用感受等等都可以获取价值)

    2.    协助产品经理完成业务流程的梳理,评估需求对现有流程的影响,是否存在互斥的因素,新业务对原有业务是否有影响。是否有遗漏的场景等等。

    如果TDD(Test Driven Development)在团队的落地可能会存在困难,我们可以尝试使用验收测试驱动开发(ATDD,Acceptance Test Driven Development)在需求分析时就确定需求(如用户故事)的验收标准,并记录在故事卡片上。从需求的角度去准备验收标准和测试用例。同样可以保障从开发的开始就有较高的质量

    Vol.2 自动化测试是敏捷测试的一种必要手段

        想要做到快速反馈,必然要依靠大量的自动化测试。

      新模式的测试金字塔下,除了顶端的探索性测试、体验测试等活动外,其它的测试均可做到自动化测试。最好能够做到端到端的自动化测试,保证更多的覆盖面。如果暂时做不到,至少接口测试和服务间集成测试需要保障,否则无法保障交付质量。需要警惕的是不要让自动化测试流于形式(如没有断言,不可被CI集成,事后补用例 等等)。持续多个迭代后,好的自动化自动化测试ROI会让你感到惊喜。

    Vol.3 敏捷测试必须是一种可持续的活动

          在开展测试活动(不管哪类测试)时,我们可能会受制于各类客观因素,如无法快速构建测试环境(特别是微服务的框架下,如何快速构建对应分支的测试环境成为很大的一个痛点),无法快速生成测试数据(业务链路长,前置数据准备要求多,数据结构复杂等)。这些问题需要整个研发团队一起努力解决,业内现在也有比较成熟的解决方案可供参考(如环境标签、链路配置等方案解决环境问题,数据工厂、数据中台等解决全平台的数据生成问题)。

    同时,我们要保证在任意节点,都可以快速开展测试(自动化脚本能够区分颗粒度的被不同研发阶段调用),只有可持续的测试,才能持续的反馈,比如开发提交代码后,就能触发单元测试,进行分支合并后,进行接口测试。

        综上,敏捷测试不是测试手段的创新,是思维的转换,需要我们更早的参与测试,更早的提出反馈。基于以上三点理解,我们就可以有效的构建起团队的质量文化,也就是所谓的内建质量,当每个环节的产出都能够得到有效的保障,就可以减少等待,让研发环节尽快的流动起来,最终交付到用户手中,得到最终的反馈。

    补充:全文多处提到反馈。这是敏捷思维中非常核心的观点。如果不能及时反馈,我们就无法修正问题,交付的价值就可能产生偏差。敏捷最大的好处就是缩短了反馈路径。其实生活中,我们也要尽可能的做到快速反馈,这样才能更好的解决问题。

    转载:https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247483668&idx=1&sn=181d1d94b07081eb46d022fbf5d7630d&chksm=c0fb1721f78c9e379ebe22f36d6c477052c6d8467c358b53811fe13452ab86d433763c17de8d&cur_album_id=1979310371207184387&scene=189#wechat_redirect

  • 相关阅读:
    android学习笔记----启动模式与任务栈(Task)
    二叉搜索树转化成双向链表
    复杂链表的复制
    判断是否为二叉搜索树的后序遍历序列
    树的子结构
    调整数组顺序使奇数位于偶数前面,且奇数之间、偶数之间的相对位置不变
    android学习笔记----HandlerThread学习
    android学习笔记----Handler的使用、内存泄漏、源码分析等一系列问题
    原因分析——cin,coutTLE,scanf,printf就AC
    洛谷P1618_三连击(升级版)
  • 原文地址:https://www.cnblogs.com/ceshi2016/p/16799713.html
Copyright © 2020-2023  润新知