功能测试

• 正向测试：验证软件在正常情况下是否能够正确工作。

• 反向测试：检查软件在异常输入或错误操作下的响应。

边界值分析

• 边界条件：测试输入范围的上限、下限及其附近值，以确保系统能够正确处理边界情况。

等价类划分

• 等价类：将输入数据划分为若干等价类，每个等价类中的数据被认为对系统有相似的影响。

• 代表性测试：从每个等价类中选择具有代表性的值进行测试。

场景测试

• 用户场景：模拟实际用户操作场景，以检查系统在真实使用环境中的表现。

• 业务流程：按照实际业务流程进行集成测试，确保各模块间无缝协作。

错误猜测

• 常见错误：基于经验和直觉，推测可能出现的错误点并进行针对性测试。

状态转换测试

• 状态图：绘制系统的状态图，设计测试用例以覆盖所有可能的状态转换。

黑盒测试

测试人员在不需要了解内部代码或实现细节的情况下，对软件的功能进行验证。这就像是你在使用一个家电（比如电视）时，只关心它是否正常工作，而不需要知道它内部的电路和组件是如何运作的。

特点：

• 关注外部行为：测试主要关注软件输入和输出之间的关系，而不关心内部逻辑和代码结构。

• 基于规格说明：测试用例通常根据需求文档和功能规格说明书来设计。

• 模拟用户操作：通常通过模拟用户操作来进行测试，以检查系统是否按照预期响应。

常见类型：

• 功能测试：验证各个功能模块是否按预期工作。

• 界面测试：确保用户界面友好且功能正常。

• 回归测试：新功能添加或修复缺陷后，验证旧功能是否仍然正常。

举个例子： 想象你在测试一个电子邮件应用程序。你会检查：

• 是否可以成功发送和接收电子邮件。

• 邮件是否正确显示在收件箱中。

• 搜索功能是否能够找到特定邮件。

你不需要去看应用程序的代码，只需要确认它能正常工作。

白盒测试

测试人员需要了解软件的内部逻辑和代码结构，并利用这些信息来设计测试用例。这就像是你在修理一台电视时，需要知道它内部的电路是如何连接的，以及每个组件的功能。

特点：

• 关注内部结构：测试主要关注代码的执行路径、条件覆盖、循环等内部逻辑。

• 需要编程知识：测试人员通常需要具备编程和代码分析能力。

• 检测代码质量：不仅仅是功能正确性，还包括代码的效率、安全性等。

常见类型：

• 单元测试：对最小的代码单元（如函数或方法）进行测试。

• 集成测试：测试多个代码单元之间的交互和集成效果。

• 代码审查：通过静态分析工具或手动检查代码，发现潜在问题。

举个例子： 假设你在测试一个计算器程序中的加法功能。你会：

• 查看代码，确保所有可能的输入组合都被考虑到。

• 设计测试用例来覆盖所有可能的执行路径，包括正常情况、边界情况和异常情况。

• 确保每一行代码和每个分支都经过测试。

总结

• 黑盒测试：不看代码，只关注软件的功能和行为，像用户一样使用软件进行测试。

• 白盒测试：需要看代码，关注软件的内部结构和逻辑，确保代码质量和运行正确。

6大测试工作流程

掌握需求：保证软件质量前提理解软件需求，怎样算是正确的

软件产品需求规格说明书（SRS）

测试计划：可以按时上线，控制成本

测试用例：测试工作执行的细节

测试执行：按照计划和用例，执行具体的测试工作

测试报告：测试完对软件质量的一个评估报告

回归测试：前面测试发现的问题，开发修复之后，再次测试

6大工作内容

阅读系统需求文档：明白软件功能何为正确

测试计划工作任务排期：excel制作、根据需求文档里的功能模块划分、每项工作开始/结束时间、排期（测试负责人<测试组长、测试经理、项目经理>）

