(1) 技能要求专业度:
软件研发: 技能的要求专业度高,技能要求不广泛
软件测试: 技能要求比较广泛，但是专业度不高
测试接口: soupUl, postman , jmeter
性能测试: loadrunner jmeter
自动化测试脚本 Python java unittest TestNg Charles fiddler appium

(2) 软件测试和软件调试
目的: 软件测试就是验证软件是否实现了它应该实现的功能(需求)
软件调试的目的是软件开发人员验证软件是否实现了他想让软件实现的功能。
开发人员的角度
角色: 测试是由开发人员(白盒测试)和测试人员共同完成
调试是由开发人员完成
阶段: 测试现在贯穿了整个软件开发的生命周期; 需求一>计划一> 设计一>编码一>测试一>运维
调试是在开发阶段

3、面试可能问到的问题：你为什么选择软件测试这个岗位？

答：一个优秀的软件测试人员应该具有良好的沟通能力，编程能力，学习能力，自动化开发能力，编写测试用例的能力。首先对于软件测试，我非常感兴趣，我认为做一个十分优秀的测试人员也是非常不容易的；我学了点关于开发的技能，能在以后作为一个专业的测试人员与开发人员沟通过程中会更容易点。其次现在一个软件产品的问世，也离不开软件测试，在平常的工作学习生涯中，我具有强烈的责任感和压力并且善于发现探索新事物，对日后的职业生涯肯定会有很大的促进作用。

4、什么是需求？

用户的期望和满足合同(文档，规则，标准)的规定所需要的条件和权限。软件需求是用户需求转换而来的，它是用户需求的细化，是用户需求的具体实现细节和规范。用户需求比较粗略，直接实现会有困难，因为没有细节，所以需要软件需求把用户需求细节实现和规范，把用户需求变成一个具体的可实现的过程文档。

5、需求是软件测试的依据

验证需求，保证需求正确可实现，细化需求，从需求中提炼出一个一个的测试项。以用户登陆为例，阐述下整个过程：

软件测试人员如何深入了解需求? 答:从用户需求分析阶段就开始介入了解需求，站在用户的角度。

6、测试用例

测试用例就是向被测试系统发起的一组集合，包含测试环境，测试数据，测试步骤，预期结果，（重要性、优先级、操作方式、标题等）

如图：测试点：用正确（已经注册）的手机号和密码登陆网易邮箱界面，登陆成功

测试用例: 标题:
测试环境: Chrome版本99.0.4844.51 PC端 Windows系统
测试数据: 用户名: 134****2311 密码: *******
测试步骤: 1、在浏览器打开邮箱URL: https://mail. 163.com/?msg= authfail#return
2、输入用户名和密码
3、点击登陆
预期结果: (操作完测试步骤后的结果)登陆成功

测试用例告诉我们测什么，怎么测
优点: 衡量需求的覆盖率(测试用例和需求对比); 复用性，借鉴意义; 可以用于回归测试; 防止遗漏测试需求。

7、什么是BUG（软件错误）？

当且仅当，程序规格说明书(软件需求)存在并且合理，如果软件功能和软件规格说明书不相符合，我们就说是软件错误;
当软件需求不存在，用户需求存在并且合理，软件功能和用户功能不相符合，就说明是软件错误;软件测试的阶段: 整个软件开发的生命周期，需求阶段介入验证需求的合理性和正确性

8、开发模型（5个模型）

软件开发的生命周期：需求分析一计划一设计一开发一测试一运行维护

（1）瀑布模型

特点 : 阶段性强，每一个阶段比较独立; 看重前期的需求分析和后期的测试
缺点 : 测试在编码后才开始介入，导致前期的问题后期才发现，会失去错误补救的机会

（2）螺旋模型

适合于项目庞大，风险大，不是很明确项目
特点: 强调每一个迭代的测试质量和风险分析
缺点: 风险管控人力物力投入很多，成本比较大

（3 4）增量模型，迭代模型

同一个系统的四个模块 A B C D 两周
增量模型：第一周开发A B功能模块，第二周开发C D功能模块
迭代模型：第一周先开发A B C D的基础功能，第二周再在第一周的基础之上完全其它的功能
特点：抗击风险能力强，

