常用测试理论基础
测试理论基础
什么是软件测试？
答：软件测试是在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估。
软件测试的目的是什么？
答：软件测试的目的在于（1）发现软件的缺陷和错误（2）保证软件的质量，确保能够满足用户以及产品的需求。
（标重点）软件测试的目的是为了找bug，并不是验证软件没有bug。
黑盒与白盒的定义
- 白盒：
白盒测试是测试人员要了解程序结构和处理过程,按照程序内部逻辑测试程序,检查程序中的每条通路是否按照预定要求正确工作.它主要的针对被测程序的源代码。
不太需要关注程序功能
- 黑盒：
黑盒测试又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。
白盒测试用例设计常用方法
答：
静态测试：不用运行程序的测试，如文档测试、代码检查等
动态测试：需要执行代码，接口测试、覆盖率分析、性能分析、内存分析等。
逻辑覆盖法：主要包括语句覆盖，判断覆盖，条件覆盖，判断/条件覆盖，条件组合覆盖，路径覆盖等。
六种覆盖标准发现错误的能力由弱到强的变化：
- 语句覆盖，每条语句至少执行一次。
- 判断覆盖，每个判断的每个分支至少执行一次。
- 条件覆盖，每个判段的每个条件应取到的各种可能的值。
- 判断/条件覆盖，同时满足判断覆盖条件覆盖。
- 条件组合覆盖，每个判定中各条件的每一种组合至少出现一次。
- 路径覆盖，使程序中每一条可能的路径至少执行一次。
黑盒测试用例设计常用方法
答：等价划分类，边界值分析，错误推测法、判定表分析法、因果图法、正交试验设计法、场景法、功能图分析法等。
等价类：等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序
中的错误都是等效的.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.
等价类划分可有两种不同的情况:有效等价类和无效等价类.
边界值分析法：边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.(内点，上点，离点)
错误猜测法：基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.
判定表分析法：等价类未考虑输入条件之间的联系,相互组合等.无效类每个用例只出现一次，不能覆盖多个无效等价类并存的情况。不同的组合用二进制解决。(条件桩和动作桩)
因果图法：输入之间有相互的组合关系，且输入和输出之间有相互的制约和依赖关系，是判定表的复杂版，最终生成的就是判定表，根本上等价
正交表分析法：有时候，大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。(打印机)
场景法：指根据用户场景来模拟用户的操作步骤，一般借助流程图来确定基本流和备选流(淘宝下单流程)。
状态图法：针对流程分析法不跨多个界面，状态图法保证每一个功能/状态的可达项都被覆盖，但对无效的路径无法覆盖(MP3).
什么是灰盒测试？
答：灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段。目前互联网的测试大多数都是灰盒测试。
列举出你所了解的软件测试方式
答：
按照软件的生命周期划分：单元测试、集成测试、系统测试、回归测试、验收测试。
按照测试关注点划分：功能测试、性能测试、稳定性测试、易用性测试、安全性测试。
按照测试实施者划分：开发方测试（α测试）、用户测试（β测试）、第三方测试。
按照技术/测试用例设计划分：白盒测试、黑盒测试、灰盒测试。
按照分析方法划分：静态测试、动态测试。
按照测试执行方式划分：手工测试、自动化测试。
按照测试对象划分：程序测试、文档测试。
什么是单元测试
答：完成最小的软件设计单元（模块）的验证工作，确保模块被正确编码。通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早发现和解决不易显现的错误。
单元测试、集成测试、系统测试、验收测试、回归测试这几步最重要的是哪一步？
答：这些测试步骤分别在软件开发的不同阶段对软件进行测试，我认为对软件完整功能进行测试的系统测试很重要，因为此时单元测试和集成测试已完成，系统测试能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足需求规格的定义，因此，我认为系统测试很重要。
集成测试和系统测试的区别，以及应用场景分别是什么？
答：
区别：
- 执行顺序：先执行集成测试，待集成测试问题修复后，再做系统测试。
- 用例粒度：集成测试比系统测试用例更详细，集成测试对于接口部分也要重点写，而系统测试的用例更接近用户接受的测试用例。
应用场景：
- 集成测试：一般包含接口测试，对程序的提测部分进行测试。测试方法一般选用黑盒测试和白盒测试相结合。
- 系统测试：针对整个产品的全面测试，既包含各模块的验证性测试和功能性测试，又包含对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。测试方法一般采用黑盒测试法。
测试开发需要哪些知识？具备哪些能力？
答：
需要的知识：
软件测试基础理论知识，如黑盒测试、白盒测试等；
编程语言基础，如C/C++、java、python等；
自动化测试工具，如Selenium、Appium等；
计算机基础知识，如数据库、Linux、计算机网络等；
测试卡框架，如JUnit、Pytest、Unittest等。
具备的能力：
业务分析能力、缺陷洞察能力、团队协作能力、专业技术能力、逻辑思考能力、问题解决能力、沟通表达能力和宏观把控能力。
请说一下手动测试与自动化测试的优缺点
答：
手工测试缺点：
- 重复的手工回归测试，代价昂贵、容易出错。
- 依赖于软件测试人员的能力。
手工测试的优点：
- 测试人员具有经验和对错误的猜测能力。
- 测试人员具有审美能力和心理体验。
- 测试人员具有是非判断和逻辑推理能力。
自动化测试的缺点：
- 不能取代手工测试。
- 无法运用在测试复杂的场景
- 手工测试比自动化测试发现的缺陷更多。
- 对测试质量的依赖性极大。
- 自动化测试不能提高有效性。
- 比手动测试脆弱，需要维护成本。
- 工具本身并无想象力。
自动化测试的优点：
- 对程序的回归测试更方便。
- 可以运行更多更繁琐的测试。
- 可以执行一些手工测试困难或不可能进行的测试。
- 更好地利用资源。
- 测试具有一致性和可重复性。
- 测试的复用性。
- 增加软件的信任度。
自动化测试的定义 前提条件 适用的测试类型
答：
定义：
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
前提条件：
实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：
适用的测试类型：
- 回答一：
- 回答二：
自动化测试的运用场景举例
答：
- 线上巡检（UI+接口）
- 简单场景监控
- 稳定性测试（monkey+遍历测试）
软件测试的核心竞争力是什么？
答：早发现问题和发现别人无法发现的问题。
测试和开发要怎么结合才能使软件的质量得到更好的保障
答：测试和开发可以按照V模型或W模型的方式进行结合。但应该按照W模型的方式进行结合比较合理。
V模型：
测试过程加在开发过程的后半段，比较被动。
W模型：
测试提前，甚至和开发是同步进行，测试不仅是程序，还包括需求和设计。W模型有利于尽早地全面的发现问题，降低软件开发的成本，风险前置。
怎么实施自动化测试（过程）
答：
- 首先判断项目适不适合进行自动化测试。
- 对项目做需求分析。
- 制定测试计划和测试方案。
- 搭建自动化测试框架。
- 设计或编写测试用例。
- 执行自动化测试。
- 评估。
测试的相关流程
答：
按W模型：
需求测试 -> 概要设计测试 -> 详细设计测试 -> 单元测试 -> 集成测试 -> 系统测试 -> 验收测试
我工作中实际测试流程：
需求评审 -> 技术评审 -> case评审 -> 开发自测以及冒烟测试 -> 整体提测（集成测试） -> 回归测试 -> 系统测试 -> 验收测试
测试项目具体工作是什么
答：
- 搭建测试环境
- 撰写测试用例
- 执行测试用例
- 写测试计划、测试报告
- 测试并提交BUG
- 跟踪BUG修改情况
- 自动化测试
- 性能测试、压力测试、安全测试等其他测试
BUG分级
答：两个维度去划分
- 按BUG严重程度划分等级：
- blocker：系统无法执行，崩溃，或严重资源不足，应用模块无法启动或异常退出，无法测试，系统不稳定。常见的：严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、服务器500等。
- critical：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统的稳定性。常见的有：功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及洁面的错别字或拼写错误。
- major：界面、性能缺陷、兼容性。常见的有：操作界面错误、边界条件错误、提示信息错误，长时间操作无法提示、系统未优化、兼容性问题。
- minor/trivial：易用性及建议性的问题。
- 按BUG处理优先级划分：
- immediate：马上解决
- urgent：急需解决
- high：高度重视，有时间马上解决
- low：在系统发布前解决或确认可以不用解决
性能指标有哪些？
从外部看，主要有：
1.吞吐量：每秒钟系统能够处理的请求数，任务数
2.响应时间：服务处理一个请求或一个任务的耗时
3.错误率：一批请求中结果出错的请求所占比例
从服务器的角度看，性能测试关注CPU、内存、服务器负载、网络、磁盘IO
可以采用性能测试工具（WeTest服务器性能），该工具是腾讯wetest团队出品，使用起来简单方便，但测试功能相当强大，能提供10W+以上的并发量，定位性能拐点，测出服务器性能最大并发。
APP性能指标有哪些？
答：内存、CPU、流量、电量、启动速度、滑动速度、界面切换速度、与服务器交互的网络速度。
APP测试工具有哪些？
接口测试：postman
性能测试：jmeter
抓包工具：chales、fiddler
UI自动化：uiautomator2、appium、atx
稳定性测试：monkey、maxim、uicrawler、appcrawler
兼容性测试：wetest、testin
内存、cpu、电量测试：GT、soloPi
弱网测试：chales
BUG的生命周期
答：
复杂版：
- New（新的）
- Assigned（已指派）
- Open（打开的）
- Fixed（已修复）
- Pending Reset（待测试）
- Reset（再测试）
- Closed（已关闭）
- Reopen（再次打开）
- Pending Reject（拒绝中）
- Rejected（被拒绝的）
- Postponed（延期）
简单版：
- 创建bug
- 分配bug
- 修复完待测试
- 关闭
- 重新开启
- 无效
什么是α测试和β 测试？
答：
α测试：在受控的环境下进行，由用户在开发者的场所进行，开发者指导用户测试，开发者负责记录发现的错误和使用中遇到的问题。
β 测试：在开发者不可控的环境下进行，由软件最终用户在一个或多个客户场所下进行，用户记录测试中遇到的问题，并定期上报给开发者。
谈谈对敏捷的理解
- 简单谈四种开发模型：
传统的瀑布式开发，也就是从制定计划到需求分析到系统设计，到编码，到测试，到提交到运维大概这样的流程，要求每一个开发阶段都要做到最好。
迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。
螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。
- 谈敏捷测试：
敏捷开发也对应着有敏捷测试，测试环节贯穿整个迭代周期，从需求评审到发布上线，都离不开测试快速跟进。
测试左移：需求评审、用例设计、自测工具、静态代码扫描等；
测试中：业务测试，接口测试，性能测试等；
测试右移：稳定性测试，回归测试，灰度测试等
什么是压力测试？压力测试需要考虑哪些因素？
答：
压力测试是在高负载情况下，对系统稳定性进行测试。在高负载的情况下，系统出现异常的概率要比正常负载时要高。高负载包含长时间运行、大数据、高并发等情况。
在做压力测试时，一般要考虑环境因素、性能指标、运行时间等要素。
- 压测环境最好和生产环境一致，假如要在生产环境进行压测，需要在凌晨等在线用户量极少的情况下进行。在生产环境测试时要做好数据隔离，生产环境需提供虚拟数据，采用虚拟账号，避免对真实线上用户造成影响。
- 性能指标包括，内存、CPU、吞吐量、QPS、网络流量、错误统计等，这些指标需要监控。
- 压测一般需要运行长时间，最好能够通过长时间的压测，绘制出曲线图，这样更容易观察到性能瓶颈。
web测试和APP测试的不同？
系统架构方面：
web项目，一般都是b/s架构，基于浏览器的
app项目，则是c/s的，必须要有客户端，用户需要安装客户端
web测试只要更新了服务器端，客户端就会同步更新。App项目则需要客户端和服务器都更新。
性能方面：
web页面主要会关注响应时间
而app则还需要关心流量、电量、CPU、GPU、Memory这些。
它们服务端的性能没有区别，都是一台服务器。
兼容方面：
web是基于浏览器的，所以要更倾向于浏览器和电脑硬件，电脑系统的方向的兼容
app测试则要看分辨率，屏幕尺寸，还要看设备系统。
web测试是基于浏览器的，所以不必考虑安装卸载。
而app是客户端的，则必须测试安装、更新、卸载。出了常规的安装、更新和卸载，还要考虑到异常场景，包括安装时的中断、弱网、安装后删除安装文件。此外app还有一些专项测试，如网络、适配性。