测试用例（具体做的事情）：根据分配的任务范围，指明哪些功能由你负责

测试执行：根据测试用例，一条条执行；发现、记录bug

编写测试用例的一般步骤和要点：

1. 确定测试目标和范围

首先，明确测试的目标和范围。例如，测试智慧分屏功能的稳定性和用户体验是否符合要求。

2. 编写用例标题和描述

用例标题应该简明扼要地描述正在测试的功能或场景。例如：

• 标题： 智慧分屏切换正常性测试

• 描述： 验证在智慧分屏模式下，切换应用程序时屏幕是否稳定显示，避免闪黑屏或者界面混乱。

3. 设定前提条件

指明执行测试用例所需的前提条件，例如：

• 前提条件： 设备已开启智慧分屏功能，并且至少有两个应用程序同时运行。

4. 列出测试步骤

详细列出执行测试的步骤，确保测试过程可重复和清晰。例如：

1. 启动智慧分屏模式，确保两个应用程序同时运行。

2. 在主屏幕上选择一个应用程序进行切换。

3. 观察并记录切换过程中的屏幕反应，包括动画效果和响应速度。

4. 重复步骤 2 和 3，选择另一个应用程序进行切换。

5. 期望结果

明确期望的测试结果，即预期软件在执行完测试步骤后应该表现出来的状态或行为。例如：

• 预期结果： 切换应用程序时屏幕应保持稳定，没有闪黑屏或界面混乱现象。

6. 记录实际结果和备注

执行测试用例后，记录实际的测试结果，并在必要时添加备注。例如：

• 实际结果： 切换应用程序时发现部分情况下会有短暂的黑屏现象，需要进一步优化处理。

• 备注： 在某些情况下，特别是在资源占用较高的应用程序切换时更容易出现。

7. 审核和验证

确保测试用例的内容和逻辑都是清晰和正确的。用例应当能够覆盖到预期的所有测试场景，同时要注意测试步骤的顺序和逻辑是否合理。

8. 反馈和修订

根据执行测试用例的结果，如果发现问题或者需要调整，及时反馈给开发团队，并修订测试用例以更好地覆盖和描述各种测试场景。

在测试过程中自主判断是否发现了一个 bug：

1. 对比实际行为和预期行为

• 执行测试用例： 按照预定的测试步骤执行软件功能或操作。

• 观察实际结果： 注意软件在执行每个步骤时的具体行为和输出。

• 比较预期结果： 深入理解功能的预期行为和输出，确保它们与实际结果一致。

判断依据： 如果实际行为与预期行为不符合，可能表明你发现了一个潜在的 bug。这种差异可以涵盖各种方面，包括界面显示、功能逻辑、数据处理等。

2. 测试边界条件和异常情况

• 测试极端值和异常情况： 尝试使用极端或不常见的输入值，或者执行不寻常的操作。

• 观察软件反应： 注意在这些情况下软件的反应和处理方式。

判断依据： 如果软件在处理边界条件或异常情况时表现异常，例如崩溃、错误消息、不一致的输出等，这可能是一个潜在的 bug。

3. 注重细节和一致性

• 捕捉细微的异常： 注意任何看似不明显但有可能表明问题的异常或不一致现象。

• 保持一致性： 确保软件在不同环境和操作下的行为是一致的。

判断依据： 如果发现一些看似无害但频繁出现的小问题，这可能表明存在一个更深层次的 bug，例如用户体验问题或功能错误。

4. 利用日志和调试工具

• 查看日志和调试信息： 如果可以访问到日志文件或者使用调试工具，查看软件在执行过程中的详细信息。

• 分析异常栈信息： 如果有崩溃或异常，查看异常栈信息可能有助于定位和理解问题的根本原因。

判断依据： 日志和调试信息通常可以提供更多的背景和线索，帮助你确认是否真的发现了一个 bug。

5. 回归测试和验证

