什么是需求?
满足用户的期望或者合同规定的文档(标准、规定、合同)所需要的条件和权限
什么是BUG(软件错误)?
当且仅当软件需求存在并且合理,如果软件功能和软件需求规格说明书不相符合,就是软件错误;如果软件规格说明书(软件需求文档)不存在,用户需求存在并且合理,如果用户需求和软件功能不相符合,就是软件错误
什么是测试用例?
向被测试系统发起的一组集合,这组集合包含测试环境、测试数据、测试步骤、预期结果、测试的功能模块、优先级、是否手动……
测试环境:系统所运行的环境
软件开发的5大模型?
1、瀑布模型:

优点:强调开发的阶段性;强调早期计划及需求调查;强调产品测试;
? ? ? ? ? ?适应于需求稳定的项目
缺点:依赖于早期进行的唯一一次需求调查,不能适应需求的变化;
? ? ? ? ? ?由于是单一流程,开发中的经验教训不能反馈应用于本产品的过程
? ? ? ? ? ?风险往往迟至后期的测试阶段才显露,因而失去及早纠正的机会?
2、螺旋模型:

优点:强调严格的全过程风险管理;强调各开发阶段的质量;
? ? ? ? ? ?提供机会检讨项目是否有价值继续下去;抗风险能力强;
? ? ? ? ? ?适合于项目比较庞大,风险大的项目
缺点:引入非常严格的风险识别、风险分析和风险控制,这对风险管理的技术水平提出了很高的要求。人员、资金和时间的投入大
3、增量、迭代模型:
优点:抗风险能力较强
增量模型:是按照一个模块一个模块的开发
迭代模型:是先把整体搭成一个框架,然后一层一层迭代
4、敏捷模型:

Scrum流程:
PO:产品经理? ?进行需求整理,把用户需求转化为user story(软件需求)
SM:项目经理? ?保证整个敏捷流程顺利进行的
ST:研发团队? ? 开发 迭代,定期交付一个高质量可用的软件
流程步骤:
1)、产品发布会议:解说user story
2)、迭代计划会议:部分user story 分配任务,估算时间
3)、研发过程——每日站会:干了什么,问题、计划
4)、产品演示会议
5)、项目回顾会议:进行总结、改进
特点:轻文挡、轻流程、重目标、重产出、拥抱变化,能够适应需求的变化
?软件测试的两个模型?
1、V模型:

?
特点:阶段的独立性强;前期的需求分析和设计阶段和后期测试阶段一一对应,前期的每个阶段是后期每一个测试阶段的依据;前期的问题到后期项目测试才发现,导致问题失去及时纠正的机会
2、W模型(双V模型):开发的每一个阶段V,测试的每个阶段V

优点:测试介入早,在需求阶段就介入
缺点:阶段性比较强,仍然是串行过程,无法适应需求变化,不支持敏捷
?软件开发的生命周期?
需求分析——计划——设计——编码——测试——运行维护
?软件测试的生命周期?(软件测试的流程?)
需求分析——测试计划——测试设计/测试开发——测试执行——测试评估
需求分析:验证需求的正确性、合理性;细化需求,找出测试项,写测试用例
测试计划:确定测试的人数、测试环境、测试时间、测试设备
测试设计/测试开发:根据需求写测试用例
测试执行:开发已经完成,执行测试用例,验证功能,提交BUG,验证BUG
测试评估:写了多少测试用例,剩余的测试用例数,BUG数量,解决的BUG数量,遗留的BUG及解决方案,测试范围和测试功能
如何描述一个BUG?
BUG管理工具、文字形式
1)测试的版本号(代码版本信息)
2)测试环境:
? ? ? 对于Web系统:?硬件设备信息:电脑品牌,型号
? ? ? ??????????????????????????软件设备? 操作系统??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 浏览器:使用的是哪个浏览器及其版本号
? ? ? 对于APP:软件设备:APP的系统是安卓系统还是IOS系统还是……及其系统的版本号
? ? ? ? ? ? ? ? ? ? ? ? 硬件设备:手机品牌(系列) 电脑品牌
3)测试数据:能更加快速的复现问题
4)测试步骤
5)测试的实际结果
6)测试的预期结果
7)附件,错误日志,错误截图……
BUG的级别? (普遍情况,了解下就行)
1)崩溃:系统无法正常运行,出现崩溃,操作死锁,死循环,黑屏,阻碍测试人员的工作
??????如果线上出现这种情况怎么办?怎么去补救?回退一个版本
2)严重:系统可以运行,但是不稳定,继续运行下去会造成严重的损失,重要的功能没有实现,或者功能和需求不符合,数据库中用户的数据存储错误,威胁到用户的安全(信息、财产)
3)一般:次要的功能没有实现,或者有错误,系统可以稳定的运行
4)建议:会影响用户的体验,排版(局促)颜色不符合大众审美,信息没有换行或者提前换行
BUG的生命周期?
?BUG的各种生存状态:

?如果因为BUG和开发人员产生冲突应该怎么办?
1)先检查,看BUG描述的是否清楚
2)从用户的角度去说服开发人员修改
3)BUG定级要有理有据(根据公司的规范)
4)不断提升自己的业务水平和技术水平,不但能够发现BUG,并且能够定位,还能够提出解决方案
5)不要争吵,找产品经理讨论
?
|