一、测试基础理论
1.1 什么是软件测试？
为了发现程序中的错误而执行程序的过程
1.2 软件测试流程
1）需求调查
2）制定初步的项目计划
3）测试准备
4）测试设计
5）测试实施
6）测试评估
1.3 软件测试阶段的划分
单元测试、集成测试、确认测试、系统测试、验收测试
单元测试：是用来对一个模块，一个函数或者一个类来进行正确性检验的测试工作
集成测试的定义：在单元测试的基础上，将所有已通过单元测试的模块按照概要设计的要求组装为子系统或系统，并进行测试的过程。
集成测试的内容：
1）将各个具有相互调用关系的模块组装起来时，检查穿越模块接口的数据是否会丢失
2）判断各个子功能组合起来是否能够达到预期要求的父功能
3）检查一个模块的功能是否对其他模块的功能产生不良影响
4）检查全局数据结构是否正确，以及在完成模块功能的过程中是否被异常修改
5）单个模块的误差累计起来是否会放大到不可接受的程度
确认测试：确认测试的目的是向未来的用户表明系统能够像预定要求的那样工作，经集成测试后已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样
验收测试：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务，验收测试是向未来用户表明系统能想预定要求那样工作。
1.4软件测试的分类
从大的方向上分：白盒测试（逻辑驱动测试）、黑盒测试（数据驱动测试）、灰盒测试
从软件的不同测试点分为：功能测试、性能测试
功能测试又细分为：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试
性能测试：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件对系统的各项性能指标进行测试
1.5 常见测试用例的设计方法
1）等价类划分 ，有效等价类和无效等价类
2）边界值分析法
3）错误推测法
4）因果图法
5）情景分析法
6）判定表驱动法
7）功能图法
8）正交试验法
1.6白盒测试方法有哪些
语句覆盖、判断覆盖、条件覆盖、判断/条件覆盖、多重条件覆盖、基本路径、符号法、静态质量度量法
1.7 软件测试的类型
能力测试、容量测试、强度测试、可用性测试、安全性测试、性能测试、存储测试、配置测试、兼容性测试、安装测试、可靠性测试、可恢复性测试、服务
/可维护性测试、文档测试、过程测试
1.8 什么是软件的生命周期？
从开始构思软件开始一直到软件的废弃的整个过程是软件的生命周期
软件的开发生命周期包括：需求分析、软件设计、代码实现、测试、实施、维护
1.9 软件缺陷产生的原因主要有哪些
1）需求不明 2）软件结构复杂 3）编码问题 4）项目期限短 5）使用新技术
1.10 负载测试、压力测试、容量测试、强度测试的区别
1）负载测试（Load Test）：是指数据在超负荷环境中运行，程序是否能够承担。通过逐步增加系统负载，确定在满足性能指标的情况下，系统所能承受的最大负载量。
2）强度测试（Stress Test）：是在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括：
Spike testing：短时间的极端负载测试；
Extreme testing：在过量用户下的负载测试；
Hammer testing：连续执行所有能做的操作。
3）压力测试：通过逐步增加系统负载，确定在什么负载条件下系统处于失效状态，以此来获得系统能提供的最大服务级别。
4）容量测试(Volume Test)：确定系统可处理同时在线的最大用户数，使系统承受超额的数据容量来发 现它是否能够正确处理。
1.11 常见的软件测试模型
1、V模型
V模型的优缺点（测试重点）
1、优点：包含了底层测试（单元测试）和高层测试（系统测试）；
清楚的标识了开发和测试的各个阶段；
自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。
2、缺点：自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；
实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。
改良：每个步骤都可以进行小的迭代工作。
2、W模型（重要）
优点：
开发伴随着整个开发周期，需求和设计同样要测试；
更早的介入测试，可以发现初期的缺陷，修复成本低；
分阶段工作，方便项目整体管理。
缺点：
开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！
3、H模型
H模型的优点：
>开发的H模型揭示了软件测试除测试执行外，还有很多工作；
>软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
>软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
>软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。
H模型的缺点：
>管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
>技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
>测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；
>对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。
1.11 如果给你一个登录页面，你如何设计测试用例？
我会从以下几个方面考虑：
-
从功能方面：
使用等价类划分和边界值分析法设计正反例
如正例，正确用户名密码，
反例：错误用例名密码等, 空用户名秘密等，字符串长度超过规定长度等
如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用
刷新页面是否会刷新验证码
如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性
用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面； -
易用性方面
快捷键是否可以使用，如按enter光标是否可以移动到下一个输入框，按enter是否可以登录
页面默认焦点是否定位在用户名的输入框中 -
安全性方面：
密码是否要求是强密码，
密码连续输入错误多次后是否会锁定，
密码是否有过期设置，密码有效期到期后，是否提示需要修改密码
用户密码后台存储是否加密
用户名密码是否有加密传输，
用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面、
用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改
用户名和密码是否大小写敏感、
页面上的密码框是否加密显示
不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确
不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面
同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期
同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。 -
兼容性方面：
不同浏览器下，验证登录页面的显示以及功能正确性
相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
不同分辨率的界面下，验证登录页面的显示以及功能正确性。 -
界面设计方面
界面是否跟设计相符，界面功能是否完整。 -
性能方面
单用户登录的响应时间是否小于 3 秒。
单用户登录时，后台请求数量是否过多
高并发场景下用户登录的响应时间是否小于 5 秒
高并发场景下服务端的监控指标是否符合预期
高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
长时间大量用户连续登录和登出，服务器端是否存在内存泄漏
