赞
踩
①需求
IEEE规定:软件需求是(1)用户解决问题或达到目标所需 条件或权能。(2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。一种反应上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求,非功能性需求对设计和实现提出了限制,比如性能要求,质量标准,或者设计限制。
在多数软件公司,会有两部分需求:用户需求和软件需求。
用户需求:可简单理解为甲方或者终端用户提出的需求,该需求一般比较简略。
软件需求:又叫功能需求,该需求会详细描述开发人员必须实现的软件功能,大多数情况下软件需求将作为测试和开发的工作依据。
软件需求分析点:
技术角度分析:
技术上是否可行,人力/资金投入成本
是否存在较大的市场需求
成本和受益的占比
②测试用例
测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素。
测试用例解决了测什么和怎么测这两大问题。
③Bug
1️⃣当且仅当产品规格说明书存在且正确时,程序的实现与规格说明书要求不匹配的时候,那就是软件错误。
2️⃣当产品规格说明书没有提到某功能时,以用户为准,也就是说,当程序没有实现其用户合理预期的要求是,那就是软件错误。
④产品的生命周期:
需求分析
市场分析、投入和收益的占比、技术上实现是否可行
计划
什么时候开始?什么时候结束?
设计
将一个大的需求拆分成一个个具体可实施的任务。(设计哪些接口,采用什么框架,采用哪些技术...)
编码
开发人员参考需求文档和技术文档等资料来进行代码开发
测试
测试人员参考测试用例来设计测试。
运行维护
修复性维护:对项目中发现的问题要及时进行修复;
完善性维护:对功能进行完善;
预防性维护(居安思危):为了避免产品在线上运行期间出现意想不到的问题,需要进行一些预防的手段。
⑤软件测试的生命周期
需求分析
测试人员需要站在用户角度思考问题:软件需求是否合理?
技术角度思考问题:技术上是否可行?是否还有优化空间?
测试的角度思考问题:是否存在业务逻辑冗余/冲突
测试计划
什么时候开始测试,什么时候测试结束,耗时多久。
测试设计与开发
写测试文档,明确标注使用到的测试方法、测试工具、测试形式等。参考需求文档、技术文档等编写测试用例。
测试执行
充分利用测试用例和其他工具对项目尽可能做到全方位的测试。
测试评估
评估产品是否存在其他的质量问题以及功能演示。
使用场景:需求固定的小项目。
特点:线性结构,每个阶段只执行一次,是其他模型的基础框架。
缺点:
1.测试后置:1)前面各阶段遗留的风险推迟到测试阶段才被发现,导致项目大面积返工,失去了及早修复的机会。2)必须留有足够的时间给测试活动,否则导致测试不充分,将缺陷暴露给用户(产品质量差)
2.周期太长,产品很迟才能被看到和使用。
使用场景:规模庞大、复杂度高、风险大的项目。
特点:螺旋模型中增加了风险分析和原型
缺点:
1.项目中可能存在的风险性与风险分析人员的技能水平有直接关系。
2.需要人员、资金、时间的增加和投入,可能会导致项目的成本太高。
假设一个软件,共有 A、B、C、D、E 五个功能
增量模型:可以先开发A、B需求,然后再开发C、D、E
迭代模型:先将A、B、C、D、E功能开发出来,然后不断进行完善。
scrum模型
特点:轻流程、轻文档、重目标、重产出。
三个角色和五个重要会议
三个角色:产品经理、项目经理、研发团队
五个会议:
发布计划会议:最终确定本次迭代要完成的需求。
迭代计划会议:任务拆解、确定责任人、工时的评估。
每日会议:昨天做了什么、今天要做什么、当前遇到的问题。(每日会议结束后需要给出“可交付的软件”)
演示会议:产出用户需求。
回顾会议:总结当前迭代周期的不足,并在下一次迭代中进行优化。
V模型最早是由Paul Rook 在20世纪80年代后期提出的,目的是改进软件开发的效率 和效果,是瀑布模型的变种。
V模型特点:
1、测试过程中存在不同类型的测试。
2、测试阶段的参考标准以前面对应阶段为准。
缺点:测试后置
W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成,分别代表测试与开发过程,图中明确表示出了测试与开发的并行关系。
W模型特点:测试的对象不仅是程序,需求、设计等同样需要测试,测试与开发是同步进行的。
W模型优点:有利于尽早地全面的发现问题。例如,需求分析完成后,测试人员就应该参与到对需求的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,显著减少总体测试时间,加快项目进度。
局限性:W模型重流程,不能迎接变化,不适用于敏捷模型。
1、项目测试完成之后,需要进行项目上线。产品在线上运行期间我们测试人员也需要及时关注产品线上运行情况,是否出现了产品质量问题,如果出现了问题,怎么做?
答:
1.尝试复现(普遍都存在的问题还是个别问题),复现成功后通知项目组所有成员进行问题的定位。
2.尝试定位问题出现的原因,帮助开发人员尽快的定位问题并解决问题。
3.反思问题(为什么出现,如何解决,后续如何避免)。
⚠️ 注意:如果问题比较严重或者比较典型,通常要写一个文档。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。