什么是需求？
满足用户的期望或者合同规定的文档（标准、规定、合同）所需要的条件和权限
什么是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）不要争吵，找产品经理讨论
1154
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
