软件测试就是软件测试工程师验证软件是否满足用户的需求
(1)开发:广度小,专业度高
测试:所需技能广泛,但是专业度低
(2)软件测试和软件调试
目的不同
–测试的任务是发现程序中的缺陷;调试的任务是定位并且解决程序中的问题。
参与角色不同
–测试主要是由测试人员和开发人员来执行,黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。调试由开发人员完成。
执行的阶段不同
–测试贯穿整个软件开发生命周期,调试一般在开发阶段。
综合能力:沟通能力,学习能力,开发能力,文字能力,自动化测试技术,编写测试用例的能力,探索性思维
感兴趣
承受压力,承担责任
用户的期望和满足合同(文档,规则,标准)规定所需要的条件和权限
用户需求和软件需求
软件需求是用户需求转化而来的,它是用户需求的细化
用户需求比较粗略,直接实现会有困难,因为没有细节,所有需要软件需求把用户需求细节实现和规范,把用户需求变成一个具体的可实现的过程文档。
验证需求,保证需求正确可实现。细化需求,从需求中提炼出一个个测试项。
问题:软件测试人员如何深入了解需求?
从需求分析阶段就开始介入了解需求,站在用户需求的角度
1.不同浏览器下,验证登陆页面的显示以及功能的正确性。
2. 相同浏览器的不同版本,验证登陆页面的显示以及功能的正确性
3. 不同移动设备终端的不同浏览器下,验证登陆页面的显示以及功能的正确性。
4. 不同分辨率的界面下,验证登陆页面的显示以及功能的正确性。
测试用例就是向被测试系统发起的一组集合,包含测试环境,测试数据,测试步骤,预期结果,(重要性、优先级、操作方式、标题等)
优点:衡量需求的覆盖率;复用性,借鉴意义;可以用于回归测试;防止遗漏测试需求
当且仅当,规格说明是存在的并且正确,程序与规格说明之间的不匹配才是错误。
当没有需求规格说明书时,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时,就是软件错误。
需求分析——计划——设计——开发——测试——运行维护
特点: 阶段性强,每一个阶段比较独立;看重前期的分析需求和后期的测试。
缺点:测试在编码后才开始介入,导致前期的问题后期才发现,失去及早纠正的机会。
适合于项目庞大,风险大,复杂度高。
特点:强调每一个迭代的测试质量和风险分析,抗风险能力强
缺点:风险管控人力物力投入很多,成本比较大。
增量通常和迭代混为一谈,但是其实两者是有区别的。
增量是逐块建造的概念,例如画一幅人物画,我们可以先画人的头部,再画身体,再画手脚……而迭代是反复求精的概念,同样是画人物画,我们可以采用先画整体轮廓,再勾勒出基本雏形,再细化、着色。
特点:抗风险能力强
《敏捷宣言》:
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中,后者并非全无价值,但我们更看重前者。
特点:轻文档,轻流程、重目标、重产出、拥抱变化。
基本流程:
scrum里面的角色:
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
其中product owner负责整理user story(用户故事),定义其商业价值,对其进行排序,制定发布计划,对产品负责。
scrum master 负责召开各种会议,协调项目,为研发团队服务。
研发团队则由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品。
(1) 产品负责人负责整理user story,形成左侧的product backlog。
(2) 发布计划会议:product owner负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,sprint backlog。
(3) 迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,每个任务都有明确的负责人,并完成工时的初估计。
(4) 每日例会:每天scrum master召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。
(5)演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。
(6)回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改
进的效果。
特点: 每一个阶段独立性强
左边每一个阶段是右边测试阶段的依据,和右边每一个测试阶段一 一 对应。
瀑布模型变种(缺点):测试在编码后才开始介入,导致前期的问题后期才发现,失去及早纠正的机会。
W模型特点:每一阶段独立性强,测试的对象不仅是程序,需求、设计等同样要测试,测试与开发是同步进行的。
局限性:需求、设计、编码等活动被视为串行的;测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临困惑。