测试理论基础

table of contents

• 1 软件测试的目的
• 2 软件测试的流程
• 3 常见的测试类型
• 4 测试用例设计常用方法
• 5 测试用例一般用什么工具编写
• 6 什么是冒烟测试
• 7 bug应该如何记录
• 8 bug的生命周期
• 9 alpha测试和beta测试的区别
• 10 你认为做好软件测试应该具备哪些能力
• 11 如何优雅的和RD沟通
• 12 在以往的工作中，发现影响大或印象深刻的bug是什么？为什么？
• 13 在以往的工作中，解决过最困难的问题是什么？
• 14 电梯case设计
• 15 三角形测试
• 16 支付系统怎么测试
• 17 登录系统的测试点

1 软件测试的目的

1）测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。2）保证软件的质量，确保能够满足用户以及产品的需求

2 软件测试的流程

项目立项，参加需求评审 -> 根据需求文档，编写测试用例 -> 开发自测通过后提测，执行测试用例，问题记录，及时有效跟进问题修复 -> 产品验收 -> 灰度测试 -> 正式上线发布

3 常见的测试类型

(1)黑盒测试，功能测试（2）白盒测试，代码层面的单元测试等（3）冒烟测试，开发自测（4）兼容性测试，包括浏览器兼容性、APP机型适配（5）接口测试，对api接口进行传参测试，常用工具是postman或自己编写脚本（6）性能测试，目的：在一定负载下（一开始就制定了负载个数），测试服务器的性能指标（7）压力测试，目的：为了发现系统能支持的最大负载（在一定的性能下，测试服务器负载个数）（8）集成测试，各个模块的测试（9）系统测试，全量case回归（10）验收测试，由PM或项目需求方进行体验测试（11）回归测试，产品上线之后进行主要功能回归，确保线上稳定（12）自动化测试，自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。比如：Monkey、appium、selenium等。

4 测试用例设计常用方法

常用的有 等价类划分法、边界值分析法、错误推测法、判定表法、正交实验法、场景法。（1）等价类划分：就是将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出若干个有代表性的值作为测试用例。（2）边界值分析法：可以划分为等于、刚刚大于、刚刚小于边界的值，测试用例可标记为min、min+-、max、max+-、正常值 （3）错误推测法：人们根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。（4）判定表法：又称策略表法，表格的形式，穷举出所有可能的情况，进行测试（5）正交实验法：和判定表法有点类似，也是通过设计出一个特殊的表格，找出能以少数代全面的测试用例（6）场景法：站在真实用户使用场景的角度，模拟用户的高频操作，确保在真实的使用场景中，避免bug发生。

5 测试用例一般用什么工具编写

因人而异，功能测试的时候，我比较习惯用xmind去编写，然后用gitlab去对测试用例进行托管。但某些逻辑复杂的功能点，需要用到判定表法或者正交实验法的时候，可能会用excel去维护。面对自动化测试的时候，可能我又会用python脚本去编写测试用例

6 什么是冒烟测试

产生于硬件测试，一根管道，往里面排入烟雾，若烟雾没有从管道其他地方冒出，就认为管道是正常的。冒烟测试用在软件测试中：1.软件最基本的功能测试，通常由开发完成，只有冒烟点都通过的产品，交由测试，才会比较有意义 2.冒烟测试贯穿于测试的各个阶段，比如集成测试，系统测试等。

7 bug应该如何记录

bug记录应该具备以下几点要求：（1）bug出现的前置条件（产生来源/版本号/触发条件），其中产生来源可以分为：测试环境中产生、线上用户反馈产生（2）bug的复现步骤（3）简练的、能让RD一目了然的标题，最好带标签分类归档（4）截图或其他能直观展现问题的方式（5）bug优先级划分。推荐bug用jira来记录，拓展性比较强

8 bug的生命周期

创建bug -> 分配bug -> 修复 -> 验证 -> 关闭（或reopen继续修复，但最终的目的是要关闭bug）

9 alpha测试和beta测试的区别

（1）alpha测试，由用户到开发环境中（程序员可控制的环境）进行体验测试，alpha测试不能由程序员或测试完成。类似与公司聘请体验师，来对产品进行体验测试，即常说的内部灰度。（2）beta测试，即当前大家常说的外部灰度，给予一部分外部用户体验新功能的权限，让这部分用户在线上环境中体验，发现问题，通过用户反馈改进产品

10 你认为做好软件测试应该具备哪些能力

（1）较好的技术能力（2）对业务的理解能力（3）良好的沟通能力（4）解决和分析事情的能力

11 如何优雅的和RD沟通

（1）首先要明确一点，QA也是研发岗位，对于需求的理解程度，应该要比RD要更清楚，在流程上应该要明确，所有需求的改动，都应该及时同步到QA这边来。对于需求文档写得不清楚的地方，应及时和PM以及RD沟通，总之一句话：QA一定不能不了解需求。（2）bug不仅要尽量地简练说明白，还要进行分级，要将心比心，不要让RD那边过度纠结在bug的理解上（3）QA的时间也很宝贵，在以往的测试经验中，花费大量时间的，不是测试，而是花费在环境的搭建上，所以，QA没有义务频繁的帮助RD去构造数据和环境，这样会严重挤压QA的测试时间，所以提交bug的时候，最好要提供完整详细的复现bug的步骤，让RD自己去复现（4）测试用例编写的时候，尽量避免“是否”、“？”、“不应该”等词汇，应该是有明确的预期，开发提测前，可以先给出准入测试用例，供开发自测，这样能够确保提测质量。