• 确认问题重现： 尝试重现发现的问题，确保它是可复制的。

• 确认修复后的验证： 如果已知有 bug 并被修复，确保在进行回归测试后问题已经解决。

判断依据： 如果问题能够稳定地重现，并且修复后验证通过，那么你就发现了一个合格的 bug。

6. 提交详细的 bug 报告

• 准备详细的报告： 描述清楚 bug 的复现步骤、实际行为、预期行为的差异，提供截图或录像以支持你的观察和判断。

• 包含环境信息： 提供软件版本、操作系统、设备信息等必要的环境信息。

判断依据： 提交的 bug 报告应当清晰、具体，并且能够帮助开发团队理解并复现问题。

以登录界面为例可以从哪些方面进行测试用例的编写

1. 功能性测试用例

• 正常登录场景：

  • 输入正确的用户名和密码，验证是否成功登录。

  • 确认登录后页面跳转或显示用户信息。

• 错误登录场景：

  • 输入错误的用户名和正确密码，验证是否提示用户名不存在或登录失败。

  • 输入正确的用户名和错误密码，验证是否提示密码错误或登录失败。

  • 输入空的用户名和密码，验证是否提示必填字段错误。

• 安全性测试：

  • 输入 SQL 注入字符串或特殊字符，验证系统是否能正确拦截并处理。

  • 输入边界条件的密码（例如，最短密码和最长密码），验证系统的反应。

2. 界面和用户体验测试用例

• 界面显示：

  • 确认登录界面元素（用户名输入框、密码输入框、登录按钮）是否正确显示。

  • 验证是否有合适的标签和提示，例如用户名/密码提示文本、忘记密码链接等。

• 用户友好性：

  • 测试用户在不同分辨率和设备上的界面显示和操作体验。

  • 验证是否支持键盘操作（例如，使用 Tab 键切换焦点）。

• 记住我功能：

  • 测试勾选记住用户名或密码后的登录流程。

  • 验证用户再次访问时是否自动填充保存的用户名和密码。

3. 安全性和性能测试用例

• 会话管理：

  • 测试会话超时策略，例如长时间不操作后是否自动注销用户。

  • 验证用户在会话过期后的行为（例如，重新登录或返回登录页面）。

• 性能测试：

  • 在高负载情况下，测试登录页面的响应时间和并发用户支持情况。

  • 确保在压力测试下系统能正常处理大量登录请求。

4. 兼容性和配置测试用例

• 浏览器兼容性：

  • 在主流浏览器（例如 Chrome、Firefox、Safari、Edge）上测试登录界面的兼容性。

  • 确保在不同浏览器版本下界面显示和功能正常。

• 设备兼容性：

  • 在不同操作系统和设备（例如 Windows、Mac、iOS、Android）上测试登录界面的兼容性。

  • 确保界面和功能在各种设备上表现一致。

5. 异常和边界情况测试用例

• 异常输入测试：

  • 输入超长的用户名和密码，验证系统的处理方式。

  • 输入非法字符（如特殊符号或控制字符），验证系统是否能正确拒绝或处理。

• 边界条件测试：

  • 测试最短和最长长度的用户名和密码，验证系统的反应。

  • 确保系统在极端情况下的稳定性和正确性。

ADB的工作方式

ADB包括三个组件:

adb 客户端，发送命令。客户端在开发机器上运行。您可以通过发出adb令从命令行终端调用客户端。

adb服务器,管理客户端与守护程序之间的通信。服务器在开发机器上作为后台进程运行。

adb守护程序，在设备运行命令。守护程序在每个设备上作为后台进程运行。

