测试基础篇（二）—— 面试挺常见

测试流程（各有千秋）

1、测试人员参与需求评审、交互评审、视觉评审；理解需求，进行需求分析

2、测试负责人编写测试计划，分配测试任务，评估测试周期

3、测试人员整理交互or需求疑难点，确认异常场景or特殊情况下的交互细节，最好是能划出新功能的数据流图&流程图

4、测试人员编写测试点，转化测试用例，评审测试点or测试用例

5、开发送测（提测）前，开发自行走查，产品视觉验收，若有必要，测试可介入冒烟测试

6、送测（提测）阶段，缺陷管理，发现bug，提交bug

7、博主这边是分A1，A2，A3...阶段，一般A1过新功能测试用例&主流程回归，A2验证bug&交叉测试&拓展测试，A3验证bug&拓展测试

8、预发（灰发）环境验证

9、线上环境验证

10、版本复盘

 

黑盒测试相关

黑盒测试主要是为了发现以下几类错误

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

5、是否有初始化或终止性错误？

 

黑盒测试优点

1.比较简单，不需要了解程序内部的代码及实现，因为与内部实现无关；

2.从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；

3.基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

4.在做软件自动化测试时较为方便

 

黑盒测试缺点

1.不可能覆盖所有的代码，覆盖率较低；

2.部分路径不能测试到，不能测试程序中隐藏的错误；

3.自动化测试的复用性较低

 

黑盒测试方法

等价类、边界值、因果图、判定表、状态迁移、正交实验、场景法、错误推断

 

自动化测试相关

自动化测试的优点

1、回归测试更方便，由于回归测试的额动作和用例是完全设计好，测试结果也是可以预料的，将回归测试自动运行，可以提高测试效率，缩短回归测试时间

2、运行更多更繁琐的测试

3、可以执行一些手工测试困难的测试，可以通过自动化测试模拟同时有大量用户的测试

4、测试具有一致性和可重复性，每次测试的结果和执行的内容的一致性可以得到保障，达到测试的可重复的效果

5、测试的复用性，实现在不同的测试过程中使用相同的用例

6、测试的执行可靠性，按脚本执行，后续定位复现有明确的路径可循

7、资源利用率高，人力成本低

8、基本的、逻辑性不强的操作，性能测试、压力测试、回归测试，自动化测试很大优势

 

自动化测试的缺点

1、手工测试比自动测试发现的缺陷更多

2、对测试的依赖性大

3、只适合回归测试

4、手工测试编写时间少于测试脚本编写时间

5、手工测试可以靠人的想象力去测试， 而工具是死的

6、自动化测试可能会制约软件开发，脚本维护会受到限制，从而制约软件的开发

总结：自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断

 

app常见测试点

1、安装、卸载 apk上安装与卸载，在工具上可以安装卸载

2、兼容性测试 系统版本，安卓版本，尺寸

3、异常测试 断网、断电、服务器异常情况下，客户端是否正常处理

4、在线升级测试 在线升级，升级后可以正常使用

5、易用性测试 操作简单，符合用户使用习惯

6、交互性测试 来电，来短信，低电量测试，拔充电线会不会影响app

7、功能测试 检验功能是否符合需求，涉及到UI层，接口，数据，服务端，代码逻辑等。

8、稳定性测试 通过Monkey：命令行工具，对正在开发的应用程序进行压测，向系统发送伪随机的用户事件流（按键输入、触屏输入、手势输入）进行压测

9、安全测试 是否容易被外界破解，是否存在被恶意代码注入的风险

10、性能测试 应用测试、ROM测试、客户端运行时设备的CPU、GPU、流量、耗电量，响应时间

11、自动化测试：robotium、Appium

12、外网场景测试 不同网络场景，wifi、3g、4g、电信、移动、联通、弱网场景，通过fiddler

13、中断测试（电话接入、来短信、电量不足提示灯外部事件）

 

app测试和web测试的区别

	web	app
性能测试	响应时间...	加上：流量、电量、CPU、GPU、内存...
兼容测试	不同浏览器和浏览器版本	加上：手机的尺寸、分辨率、系统版本、安卓版本
交叉事件测试		在操作某个软件的时候，来电话、来短信，电量不足提示等外部事件
操作类型测试		横屏测试，手势测试

 

冒烟测试和回归测试的区别

冒烟测试：新版本验证测试，主要确认新的版本是否存在致命性bug，功能可以正常运行，不会影响下一轮测试，不要求覆盖面有多广，但是要保证被测对象的主功能点得到测试，还要保证所有被修改过以及修改相关的功能都是可用的，若都通过则可以进行系统测试

回归测试：是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误

 

静态测试和动态测试的区别

静态测试：不运行被测程序本身，通过评审文档和阅读代码等方式测试软件

动态测试：通过运行被测程序，检查运行结果与预期结果的差异，通常使用白盒和黑盒测试从不同的角度设计测试用例来查找代码中的错误

关键字：不运行，文档，代码

　　　　运行，结果差异，黑盒白盒

 

α、β、λ测试的区别

• α测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。目的是评价软件产品的FURPS（即功能、可使用性、可靠性、性能和支持）
• β测试：是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。（文档，客户培训，产品支持，可支持性）
• λ测试：是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行

 

负载测试(Load testing)、压力测试(stress testing)和性能测试(Performance Evaluation Test)的区别

• 性能测试：为了获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据
• 负载测试：模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（逐渐增加模拟用户的数量）或其他加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存），以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现 了一种方法或一种技术
• 压力测试：在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试

 

什么是需求文档测试？

测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现

关键字：测试需求，逻辑矛盾，技术实现

 

什么是设计文档测试？

测试设计是否符合全部需求以及设计是否合理

关键字：测试设计，符合需求，是否合理