客户端测试_笔试题

微信【文本】聊天的测试功能点

抓包工具如何修改服务器的返回值

1. 以Charles为例，使用断点功能和maplocal功能即可。

如何拿到app crash日志，并定位堆栈

1. 产品未上线前，开发人员可以通过开发者工具拿到crash日志（Android通过AndroidStudio工具，iOS通过Xcode）
2. 崩溃不会自己保存成日志文件，所以需要程序能收集异常信息，为了方便查看，需要保存在sd卡中（默认保存在sd卡根目录/你的appName/Crash/下，具体目录咨询开发人员），并在适当的时候上报到服务器。
3. 测试过程中发现了crash，找到相关日志信息，通过关键字定位一下。

Android具体的操作：

1. 使用adb命令连接到手机，再使用adb logcat命令去收集打印日志信息
2. 日志收集好后，可以根据exception、fatal、error等关键字进行搜索，找到具体报错的信息位置
3. 将找到的报错信息截图发给开发人员，帮助其定位问题

iOS获取crash日志的方法：

1. 使用Xcode：
   1. 如果你有应用的源代码并且正在使用Xcode进行开发，你可以通过Xcode来获取crash日志。
   2. 选择“devices”或“Organizer”，然后在设备列表中选择你的设备。在设备的详情页面中，可以查看设备的日志，包括应用的crash日志。
2. 通过设备的设置：
   1. iOS设备本身也会记录一些crash日志。可以通过进入设备的“设置”-“隐私”-“分析与改进”，然后打开“共享iphone分析”或“共享iPad分析”。这样设备会自动将一些崩溃的日志发送给苹果，也可以通过苹果的开发者网站或者其他相关工具来查看这些日志。
3. 使用第三方工具：
   1. 有一些第三方工具可以帮助你获取iOS应用的crash日志。
   2. 例如，.crash文件（通常在设备的Library/Caches/Logs目录下），然后使用合适的工具来解析和分析这些日志
4. 集成崩溃报告工具：
   1. 在开发过程中，可以让开发集成一些专门的崩溃报告工具，如Firebase Crashlytics、Bugsnag等。这些工具可以在应用发生崩溃时自动收集相关信息，并提供给开发用于分析和解决问题。

举几个app崩溃的堆栈类型

1. 内存泄漏。关键字java.lang.OutOfMemoryError:Java heap space。当应用程序使用完内存后，没有及时释放，导致内存占用逐渐增加，最终可能导致应用程序崩溃。
2. 数组越界。关键字IndexOutOfBoundsException。当访问数组元素时，使用了超出数组边界的索引，可能会导致应用程序崩溃。
3. 空指针异常。关键字NullPointerException。当尝试访问一个为空的指针或者引用时，会导致应用程序崩溃。
4. 除0错误。在数学运算中，除以零会导致应用程序崩溃。
5. 线程死锁。当多个线程互相等待对方释放资源时，会导致线程死锁，从而使应用程序崩溃。
6. 资源竞争。当多个线程同时访问共享资源时，如果没有正确的同步机制，可能会导致资源竞争，进而导致应用程序崩溃。
7. 内存溢出。关键字OutofMemoryError，简称OOM。
   1. 是由于程序对内存的需求超过了系统的可用内存，可能是由于分配了过大的内存、内存使用效率低下等原因。
   2. 集合类中有对对象的引用，使用完后未清空，使得JVM不能回收
   3. 代码中存在死循环或循环过多重复的对象实体
   4. 启动参数内存值设定的过小

app兼容性测试有哪些维度

APP测兼容性可以从以下几个维度进行考虑：

1. 操作系统版本：
   1. 不同操作系统版本可能会对app的兼容性产生影响。例如，测试APP在Android和iOS不同版本上的运行情况，包括界面显示、功能可用性、性能等。
   2. 如：在不同版本的Android（8.0、9.0、10.0等）和iOS（如iOS12、13、14等）上安装和运行APP，检查界面布局、功能操作、性能表现等是否正常
   3. 测试APP在不同版本的WebView中的兼容性，例如检查网页加载、表单提交等功能