adb devices	显示已连接的设备列表
adb install <path_to_apk>	安装 APK 文件到设备 （-r即可覆盖安装）
adb shell	进入设备
adb uninstall <package_name>	卸载指定包名的应用
adb push <设备路径> <本地路径>	从设备中复制文件到本地
adb pull <本地路径> <设备路径>	将本地文件复制到设备
adb logcat -v time	打印log的详情日志
adb logcat -c	清除之前的日志信息
adb reboot	重启设备
adb shell screencap <file>	截取设备屏幕截图（后缀需要 .png 才行， .jpg 是个损坏文件(失败)）
adb shell wm size	屏幕分辨率
adb shell wm density	屏幕密度
adb shell getprop ro.build.version.release	查看 Android 版本
adb shell pm list packages	设备所有包名(含系统)

兼容性测试

兼容性：程序能在不同的设备上运行正常

品牌型号（品牌、系统版本、分辨率）

网络

软件兼容

硬件兼容

 

 

push消息推送方式

pull(拉)客户端主动获取：客户端固定时间主动向服务器获取消息。消耗客户端和服务器资源

push（推）客户端被动接受：当服务器有更新消息时，主动发送到客户端。节省客户端和服务器资源

在APP项目中，基于手机电量与流量的考虑，使用的都是push方式进行消息推送，因此又叫做push消息。

push消息测试点提取：

交叉测试：

又叫(冲突、干扰)测试，是指一个功能正在执行过程中，另外一个事件或操作对该过程进行干扰的测试。如:在App前台/后台运行同时接听来电或者下载文件等。

交叉事件测试关注点：

用户体验测试：

以主观的角度去感知产品或服务的舒适、易用、友好亲密程度。

非功能测试

性能测试：工具或命令进行测试

• 工具 SoloPi：无线的Android自动化工具，具备录制回放、性能测试等功能。

  ①Android:工具( solopi、GT) +命令(adb ) ②los:苹果开发工具xcode

  下载: SoloPi Android 版本 APK 下载 - PGYER.COM

• 功能 1、性能测试：能够对CPU、内存与网络环境进行限制，复现应用在性能较差、网络环境不佳场景下的表现。 2、录制回放（自动化操作）：能够将用户的操作记录下来，支持在各个设备上进行回放。 3、一机多控（兼容性测试）：操作一台主机设备来控制多台从机设备，进行重复冗杂的兼容性测试，能够极大提升兼容性测试的效率。

• 分类：资源占用、稳定性

APP性能测试关注点：内存、CPU、流量、电量、启动速度、流畅度、稳定性。

1. 内存监控指标（关注点）：

内存问题的现象：内存泄漏、内存溢出

2.CPU监控指标（关注点）

• Solopi工具提供两个CPU监控指标：全局占用CPU和应用进程CPU

（1）全局占用CPU：整机的CPU使用水平，即当前手机的CPU整体使用率。 在Linux系统下，CPU利用率分为用户态、系统态和空闲态 用户态：表示CPU处于应用程序执行的时间。 系统态：表示系统内核执行的时间。 空闲态：表示空闲系统进程执行的时间。

CPU使用率= CPU执行非系统空闲进程时间1 CPU总的执行时间

（2）应用进程CPU：表示自开机以来,应用程序消耗的CPU时间的总数。

• CPU消耗引起的现象： CPU使用长时间处于90%以上 手机发热、耗电量增加 响应变慢、引起ANR 无响应(Application Not Responding)

3.流量监控指标（关注点）

流量：操作APP与服务器交换数据的总大小

提示：在模拟器中无法统计电脑流量使用情况，看进程使用流量即可

流量优化策略：

• 数据的压缩

• 不同数据格式的采用

• 控制访问的频次

• 只获取必要的数据

• 缓存机制

• 针对不同的网络类型设置不同的访问策略

4.电量监控指标（关注点）

耗电量大场景：

定位 网络传输 屏幕亮度 wake_ locker (锁屏-解锁)

结果分析（分析结果） 1、与基准数据对比(基准数据来自于产品经理，或者以往数据积累)。 2、横向对比(竞品) (目前多数采用这种方法)。

提示：模拟器没有电池，无法获取电量数据。

