敏捷中测试如何开展文档格式.docx
《敏捷中测试如何开展文档格式.docx》由会员分享,可在线阅读,更多相关《敏捷中测试如何开展文档格式.docx(14页珍藏版)》请在冰豆网上搜索。
咱们零缺点的目标确实是一种精益求精的思想。
那么,在实际敏捷项目中,测试活动如何开展,如何才能杜绝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
Developer
Coding
Always
Tester
Test
Possible
Developer/Tester
Build/Test
Client/Users
Deployment/
Delivery
Tester/SupportEngineer
Deployment
PerformanceEng