功能测试

一个完整的测试计划应该包含哪些内容

• 项目/功能描述
• 测试范围（功能/非功能）
• 测试开销估计（时间/人力）
• 预计排期
• 测试用例
• 测试开始和结束的标准
• 可能存在的风险和应对方案
• 相关人员（开发/产品）的审核记录
• 历史版本

一个完整的测试用例包含哪些内容？

用例描述、优先级、适用的平台、所属模块、测试步骤、期望结果，与界面相关的提供截图等。

什么时候需要发测试报告？一份测试报告应该包含哪些内容？

• 项目测试过程中，每天的测试执行完成之后需要发送测试报告，项目测试完成后要发一份整体的测试报告。
• 测试报告中需要包含整体测试状态，进度，问题列表，每项子任务的预计完成时间，已经测试完成的用例和测试结果，是否有需要处理的风险或阻碍项，问题列表中需要有问题描述，优先级，状态，责任人等。

一个完整的缺陷报告应该包含哪些内容？

完整的缺陷报告至少应该包含：发现问题的软件版本、使用的测试数据和账号、测试步骤、期望结果、实际结果、严重程度、期望修复的时间和版本、复现的概率、日志、截图、录屏等。

简述等价类划分法并举例

• 等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例.
• 例如测试用户输入框，可以把字母/数字/无效输入/组合输入等划成几类，针对不同类设计用例。

针对具体场景的测试用例设计（比如测试一只笔，一个用户登录页面等）

使用常用的用例设计方法对可能的场景和功能尽可能覆盖到，同时考虑支持的平台，不同用户的差别，兼容性和易用性，非功能性测试可以考虑性能，安全性等。
http://t.csdnimg.cn/NbCtH

怎样与开发沟通一个不总是能复现的缺陷？

• 通过不同测试条件（设置，数据，账号等）的组合尝试找出可能触发问题的场景；
• 保留问题发生时的完整日志，尝试从日志中发现可能的错误；
• 在缺陷报告中提供完整的场景描述、截图录屏、日志以及发生概率，配合开发人员做后续测试和分析。

怎样与开发沟通一个开发不认为是缺陷的问题？

• 从用户体验的角度看目前的行为是否合理；
• 竞品比较，行业内其他类似的产品是如何处理的；
• 邀请产品经理介入，询问他的意见。

如何划分缺陷的严重级别？

缺陷一般分成四个等级：

1. 严重 - 导致严重用户体验问题和关键功能失效的必须修复的缺陷;
2. 重大 - 必须修复的用户体验问题，与需求文档不符合的关键功能缺陷；
3. 一般 - 不好的用户体验，需要修复但是不紧急；
4. 小 - 最好能修复的可以提升用户体验的问题。

如何和开发就缺陷的严重程度达成一致？

通过文档和流程来确保和团队其他成员就缺陷的等级划分达成一致意见。比如制定流程规范，邀请所有相关人员审核，达成一致后作为标准指导后面的缺陷提交和修复。

整个项目开发过程中有哪些需要测试参与的环节

• 需求评审
• 代码设计评审
• 代码评审
• 测试评审
• 测试执行
• 缺陷跟进
• 上线评估
• 上线后的测评
• 线上数据分析
• 线上问题跟踪
• 回归测试自动化
• 定期的缺陷分析和用例/流程改进

测试人员是否需要参加代码审核？重点需要关注什么？

测试人员需要参加代码评审，通过静态代码走查和代码审核报告确保：

1. 代码变动有足够的单元测试覆盖率；
2. 发现可能的边界条件处理问题；
3. 通过测试用例补充单元测试中可能无法覆盖的分支；
4. 检查代码中可能存在的问题提早纠正；
5. 检查代码是否能够实现预期的功能。

如何预估测试工作量

• 根据测试计划，预估测试用例设计及评审、测试计划制定及评审、测试执行及缺陷跟进、上线准备、上线后的跟踪和数据分析、回归测试自动化分别所需要的时间
• 同时考虑测试过程中可能存在的风险（比如首次提测无法达到测试开始标准、对其他团队的依赖导致的延迟、可能的需求变更导致的测试范围变化等）给出对应的可能结果和应对方案。

