一、 开发和测试的通性困扰?
面对复杂性(客户):不断地修改计划、不断地增加预算、低劣的产品质量……
面对复杂性(项目组成员):经常加班到深夜、提交的产品不合格……
二、敏捷开发中的敏捷测试目的:
敏捷宣言
个体和交互比过程和工具更有价值;能工作的软件比全面的文档更有价值;顾客的协作比合同谈判更有价值;及时响应变更比遵循计划更有价值。其核心是:以人为本,发挥人的主观能动性.
三、传统测试和华为敏捷测试区分:
3.1 、传统的测试
1.守门员:质量保证者,阻止那些不可靠的、无效的、充满 BUG 的版本发布。
2.信息提供者:提供大量积极的、关于项目开发的状态的信息。告诉大家哪些功能正常工作、哪些功能不能正常工作、哪些 BUG 必须处理。
3.2 、 华为敏捷测试
测试和开发的角色界线变得模糊。有些人主要做测试工作,有些人主要做开发工作,但是在快速推进的过程中,所有人都会被号召起来测试或支持测试的工作。更多职责:帮助开发人员理解需求,尽早确定测试规范。
3.3 、 敏捷测试中测试人员扮演的角色
1.测试是项目的“车头灯”,它告诉大家现在到哪了,正在往哪个方向走。
2.测试为项目组提供信息,使得项目组基于可靠的信息作出正确的决定。
3.测试人员不作出项目发布的决定。
4.测试员不保证质量,整个项目组对质量负责。
5.测试不是抓虫子的游戏,它的目的不是纠缠在错误中,而是帮助找到目标。
四 、 敏捷测试用例的设计和评审要素:
4.1 、 基于需求的用例场景来设计测试用例:
1.基于需求的用例场景来设计测试用例是最直接有效的方法,因为它直接覆盖了需求,而需求是软件的根本,验证对需求的覆盖是软件测试的根本目的。
2.把测试用例当成“活”的文档,因为需求是“活”的、善变的。因此在设计测试用例方面应该符合敏捷的“及时响应变更比遵循计划更有价值”这一原则。
3.测试用例的设计不是一个阶段,测试用例的设计也需要迭代,在软件开发的不同的阶段都要回来重新审视和完善测试用例。
4.2 、 敏捷测试用例设计原则
通常我们所看到的测试用例的设计是其中一项。
测试用例可以写得很简单,也可以写得很复杂。最简单的测试用例是测试的纲要,仅仅指出要测试的内容,如探索性测试中的测试设计,仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像银行取款机系统中工作指令系统界面一样,会指定输入的每项数据,期待的结果及检验的方法,具体到界面元素的操作步骤,指定测试的方法和工具等等。
测试用例写得过于复杂或过于详细,会带来两个问题:一个是效率问题,一个是维护成本问题。另外,测试用例设计得过于详细,留给测试执行人员的思考空间就比较少,容易限制测试人员的思维。
测试用例写得过于简单,则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”,只是把需要测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测试计划,提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求,检验需求,并把对软件系统的测试方法的思路记录下来,以便指导将来的测试。
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键,也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
软件是开发人员需要去努力实现敏捷化的对象,而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则,则关键是考虑怎样使设计出来的测试用例是能有效工作的。
4.3 、 敏捷中测试用例评审:
1.同行评审是最敏捷的检查测试用例的方式,它主要强调测试用例设计者之间的思想碰撞、互补,通过讨论、协作来完成测试用例的设计,原因很简单,测试用例的目的是尽可能全面地覆盖需求,而测试人员总会存在某方面的思维缺陷,一个人的思维总是存在局限性。因此需要一起设计测试用例,从而体现敏捷的“个体和交互比过程和工具更有价值”。
2.除了同行评审,还应该尽量引入用户参与到测试用例的设计中来,让他们参与评审,从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。
备注:这里顾客的含义比较广泛,关键在于你怎样定义测试,如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是指对开发提供帮助和支持,那么顾客显然就是程序员了。
五、 华为常用敏捷的测试方法和测试流程:
1.进行敏捷测试主要分以下几个步骤:
敏捷测试采用的功能测试方法是我们常用的基本的测试方法,例如:
等价类划分、
边界值分析法、
错误推测法……
2.敏捷测试和传统测试不同的是:
需要高度的迭代工作、
频繁得到客户的反馈,
需要动态调整测试计划、
测试的执行。
3.敏捷测试过程中性能测试方法和考虑:
性能测试的方法?
性能测试、负载测试、压力测试、配置测试、并发测试
性能测试:通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生产性能要求。
负载测试:通过在被测系统上不断增加压力,直到性能指标,例如“响应时间”超过预定指标或者某种资料使用已经达到饱和状态。
配置测试:通过对被测系统的软/硬 件环境的调整,了解各种不同环境对系统性能影响的程度,从而找到系统各项资源的最优分配原则。
压力测试:测试系统在一定的饱和状态下,例如 CPU、内存等在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误。
并发测试:通过模拟用户的并发访问,测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
六 、 与您共勉
最后送大家一句话,兵无常势,水无常形,能因敌变化而取胜者谓之神,相信在测试的过程程中只有找对了方法,不管是传统的测试还是现当今国外比较流程的敏捷测试,只要应用得当就是好的测试。
欢迎加入 51软件测试大家庭,在这里你将获得【最新行业资讯】,【免费测试工具安装包】,【软件测试技术干货】,【面试求职技巧】... 51与你共同学习,一起成长!期待你的加入: QQ 群: 755431660