12 在以往的工作中，发现影响大或印象深刻的bug是什么？为什么？

印象深刻的bug：一天晚上下班前，我在轮值执行monkey时，发现以前每次执行monkey的时候，大家都是让测试手机处于联网的状态，但是真实用户可能是会有断网或者弱网的情况的。当时我就把其中一台跑monkey的测试手机设置成无网情况，这时出现了意想不到的bug：app在启动页面加载时，就出现了crash。我当即找到了移动端的RD，一起分析原因，没想到，这个bug已经存在了半年之久，一直都没有人发现，庆幸的是这个app是公司新出的app，还没有大规模的用户推广，否则后果不堪设想。后来，在我的提议之下，每次跑monkey，测试机都不应该是千篇一律的，而是存在不同状态的（wifi/流量/无网/登录/未登录等）。这件事之后，我后来没听说过还有因为断网状态而出现crash的情况。

13 在以往的工作中，解决过最困难的问题是什么？

18年年初，答题赢奖金的活动走到了风口浪尖。项目组从成立到完成开发、测试，排期仅仅只有10天，在高压的强度之下，走以前传统的测试流程，时间上来说几乎是不可能的，我们的工作时间几乎是和开发并行的，而且还是一种测试驱动开发的模式，当一些需求设计的时候，因为时间紧，业务逻辑也是混乱的，当测试的时候发现问题的不合理，再和PM/RD沟通去变更需求逻辑。一遍遍review代码、测试功能、一轮又一轮的线上线下回归，熬了好几个通宵。终于，我们整个项目组，把之前从未做过的业务需求能够在这么短的时间内顺利完成，也算是在作业帮最困难而又有成就感的一件事了。

14 电梯case设计

【题目】一台电梯，如何去设计测试用例

解答如下

需求背景：楼层数，电梯数

需求文档：电梯使用说明书，安全说明书

UI测试：电梯内饰，灯光，广告位，按键高度

功能测试：

• 升降机：（1）每层的停靠精准度（2）边界值停靠（最底层、最顶层、中间层）（3）电梯速率
• 门：（1）开关灵敏度（2）不关门不会上下运行（3）异物卡门不会导致异常下坠（4）自动关门时间
• 按键：（1）按键灵敏度（2）按键层数与实际层数停靠吻合（3）多次点击按键是否会取消停靠（4）按键时机与电梯运行的配合逻辑
• 预警：电梯摄像头，梯内报警电话，警铃电话
• 通风：通风情况

兼容性测试：电梯里是否有信号

性能测试：（1）满载运行（2）频繁点击按键（3）不停地开关门（4）长时运行（5）电梯突然断电的灾备情况（6）长时停留

15 三角形测试

【题目】一个程序，从输入框中读取三个整数值，这三个数值代表了三角形三边的长度。程序显示提示信息，指出该三角形究竟是不规则三角形、等腰三角形还是等边三角形。（注：不规则三角形指三角形中任意两边不相等，等腰三角形指有两条边相等，等边三角形指三条边相等）– 设计测试用例

解答如下（等价划分法）

等价划分表：

输入条件	有效等价类	无效等价类
是否三角形的三条边	⑴ A>0	⑺ A<=0
	⑵ B>0	⑻ B<=0
	⑶ C>0	⑼ C<=0
	⑷ A+B>C	⑽ A+B<=C
	⑸ B+C>A	⑾ B+C<=A
	⑹ A+C>B	⑿ A+C<=B
是否等腰三角形	⒀ A=B	⒃ A!=B&&B!=C&&C!=A
	⒁ B=C
	⒂ C=A
是否等边三角形	⒄ A=B&&B=C&&C=A	⒅ A!=B
		⒆ B!=C
		⒇ C!=A

case：

序号	[A,B,C]	覆盖等价类	输出
1	[3,4,5]	⑴⑵⑶⑷⑸⑹	一般三角形
2	[0,1,2]	⑺	不能构成三角形
3	[1,0,2]	⑻
4	[1,2,0]	⑼
5	[1,2,3]	⑽
6	[1,3,2]	⑾
7	[3,1,2]	⑿
8	[3,3,4]	⑴⑵⑶⑷⑸⑹⒀	等腰三角形
9	[3,4,4]	⑴⑵⑶⑷⑸⑹⒁
10	[3,4,3]	⑴⑵⑶⑷⑸⑹⒂
11	[3,4,5]	⑴⑵⑶⑷⑸⑹⒃	非等腰三角形
12	[3,3,3]	⑴⑵⑶⑷⑸⑹⒄	等边三角形
13	[3,4,4]	⑴⑵⑶⑷⑸⑹⒁⒅	非等边三角形
14	[3,4,3]	⑴⑵⑶⑷⑸⑹⒂⒆
15	[3,3,4]	⑶⑷⑸⑹⒀⒇

16 支付系统怎么测试

解答如下

支付系统需要考虑：

支付金额：（1）考虑边界值和小数点（2）折扣逻辑的四舍五入（3）0元支付（4）支付金额错误：格式错误、数字错误（5）超大金额（6）余额小于需要支付的金额（7）银行卡或其他设置当日消费金额或者是单笔消费金额超限。

后端处理：（1）支付事务的ACID原则（2）支付流程不能走异步操作（3）第三方支付接口对接（4）商品记录（5）订单记录（6）交易记录 （7）账户余额

支付操作（1）指纹支付（2）免密支付（3）账号+密码支付（4）动态获取支付验证码支付（5）银行卡号+密码绑定支付（6）信用卡可能会设计到支付码等

17 登录系统的测试点