文章目录：一.什么是需求（1）用户需求
（2）软件需求
二.测试用例 （1）测试用例的含义
（2）测试用例的作用
三.开发模型和测试模型（1）软件生命周期
（2）开发模型
（3）测试模型
（4）软件测试生命周期
四.bug （1）bug的含义
（2） 如何描述bug
(3)如何定义bug的级别
（4）Bug生命周期
（5）和开发人员产生了争执怎么办
（6） 如何开始第一次测试
（7）如何发现更多的bug
一.什么是需求？
用户需求：用户提出的想要实现的功能
软件需求：产品经理根据用户需求写的需求文档（详细描述用户需求如何实现）
二.测试用例
1.测试用例的含义：测试用例是一组集合，包括测试环境、测试数据、预期结果、操作步骤、、、
比如我们在牛客网刷题的时候
测试环境：牛客网为我们提供的测试环境
测试数据：字节输入测试数据
预期结果：通过率100%
操作步骤：写代码，提交代码
再比如我们登录教务系统
测试环境：windows+浏览器+本地
测试数据：账号、密码
操作步骤：输入账号和密码然后登录
测试用例的作用：（1）测试用例提高测试人员工作效率，降低测试人员工作的重复性
（2）测试用例是建立自动化的基础
三.开发模型和测试模型：
1.软件生命周期：（1）需求分析：分析需求是否合理，需求是否完整
（2）计划：规划谁开发、谁测试、测试的时间大约多久、开发的时间大约多久
（3）编码：写代码
（4）测试（会生成测试报告）
（5）运行维护：如果上线后有bug,测试人员和开发人员一起协助解决问题
2.开发模型：
（1）瀑布模型
特点：线性的
优点：每一步干什么很清楚
缺点：测试介入的过晚，不利于及时纠正错误
适用的项目：适用于小型项目
（2）螺旋模型：
优点：每个阶段都会进行风险分析，从而避免一些风险的产生
缺点：风险分析可能分析错，需要人力、物力、财力的投入
适用的项目：适应于比较大的项目，风险比较多
(3)增量模型：每个功能都实现了，再实现下一个功能
(4)迭代模型：每个功能都开发一部分，就开发一个功能
(5)敏捷：重视面对面沟通
重视可用的软件
重视客户协作
重视响应变化
scrume敏捷开发里最常见的
三大角色：产品经理、项目经理、研发人员
3.测试模型：
特点：左边是开发、右边是测试，类似于瀑布模型
优点：测试被划分成许多类型
缺点：测试人员介入太晚，发现问题时机太晚
W模型(双V模型）
特点：开发一个，测试一个
优点：测试人员尽早介入需求
缺点：测试人员和开发人员一定程度上还是串行的，不能拥抱变化，不能适用于敏捷
4.软件测试生命周期：
四.Bug
1.Bug的含义：软件程序实现的功能和预期不一样
2.如何描述bug
（1）发现问题的版本
开发人员需要知道出现问题的版本，以此来获取对应版本的代码来重现故障，并且版本的标识有利于统计和分析每个版本的质量
（2）问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器的版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本，详细的环境描述有利于故障的定位。
（3）错误重现的步骤：
描述问题出现的最短步骤
（4）预期行为的描述
描述程序的行为是怎样的，如果是依据需求提出的故障，写明需求的来源最好
（5）错误行为的描述
描述错误的现象，crash等可以上传bug,可以上传截图
（6）其他
某些公司会有一些其他的要求，例如故障的分类，功能故障，界面故障，兼容故障，开发人员可以根据bug的优先级来依次解决
（7）不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放到一起提交
3.如何定义bug的级别：
（1）崩溃
例如：造成系统崩溃、死机、死循环，主要功能丧失
（2）严重
例如：系统主要功能部分丧失
（3）一般
功能没有完全实现但不影响使用，例如：操作时间过长，查询时间过长，格式错误，删除没有确认框，数据库中字段过多
（4）次要：
建议类问题，不影响操作功能的执行，可以优化性能的方案，例如：错别字、用户体验不好
4.Bug生命周期
5.和开发人员产生争执怎么办？
前提：不要吵架，更不要打架
（1）确保自己确实发现了bug，确保自己对需求理解没问题
（2）好好说话，注意说话技巧，高情商说话
（3） 站在用户角度考虑问题
（4）不光要发现问题，提出解决问题的方案
（5） 第三方会议：
开会之前：明确问题产生的原因，问题是什么，解决方案是什么
开会之后： 问题要不要解决，什么时候解决，谁解决
6.如何开始第一次测试：
（1）充分理解需求
文档（产品文档+技术文档）
项目问题问产品经理，模块底层问开发
（2）确定测试计划
（3）执行测试
开发人员将Bug修复了以后，测试人员要再次进行验收
测试的执行和Bug管理
7.如何发现更多的bug
（1）软件测试存在二八原则，80%的故障集中于%20的模块，如果某部分问题较多，加深这个模块的测试深度和广度
（2）开发人员存在二八原则，80%的故障集中于%20的开发人员，如果某些开发人员的Bug较多，将强他开发模块的测试广度和深度
（3）多进行逆向性思维和发散性思维
（4）不要局限于用例和需求文档
（5）尽早介入项目，不要等开发的差不多了再介入