2. 屏幕尺寸和分辨率：
   1. 各种屏幕尺寸和分辨率可能会导致APP的布局和显示问题。例如，测试APP在不同尺寸的手机、平板电脑和可穿戴设备上的适配性
   2. 如：在具有不同屏幕尺寸的手机（如小屏幕、大屏幕、全面屏等）上测试APP，检查界面元素的现实是否完整、清晰，是否存在布局错乱或截断的问题
   3. 针对高分辨率和低分辨率的设备进行测试，确保图形、图标和文字的显示质量。
3. 硬件配置：
   1. 不同的硬件配置（如处理器、内存、存储等）可能会影响APP的性能。例如，测试APP在低端、中端、高端设备上的运行速度和稳定性
   2. 如：在低端、中端、高端设备上测试APP的启动时间、响应速度和资源占用情况，评估APP在不同性能设备上的表现。
   3. 测试APP在内存受限的设备上的运行情况，观察是否出现闪退货内存泄漏等问题
4. 网络环境：
   1. 网络连接类型（如Wi-Fi、移动数据）和网络速度可能会对APP的数据传输和功能产生影响。例如，测试APP在不同网络环境下的加载速度、数据同步等
   2. 如：在不同网络条件下（无Wi-Fi、4G/5G网络）测试APP的联网功能，如登录、刷新数据、下载等，检查是否能够正常工作并处理网络异常情况
   3. 模拟网络延迟和中断，测试APP的容错性和数据恢复能力
5. 其他应用的兼容：
   1. 与其他应用的交互或共存可能会引发兼容性问题。例如，测试APP在与常见的三方应用一起使用的时候是否正常。
   2. 与常见的第三方应用（如社交媒体、地图导航、音乐播放器等）同时运行APP，观察是否存在冲突或功能异常
   3. 测试APP在安装和运行其他应用后是否能正常工作，例如检查内存占用和后台运行情况
6. 数据兼容性：
   1. APP可能需要与各种数据格式和数据库进行交互。例如，测试APP对不同格式的文件的读取和处理能力（如图片、音频、视频等）
   2. 如：导入和导出不同格式的文件（如图片、文档、音频等），检查APP对各种文件格式的支持和处理能力
   3. 测试APP与不同版本的数据库或数据存储方式的兼容性，确保数据的完整性和正确性。
7. API和库的兼容：
   1. APP可能依赖于特定的API或库。例如，确保APP所使用的API和库与目标操作系统和版本兼容。
   2. 如：更新或替换APP所使用的API或库，检验APP是否能正常工作，是否存在兼容问题
   3. 检查APP在使用旧版本API或库时的兼容性，确保向后兼容性
8. 用户设置和偏好：
   1. 不同用户的设置和偏好可能会影响APP的行为。例如，测试APP在不同的语言设置、主题模式、通知设置等情况下兼容性。
   2. 如：更改设备的语言、主题模式、通知设置等，测试APP在不同用户设置下的显示和功能

可以在测试过程中，使用真机或模拟器来模拟不同的设备和操作系统环境。同时可以结合自动化测试工具和人工测试来全面评估APP的兼容性。需要注意的是，具体的兼容性测试维度和重点会根据APP的特性和目标用户的设备使用情况和条件，提高测试的效率和准确性。

线上app数据突然加载不出来，有哪些可能性

1. 网络问题。网络连接不稳定、断网或者网络延迟可能导致数据加载失败。例如，服务器网络故障、客户端网络连接问题或网络中间设备出现故障。
2. 服务器故障。服务器可能出现故障或过载，无法及时响应请求并提供数据。例如，服务器硬件故障、服务器软件崩溃或数据库连接问题。
3. 数据库问题。数据库可能遇到性能问题、连接中断或数据损坏。例如，数据库服务器宕机、数据库查询过于复杂或数据库表结构损坏。
4. 代码错误。应用程序代码中的错误或异常可能导致数据加载失败。例如，逻辑错误、语法错误或与数据加载相关的代码bug。
5. 权限问题。用户可能没有足够的权限访问所需的数据。例如，身份验证或授权问题可能阻止数据的加载。
6. 数据完整性问题。数据可能存在损坏或不一致，导致无法正确加载。例如，数据文件损坏、数据格式错误或数据传输过程中的错误。
7. 缓存问题。缓存失败、缓存设置不正确或缓存清除问题可能影响数据的加载。例如，缓存服务器故障或缓存过期策略导致数据无法从缓存中获取。
8. API更改或升级。如果应用依赖外部API获取数据，API的更改或升级可能导致不兼容性，从而影响数据加载。
9. 安全限制或防火墙。安全设置或防火墙规则可能阻止数据的传输和加载。例如，网络安全策略限制了对特定数据源的访问。
10. 大量并发请求。高并发负载下，服务器可能无法及时处理所有请求，导致部分数据加载失败。

