2011-10-27 08:41:23 VipWangJian 阅读数 93
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10600 人正在学习 去看看 CSDN讲师
测试的主要任务是设计功能用例和非功能测试用例,同时要开发自动化测试代码或测试脚

本,代码和脚本必须要进行Review,并应该要调测通过能够运行,最后才能check in到配

置库加入到持续集成环境中。

用例设计前可能需要考虑必要的测试策略和测试方案。

(关于功能用例和非功能用例,也许项目现在还无法实现测试自动化,此时的主要任务还

是在设计和完善测试用例上。但必须明确的是能否自动化测试是敏捷项目能否成功的关键因素

之一。)

(1) 资料开发可能会分成两类:

一类是针对单个Story的资料写作,它需要伴随Story开发同步提交,如果可能也要加入到持续集成环境中;
另一类是无法随Story同步提交的端到端资料开发,此类任务需要在迭代前准备阶段明确并体现在E2E迭代计划中。

输出的资料必须得到SE、开发、测试以及资料人员的Review。
2014-04-19 09:07:07 u011790275 阅读数 1159
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10600 人正在学习 去看看 CSDN讲师

前言:

本篇文章主要是讲述以精益敏捷开发的思维, 经由表格式的测试用例, 使团队成员能更高效的协作,更即时的能识别出不清楚的需求◦

 

本文:

  精益敏捷开发 V.S. 传统的软件工程开发:

     相较于传统的软件工程; 如: 面向对象的开发模式, 精益敏捷开发更强调的是 “团队中各不同角色间的协同合作” 与 “团队成员的自主性”◦

所以, 在实施精益敏捷开发的团队, 假如, 在写文档的过程中, 无法使团队中各不同的角色间协同合作, 则团队便极有可能, 还是在用传统软件工程的思维与作法在实施精益敏捷开发◦如此的作法, 显然将无法激发起团队成员的自主性, 更糟糕的是, 还极有可能使团队在实质上, 依旧是停留在低效的瀑布式开发模式◦

 

  精益敏捷开发的作法:

    精益敏捷开发是以测试驱动需求; 以测试用例审视需求是否已明确? 是否已可进行设计/开发?

    所以, 精益敏捷开发的重点工作之一便是, 如何能经由团队的协作进行测试用例设计, 以激发起成员的自主性, 进而能即时的识别出不清楚的需求, 以能有效的降低项目开发的风险◦

精益敏捷开发为提升“团队协作” 与 “成员的自主性”, 主要的作法之一便是: 采用 “表格式” 的测试用例◦

如下例; User Story: Check Out CD◦

“我是 CD 出租店的店员, 我期望能经由 User Story: Check Out CD, 纪录客户出租 CD 的资料, 并能打印出收据, 请客户签字◦”

 

 针对User Story: Check Out CD, 我们设计了“表格式” 的测试用例, 这其中包括:

1.         输入数据表 (Given)

Customer Data

Name

ID

James

007

 

 

CD Data

ID

Title

Rented

Rental Period

CD2

Home Land

No

2

 

2.         业务规则表 (Rule)

每个客户至多可租 3 片 CD

客户目前所租的 CD

是否可再租

CD2, CD3

Yes

CD2, CD3, CD4

No

    

3.         业务运算表 (Calculation)

计算客户 CD 归还日期

Start Date

Rental Days

Due Date?

Note

2011/1/21

2

2011/1/23

 

2012/2/28

3

2012/3/2

Leap Year

2010/12/31

4

2011/1/4

New Year

 

4.         操作过程/ 事件表 (When)

Check out CD

Enter

Customer ID

007

Enter

CD ID

CD2

Press

Submit

 

Check

Message

Check out CD Successfully

               

Start Date

2011/1/21

 

5.         预期结果 (Then)

CD Data

ID

Title

Rented

Customer ID

Rental Due

CD2

Home Land

No

007

2011/1/23

 

 

Receipt

Customer ID

Customer Name

CD ID

CD Title

Rental Due

007

James

CD2

Home Land

2011/1/23

 

  结论:

1.         “表格式” 的测试用例, 使得团队中的各不同的角色; 如:使用者, 需求分析人员, 开发人员, 测试人员, 均可面对面, 或以远程接入的方式, 共同协作, 使测试用例的设计更加的完备◦

2.         “表格式” 的测试用例, 使得团队成员可经由无法确认的 “栏位”, 便可识别出不清楚, 不明确的需求◦

 

所以, “表格” 使团队得以协作◦

“栏位” 使团队得以识别出不清楚, 不明确的需求◦

方法很简单, 却很实用且很轻量级◦

 

欢迎你来试试!

2009-06-23 10:34:00 xrqiu 阅读数 1008
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10600 人正在学习 去看看 CSDN讲师

在敏捷开发过程中,项目的开发周期特别短,因此在质量和开发进度上会出现一定的矛盾,最突出的就是单元测试用例的编写。从项目的长期角度来看,单元测试用例对提供团队整理开发效率都有比较大的提升,同时还能提高代码质量、减少程序缺陷。如果我们对测试用例的编写把握不好的话,也会给开发效率带来一定的影响,那么我们应怎样去把握测试用例编写的度呢?下面总结了几点关于单元测试编写的原则:

  1. 为主要的、关键的逻辑组件,关键的逻辑方法进行测试驱动开发

   这样对设计、设计演化很有帮助。