（5）敏捷模型

个体与交互重于过程和工具；可用的软件重于完备的文档；客户协作重于合同谈判；响应变化重于遵循计划
特点：轻文档，轻流程，重目标，重产出

角色:
PO product owner，把用户需求转化成user story
SM scrum master项目经理，管理整个团队，负责敏捷流程顺利实施，各种会议
ST scrum team各种技能的人组成，开发，测试UI

scrum流程:

发布计划会议：产品经理收集需求形成userstory ,讲解，排出本迭代需要进行开发的userstory形成sprint backlog
迭代计划会议：分析用户故事，把userstory分解- 个个的任务, 分配开发人员，制定开发计划
每日站会：昨天干了什么，遇到的问题，今天的计划
产品演示会议：甲方，用户演示产品，PO把不足的地方收集成user story,下一次迭代改进
回顾计划会议：回顾整个迭代过程，把不足的地方找出，在下一次迭代过程中改进，优化迭代流程

9、测试模型

（1）V模型

特点：每一个阶段独立性强；左边每一个阶段都是右边测试阶段的依据；和右边阶段每一个测试阶段一一对应。

缺点：编码后才进行测试；前期的错误后期才会被发现，会失去错误即使补救的机会（瀑布模型的变种）

（2）W模型——双V模型

特点：每一阶段独立性强；测试一开始就介入；可以保证前期的问题及时发现和纠正；测试和开发并行。

缺点：每一阶段都是串行的过程；一个阶段完了之后就进行下一个阶段。

不支持敏捷(拥抱变化)开发

10、软件测试的生命周期（软件测试流程）

需求分析——测试计划——测试设计/开发——测试执行——测试报告

去求分析：分析需求，验证需求的正确性、合理性；细化需求，根据需求去提炼测试点

测试计划：确定测试范围、目的、目标、测试人员、测试工具、时间、测试环境

测试设计/开发：开发测试用例

测试执行：开发人员已经提交了代码，执行测试，提交BUG

测试报告：对本次迭代的测试情况进行分析和总结；写了多少测试用例执行了多少；发现了多少BUG，修改了多少，剩余多少BUG没有解决；方案；测试的覆盖率

11、如何描述一个BUG

（1）测试版本（代码提交版本号）

（2）测试环境

因为在不同测试环境问题出现的情况也不一样

（3）测试步骤

测试数据和执行测试的详细步骤，方便为开发人员复现问题

（4）实际结果

（5）预期结果（需求期望的结果）

（6）BUG产生时的log日志，错误截图等附件

12、BUG的级别

（1）崩溃

系统崩溃，不能运行，死循环，数据库死锁，资源分配不均，黑屏，闪退，阻塞。

线上（用户使用的环境）出现崩溃级别的BUG：回到上一个可稳定运行的历史版本

（2）严重

服务器可以用，但是不稳定，继续使用会产生严重的错误；一级菜单错误，数据库插入数据错误，威胁到用户的安全等

（3）一般

系统可以稳定的运行，次要的功能没有实现，提示语不完整，弹出框没有关闭按钮，不影响用户的使用

（4）建议（次要）

建议性的，提示信息重叠（看不清楚），界面排版不符合用户使用习惯，颜色不符合软件使用场景

13、BUG的生命周期

问题：发现一个BUG，开发人员修改了，通知测试人员验证，但是测试人员又复现了这个BUG，是哪些可能的原因引起的？

答：测试环境不一样；开发人员理解不到位，没有修改成功；代码在开发人员修改之后未进行远程提交代码，测试人员用旧版本（有问题的代码）进行测试

14、测试人员因为一个BUG和开发人员发生冲突，该怎么做？

（1）检查自己的BUG描述，是否描述清楚

（2）可以从用户的角度考虑，说服开发人员

（3）BUG定级要有理有据，符合公司规范

（4）测试人员要不断提升自己的专业技能和业务水平（权威性）

（5）找产品经理去讨论问题的解决方案

本小节完^_^

以上是关于软件测试——入门篇知识要点总结的主要内容，如果未能解决你的问题，请参考以下文章

新手入门软件测试知识要点总结

Android NDK开发学习思路以及知识要点（音视频篇）