影响app FPS的因素有哪些

• 首先知道FPS是什么？
  • 是“每秒帧数”的意思，是衡量显示设备或计算机图形处理能力的一个重要指标
• 其次影响App FPS的因素主要包括：
  • 硬件配置。帧数与计算机的硬件有很大关系。显卡、CPU和内存条的性能对FPS有直接影响。高性能的显卡可以提供更高的图形处理能力，而强大的CPU和足够的内存可以确保游戏或应用流畅运行。
  • 显示器刷新率和分辨率。
    • 刷新率：显示器每秒钟刷新屏幕的次数，单位赫兹（Hz）。显示器的刷新频率直接影响到FPS。高刷新率的显示器能够显示更流畅的动作。
    • 分辨率：显示器所能显示的像素数量。分辨率较高的显示器可能呈现更新清晰、更细腻的图像。提高分辨率会增加显卡的工作负荷，因此可能会降低帧数，相反，降低分辨率可以提高帧数。
  • 画面细节：游戏画面中的高级特效和细节也会影响帧数。如果将这些特效和细节设置的过高，可能会提高帧数。
  • 硬盘性能。硬盘的读写速度和稳定性也会影响FPS。SSD（固态硬盘）通常提供更快的读写速度，有助于减少系统负担，从而提升FPS。
  • 软件设置。游戏或应用的帧数设置和其他设置也会影响FPS。例如，将帧数限制设置的太低可能会导致画面卡顿。
  • 网络情况。网络延迟或不稳定也会影响FPS。特别是在需要联网的游戏或应用中，稳定的网络连接对于保持高FPS至关重要。
  • 其他因素。还包括电量消耗、电池寿命、操作系统的性能等。

如何判断app内存泄漏？举几个本质原因

1. 判断app发生内存泄漏的方法
   1. 观察内存使用情况。持续检测应用的内存使用量，如果它在一段时间内持续增长，即使在没有明显的新操作或数据加载的情况下，可能就暗示着内存泄漏。
   2. 使用内存分析工具。例如Android开发中可以使用Android Studio中的内存分析工具，或者三方内存分析工具，LeakCannry
   3. 监控内存泄漏警告或错误。有些操作系统或开发环境会在发生内存泄漏时发出警告或错误信息。密切关注这些消息可以提示你可能存在的内存泄漏。
   4. 进行压力测试。通过对应用进行高负载或长时间运行的测试，观察内存使用情况是否出现异常增长。
   5. 比较不同场景下的内存使用。比相同应用在不同操作或场景下的内存使用情况。如果在特定操作后内存使用显著增加，而这些操作应该不会导致内存增长，那么可能存在内存泄漏。
   6. 查看日志和堆栈跟踪。检查应用的日志和堆栈跟踪信息，看是否有与内存相关的异常或错误消息，这可以提供关于内存泄漏的线索。
   7. 可以通过客户端现象初步判断。
      1. 性能下降。内存泄漏会导致应用占用的内存增加，可能会使应用的响应速度变慢，出现卡顿或延迟。
      2. 崩溃或闪退。如果内存泄漏严重，导致系统内存耗尽，应用可能会崩溃或意外退出。
      3. 卡死或无响应。内存泄漏可能会导致应用在一定时间后变得无响应，用户可能会遇到界面卡死的情况。
      4. 电池消耗增加。
      5. 应用功能异常。内存泄漏可能会干扰应用的正常功能，比如说导致数据丢失、错误或不一致。
      6. 但是，并不是所有的内存泄漏都会立即导致明显的问题。内存泄漏的影响程度取决于泄漏的严重程度、应用的设计和使用情况，以及设备的硬件资源等因素。
