先定位到下拉菜单，激活这个菜单，然后定位其中的选项

1、从是否关心内部结构来看

（1）白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。

（2）黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。

（3）灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。

2、从是否执行代码看

（1）静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

（2）动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。

3、从开发过程级别看

（1）单元测试：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。

（2）集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。

（3）系统测试：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

在系统测试中，对于具体的测试类型有：

（1）功能测试：对软件需求规格说明书中的功能需求逐项进行的测试，以验证功能是否满足要求。

（2）性能测试：对软件需求规格说明书的功能需求逐项进行的测试，以验证功能是否满足要求。

（3）接口测试：对软件需求规格说明中的接口需求逐项进行的测试。

（4）人机交互界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的需求。

（5）强度测试：强制软件运行在异常乃至发生故障的情况下（设计的极限状态到超出极限），验证软件可以运行到何种程序的测试。

（6）余量测试：对软件是否达到规格说明中要求的余量的测试。

（7）安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，

（8）可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能（其输入覆盖和环境覆盖一般大于普通的功能测试）

（9）恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况，逐一进行的测试。

（10）边界测试：对软件处在边界或端点情况下运行状态的测试。

（11）数据处理测试：对完成专门数据处理功能所进行的测试。

（12）安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。

（13）容量测试：检验软件的能力最高能达到什么程度的测试。

（14）互操作性测试：为验证不同软件之间的互操作能力而进行的测试。

（15）敏感性测试：为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。

（16）标准符合性测试：验证软件与相关国家标准或规范（如军用标准、国家标准、行业标准及国际标准）一致性的测试。

（17）兼容性测试：验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。

（18）中文本地化测试：验证软件在不降低原有能力的条件下，处理中文能力的测试。

你好：

测试用例：

指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。

也可以认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

测试脚本：

一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。 

为了提高测试脚本的可维护性和可复用性，必须在执行测试脚本之前对它们进行构建。

关系：

测试用例为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。

测试脚本是为了进行自动化测试而编写的脚本。

测试脚本的编写必须对应相应的测试用例

黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试 ：
这些测试的范围正好是逐步递增的关系，但是测试的人员角色是不同。

黑盒测试、白盒测试、单元测试：开发人员分在不同的开发阶段要做的事情
黑盒测试、集成测试、系统测试：测试人员在测试周期内级层做的工作

验收测试：一般是在用户方做的工作 

这个问题范围有些宽泛了，具体可以先了解下jmeter。

推荐你查看网站讲堂：http://quan.51testing.com/pcQuan/lecture/107

可以先把日志过滤出来：adblogcat|findstrxxxxx(过滤日志信息)，然后再搜索其中的关键字

这和【软件上线后遇到bug怎么处理】是类似的，唯一的区别就是没有上线，你要定位好bug的优先级，影响范围，汇报产品情况，再来决定产品是否上线， bug优先级低，产品影响范围小，不影响业务主流程，可以考虑下次版本迭代修改，如果bug很严重，那就必须修改，然后还要反思bug为什么会发生？产品是否上线，最终决定权在产品或者项目经理手上，但是我们测试的测试报告要体现出了风险和建议，

后面一定要避免同样的错误，第一次出现的问题处理好了，这事可以过去了，但是出现过的问题最好不要再次出现，否则一而再再而三的出现同样的问题，会让boss和领导怀疑整个团队或个人的能力及责任感。所以，记得汲取教训，避免以后跳进同一个bug坑里。

BUG出现的原因是什么，可能有以下几种情况：

1、测试环境无法重现

可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。

解决方法：尽量完善测试方法，尽可能模拟仿真线上测试环境，以及增加上线后的复查确认测试。

2、漏测

A、测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例

解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。

B、测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏

解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为疏忽漏测，还是因为负责模块过多漏测，还是有其他原因。应该及时反馈给测试经理，并对该测试人员后面的工作进行调整和处理。

C、测试用例覆盖不全：需求模糊导致的，由于用例评审的不严格造成的;中途需求变更造成的;由于某些其他因素造成的

解决方法：找到原因，并进行记录，在以后的项目或者下一版本改进。并且要及时增加、补充用例。

3、程序的质量问题

出现bug，肯定是因为程序出了问题。黑盒测试是很难发现逻辑和代码层面的所有问题的。所以也应该从开发的角度去评估bug出现的原因，可能是因为开发粗心疏忽导致的，也可能是开发人员蓄意隐藏出现的。

解决办法：首先确定bug出现的原因，如果是因为粗心，如错误的大小写、错误的参数变量导致的，应该让对应开发人员做出整改。如果是深层次的逻辑问题导致的，那应该在后续项目和版本中加大代码的走查测试。

4、产品实际使用超出想象，导致的bug

这应该是整个团队的问题，应该吸取经验。规划一款新领域、业务的产品，对这个领域可能没有深入的理解，那么可能会导致一些意想之外的BUG。比如我经历过的无人值守停车场的物联网项目，主要依赖于摄像头进行车牌识别然后进行车辆的放行。因为周期短，并且地域的限制没做太过周全的测试，一开始也没有暴露问题。但是实际使用中，发现摄像头外壳因为没有考虑导热设计，导致在高温暴晒下出现摄像机宕机。在阴暗潮湿环境下，车辆如果角度不正对摄像头，导致识别错误等。你能说这是测试的问题，或者开发的问题，或者硬件的问题，工艺的问题。只能是大家经验不足，是团队所有人的问题。