如果出现排期紧张，上线之前大量测试可能无法按时测试怎么办？

1. 根据现有数据提前预警和告知所有相关人员，提示可能的风险；
2. 提出可能的应对方案，包括合并和精简测试，扩充人员，倒休；
3. 对每种方案带来的优劣点做充分沟通保证团队达成一致；4. 确定方案后给出新的估计和可能存在的风险。

产品上线之后发现问题，测试人员需要如何做出响应？

1. 配合开发人员复现和调研问题；
2. 如果是环境差异（配置或者资源本身）导致的问题，需要优化上线前测试流程，添加在无此差异的环境上测试用例；
3. 如果是软件问题，需要查看是否有用例覆盖此场景，如果没有需要添加，如果有，需要调查为什么没被执行或者执行了未被发现；
4. 写总结报告，总结问题和需要采取的行动，避免下次出现同样的问题。

测试过程中如何保证测试用例能够及时更新？

• 借助测试用例管理工具比如禅道，testrail对测试用例进行版本管理；
• 需求、设计或者实现发生变更时及时更新用例；
• 定期的测试用例评审保证测试用例有效性。

如何衡量和保证测试覆盖率？

• 根据业务流程图、数据处理时序图、类图等设计文档检查用例对主要分支的覆盖程度；
• 邀请产品经理、项目经理、开发团队、测试团队审核测试用例；
• 根据测试过程中发现的问题对出现问题较多的功能加强用例覆盖

产品需求发生变更时，测试人员需要做出什么响应？

1. 与产品经理及开发人员沟通该变更是否必要，如需变更，是否有其他更好方案；
2. 评估变更对测试范围和测试工作量的影响；
3. 更新测试用例和测试排期并邀请所有相关人员审查；
4. 明确告知变更带来的影响和可能的解决方案（更多测试资源，交叉简化部分测试，分批上线等）。

测试计划中的测试开始条件一般包含哪些内容？

软件关键功能工作正常，无阻碍测试的缺陷，无影响用户使用的重大缺陷。具体执行中，需要测试人员在测试计划中列出测试开始条件，与开发团队共同审核达成一致后执行。

测试计划中的测试结束条件一般包含哪些内容？

无严重、无重大、无一般级别缺陷，达到需求验收标准，所有未修复缺陷缺陷团队整体已经知晓并达成一致可以发布后修复。

什么是白盒测试？可以完全替代黑盒测试吗？

• 白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。 它根据程序的控制结构设计测试用例，主要用于软件或程序验证。 白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。
• 由于不能模拟端到端，因此不能替代黑盒测试。

白盒测试的覆盖标准有哪些？分别指的是什么？

白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。

• 逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和修改条件判断覆盖，六种覆盖标准发现错误的能力呈由弱到强的变化，分别是：
  • 1.语句覆盖每条语句至少执行一次；
  • 2.判定覆盖每个判定的每个分支至少执行一次；
  • 3.条件覆盖每个判定的每个条件应取到各种可能的值；
  • 4.判定/条件覆盖同时满足判定覆盖条件覆盖。
  • 5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次；
  • 6.修改条件判断覆盖每一个判断的所有可能结果都出现过、每一个判断中所有条件的所有可能结果都出现过、每一个进入点及结束点都执行过、判断中每一个条件都可以独立的影响判断的结果。

产品上线后，还需要做哪些工作保证线上质量？

产品上线之后，还需要做线上回归测试，保证产品的各项功能和性能均正常。同时需要监测线上数据和异常日志，跟踪用户反馈并及时处理。

你了解灰度发布吗？它的作用是什么？

• 灰度发布 （又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。
• 在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
• 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 灰度期 ：灰度发布开始到结束期间的这一段时间，称为灰度期。
• 为什么要灰度发布
  • 灵活选择用户参与产品测试。
  • 规避一定的发布风险，降低产品迭代升级所影响的范围。

什么是a/b测试？a/b测试中如何保证覆盖率？