2. 导致内存泄漏的一些本质原因
   1. 对象的生命周期不正确。对象在不需要时，没有被正确的销毁和释放内存。例如，没有正确的取消注册观察者、释放资源或关闭连接。
   2. 程序内有循环引用。这是内存泄漏的常见原因之一。对象之间形成循环引用后，它们将无法被垃圾回收器正确回收。
   3. 没有正确的处理异步操作和回调。
   4. 长生命周期的对象持有短生命周期对象。如果一个长生命周期对象持有了短期对象的引用，即使短期对象不再需要，它们也无法被垃圾回收。
   5. 匿名内部类的使用。匿名内部类可能会导致对外部类的隐式引用，从而延长对象的生命周期。
   6. 资源泄漏。例如，没有关闭数据连接、释放文件句柄或释放其他系统资源。
   7. 错误的内存分配。分配了过大的内存或在不需要的情况下频繁分配内存。
   8. bug或错误的代码逻辑。

微信iOS客户端和安卓客户端聊天，会有哪些兼容问题？为什么？

（是打字聊天？语音聊天？视频聊天？没搞明白）可能的兼容问题：

1. 处理图片、语音消息时表现不一样，视频聊天时画面、语音不同步。（不同系统实现方式不一样）
2. 页面布局问题。（对布局的支持略有不同）
3. 样式问题。（iOS和Android设备对字体的默认设定存在差异）
4. Javascript问题。（对javascript API的支持存在差异）
5. 数据显示问题。（之前iOS微信可以发送动态表情包，安卓不行）
6. 三方库和插件的支持。（三方库和插件在不同平台上的实现存在差异的话，可能也会有一些问题。）
7. 安全和权限限制。（iOS和安卓的安全和权限模型可能不同导致一些问题，如地理位置共享或文件传输。）

原因：

1. 操作系统差异。
2. 微信版本不一致。
3. 硬件和性能差异。
4. 第三方库和插件。
5. 安全和权限限制。

（不知道题目是不是问的这些，救救孩子吧……）

如何验证发送1W条消息是否有数据丢失？是否时序正常？

作为一个测试人员，可以利用消息队列的拦截器机制来验证，发送一万条消息时是否有数据丢失，并且保证它的时序与正常时间的时序一致。具体操作步骤：

1. 在Producer发送消息之前的拦截器中将序号注入到消息中
2. 在Consumer收到消息的拦截器中检测序号的连续性
3. 如果是分布式系统，需要指定分区，并在每个分区单独检测消息序号的连续性
4. 如果Producer是多实例，需要每个producer分别生成各自的消息序号，并附加上Producer的标识
5. Consumer实例的数量最好喝分区数量一致，方便在Consumer内检测消息序号的连续性

通过以上方法，可以在不影响业务代码的情况下，检测消息是否丢失，并确保时许的正常顺序。

除了上述方法外，还可以利用消息队列的有序性来验证是否有消息丢失：

在Producer端，给每个发出的消息附加一个连续递增的序号，然后在Consumer端检查这个序号的连续性。如果没有消息丢失，Consumer收到消息的序号必然是连续递增的。如果检测到序号不是连续的，就说明丢消息了，可以通过确实的序号来确定丢失的是哪条消息，方便进一步排查原因。

具体的操作案例：

1. 准备工作：
   1. 确定使用的消息队列系统或工具
   2. 设计测试用例，包括消息的内容、格式和顺序
2. 发送消息
   1. 使用测试工具或代码发送一万条消息到消息队列
   2. 在发送过程中记录每一条消息的唯一标识（如消息编号）
3. 接受消息
   1. 在接收端使用相应的工具或代码从消息队列中获取消息
   2. 确保接收端能够正常处理和存储接收到的消息
4. 数据完整性检查：
   1. 对比发送的消息数量和接收的消息数量是否一致
   2. 检查接收的消息内容是否与发送的消息一致，确保没数据丢失
5. 时序检查
   1. 根据记录的消息编号，检查消息的顺序是否与预期的顺序一致
   2. 可以使用时间戳等方式来辅助判断时序是否正常
6. 异常情况处理：
   1. 在测试过程中，注意观察是否有异常情况出现，比如消息丢失、重复或乱序
   2. 如果发现异常，及时进行排查和解决
7. 重复测试
   1. 为了增加测试的可靠性，可以进行多次重复测试，并比较结果
8. 分析和报告
   1. 根据测试结果进行分析，却行消息队列在发送大量消息时的性能和稳定性
   2. 撰写测试报告，包括数据完整性和时序性的情况

在实际操作中，可能需要根据消息队列系统和测试环境进行适当的调整。同时，还可以结合监控工具来实时监测消息队列的状态和性能。