文章目录
一、什么是软件测试
1.什么是软件测试
- 软件测试就是找BUG，发现缺陷
- 软件测试只是一个样本测试，具有不可穷尽性。
软件测试就是验证软件产品特性是否满足用户的需求。
在早期，更多的是将软件测试看做对软件产品的“检验” ，检查软件的每个功能是否正常运行正常
- 验证软件功能执行的正确性，可以是否能正常工作。
- 测试的活动是以测试人员“预期的结果（需求定义）”为依据，看是否符合需求
测试：就是保障软件的质量
2.软件测试和调试的区别
调试：开发自己调试，确保程序做了程序员想做的事，发现问题，解决问题。在开发阶段进行。
测试：测试和开发一起执行。确保程序解决了它要解决的问题，来发现问题。测试伴随软件的整个生命周期
测试人员需要的素养
技能：
1.测试用例设计的能力
2.编程能力（编写测试工具、自动化测试用例）
3.技术快速学习的能力、业务快速学习能力
非技能
1.沟通合作能力
2.文字表达能力（写测试用例、编写测试文档、BUG）
3.抗压能力
4.责任感
二、软件测试概念
1.需求
1.需求的定义
-
用户需求：甲方提出来的需求，或者用户要完成的任务
-
软件需求：功能需求，详细描述需要实现的软件功能
软件需求是产品经理写的
软件需求是测试人员进行测试的基本依据
用户需求就是一句话，软件需求是一个文档（详细描述用户需求应该如何实现）
2.测试人员眼中的需求
-
需求是测试人员开展软件测试工作的依据
-
业务需求—>软件功能需求点—>测试需求点—>测试用例
- 从软件功能需求出发，无遗漏的识别出测试需求。直接关系到用例的测试覆盖率
- 对于每个测试需求点，需要具体设计测试用例
- 测试工程师在需求分析和设计阶段开始介入
2.测试用例
Test Case
1.测试用例概念
- 测试用例是一组集合，包含测试环境、测试数据、预期结果、操作步骤
例子：测试环境：windows+Chrome +本地
测试数据：用户名字符串、密码字符串 操作步骤：输入用户名、输入密码、点击登录按钮
测试预期：登录成功
- 测试用例可以提高测试人员的工作效率，降低工作的重复性
- 测试用例是建立自动化的基础
3.BUG 软件错误
- 当且仅当规格说明书（软件需求）是存在的并且正确。程序与规格说明之间的不匹配（预期结果!=执行结果）才是错误
- 当程序没有实现最终用户合理预期的功能要求时，就是软件错误。
4、开发模型和测试模型
1.软件的生命周期
- 需求分析：分析需求是否合理、需求是否完整
- 计划 ： 谁开发、谁测试、开发多久、测试多久…
- 设计 : 设计应该如何实现功能
- 编码 ：进行具体的代码编写
- 测试 ： 对代码功能进行测试，出具测试报告后才能上线
- 运营维护 ：如果线上有问题，测试人员需要协助开发定位、解决问题
2.开发模型
1.瀑布模型
- 需求分析产出：需求文档
- 设计环节产出：技术文档（涉及到哪些接口，库表，mq, 定时任务…）、UI视觉搞
特点：线性的
优点：强调开发的阶段性，每个阶段做什么，产出什么非常清晰
缺点：风险往往会推迟到后期测试阶段才会显露，失去及早纠正的机会
适应的项目：小型的项目
2.螺旋模型
优点：每个阶段都会进行风险分析，避免发生一些线上问题
缺点：风险分析可能会分析错，需要大量人力财力时间的投入
适应项目：比较大的项目、风险比较多的项目
3.增量、迭代
增量：逐块建造的概念，做完一个模块，再做下一个模块
迭代：反复求精，先整体，再细节 （就像素描，先画一个轮廓，再画手、画脸）
4.敏捷
敏捷宣言
- 拥抱变化、请流程、重交付、轻文档、重交互
个体与交互重于过程和工具（个体之间面对面沟通）
可用的软件重于完备的文档 （开发文档、需求文档）
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
scrume开发模式
三大角色
product owner(产品经理)
scrum master(项目经理)
team(研发团队)：后端开发、前端开发、UI设计师、测试
流程
1.产品经理收集用户需求
2.项目经理将需求进行优先级的划分、计划项目什么时候开始和结束、由谁来做
3.每日站会，汇报昨天的工作。如果没有完成，遇到了什么问题、今天计划要做什么。
4.演示。
3.测试模型
1.V模型
特点：左边是开发、右边是测试、类似于瀑布模型
优点：测试被划分成很多类型
缺点：测试介入太晚，问题发现的时间太晚
2.W模型（双V模型）
特点：开发一个V 、测试一个V
优点：测试人员尽早的介入
缺点：测试人员和开发人员在一定程度上仍是串行的。并且不能拥抱变化、不能适应于敏捷
三、软件测试基础
1.软件测试的生周期
- 需求分析->测试计划->测试设计、测试开发->测试执行->测试评估
需求分析：需求是否完整、需求是否正确
测试计划：确定由谁测试、什么时候开始测试、结束测试
测试设计：写测试用例（手工测试用例、自动化测试用例）、编写测试工具
测试执行：执行测试用例
测试评估：测试人员产生测试报告
2.描述一个BUG
1.发现问题的版本
2.出现问题的环境
3.错误重现的步骤
4.预期行为的描述
5.错误行为的描述
6.其他。比如BUG复现的前置条件、BUG给谁、BUG的优先级
1.BUG的优先级
- 根据bug的影响程度进行划分
1.Blocker(崩溃)：阻碍开发、测试工作的问题，系统崩溃、死机、数据库数据丢失、主要功能丧失…
2.Critical(严重):只要功能部分丧失、数据库保存调用错误、用户数据丢失
3.Major(一般)：功能没有完全实现，但是不影响使用、如操作时间长、数据库表中字段过多。
4.Minor(次要)：优化、建议类、不影响功能的使用。如错别字
强调：如果发现崩溃级别的bug，就需要停止测试，测试打回
2.BUG的生命周期
-
New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
-
Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
-
Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
-
Rejected：如果认为不是Bug，则拒绝修改。
-
Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
-
Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
-
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed
3.如何发现bug
1.测试的二八定律：80%的故障集中于20%的模块
2.开发的二八定律:80%的故障集中于20%的开发人员
3.进行逆向思维和发散性思维
4.不局限于用例和需求文档
5.尽早介入项目
4.如何进行测试
1.充分理解需求
文档（产品文档+技术文档）
项目功能问题问产品。模块底层如何实现问开发
参加会议
2.确定测试计划
3.执行测试
bug在开发修复之后，一定要进行验收
4.项目上线 +维护
