敏捷中测试如何开展.docx

敏捷中测试如何开展.docx

《敏捷中测试如何开展.docx》由会员分享，可在线阅读，更多相关《敏捷中测试如何开展.docx（14页珍藏版）》请在冰豆网上搜索。

敏捷中测试如何开展

敏捷中如何测试

1前言

在《第一次把情形做对》中讲到的三种做事的方式：

明明只是应付转变，是事后拯救型的：

出了问题才去灭火；聪聪想到了转变，但只是为转变而转变，是一边灭火一边想着防火；慧慧那么是使自己处于应变的状态当中，随时预备转变，是一边认真地防火，一边随时预备着灭火。

最终慧慧以最小的代价达到了目标。

咱们软件测试又如何才能以最小的代价才能达到目标呢？

从事软件测试行业的FrancisZhou（FrancisZhou毕业于加州大学系统圣克鲁斯分校。

他于2000年加入微软，曾在总部前后担任软件开发测试工程师及测试组长等职务，参与了WindowsXP及WindowsPresentationFoundation的开发。

2005年初他正式加入微软亚洲工程院并前后参与了TTS,MicrosoftSpeechServer,ActiveSync,GamesUX等项目的开发及测试）谈到刚加入微软什么缘应选择测试时回答到：

“我感觉在那个领域有专门好的进展前景。

此刻软件测试大多数还只是停留在找bug时期，而若是真的要做好产品的话要在bug还没显现以前就将其杜绝，这才是软件测试的以后。

”

正如FrancisZhou描述咱们软件测试的以后，杜绝bug，咱们的测试付出的代价确实是最小的。

因此，咱们的软件测试目标不是找bug，而是预防bug，零缺点是咱们测试的最终目标。

再回到敏捷中，业界一样以为敏捷是XP编程，是SCRUM项目治理，更是一种精益求精的思想。

咱们零缺点的目标确实是一种精益求精的思想。

那么，在实际敏捷项目中，测试活动如何开展，如何才能杜绝bug。

2敏捷模式

常见的敏捷开发模式图：

需要强调一下，敏捷之思想。

那个地址描述的，只是一种经常使用的软件开发模式。

在咱们实际项目中，需要依照自己项目和团队的特点，定制该项目的软件开发模式；实践活动更在于神。

正如咨询公司TH的工程师Eric所描述的：

若是都是一群超级牛的人，软件编码和设计技术超级强，那么TDD活动就没有必要开展。

这些活动的开展，都是以价值为驱动的。

3一体化团队

团队，大伙儿都明白，一个是团队，有一起的目标是必然的。

同时，一个团队还应该具有：

自主性、试探性、合作性。

若是SE做SE的设计，开发做开发的code，测试做测试的版本，资料做资料的版本，如此不同角色不可能达到一致的目标。

犹如候车厅等车的一群人，目的尽管都一样是侯车，可是方向却是东南西北。

敏捷中提倡组建的团队，是价值驱动型的，是自发式治理模式。

团队要紧角色

敏捷团队角色

角色要求

备注

PO（产品负责人）

ProductOwner代表了客户的意愿。

这保证了Scrum团队在做从业务角度来说正确的事情。

产品负责人编写用户故事，排出优先级，并放入ProductBacklog。

ScrumMaster

ScrumMaster促进Scrum过程，他的主要工作是去除那些影响团队交付迭代目标的障碍。

ScrumMaster并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。

Team

负责交付产品的团度。

具有跨职能技能的人（设计，开发，测试、资料等）组成的小团队完成实际的交互工作。

在实际项目运作中，提倡能者居其职，发挥个人最大能量，激发团队最大潜力。

在目前试点的各个项目中实践中，角色之间不是区分那么明显，一个团队的成员能够承担多个角色。

测试人员定位

在敏捷项目中，测试人员如何定位，如何融入到一体化团队，发挥测试人员的技术，同时弥补自身技术的不足。

一、敏捷中咱们测试人员又叫QA（质量保证）。

