敏捷开发中测试如何进行_敏捷开发是否只需要进行验收测试 - CSDN
  • 敏捷开发中测试角色的窘境 先说说敏捷开发中码农哥哥与测试妹妹的一段恩怨情仇: 测试妹妹:需求文档在哪里? 码农哥哥:这个...,没有需求文档,产品经理发了我一句话,后来直接和我说了要求,很简单,我和你再讲...
    敏捷开发中测试角色的窘境


    先说说敏捷开发中码农哥哥与测试妹妹的一段恩怨情仇:


    ------------------------------------------------------------------------------------------------------------------------------

    测试妹妹:需求文档在哪里?
    码农哥哥:这个...,没有需求文档,产品经理发了我一句话,后来直接和我说了要求,很简单,我和你再讲一下吧。
    测试妹妹:好吧,懂了,那我开始测了。

    测试妹妹:测试完了,有5个bug,我都提交了,你看看吧。

    码农哥哥:好的,还有一个新需求,再和你讲一下。

    测试妹妹:终于测完了,全部测试通过了,恭喜啊
    码农哥哥:sorry,刚我改动了一个小点,你再重新回归测试一次吧,这次应该OK了。
    测试妹妹:终于回归完了,又发现一个问题...

    产品经理:客户反馈了一个bug,你赶紧看看
    码农哥哥:不可能啊,这个功能我都测过的,我看看
    码农哥哥:真晕,线下测试是好,线上有问题,有个配置错了,另外这个客户的数据比较奇怪,测试也没有验证过这种场景
    产品经理:XXXXXX,客户已经提故障了!
    码农哥哥:下次线上发布一定要叫上测试妹妹仔细回归

    码农哥哥:今天晚上12点产品更新,到时要你来回归验证啊
    测试妹妹:好吧
    测试妹妹:你们发布完了吗?都凌晨2点了,我什么时间可以回归验证啊?
    码农哥哥:再等等,还有一个小问题在搞。
    测试妹妹:现在好了吗?
    码农哥哥:sorry,没搞定,发布要回滚了,今天不需要回归验证了,你先回去吧
    测试妹妹:你妹啊!!!

    ------------------------------------------------------------------------------------------------------------------------------

    故事讲完了,以上就是一些项目敏捷开发中很常见的问题。

    敏捷开发强调的是快速迭代,通过快速迭代发布并验证产品是否满足用户需求来减少产品风险,而不是像传统软件一个花一年甚至几年才发布。敏捷开发在互联网行业里非常流行,大型网站基本每周都会有发布,甚至一周发布几次,超大型网站的应用都是分布式的,一天都可以发布上百个feature。
    互联网的需求变化很快,有些产品也是实验性的,所以更需要快速迭代,这也会导致许多产品在一些小的需求都没有需求说明书或者设计文档,全是靠产品经理与研发同学沟通需求,然后就快速发布上线了。这种模式在传统软件里是不可能,传统软件都会有很强的产品版本概念,并且会对每次升级都要制定详细的设计、开发、删除与发布计划。 

    面对互联网这种快速迭代,并且还有时缺少需求与设计文档的背景下,我们测试同学如何跟上节奏。如果按传统模式,测试与研发是不同的人员负责,那么必需要有清晰的需求设计文档,否则测试基本靠感觉。并且产品经理与研发同学还要与测试同学沟通需求,沟通项目计划与资源协同。第二,今天互联网的研发同学普遍比测试同学多很多,有些产品甚至是10:1以上或者是没有测试角色,这样的团队测试同学根本来不及了解需求细节,只能做一些核心主功能验证,对于边界测试没法顾上。总体看起来独立测试角色在敏捷开发里有点力不从心。

    经过几十年的发展,测试类型也细分成很多种,有白盒测试、黑盒测试、灰盒测试、单元测试、功能测试、集成测度、性能测试、压力测试、自动化测试、回归测试、灰度测试、安全测试、恢复测试等等概念。 当前业界的测试工具眼花缭乱,有QTP/UTF、LoadRunner、JMeter、Selenium、TestDirector、QACenter、Rational系列等知名产品,也有很多JUnit、TestNG、RobotFramework、gtest等测试框架,还有更多如网络、数据库、硬件等专业领域的测试工具。

    这些产品,除了JUnit、JMeter这类程序员可以轻松掌握的轻量级产品框架外,其它产品在敏捷开发中都感觉力不从心,主要原因是大部份产品为测试角色开发的,研发角色有学习成本,并且研发同学更喜欢白盒测试。

    如果测试的工作由研发来完成,这会更符合敏捷开发思想,大大减少沟通成本。但是问题来了,研发同学并不擅长使用各种测试工具,研发同学更多只会完成单元测试。如果能有一个专门面向研发同学的测试工具,岂不是很爽,那一个面向研发同学的测试工具应该是什么样的呢?我先说说程序员自测的一些现状:
    1.单元测试:目前JUnit、TestNG加各种Mock基本还能应付,就是测试代码写起来很多
    2.功能测试:这个很头疼,如果软件有界面,可以通过软件操作来完成核心功能测试,如果没有界面,就自己模拟软件对外API接口规约来模拟测试
    3.性能测试:这个要么使用JMeter这样专业工具来完成,实在不行,要不就自己再单独写一个程序或脚本来压测
    4.回归测试:不好搞,面对各种运行环境,人工回归太不靠谱了,真心需要一个全自动化的工具
    5.安全测试:太专业了,估计搞不定
    6.边界测试:写各种边界值来搞死自己,想到的就试试,没想到的就当不存在了
    7.bug管理:都自己测试了,还提个毛bug啊,自己老老实实把屁股擦干净

    从上面看起来,要是交给程序员自测也不靠谱啊,完全是靠感觉,凭经验测试了。

    如果有一款面向程序员自测的专业测试工具,它会是什么样的呢,我列了几点:
    1.学习成本低
    上手很容易,如果是框架,不要超过JUnit这样的难度吧,如果是产品,那应该有一套简单易用的界面,并且不要冒出很多测试概念,不要动不动就来1GB的安装文件,最好能免安装了。
    2.功能测试用例编写简单
    编写功能测试用例,不要只是简单的像bug管理那样写一堆文字描述,测试用例应该是可以运行的,编写完后就能直接运行、验证
    用例编写的语言应该非常简单易学,或者是直接用程序同样的语言(如JAVA、C、Python等),不要让我去学习一套新的语言或规范
    测试用例的代码应该很短,不要是我的业务程序写了100行代码,结果测试用例写了300行代码,这会很奔溃,可能会导致我花了大量的时间在调试测试用例脚本是否正确,如果测试代码小于程序代码的1/5就挺好。
    3.功能测试用例能同样显示测试代码覆盖率等信息
    单元测试可以比较简单的看到测试代码覆盖率,查看未测试到的代码。这个很有用,功能自动化测试希望也能看到这个,这样可以确认哪些地方没有测试到位。
    4.可重用,可扩展
        有些组件是已经写好的,测试用例应该能直接复用,比如java中一些标准jar包函数,或者是自己产品里封装的组件。这样对于编写测试就更高效了。
    扩展性要好,自己也可以封装一些测试组件,供别人使用或者模块公用。
    5.可以自动化回归测试
    面对各种环境:开发环境、测试环境、预发环境、生产环境A、生产环境B,自动化回归测试太重要了,最好是功能测试用例编写完后可以直接用在回归测试里,不要又单独写一套回测试用例。
    6.能自动造测试数据
    造测试数据很花时间,有时还需要造各种随机数据,另外各种边界数据也能自动化最好了,靠人想有时不靠谱的
    7.能支持UI自动化测试
    现在UI测试基本靠人工,Selenium之类的产品IDE比较简陋,语法也需要重新学习,学习成果不低,而且有点地方写起来很难受。需要能有更高效的UI自动化测试支持。
    8.调试方便
      编写测试用例脚本要有方便的调试功能,用例运行过程希望能显示详细的输出日志,特别是在用例运行失败的情况下,不然找问题很花时间。
    9.免费、开源
    你懂的

    最近自己团队也在做这方面的探索,希望能设计出一个适合程序员自测的专业测试工具与方案。 
    好了,写了这么多点,可能我孤陋寡闻,也不知道是否已经有这样专业的产品,谢谢推荐。
    展开全文
  • 敏捷sprint进程中测试任务的简要描述:   需求讨论:这个阶段测试人员要把自己带入到用户角色,列举用户角度的场景需求,协助开发和产品制定技术实现方案; 确认验收标准:为了避免sprint进行中产生的扯皮...

    对敏捷sprint进程中测试任务的简要描述:

     

    需求讨论:这个阶段测试人员要把自己带入到用户角色中,列举用户角度的场景需求,协助开发和产品制定技术实现方案;

    确认验收标准:为了避免sprint进行中产生的扯皮推诿,应当在需求讨论会上就确定验收标准。

    形成开发任务tag:形成测试tag,估算测试时间,形成概要测试计划。

    开发过程中:1.针对开发任务顺序,提前预备环境,数据等。这个过程往往在需求讨论时就已经开展。

    2.验收测试,反馈修改。这一阶段的重点词是“反馈”和 “现场验证”。及时而准确的反馈,是敏捷的灵魂,是开发和测试工作告诉运转的保证;“现场验证”是交付的终点,如果不做现场验证,即使在测试环境中通过也不能算作交付完成。

    3.站立会议。传达测试任务进度,了解开发进度,以便预先配置环境;针对测试任务提出问题/给出建议/寻求帮助;预估风险

    demo前一天:

    不再接受测试任务提交;

    对已通过功能现场回归测试一遍;

    完成次日测试环境数据的准备;

    总结会:

    针对上一个sprint不足,改进测试方法流程;

    发现团队不足,增强协作力。

     

    展开全文
  • 敏捷开发中测试

    2017-03-20 16:24:16
    敏捷开发过程,很多时候测试人员就时常被当成项目无法加快的阻力,一下这边爆一个bug,那边有个缺陷,所以项目经理痛恨测试,程序员们也巴不得测试快快放行,让程序好好上线,但我们都知道没有测好的东西是不能硬...
    敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。

    敏捷开发过程中,很多时候测试人员就时常被当成项目无法加快的阻力,一下这边爆一个bug,那边有个缺陷,所以项目经理痛恨测试,程序员们也巴不得测试快快放行,让程序好好上线,但我们都知道没有测好的东西是不能硬上的,测试这种把守项目上线最后一关卡的,若没有两把刷子,可能会时常变成项目延迟的炮灰。

    为了让测试的效率跟上项目开发的进度,需要抓住两个关键点:
    1. 品质是规划出来,非测试出来的
    测试在专案的早期就必须参加,熟悉需求,并从测试角度提出各种问题,确保产品经理、开发、测试的等角色的关注点都有备考量到,而测试也会从早期就开始撰写测试用例,在撰写过程中如果有发现任何问题也趁早反馈给产品经理、项目经理,趁早把问题给理清,这样做测试才能把自己的角色提升到为质量负责的角色。

    2. 落实自动化
    所有重复性的工作都应该被自动化,包含测试,如果你项目大多数的时间都花在基础功能测试,那效率肯定不会高的,所以测试环境、测试资料的准备应该都要有工具能辅助,各种测试用例如果是反覆发生且变动性少,绝对值得你花时间去撰写自动化脚本,而对于后端API接口的测试更是关键,一般的测试可能大多针对功能进行测试,但我们知道很多会露出被用户测到的bug,大多都不是点一点就能测的出来,很多都是因为API在某种情境下出错了,或在某种负载下出错了,这些靠人工非常难验证,透过自动化工具就相对简单多了。

    对于敏捷开发项目的测试而言,单元和集成测试是测试策略的关键环节。单元测试是验证最小和独立单元代码行为的过程,比如C++类,C函数,Ada包。这通常在系统测试之前进行。单元和集成测试是构建稳定减少错误应用程序的重要方法,因为它允许测试人员更容易模拟应用程序基本逻辑功能,并验证其是否满足设计需求。

    传统的单元测试,通常针对开发人员写的每个软件单元生成测试用例,执行这些用例验证代码功能的正确性。这种模式存在一定风险,因为开发人员在设计测试用例时,很容易受自己实现该代码的思维的影响,从而导致某些情况不能被考虑到或测试到。


    自动化测试工具,如:VectorCAST可支持C/C++语言(VectorCAST C/C++)和Ada(VectorCAST/Ada)的单元测试和集成测试。两者都可以自动化地完成单元测试和集成测试的关键步骤。包括测试驱动的生成,测试用例和测试结果的管理,以及自动化的回归测试。

    自动化的测试不仅大大提高了测试效率,而且自动化的客观性还能大幅提高测试的准确性。测试的自动化让敏捷开发更加“敏捷”!



    展开全文
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...

     敏捷软件开发是目前十分流行,并在业界逐步推广的软件开发模式。

       不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。
       其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。

    第一部分:敏捷软件开发简介

    敏捷软件开发(Agile Software Development)初起于九十年代中期。最早是为了与传统的瀑布软件开发模式(waterfall model)相比较,所以当时的方法叫做轻量级方法(Lightweight methods)。二十世纪初,17 位该方法的倡导者建立了敏捷联盟(Agile Alliance),并将该软件开发方法命名为敏捷软件开发过程。

    敏捷联盟在成立之初总结了四条基本的价值原则:

    1. 人员交流重于过程与工具(Individuals and interactions over processes and tools)
    2. 软件产品重于长篇大论(Working software over comprehensive documentation)
    3. 客户协作重于合同谈判(Customer collaboration over contract negotiation)
    4. 随机应变重于循规蹈矩(Responding to change over following a plan)

    基于这四点原则,敏捷软件开发有着自己独特的流程

    图  敏捷软件开发流程
    图 . 敏捷软件开发流程

     

    整个过程中夹杂了很多在敏捷开发前己经出现的软件开发方法,包括极限编程(Extreme Programming,1996)、Scrum(1986)、特征驱动开发(Feature Driven Development),测试驱动开发(Test Driven Development)等。这些方法在敏捷软件开发流程的各个阶段都有充分的体现和应用。

    例如,Scrum 主要着重于项目管理,团队中的项目经理(Scrum master)需要在每个客户需求到来的时候制定 Sprint 的周期,定义每个 Sprint 的目标、分派任务、进行监督、最后总结得失并开始计划新的 Sprint。

    相反,特征驱动开发和测试驱动开发主要被应用于 Sprint 周期中。如果项目进行于开发新功能时期,这个阶段主要推行特征驱动开发。所有测试和开发人员都将自己的工作重心放在新的功能上面,从开发和测试两个方面来完成各自的任务。如果项目进行于测试新功能时期,这个阶段需要将工作的重点挪到测试上来。所有的测试和开发人员都密切关注着目前版本的缺陷状况。测试人员需要在每天的站立会议(Daily Standup Meeting)上报告前一个工作日发现的新缺陷情况,项目经理根据项目进度和缺陷严重性来决定是否修复这些问题。需要及时修复的缺陷是目前 Sprint 中的一个新任务,将由项目经理添加到 Sprint Backlog 上并通知开发人员去修复漏洞。

    对于敏捷开发和测试中的审查过程,极限编程中的同行评审(peer review)思想得到了充分应用。代码和文档的审查追求简单而高效。团队成员两两组成一对,互相评审;有时候,一个开发和一个测试人员也可以组成一对,互相协作。这样能够有助于缺陷和问题在第一时间被抹杀在萌芽中。

    敏捷开发还有以下几个关键概念 (Key Issues):

    1. 迭代过程(Iterative process)
    2. 用户故事(User stories)
    3. 任务(Tasks)
    4. 站立会议(Stand-up meeting)
    5. 持续集成(Continuous integration)
    6. 最简方案(Simplest solutions)
    7. 重构(Re-factoring)

    这些概念是敏捷开发中经常使用到的观点和方法。下面我们将详细论述测试人员在敏捷软件开发中扮演的角色和职能。

     

     

    第二部分:敏捷开发中的测试人员

    本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

    2.1 敏捷开发团队介绍

    我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 2)。每天早上十点,在固定的时间和会议室里面,团队会举行站立会议。这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。

    图 2. 敏捷开发团队成员

    图 2. 敏捷开发团队成员

    由于敏捷开发要求参与人能够快速而高效得应对变化,所以无形中对测试人员提出很高的要求。

    2.2 测试人员需要具备的素质

    测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号:测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

    每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求:

    1. 具有质量检测和编写代码的能力–> 测试开发
    2. 具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员
    3. 具有开发和执行测试程序的能力 -> 软件质量工程师

    总结而言,有三方面的基本素质要求:代码编写(Coding)、测试 (Testing) 和分析 (Analysis)。

    在很多其他的开发流程中,各个测试阶段对测试人员的能力有所不同;有时候侧重分析(比如系统配置测试),有时候侧重代码编写 ( 比如功能测试 )。但是,在敏捷开发流程中,测试人员需要结合这三方面来开展工作,只有这样才能真正反映敏捷测试的本质:简单而高效得应对变化。

    2.3 测试人员的主要职责

    在敏捷软件开发中,测试人员的职责有三个主要方面:

    1. 定义质量 (Define Quality):这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流,从自己的经验出发,共同为产品功能制定质量要求。
    2. 交流缺陷(Communication):敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能,测试人员应该抓住细节,寻找设计中的“missing door”;另外,开发人员使用单元测试来保证产品的基本质量,测试人员可以使用验收测试(Acceptance Test)来鉴定客户需求与实际成果之间的不一致性。
    3. 及时反馈 (Feedback): 敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。这样一来,团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话,敏捷流程要求每天汇总质量问题。在我们的项目中,内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。另外,我们的测试框架提供自助测试 (Self-assistant Test):通过点击测试用例列表中的某个具体用例,开发人员不需要中断测试人员的工作就可以重现缺陷。

    以上总结了测试人员在敏捷开发中的需要展现的能力和担负的任务,下面请跟随一个项目实例来详细了解敏捷测试的最佳实践。

     

     

    第三部分:敏捷开发中的测试流程

    本部分结合一个软件项目,详细介绍项目流程中的主要测试活动,每个活动的前提条件和目标任务等。

    3.1 介绍项目实例

    项目介绍:根据一家在线 B2B 公司的要求,我们将为其开发一款类似于谷歌的搜索服务。作为 Web Service,该服务可以内嵌于网页中。当用户输入关键词并选择商户的类型和位置后,系统会返回具体商户的列表(参见图 3)。

    图 3. 项目实例图

    图 3. 项目实例图

    典型的敏捷开发和测试活动参见下表。它主要由三部分构成,从最初的用户故事设计和发布计划,到几次 Sprint 周期的迭代开发和测试,以及最后的产品发布阶段。每个时间段都有相应的测试活动。通常 Sprint 周期被分成两类:特征周期(Feature Sprint)和发布周期(Release Sprint)。特征周期主要涉及新功能的开发和各类测试。发布周期则会结合计划,确定新版本功能,然后对最新的功能进行测试。

    敏捷开发的主要活动 测试活动
    用户故事设计 寻找隐藏的假设
    发布计划 设计概要的验收测试用例
    迭代 Sprint 估算验收测试时间
    编码和单元测试 估算测试框架的搭建
    重构 详细设计验收测试用例
    集成 编写验收测试用例
    执行验收测试 重构验收测试
    Sprint 结束 执行验收测试
    下一个 Sprint 开始 执行回归测试
    发布 发布

    在迭代的 Sprint 周期中,开发部分可以根据传统步骤分成编码和单元测试、重构和集成。需要指出的是,重构和集成是敏捷开发的 Sprint 迭代中不可忽视的任务。如果在新的 Sprint 周期中要对上次的功能加以优化和改进,必然离不开重构和集成。

    在每个 Sprint 周期结束前,测试团队将提交针对该 Sprint 周期或者上个 Sprint 周期中已完成的功能的验收测试(在实际项目中,测试团队的进度通常会晚于开发团队)。这样一来,开发团队可以运行验收测试来验证所开发的功能目前是否符合预期。当然,这个预期也是在迭代中不断变化和完善的。

    当产品的所有功能得以实现,测试工作基本结束后,就进入了发布周期。此时,测试团队的任务相对较多。

    以上,我们概述了敏捷开发的主要活动。下面我们将对各阶段相应的测试活动作详细的介绍和分析。首先是用户故事设计和发布阶段。

    3.2 用户故事设计和发布计划阶段

    在用户故事和发布计划阶段,项目经理和产品经理会根据客户的需求,制定概要的产品发布日程计划。此时,测试人员可以和开发人员一起学习新的功能,了解客户的需求。其中,有两个主要活动:寻找隐藏的假设和设计概要的验收测试用例。

    3.2.1 寻找隐藏的假设

    正如前文所述,开发人员通常关注一些重要的系统功能而忽视细节。此外,敏捷开发倡导简单的实现方案,每个开发 Sprint 周期不可能将功能完美得实现;相反,每个 Sprint 都会增量得开发一些功能。所以,测试人员在最初就需要从各种角度来寻找系统需求,探索隐藏的假设。

    项目实例:

    1. 从在线 B2B 公司角度思考
    Q:这个搜索框对公司的业务有什么价值?

    A:搜索框可以为用户方便得提供商户的目录信息。如果越来越多用户使用这个搜索框,可以增加我们网站的访问量。
    1. 从用户角度思考
    Q:作为查询信息、寻找商业合作伙伴的网站用户,搜索框对我有什么好处?

    A:坏处:找到一家商户的地址,过去才发现已经关门歇业
    好处:查找商户很简单,只要轻点鼠标

    不快:有时候在寻找一类商户,却记不清楚具体名字
    1. 从程序员角度思考
    Q:一个搜索框的最简单实现方法是什么?

    A:一个有 text input 和 search button 组成的 form;后台通过 server 程序将符合类型和地址的商户名从数据库中取出,返回给用户;每个返回项包括商户的名称、地址和评价意见。
    1. 寻找这些观点中的问题
    Q:搜索框如何在用户忘记具体名字的时候提醒用户?

    A:在第一版本中实现比较困难。可以让用户输入至少一个类型来提高模糊查找的效果。
    1. 最后寻找到隐藏的假设

    以上的思考让测试人员对系统的隐含假设更加清晰:

    首先,系统应该能够在高峰时候处理 200 条搜索请求和 1000 个鼠标点击事件。

    其次,用户可以在已经查找到的内容中继续查找

    最后,系统提供一个商户类别清单;如果用户选择商户类别而忘记具体名字,系统提供模糊查询。

    在敏捷开发中,这些假设可以作为用户故事记录下来,从而指导未来系统的开发和测试。

    3.2.2 设计概要的验收测试用例

    定义完一系列用户故事后,测试人员就可以着手设计概要的验收测试用例。正如我们在前文论述,不同于单元测试,验收测试检查系统是否满足客户的预期,也就是用户故事是否能够实现。于是,测试人员可以根据每条用户故事来扩展,寻找其中的“动作”,然后为每条“动作”制定正例和反例。

    项目实例:

    动作 数据 期待的结果
    搜索 一组能成功搜索到的(类别,位置)数据 在该类别和位置条件下的一组商户信息
    搜索 一组不能成功搜索到的(类别,位置)数据 空列表

    3.3 迭代 Sprint 阶段

    当一个 Sprint 周期正式开始时,项目经理将制定该周期的具体开发和测试任务。在定期的 Sprint 计划会议(Planning Meeting)上,每位团队成员都要提供自己在未来一个 Sprint 周期中的休假和培训计划。另外,每个团队可以根据各自团队成员的能力和工作经验,适当设定一个工作负载值(Load Factor)。比如,我们团队的工作负载值为 75%,也就是说每个人平均每天工作 6 小时(以 8 小时计算)。接着,大家就可以开始分配任务。

    当开发团队开始编码和单元测试时,测试人员的工作重点包括:估算验收测试的时间、估算测试框架的搭建、详细设计验收测试和编写验收测试代码。第两个主要活动一般在项目初期的 Sprint 周期中完成。其他的三个主要活动将在接下来的多个 Sprint 周期中视情况迭代进行。下面我们将具体介绍每个主要活动。

    3.3.1 估算验收测试时间

    在软件开发初期,需要估算时间以制定计划。这一点在敏捷开发中应用更加广泛。如果以前的开发模式需要测试人员估算一个软件版本发行的计划(这样的计划通常会延续几个月),那么现在则要在每个 Sprint 机会会议上估算两周到一个月的任务。此外,在每天的站立会议上,测试人员需要不断得更新自己的估算时间,以应对变化的需求。所以,每个测试人员都应该具备一定的估算任务能力。下面我们将介绍两个通用的估算测试计划的方法:

    1. 快速而粗糙的方法

    从经验而言,测试通常占项目开发的三分之一时间。如果一个项目开发估计要 30 天 1 人,那么测试时间为 10 天 1 人。

    项目实例:

    搜索框的开发估计需要 78 天 1 人完成。但是,考虑到系统有模糊搜索的功能,所以测试任务可能会占 40%左右,大概 31 天 1 人。下面列出了具体的任务:

    任务 估计时间
    设计测试用例,准备测试数据(搜索数据集) 8
    加载数据集 2
    编写自动测试代码 18
    执行测试和汇报结果 3
    总结 31
    1. 细致而周全的方法

    这个方法从测试任务的基本步骤出发,进行详细分类。其中包括 :

    1. 测试的准备(设计测试用例、准备测试数据、编写自动测试代码并完善代码)
    2. 测试的运行(建立环境、执行测试、分析和汇报结果)
    3. 特殊的考虑

    项目实例:

    估算单个测试任务的事例参见下表:

    测试 准备 运行 特殊考虑 估算
    1 设计测试用例 0.5 建立环境 0.1    
      准备测试数据 0.5 执行测试 0.1    
      编写自动测试代码 0.5 分析结果 0.1    
      完善自动测试代码 2.5 汇报结果 0.1    
    总共   4   0.4 0 4.4

    估算多个测试任务的汇总参见下表:

    测试任务编号 准备 运行 特殊考虑 估算
    1 4 0.4 0 4.4
    2 4 0.4 0 4.4
    3 12 4.5 8.5 25
    4 4 0.4 0 4.4
    5 4 0.4 0 4.4
    6 4 0.4 0 4.4
    7 4 0.4 0 4.4
    总共   51.4

    3.3.2 估算测试框架的搭建

    测试框架是自动测试必不可少的一部分工作。由于敏捷开发流程倡导快速而高效得完成任务,这就要求一定的自动测试率。一个完善的测试框架可以大大提高测试效率,及时反馈产品的质量。

    在敏捷开发流程中,在第一个 Sprint 周期里,需要增加一项建立测试框架的任务。在随后的迭代过程中,只有当测试框架需要大幅度调整时,测试团队才需要考虑将其单独作为任务,否则可以不用作为主要任务罗列出来。

    项目实例:

    考虑该项目刚刚进入测试,需要为此建立一个测试框架。于是,在原先的估算中多增加一些任务。

    任务 估算(小时)
    选择测试工具 3
    建立测试系统 3
    编写下载、存放和恢复测试数据的脚本 2
    寻找或建立测试结果汇报工具 8
       
    设计具体的搜索测试用例 4
    准备搜索测试数据 4
    编写和测试“搜索”模块 3
    编写和测试“验证返回列表”的模块 1
    学习“在结果中搜索”的模块设计 4
    编写和测试“在结果中搜索”模块 4
       
    第一次执行测试 4
    分析第一轮测试结果 4
    第二次执行测试 4
    分析第二轮测试结果 4
       
    总共 52

    3.3.3 详细设计验收测试用例

    完成对测试任务的估算,接着就可以着手详细设计验收测试用例。我们可以对概要设计中的测试用例进行细化,根据不同的测试环境、测试数据以及测试结果,编写更详细的测试用例。另外,可以结合几个用例,完成一个复杂的测试操作。

    由于敏捷开发的流程是不断迭代的过程,所以很多复杂的功能可能会在未来的 Sprint 周期中被优化。对测试人员而言,一个有效的方法是尽量将一些验证基本功能的测试用例作为基本验证测试用例(Basic Verification Test Case)在第一时间实现自动化;而对一些复杂的功能测试用例,可以先采用手工的方法测试,直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。此外,对测试中出现的缺陷可以设计回归测试用例(Regression Test Case),为其编写自动测试代码,使得此类问题在发布周期(Release Sprint)时可以顺利而高效得进行验证。

    项目实例:

    基本验证测试用例:

    动作 数据 期待的结果
    登录 用户名:(空)
    密码:(空)
    “用户名和密码无效”

    功能测试用例:

    动作 数据 期待的结果
    登录 正确的用户名和密码 进入系统:请输入搜索条件并点击“搜索”按钮
    搜索 错误的类型 提示正确的类型
    搜索 使用正确的类型 商户列表

    3.3.4 编写验收测试用例

    敏捷开发不提倡撰写太多的文档,提倡直接编写测试用例。此外,测试人员和客户应取得良好的沟通,将这些需求总结下来,转化成验收测试用例。如果资源充足,最好对验收测试用例建立版本控制机制。

    考虑到需求在每一轮 Sprint 周期中会不断得变化,测试团队要控制测试的自动化率,正确估计未来功能的增减。自动化率过高会导致后期大量测试代码需要重构,反而增加很多工作量。

    3.4 Sprint 结束和下一个 Sprint 开始

    在一个 Sprint 周期结束时,团队要举行一个回顾会议(Retrospective Meeting)。团队成员可以在会议上畅所欲言,指出在过去一个 Sprint 周期中可行的,不可行的和有待改进的地方。待改进之处将在项目经理监督下于未来的 Sprint 周期中实现。

    由于敏捷开发倡导增量开发,当新的 Sprint 开始时,测试团队需要根据新 Sprint 周期的开发进度及时重构验收测试。如果新 Sprint 周期没有具体的新功能开发,测试团队可以将精力集中在执行验收测试和寻找缺陷上。

    如果下一个 Sprint 周期是发布周期,那么测试人员需要准备执行回归测试。下面我们来详细了解每个测试活动。

    3.4.1 重构验收测试

    正如上文所提及,敏捷开发是以迭代方式进行的,功能在每次迭代中推陈出新。于是,验收测试用例经常需要修改或者添加,相应的验收测试代码也需要删减。这部分工作如果时间花销很大,最好在估算的时候一并提出。

    项目实例:

    在下一个 Sprint 周期中,我们需要实现之前没有实现的“模糊查找”功能。测试人员要在新的 Sprint 周期中更新原来的验收测试用例,在测试“搜索”模块中添加模糊查找测试。重新估算的测试任务参加下表:

    任务 估计时间
    设计测试用例,准备测试数据(模糊搜索数据集) 2
    加载数据集 1
    编写自动测试代码 3
    执行测试和汇报结果 2
    总结 8

    3.4.2 执行验收测试

    验收测试可以分为两大类,基本验证测试和功能测试。如果是基本验证测试,推荐开发人员在运行完单元测试和提交代码前直接运行自动测试脚本。如果是功能测试,可以在每个 Sprint 后期,新功能代码提交后,由测试人员单独执行。

    敏捷开发的开发和测试是相辅相成的。一旦基本验证测试出现问题,那就说明开发人员的实现违反了最初客户定义的需求,所以不能够提交。如果功能测试出现问题,那么测试人员要及时与开发人员沟通。如果是缺陷,需及时上报给项目经理,并在每天站立会议中提出;如果不是,那么继续下一项任务。这个过程充分体现了敏捷开发所提倡的团队交流机制。

    3.4.3 执行回归测试

    在发布周期中,测试人员所肩负的任务非常重要,因为这是产品发布前的最后质量检验。

    首先,要建立一套自动生成 build、运行自动测试代码、手工执行测试用例并汇总测试结果的框架。估算方法参加上文。

    其次,定期执行各类测试,包括功能和系统测试。

    最后,要整理之前在每个特征测试周期中出现的问题。如果已经整理并归类为回归测试用例,那么只要定时执行就可以了;否则,需一一添加。如果用例已经被自动化,可以直接运行;如果是手工测试,测试人员需要按照测试用例进行操作,最后汇总测试结果。这部分测试就是所谓的回归测试。

     

     

    总结

    以上我们回顾了敏捷测试在整个项目开发中的基本流程。详细介绍了各阶段存在的主要测试活动,结合实际项目,叙述每个测试活动的最佳实践。

    最后,我们来探讨一下测试中的两个问题:手工测试和测试报告。

    手工测试和自动测试是两个主要的测试类型。考虑到敏捷开发的高效性,自动测试会优于手工测试。手工测试有两个主要的缺点:不可靠和容易被遗忘。比如,在文中的搜索实例中,一旦我们重新建立索引,那么先前在搜索文本中出现的文字错误就无法重现。另外,当测试人员按部就班得手工完成一个一个测试用例时,他们很容易遗忘一些特殊的测试用例,很多缺陷因此而被埋没。敏捷测试主张一些基本的验收测试可以被自动化;对一些涉及系统方面的测试,手工测试比较适合。

    测试报告是反映一个测试团队工作的最好成果。为适应敏捷开发的节奏,测试报告可以以网页的形式发布在内部的 web 服务器上,在一些问题区域上标注鲜明的色彩,用来警示团队中的每个人。

    综上所述,本文详细谈论了敏捷开发中测试的各项任务。希望本文有助于正在使用敏捷模式或者打算使用敏捷模式的团队更好得理解敏捷测试。

     

     

    附录:敏捷开发管理工具

    很早以前,就有这么一个想法:开发一套高效的、用于软件开发行业进行项目管理的管理型软件。之所以有这个想法,与我本人的经历有关。早年,在做**系统的时候,部门的总监就让我去做那么一套东西,基于Visual Basic和adodb,当时确实是经验、眼界、思路都不足,确实带着尝试和研究的心态去做了,只是限于以上的局限性,做出来的东西怎么说呢?显得很小家子气,因为没有做专门的界面设计,UI设计也不大气,在部门内部只能实现基于局域网的任务分发、周报编写和文档的上传。

    1、Leangoo,这个工具是我通过网络搜索了解到的,通过网站,我注册了一个账号,新建了一个product backlog并查看了网站现有的部分实例,总体来说,综合了敏捷开发管理的思路,视图清晰,感觉不错。

    2、Teambition,这个是之前就了解到过的一个软件,有网络版也有app版本。有任务管理、FAQ管理什么的,也还不错,但敏捷性管理的任务卡片、看板、燃尽图什么的概念在软件内好像没展现。给我印象最深的是FAQ,也许是和我本人的工作性质有关系,个人觉得这个模块比较实用。这些是之前的状况,不知道现在是否有改版,好久没有去看了,也许有更新吧。

    3、Worktile , 在Worktile中,我们进入的默认页面是“消息”这个IM,这个即时通讯功能正是沟通的体现。而在企业协作场景中,任务又是沟通后的最初成果,也是即将展开的各项工作的核心,而Worktile的核心就是任务这件事。

     

     

     

    ·



     

    展开全文
  • <br /> 今天浏览51testing,有个讨论是“敏捷开发中测试人员的工作成绩如何体现”,想想我们公司的项目不就是敏捷开发吗?需求不确定,经常改,做的差不多了,产品就交付,用户再提意见,再修改。看到有个人...
  • 敏捷开发测试流程

    2019-07-08 16:12:47
    1、敏捷开发:包含各个工程师并发进行 传统交付的流程: 低效率 客户不可以提前使用 无法相应需求变化 敏捷开发的迭代流程: 什么是敏捷开发 将一个项目的模块分为多个相互联系但是可以独立运行的小...
  • 最近发现被人盗版了多处, 重新发布在CSDN]最近读了《我和敏捷团队的五个约定》(from InfoQ),很是赞同,...在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践? 从敏捷团队的组建上来说,敏捷团
  • 敏捷开发模式,往往传统以功能测试为主的测试难以适应新的角色,而敏捷团队也面临着产品质量和快速市场的压力,需要通过快速的迭代抢占市场,但另外一方面质量的问题,又可能导致市场丢弃,这时,测试应尝试调整...
  • 敏捷开发:包含各个工程师并发进行 传统交付的流程: 低效率 客户不可以提前使用 无法相应需求变化 敏捷开发的迭代流程: 什么是敏捷开发将一个项目的模块分为多个相互联系但是可以独立运行的小项目,然后并行...
  • 敏捷开发与单元测试

    2009-06-23 10:37:00
    敏捷开发过程,项目的开发周期特别短,因此在质量和开发进度上会出现一定的矛盾,最突出的就是单元测试用例的编写。从项目的长期角度来看,单元测试用例对提供团队整理开发效率都有比较大的提升,同时还能提高...
  • 一、敏捷开发/测试的特征  1. 敏捷开发提倡迭代式和增量式的开发模式,并强调测试在其中的重要性。  敏捷开发模式的三个特点:依赖客户的参与、测试驱动以及紧凑的迭代开发周期。  2. 敏捷测试是协同测试的一...
  • 敏捷测试的特点

    2015-12-20 23:54:36
    敏捷测试的特点敏捷测试就是符合敏捷宣言思想,遵守敏捷开发原则,在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践,这些实践具有鲜明的敏捷开发的特征,如TDD、ATDD、结对编程、持续测试等。...
  • 测试驱动开发 TDD(Test-Driven Development)是敏捷开发的一项核心实践,同时也是一种设计技术和方法。1. 基本思想在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷...
  • 这几年关于敏捷开发在互联网企业越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 测试驱动开发 测试驱动开发基本思想是,开发人员先编写测试用例,再编写能通过用例的代码。就像砌砖师傅先用桩子拉上线再砌墙一样。 思想: • Test Driven Development测试驱动开发 • Acceptance Test...
  • 敏捷方法在软件开发中受到青睐,特别是在互联网应用服务系统的开发中,越来越多的公司采用敏捷方法,包括XP、Scrum、Lean、Crystal、FDD等。具体的敏捷方法在操作时有一些区别,但基本思想是一致的,如客户...
  • 在“敏捷开发过程,自动化工程师先对哪一部分功能进行优先的用例实现:可以从以下几个方面进行考虑:1.优先考虑数据对比类型的功能,这种功能人工操作比较费眼力和时间 2.优先考虑已经测试出问题的功能,这样...
  • 在08年的STP第6期杂志,Glenn Jones在《Fly into agile development with agile testing》一文敏捷开发中测试分为7种类型:(1)自动化回归测试(Automated regression test)运行自动化测试代码来验证当前的...
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。...
1 2 3 4 5 ... 20
收藏数 74,121
精华内容 29,648
关键字:

敏捷开发中测试如何进行