5.流畅度监控指标（关注点）

流畅度：动画播放或图片切换的流畅性。

注意事项：

1、当页面多为静态时，FPS值很小是正常的 2、页面数据多为动态加载时，FPS值比较大(建议在24帧以上) 3、达到流畅效果24/S，最佳流畅效果60/S。

6.启动速度监控指标（关注点）

APP启动速度：从启动app到主页面加载完成的速度。

APP启动分类：冷启动、热启动。 冷启动:：启动app进程。 热启动：将app从后台置于前台。

Solopi指标：启动耗时计算。

7、稳定性测试（Android-SDK环境）

app使用过程中会遇到的现象：崩溃、闪退、无响应、卡顿。

稳定性：app程序能持久良好的运行。

稳定性测试：在app应用中随意操作，挖掘有可能出现的异常。

1、使用Monkey工具进行测试。

monkey就是猴子，monkey测试就像 一只猴子在玩手机(乱抓、乱点)。

作用：模拟用户随机(触摸屏幕、滑动、按键)等操作来对程序进行稳定性测试，检测程序异常情况。

提示：

①Monkey程序是Android系统中自带一款稳定性测试工具， 由Java语言编写。[无需单独安装]

②Android位置: /system/framework/monkey.jar

Monkey命令参数：

AI使用技巧

1、AI助力需求分析

1、阅读需求，对业务进行学习。 2、评审需求，提出疑问。 AI作用 ●分析需求，协助理解需求。 ●评审需求合理性，提出需求不足之处。 需求: 1.账号：必填，已经注册手机号或邮箱。 2.密码：必填，注册账号的密码。 3.验证码：正确且未过期。

评审需求的合理性是确保软件项目成功的关键步骤。对于上述需求，我们可以从以下几个方面进行合理性评估，并提出潜在的不足之处：

1. 账号需求：

• 合理性：要求用户使用已注册的手机号或邮箱登录是常见的做法，这有助于确保用户账户的安全性。

• 不足之处：需求中没有说明用户是否可以在选择手机号或邮箱之间切换，如果用户更倾向于使用另一种方式登录，可能会造成不便。

1. 密码需求：

• 合理性：要求用户输入密码以验证身份是标准的安全措施。

• 不足之处：需求中未提及密码的复杂性要求、是否支持密码重置、忘记密码的处理流程等，这些都是用户体验和账户安全的重要组成部分。

1. 验证码需求：

• 合理性：使用验证码可以增加账户安全性，防止自动化攻击。

• 不足之处：需求中没有明确验证码的有效期是多久，以及用户在验证码过期后应如何重新获取。此外，也没有说明如果用户输入错误验证码的次数限制，以及处理策略，这可能会导致用户在输入错误多次后被锁定。

1. 用户体验：

• 不足之处：需求中缺乏对用户友好性的考虑，例如，没有提供图形验证、生物识别等替代登录方法，这些方法可以提高用户体验并减少传统登录方式的麻烦。

1. 隐私和合规性：

• 不足之处：需求中没有提及如何处理用户敏感信息，例如密码和手机号的存储和传输安全性。也没有提到是否符合相关的数据保护法规（如gdpr、ccpa等）。

1. 技术支持和帮助：

• 不足之处：需求中没有提供用户在忘记密码或无法登录时的支持和帮助指南。

1. 国际化和本地化：

• 不足之处：如果系统面向多个国家或地区，需求中没有考虑到不同地区的语言和文化差异。

1. 无障碍性：

• 不足之处：需求中没有考虑到残疾人用户的无障碍需求，如屏幕阅读器兼容性等。

为了提高需求的完整性和系统的最终用户体验，建议对上述不足之处进行补充和完善。需求文档应该全面覆盖所有可能的用户场景，并提供清晰、明确的指导，以确保开发团队能够实现一个既安全又易用的软件产品。

2、AI生成测试报告：