• a/b测试是一种用户体验研究方法，通常针对两到三个不同的用户体验方案给出不同的代码实现，按比例随机分配用户到其中的某个方案，根据上线后的用户数据（点击率，购买率，存活率，注册率等）来决定哪个方案更受用户青睐。
• 针对a/b测试，测试计划应该覆盖不同入口条件下的不同方案的组合测试，从而保证任何路径下用户的体验是完整合乎期望的。

你是否组织或者参加过上线之前的beta测试？它的作用是什么？

• beta测试通常指的是测试和缺陷修复完成之后，组织人力资源对项目进行集中测试。
• 它的组织形式可以是会议，也可以是发送请求测试邮件和在系统中搜集反馈，参与人员可以包括所有项目相关人员，也通常邀请其他团队人员来交叉测试和验收
• 主要目的是尽可能的在上线之前发现可能遗漏的问题或者提升用户体验的建议。

什么是冒烟测试？

冒烟测试通常用于验证软件的关键功能工作正常，它通常是执行详细的功能测试或者回归测试的前提条件

冒烟测试之后发现交付的软件达不到开始测试的标准应该怎么办？

1. 测试计划中应该明确标注测试开始的标准（如冒烟测试中无重大问题，没有阻碍测试的重大缺陷）；
2. 冒烟测试后发现无法达到测试开始的标准，应该果断拒绝继续测试并且将问题反馈给所有相关人员；
3. 要求开发团队给出明确的下个版本交付的时间并说明对测试工作和整体项目排期可能造成的影响；
4. 对测试资源和进度进行重新安排和沟通已确保整体项目进度。

单元测试的作用是什么？是否使用过junit之类的单元测试工具？

• 单元测试是用来测试软件中某些独立单元的技术，用于在开发阶段验证代码的正确性
• junit是常用的单元测试工具之一。一般开发人员需要自己写单元测试，测试人员可以通过审查单元测试查看覆盖率和发现需要在端到端测试中加强的点。

系统测试和集成测试分别指什么？

• 集成测试在系统测试之前，单元测试完成之后系统集成的时候进行测试。
• 集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。
• 集成测试对测试人员的编写脚本能力要求比较高。 测试方法一般选用黑盒测试和白盒测试相结合。
• 系统测试是基于软件需求的黑盒测试，是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确。

测试中需要收集哪些日志？这些日志的作用是什么？

• 对于服务器端测试，需要收集服务器日志，以便出现问题时，开发人员可以从日志中获取堆栈信息定位问题；
• 自动化测试需要采集测试执行的日志，追踪执行的步骤和可能抛出的异常；
• 对于性能测试，需要采集系统资源使用数据和时间戳；
• 客户端测试在发现问题时需要采集发送的完整请求和响应消息内容。

移动端测试相比传统web端，需要注意哪些方面？

相较于传统的web端、PC客户端产品的测试，移动端的测试受手机屏幕大小、内存、CPU、网络特性，操作系统、用户使用习惯的差异，有其自身的特点，所以对移动端产品测试就需要充分考虑测试差异而单独分列出来。

安卓和ios客户端测试有何不同？

1. 按键习惯差异：Home键，左右滑动，返回的处理等;
2. 操作系统和品牌差异：在Android平台则包括各种主流品牌，操作系统和版本的测试，选型涉及较多，而iOS较少;
3. 分辨率差异：Android端有多种，iOS较少;
4. 升降级：iOS不能降级，只能单向升级;新的iOS系统中的资源库不能完全兼容低版本中的iOS系统中的应用，低版本iOS系统中的应用调用了新的资源库，会直接导致闪退(Crash);Android可以被升级的必要条件：新旧版本具有相同的签名;新旧版本具有相同的包名;有一个标示符区分新旧版本，比如版本号，对于Android若有内置的应用需检查升级之后内置文件是否匹配(如内置的输入法);
5. 推送差异：Android：点击home键，程序后台运行时，此时接收到push，点击后唤醒应用，此时可以正确跳转;iOS，点击home键关闭程序和屏幕锁屏的情况下显示红点;
6. 安装卸载差异：Android的下载和安装的平台和工具和渠道比较多，iOS主要有app store，iTunes和testflight下载;
7. 编程语言：Android下app使用的是java语言，而iOS是objective c++;
8. 导航方式：iOS的Tab放在页面底部，不能通过滑动来切换，只能点击。也有放在上面的，也不能滑动，但有些Tab本身可以滑动，比如新闻类应用。Android：一般放在页面顶端，可以通过滑动页面来切换Tab，当然Tab可以点击切换，Tab多的话，Tab本身也可以滑动。