2. 结对编程的方式测试用例让另一个同事来完成。

   更好的发现程序设计及接口设计中的一些缺陷。

  3. 逻辑类似的组件如果存在多个,优先编写其中一种逻辑组件的测试用例

     实践中可能会出现一些组件在逻辑上可能完成差不多的功能(例如类型转换帮助类),可以先只编写其中一种组件的 测试用例以节省时间。

  4. 发现 Bug 时一定先编写测试用例进行 Debug

     在测试和调试之间众说纷纭,最好是先编写测试用例找出这个 Bug,越复杂的系统,测试越发杂,单元测试能更好的模拟参数边界值。

  5. 关键util工具类要编写测试用例

     不要忽视了这些帮助类、基础类的正确性和运行效率。

  6. 保持测试用例与逻辑代码同步

     这里说的“同步”主要包括了测试方法和实现方法的同步;测试用例注释和逻辑代码注释的同步。

  7. 保证测试用例的独立性

     让测试用例独立的可执行,尽量不要依赖其他的测试用例。这样才能让 TDD 与设计保持良好的协作。

  8. 测试过程中,适当的引入Mock 是必不可少的,最好还是提供一个集成测试用例。

     使用 Mock 可以让接口的设计得到快速验证与反馈,也对团队的平行开发提供便利。

2007-09-25 21:24:00 Testing_is_believing 阅读数 6250
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10600 人正在学习 去看看 CSDN讲师

敏捷测试用例设计

 

陈能技

2007-9-20

 

敏捷宣言:

个体和交互比过程和工具更有价值;

能工作的软件比全面的文档更有价值;

顾客的协作比合同谈判更有价值;

及时响应变更比遵循计划更有价值。

- www.agilemanifesto.org

 

并非每个企业都能严格按敏捷的相关开发方法进行项目管理,例如测试驱动、XPSCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓,我认为很多方法、很多地方都可以应用敏捷的思想,实现敏捷的管理。

 

测试用例的设计是其中一项。

 

测试用例的粒度

测试用例可以写得很简单,也可以写得很复杂。最简单的测试用例是测试的纲要,仅仅指出要测试的内容,如探索性测试(Exploratory Testing)中的测试设计,仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样,会指定输入的每项数据,期待的结果及检验的方法,具体到界面元素的操作步骤,指定测试的方法和工具等等。

 

测试用例写得过于复杂或过于详细,会带来两个问题:一个是效率问题,一个是维护成本问题。另外,测试用例设计得过于详细,留给测试执行人员的思考空间就比较少,容易限制测试人员的思维。

 

测试用例写得过于简单,则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”,只是把需要测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测试计划,提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求,检验需求,并把对软件系统的测试方法的思路记录下来,以便指导将来的测试。

 

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键,也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

 

软件是开发人员需要去努力实现敏捷化的对象,而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则,则关键是考虑怎样使设计出来的测试用例是能有效工作的。

 

基于需求的测试用例设计

基于需求的用例场景来设计测试用例是最直接有效的方法,因为它直接覆盖了需求,而需求是软件的根本,验证对需求的覆盖是软件测试的根本目的。

 

要把测试用例当成“活”的文档(Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin),因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。

 

不要认为测试用例的设计是一个阶段,测试用例的设计也需要迭代,在软件开发的不同的阶段都要回来重新审视和完善测试用例。

 

测试用例的评价

测试用例设计出来了,质量如何,如何提高测试用例设计的质量?就像软件产品需要通过各种手段来保证质量一样,测试用例的质量保证也需要综合使用各种手段和方法。

 

测试用例的检查可以有多种方式,但是最敏捷的应当属临时的同行评审。我认为同行评审,尤其是临时的同行评审,应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”,要强调测试用例设计者之间的思想碰撞,通过讨论、协作来完成测试用例的设计,原因很简单,测试用例的目的是尽可能全面地覆盖需求,而测试人员总会存在某方面的思维缺陷,一个人的思维总是存在局限性。因此需要一起设计测试用例。

 

除了同行评审,还应该尽量引入用户参与到测试用例的设计中来,让他们参与评审,从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛,关键在于你怎样定义测试,如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是指对开发提供帮助和支持,那么顾客显然就是程序员了。

 

因此,参与到测试用例设计和评审中来的人除了测试人员自己和管理层外,还应该包括最终用户或顾客代表,还有开发人员。

 

 

测试用例数据生成的自动化

在测试用例设计方面最有希望实现自动化的,要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现,但是数据则不同,数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。

 

很多时候,测试用例的输入参数有不同的类型、有不同的取值范围,我们需要得到测试用例的输入参数的不同组合,以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛,我们又需要科学地筛选出一些有代表性的数据,以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。

 

可利用一些工具,例如TConfig、PICT等来产生这些数据。

 

在性能测试、容量测试方面,除了设计好测试用例考虑如何测试外,还要准备好大量的数据。大量数据的准备可以使用多种方式:编程生成、SQL语句生成(基于数据库的数据)、利用工具生成。

 

工具未必能生成所有满足要求的数据,但是却是最快速的,编程能生成所有需要的数据,但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具,例如DataFactory等。

 

 
2014-06-09 23:33:29 u011790275 阅读数 625
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10600 人正在学习 去看看 CSDN讲师

测试用例的设计,往往面临场景遗漏或覆盖过度的问题◦

此份材料,便是在探讨如何利用视觉化的工具;看板与表格;使领域专家,测试人员与开发人员可共同的协作,设计测试用例并识别Sprint 中该执行那些测试用例◦

以期望能经由集体的智慧,设计出有效性高的测试用例,并使各Sprint中的测试时间,均得到最充分的利用 ◦

附件:视觉化测试用例设计

敏捷开发,SIT测试

阅读数 256

敏捷开发中的测试

阅读数 399

没有更多推荐了,返回首页