因此，从项目一开始就需要让全员达到一致：

关注质量，随时构建质量，形成零缺点文化。

二、引导全员都关注质量，团队成员技术互补给团队带来壮大合力，从不同角度关注质量，预防bug，充分激发团队潜力。

三、开发和测试紧密合作，形成技术互补，协助开发人员完成LLT，幸免开发老是测试不出问题现象，和测试不充分的情形。

四、测试人员更能够从用户角度动身，引导开发人员能够从用户的角度去试探和设计软件实现。

五、测试人员能够从架构预演等方式，从整体上把握产品，及时提出架构上的问题，和一些组件化开发的共享。

六、提高开发技术，做到人力备份。

同时，也能够提高自动化设计效率。

七、及时反馈，持续改良。

测试人员需要对story及时反馈，以便团队的及时改良和持续改良。

优秀实践

要紧介绍一下中软的一个项目的一体化团队怎么组建的。

一样，在很多实践项目中，采取这种组建特性化团队实践是比较成功的，也取得了专门好的成效。

一、建面向特性的交付团队

由SE、TSE、开发人员、测试人员、资料开发人员组成的特性团队，团队对最终交付结果负责，团队Leader称为DomainManager。

1）DM统一安排开发和测试工作，做到按特性为单位交付，促使问题快速闭环，以便缩短交付周期。

2）必要时开发人员能够从事测试工作，测试人员也能够从事开发工作，完全打破开发和测试之间的部门墙，做到了开发和测试人员的资源利用最大化。

3）团队不对测试进程进行考核，对最终交付结果负责，极大程度减少开发和测试的内耗。

4）开发和测试不断彼此渗透，开发更懂测试、测试更懂开发，团队整体能力比较以前大幅增强。

二、开放式办公区

同一个特性团队围绕同一张桌子办公，桌子周围墙壁悬挂白板。

特性相关人员可随时随地交流，大幅程度降低沟通本钱。

三、组织结构

（1）、敏捷团队中不存在纯粹的资源线角色，DM兼开发PL的角色，开发代表兼开发PM的角色，测试领导兼测试PL的角色，资料人少，资料PL为STDT的资料领导（不在敏捷团队中）。

（2）、DG团队能够随着项目情形动态组建和转变，DM能够来自开发，也能够来自测试。

（3）、若是DM来自开发，那么DM能够授权给测试领导负责敏捷测试治理；若是DM来自测试，DM能够授权开发PL负责敏捷开发部份治理工作。

（4）、TL为团队内的开发骨干，进行核心代码编写。

（5）、版本TSE，TSE为测试骨干，要紧负责产品/特性测试分析，测试方案和策略，自动化分析和设计，自动化框架搭建，专项测试分析和设计等。

（6）、DG中所有开发人员被DM考核，测试、资料由对应的资源部门主管考核，业务主管为考评第一相关人，具有考评否决权。

4敏捷之测试

大伙儿都明白，如何才能让软件正常的工作，那确实是测试，测试，再测试。

这也是表现咱们测试价值之所在。

QualityFunnel：

从图能够看出，软件测试活动需要贯穿整个软件生命周期，因为其价值在于发觉该时期的bug。

从散布图能够发觉，咱们传统测试发觉的bug应该最少，可是，往往在咱们测试时期，发觉的问题太多，缺点无法收敛，付出的本钱太高，而且致使更多的问题遗留到现场。

因此，在整个软件测试活动进程中，咱们测试人员拥有更专有的测试技术，应该占主导地位。

测试用例分层

在敏捷项目中，持续集成是最关键的实践活动之一。

若是持续集成中没有测试用例run，那么也就不叫持续集成了。

因此，在敏捷中测试用例分层是超级重要的。

（1）单元测试用例

持续集成超级强调单元测试，TDD实践。

可是需要明确：

单元测试用例执行是毫秒级别的。

不然，执行的测试用例就不是UT测试用例，或架构或工具选择有问题。