web端和移动端可以分别使用什么抓包工具？通常可以从包中获得哪些信息？

• web端可以直接使用浏览器抓包，
• 移动端常用的的抓包工具有Charles、fiddler等，可以通过连接代理等方式抓取请求。
• 包可以提供：消息的时间戳、路由信息，请求的发送方、接收方、请求消息头、请求消息体、响应消息头和响应消息体等信息。

移动app测试需要覆盖哪些测试类型？

可用性/兼容性/接口测试/服务测试/底层资源测试/性能测试/安装测试/升级测试/安全性测试。

什么是性能测试？

• 狭义的性能测试指的是通过增加并发请求的数量，观察系统的吞吐量，一直到系统处理能力达到饱和的时候，系统吞吐量保持在一个数字保持不变，得到系统吞吐量和请求之间关系的测试，
• 实际中还会同时考虑如响应时间（SLA），稳定性，硬件资源，网络等因素。
• 广义的性能测试包括狭义性能测试，容量测试，负载测试、压力测试和稳定性测试等。

web端和移动端的性能测试关注点有何不同？

• web端和移动端的性能测试都关注页面加载速度
• 移动端由于自身特性，性能测试中同时关注手机CPU使用率、内存使用率、流量、电量、流畅度等性能指标。

性能测试中需要考虑哪些参数？

cpu使用率/内存使用率/带宽/网络请求队列长度/响应时间/线程数量/top等待等。

UI自动化测试

什么是页面对象模型？

页面对象模型是一种前端自动化的设计模式，把一个页面中的所有的元素封装到一个对象中，
测试流程调用页面对象成员来实现完整的业务场景，按页面封装的方式，提高了测试的可维护性，减少了代码冗余。

自动化测试一般在哪个阶段开始编写？通常用于哪些阶段的测试？

• 在功能的主体已经完成，需求稳定之后就可以开始准备自动化测试的脚本
• 自动化测试可以用于日常版本迭代中做主要场景的回归测试，产品上线之后做线上回归测试，后续功能开发中对已有功能的回归测试等

客户端自动化测试中有哪些常见的问题导致元素无法定位？如何解决？

1. 页面加载元素过慢，加等待时间；
2. 页面有frame框架页，需要先跳转入frame框架再定位；
3. 可能该元素是动态元素，定位方式要优化，可以使用部分元素定位或通过父节点或兄弟节点定位；
4. 可能识别了元素，但是不能操作，比如元素不可用，不可写等。需要使用js先把前置的操作完成。

客户端自动化测试中如何处理多个窗口切换？

1. 页面跳转之前使用driver.current_window_handle获得当前窗口句柄；
2. 跳转之后通过driver.window_handles获得所有窗口的句柄；
3. 循环找到新窗口的句柄，再通过driver.switch_to.window()方法跳转到新的窗口。

所有的测试都可以自动化吗？哪些测试不适合做自动化？

不是所有的项目都适合做自动化，下面几种情形不适合做自动化：

1. 项目周期很短的项目；
2. 业务规则复杂的对象；
3. 美观、声音、易用性测试
4. 测试很少运行；
5. 软件不稳定；
6. 涉及物理交互

什么是testng？它有哪些优点？

testng是一套用来在自动化测试代码中管理用例组织、运行和配置的工具，它的优点是：

1. 允许并行执行；
2. 可以定义用例之间的依赖关系；
3. 可以给用例分配优先级；
4. 允许测试用例的分组；
5. 提供用例的参数化配置；
6. 支持多种断言；
7. 提供详尽的html测试报告。

testng中如何设置测试用例的优先级？

testng通过priority属性支持用例的优先级设置。具体的实现方式是在@Test标注之后加上priority属性，设置用例的优先级，比如@Test(priority=0)，如果没有设置优先级，则默认用例按照字母顺序执行。