软件测试：描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
1. 软件测试的定义
软件测试就是根据需求，采用不同的测试方法或测试工具，对软件进行测试，尽可能早、尽可能多地发现软件的缺陷，跟踪并确保缺陷得到正确的解决，提高软件的质量。
2. 软件测试的目的
- 软件测试为了发现程序存在的代码或业务逻辑错误；
- 软件测试为了检验产品是否符合用户需求；
- 软件测试为了提高用户的体验。
3. 什么是软件缺陷
- 功能：没有实现的功能、实现了错误的功能、实现了多余的功能、功能出现错误、没有实现一些需求上没有说明，但是默认要有的功能/隐性需求（密码掩码显示）；
- 兼容性：在不同的浏览器、不同的PC端或移动端上，页面显示出现问题；
- 性能：达不到要求的性能指标，比如说：响应或加载的速度慢，无法达到所要求的并发量；
- 安全：一般是用安全工具（appscan）扫描。比如说：不应该暴露的请求暴露了出来，需要**传输的数据没有**等情况
4. 软件测试的策略
使用不同的
测试用例设计方法，设计出合理的数据，在测试环境中，输入到软件当中，使软件的状态发生变化，观察软件的输出结果，根据需求文档判断是否是缺陷，如果是缺陷，则提交
BUG。
5. 测试用例常用的设计方法
- 场景法：运用场景对系统的功能点或业务流程进行描述，然后设计测试用例，从而提高了对系统主要功能和业务流程的测试效果。场景法适合测试业务流程清晰的系统或功能。
- 等价类：等价类划分思想所有可能输入的数据（无效数据和有效数据）合理地划分成若干个等价类，在每个等价类中选取少量的数据来代替这一类其他数据的测试。
- 边界值：使等价类的每个编辑都作为测试条件，在边界处选取正好等于、刚刚小于或刚刚大于边界的值作为测试数据。此外，边界值分析法，不仅需要考虑输入条件边界，还要考虑输出域边界的情况。
- 因果图：如果程序的输入条件和动作之间的逻辑关系明确，则可直接使用判定表驱动法。但是，如果输入条件和动作关系不明确，则应当使用因果图法
- 错误推测：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
- 判定表：判定表也称为决策表，用于描述程序输入条件组合与相应的程序处理动作之间的对应关系。等价类划分和边界值分析都没有考虑被测程序输入条件的组合情况，只是孤立地考虑各个输入条件的测试数据取值问题，对输入组合情况下产生可能产生的错误没有进行充分地测试。判定表驱动法从多个输入条件组合的角度来满足测试的覆盖率要求，是黑盒测试方法中最严格、最有逻辑的测试方法。
6. 软件测试的原则
软件测试是为了证明BUG的存在，而不是为了证明BUG的不存在
测试并不能保证软件100%无BUG，因为就算再严格的测试，也会有隐藏的BUG在软件当中
测试工作越早介入越好，因为BUG发现得越早，修复的成本就越低
软件测试应该追溯到用户需求（没需求文档则参考同类型的标杆产品）
8-2原则：80%的BUG出现在20%的模块上。因为代码的编写是有逻辑关联性的，如果一个模块经常出现BUG，那么修复了当前的BUG后，往往会有新的BUG出现
7. 软件测试什么时候进行
因为BUG越早发现，修复的成本越低。所以，测试工作的介入越早越好。建议在需求评审阶段，甚至需求设计阶段，测试人员就针对需求进行测试工作，下面举两个方面的例子：
需求设计的不合理，比如：UI随着用户心情变化而改变颜色
需求过于繁琐，比如说：**需要账号密码和
手机号验证，这两种只需要取一个即可。
软件测试的生命周期？测试流程？测试周期？项目经历哪些阶段？
测试人员在一个项目中，一般经历这些阶段：需求评审 -> 熟悉需求，编写测试用例 -> 测试用例的评审和修改 -> 软件完成，执行测试用例，发现BUG则提交BUG，并跟踪BUG，对已修复的BUG进行验证测试（有关联的功能也需要重新测试） -> 测试完毕后，提交测试报告
如果是迭代的新版本，那么在执行测试用例之前，需要对旧功能进行回归测试
8. 测试用例有哪些字段
ID、测试模块、标题、优先级、预置条件、测试数据、测试步骤、预期结果、实际结果（如果是接口方面的bug需要另外说明）
9. 测试用例的优先级根据什么划分
按照功能模块的重要程度来划分，系统的主打功能以及用户使用最多的功能最优先
10. BUG的必备描述字段
一般是按照测试工具上的默认字段进行填写的。但这里说明下必备字段：
标题、功能模块、测试环境、BUG的详细描述（复现步骤、预期结果、实际结果）、严重程度、优先级、指派人员、附图
标题要简洁易懂，最好是做到开发看到标题就知道BUG如何复现，甚至BUG的产生原因
BUG的描述需要客观，其中包括BUG的复现步骤、预期结果和实际结果。当然，如果知道BUG的产生原因更好
PS.一个BUG单只针对一个BUG进行说明
11. BUG的严重等级的划分
一般来说，不同的项目，BUG的严重等级的划分也不一样，而且也没硬性要求。但一般会分成4个级别，下面概括说下，实际工作中还是具体情况具体处理。
A级：一般是导致软件不能正常工作的情况，比如说
数据库连接失败，项目文件夹没分配权限、软件崩溃等情况
B级：一般是软件功能无法正常执行的情况，比如说登录无法登录，搜索无法搜索等情况
C级：一般是软件功能出现异常的事情况，比如说输入框搜索结果不正确，错误异常没有处理直接暴露代码等情况，这类BUG是最多的事
D级：一般是UI层面上的，比如说控件的位置不正确，错别字，提示语不对等情况
12. BUG严重成都和优先级有的区别
严重成都是在用户使用系统的角度，是否影响到用户使用系统
优先级是在测试人员进行测试工作的角度去看，是否影响到测试人员后续的测试工作
一般来说，严重程度高的BUG，优先级也高。不过也有例外的，比如说一个场景走到最后的步骤是保存图片，现在无法保存图片，严重程度高，优先级低，因为它没影响到后续的测试工作 ；也有严重程度很低，但是优先级很高的Bug，一般都是UI上面的Bug，比如说错别字，图片显示有问题之类的
13. BUG的管理流程/BUG的生命周期
- 测试人员发现并确定BUG；
- 测试人员在测试管理工具中，编写并提交BUG单给负责的开发人员；
- 开发人员解决后，指派给测试人员；
- 测试人员验证该BUG是否修复成功，如果修复成功则关闭BUG。如果没有修复成功，则激活并说明原因，再指派回负责的开发人员；
- 在验证BUG是否修复的过程中，需要去测试被这个BUG所影响到的功能，看是否出现修复了这个BUG，却导致其它新的BUG出现的情况。
14. 如何减少开发阶段的BUG
测试人员在需求评审阶段就介入，对需求进行测试工作。
在这一过程，测试人员应该思考功能点如何进行测试、明确功能点的需求、对不合理或多余的需求提出改善建议等
15. 如何避免BUG的产生
如果软件还没进入开发阶段，那么可以从需求设计或评审阶段进行测试工作，对不合理的需求，能优化的需求提出建议，比如说：一个表单有个时间字段，那么这个字段的值的输入，可以设计成选择项，而不是输入框，这样就能避免由于用户输入的不合理数据所产生的Bug
如果软件已经开发出来了，那么BUG的产生是无法避免的，
软件开发出来，BUG就在那里了。测试人员只能尽可能快，尽可能多地找出BUG，从而修复它们
白盒测试的测试对象是代码
白盒测试一般使用测试桩函数来进行测试，代替被测函数所调用的那个函数。
白盒测试的覆盖标准有：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖等（越后覆盖率越高，耗时和难度越高）
17. 测试用例的定义
测试用例就是设计一种情况，按照这种情况，软件是否能够正常运行并且达到预期结果，如果不能正常运行或达不到预期结果，那可能就是一个Bug
18. 测试用例的作用
可以让测试人员有条理，有顺序地执行测试工作，避免盲目测试，并提高测试效率
用例的复用性，可以在新版本迭代后进行回归测试
有利于工作的改进，测试完毕后，可以总结哪些用例测出的BUG几率比较大，哪些用例需要改进
19. 如何进行测试用例评审
人员：测试组评审或者产品开发也参与进来
是否是按照软件需求来进行编写的？
对需求的覆盖率是否到位？是否有需求遗漏了？
异常情况是否考虑全面？
用例的描述是否清晰？是否有冗余的用例？
ps.再严格的评审，也会有遗漏或错误