5、产品上线后，在某种操作系统下出现兼容性的问题，是谁的责任？

主流的系统，比如Win10，有兼容性的问题，肯定是测试的问题，没有覆盖主流的系统。后面应该明确需要兼容的系统并进行测试。

历史系统，比如XP，有兼容性问题。但是规格明确写明不支持XP。那么有可能是市场调研、需求的问题，没有搞清楚产品的实际客户和特性。也有可能是用户手册的问题，没有提示不支持XP，导致错误的安装。还有可能是软件的问题，没有做保护，检测到是XP系统，就应该停止安装并提示系统版本太旧。而不是一路走到黑，安装完出现一些兼容性的问题。这都是需要后期进行考虑的。

一开始有测试工程师这个岗位的时候，门槛低，技术低，可以说基本上不需要任何程序语言基础，数据库，操作系统等，只要能执行别人写好的测试用例，会提BUG就行，这也是10多年前测试行业刚兴起，且逐步需求量增大，企业中的测试人员主要从事的就是手工测试（基本上就是俗称的“点点点”），论技术含量基本上趋近于0，随着工作年限的增长，能够积累的仅仅是当前被测领域中的业务能力，测试需求分析能力，测试用例编写能力，团队管理能力（这个就因人而异了）

第二阶段：自动化测试萌芽阶段

第三阶段：自动化测试快速发展阶段

第四阶段： 测试开发

针对测试的开发，这个岗位需要具备测试行业中的相关经验，同时也要具备开发人员程序设计的能力，因为他们最终的工作产物是一款成型的自动化测试工具/自动化测试平台

测试人员技术门槛的变迁，持续走高，相信要不了多久AI测试也会辅助到测试行业中，目前已经又不少AI测试工具崭露头角，虽然还不尽完善，但AI测试这个阶段的到来，也是指日可待的。身为测试人员，需要不断学习，持续学习，跟上时代步伐，技术上尽可能不要掉队太多。

接口测试的工具很多，比如 postman、RESTClient、jmeter、loadrunner、SoapUI等，本人首推的测试工具是postman和jmeter，还有很多开源的工具，适合自己的就是最好的

白盒测试也称为结构测试，是根据代码逻辑来设计的，主要用于检测软件编码过程中的错误。程序员的编程经验、对编程软件的掌握程度、工作状态等因素都会影响到编程质量，导致代码错误。

特点：代码覆盖率高；覆盖所有代码路径难度大；业务功能可能覆盖不全；测试开销大。

1、白盒测试基本上是和代码打交道，所以需要掌握语言，以及单元测试框架，例如 java+Junit/TestN、python+unittest。

2、掌握语言后还需要了解一些编码知识，学习编码风格。

3、作为功能测试，一定掌握了等价类、边界值等测试用例设计方法，在白盒测试中同样需要掌握。

4、掌握白盒测试的设计思想和方法，逻辑覆盖、循环覆盖和基本路径测试，其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

5、学会画流程图，如果对功能比较复杂，那么就需要画流程图进行理清思路。例如：

6、覆盖率统计，这是白盒测试中的重要手段，在测试报告中可以作为量化指标的依据，对于软件的重点模块，应使用多种覆盖率标准衡量代码的覆盖率。

重点：一些常用的工具，像画流程图工具在功能测试中相信已经掌握。目前需要重点学习的是学习语言、白盒测试用例设计方法。深层次的还可以考虑一下测试架构的搭建。

1、第一个办法：把你的apk 和aapt.exe 放在同一个路径下 然后转到这个路径下输入命令就OK了

2、第二个办法：检查Aandroid SDK下的build-tools目录是否添加到环境变量

3、第三个办法：将你的apk包移动到与aapt命令的同级目录，然后在当前目录中打开终端，执行命令就ok了

移动端自动化测试----Monkey

Monkey 是Android SDK提供的一个命令行工具， 可以简单，方便地运行在任何版本的Android模拟器和实体设备上。 Monkey会发送伪随机的用户事件流，在实际应用中经常有公司用来做一些APP的稳定性测试和压力测试。

Monkey测试的原理就是利用socket通讯的方式来模拟用户的按键输入，触摸屏输入，手势输入等，看设备多长时间会出异常。当Monkey程序在模拟器或设备运行的时候，如果用户出发了比如点击，触摸，手势或一些系统级别的事件的时候，它就会产生随机脉冲，所以可以用Monkey用随机重复的方法去负荷测试你开发的软件。

1.缓存垃圾过多；

2.运行的程序过多,导致内存不足；

3.应用版本兼容问题；

4..检查APP中访问网络的地方，组件中的ImageView是否可以正常的下载并显示到app页面上；

5.检查APP的sdk和手机的系统是否兼容；

6.在一些特定情况下的闪退；

你好，可以参考下列文章：

http://www.51testing.com/html/06/n-4461606.html

http://www.51testing.com/html/57/15123757-3713667.html

希望对你有帮助