（2）冒烟测试用例

一样由开发人员完成测试，总用例数的比例低于10%。

以便保证该测试时期时刻也超级短。

（3）用户同意测试用例

测试人员验收story的测试用例。

一样要求覆盖要紧场景。

（4）功能测试用例

和CMM中的功能测试用例，要求进行全面的测试。

（5）非功能测试用例

要紧包括性能测试用例、靠得住性测试用例等非功能测试用例。

这些测试用例分层，是为了更好地支持敏捷中各个时期的测试活动开展。

自动化测试

持续集成中，没有自动化，测试用例也就无法run起来，因此，自动化测试是敏捷测试中的关键。

一个项目中的自动化测试是不是成功有效开展起来，自动化的测试框架是关键。

自动化测试框架又依托于咱们的产品框架。

目前业软产品的技术框架主流是业务解耦和业务分层。

因此，自动化测试关键也在于分层，专门是咱们业软产品很多都是BS结构的。

敏捷开发模式下单元测试活动相关介绍很多那个地址再也不描述。

那个地址要紧描述基于功能测实验证的。

如安在不同时期开展功能测试。

那个地址引入业务功能单元测试概念。

咱们把一个业务功能能够看出有多个业务功能单元的集合体。

如此咱们就能够够把不同业务功能单元放在不同时期进行测试。

关于一样B/S结构产品，一个完整的业务功能大致能够划分为三个业务功能单元：

UI功能单元（界面视图）；操纵功能单元（要紧表现形式：

Action接口）；业务逻辑处置功能单元（要紧表现形式：

WebService接口，API接口，SQL接口等）。

另外每一个业务功能单元还能够进一步细化为子功能业务单元。

划分的原那么是便于测试的开展，专门是自动化测试开展。

同时，分层的同时不同时期也需要不同的工具支撑，如下是业界场景的一些测试工具。

测试类型

Tools

UnitTesting

NUnit,JUnit,Mock,DBunit

IntegrationTest

Unittesttools,

HttpUnit,SoapUI,

RESTClient

SystemTesting

Selenium，Fit，WET，Watir，WatiN

RegressionTesting

Unittesttools，Systemtesttools

AcceptanceTesting

FIT，FitNesse

SmokingTesting

Regressiontesttools

LoadTesting

JMeter，Httperf，loadrunner

E2E测试

咱们软件要实现的是客户的需求，表现的是客户的价值。

在CMM模式下，咱们的需求跟踪是严谨的，咱们的测试是严格的。

可是，交互给客户的产品却不是客户当前所要的。

在研发流程中，需求失真的可能性仍是存在的。

因此，咱们不能不面对如此一个残酷的现实：

（1）客户往往提交给咱们研发的需求往往是概念型的，客户是慢慢发觉他们真正想要的。

（2）研发人员对产品的需求明白得失真，同时研发人员也只能慢慢发觉客户想要的。

（3）同时，客户的需求还存在转变的可能。

因此，拥抱转变是咱们唯一不变的。

咱们只能当“慧慧”，使自己处于应变的状态当中，随时预备转变，是一边认真地防火，一边随时预备着灭火。

咱们的宣言是：

不怕转变。

说明：

E2E测试全流程实践中，需要依照具体项目情形选择实践活动。

实践活动，是为流程效劳的。

分层测试

一、分层概念

分层测试，即在不同时期开展不同的测试活动。

V模型表现了设计分层和测试执行分层的概念，一样适合于敏捷模式。

不同时期的测试活动如下：

What

Who

Wen

Automation

UnitTesting

Developer

Coding

Always

IntegrationTest

Developer

Coding

Always

SystemTesting

Tester

Test

Possible

RegressionTesting

Developer/Tester

Build/Test

Possible

AcceptanceTesting

Client/Users

Deployment/

Delivery

Possible

SmokingTesting

Tester/SupportEngineer

Deployment

Possible

LoadTesting

PerformanceEng