app稳定性测试怎么测（安卓app测试）

一个app性能测试+ᓉ+主要测试哪些方面

如果你说的是古文，就是指被审判！一般用于犯罪嫌疑人！通常会被严刑逼供，很掺

如何制作移动app测试方案及详细流程?

1.首先是测试 资源确认及准备
（1）产品需求文档，产品原型图 ，接口说明文档及设计文档应该齐全
（2）测试设备及测试工具 的准备：IOS和Android的不同年版本的真机，以及测试相关工具的准备
2.测试用例的设计及评审
（1）根据产品需求文档，产品原型图等文档，设计客户端的一般功能测试用例
（2）测试用例评审，修改与完善，评审过后着手进入正式测试阶段
3. UI测试
（1）确保手头的原型图与效果图为当前最新版本，符合产品经理及用户需求
（2）测试过程一切以效果图为准，若用户体验方面有建议，先以邮件的形式 与产品经理确认，确认通过后，可以正式的发出用户体验方面的问题
4.功能测试
（1）APP功能测试主要依据编写的功能 测试用例进行软件功能的遍历
（2）涉及的测试主要包括基本功能测试，安装，卸载，运行测试 ，异常处理（包括网络 突然中断或者网速 过慢，机器内存不足等异常情况的处理 ）
5.中断测试
（1）软件运行 过程中接电话，收短信，锁屏，闹铃，充电，收到通知提醒后在 使用软件，软件任可以 正常运行
（2）运行软件时由前台切换到后台，再切换回前台 仍能继续运行
6.兼容性及适配器测试
（1）硬件的适配 ：不同手机 厂商，硬件 性能，不同屏幕大小的适配
（2）OS版本的兼容
（3）不同屏幕分辨率的适配：移动端设备的屏幕分辨率多种多样 ，如果 app没有做合适的处理可能会显示不好，甚至影响功能的操作
（4）兼容性测试必须放在 一定数量的真机上运行 ，由于真机类型较多，兼容性测试 的时候可以选取典型的几种运用较多的真机进行兼容性测试
7.性能测试
（1）客户端性能测试注重安装卸载时间，启动时间，页面加载时间，主要功能占用的床铺，内存，流量，耗电量 等，以及与同类产品相比较是否具有优势
（2）至于服务器端的性能，主要利用接口对服务器进行加压，重点关注相应时间，吞吐量，并发数，事务通过率等
8.稳定性测试
（1）安卓app的稳定性常常使用 monkey进行测试，通过随机事件流模拟个人操作，对检查程序的内存溢出，空指针有很大的作用
9.检测分析及测试报告输出
以上各种形式的APP测试结束后，应该形成完整的分析及报告文档，输出给相关人员
TestBird

手机app测试有哪些工具盒方法

1、安卓黑盒测试工具
1)包括本身自带的monkey,Monkey是Android中的一个命令行工具，可以运行在模拟器里或实际设备中
2) robotium与appium，这些工具用于黑盒的自动化测试。可以在有源码或者只有APK 的情况下对目标应用进行测试。提供了模仿用户操作行为的API，比如在某个控件上点击，输入Text
等等。（推举你可以研究一下这个工具，开源的，我有资料）
2、白盒测试，Android在SDK中集成了JUnit框架。所以，你可以基于JUNIT框架进行安卓的白盒测试代码开发
3、安卓的测试方法其实与web测试方法大多类似，只是多了一些特殊的测试场景，例如-遍历测试、故事驱动、适配测试、电量测试、弱网测试、流量测试等
4、兼容性测试的话，一是可以利用虚拟机保证系统间的兼容性，但更多的还需要依靠真机测试，因为每个真机的上层API使用和渲染是不太一样的
如果你想要什么资料的话或者想一起学习研究的话，可以给我发邮件：test_sunny@hotmail.com

如何软件测试稳定性

运行在手机里的软件由于平台和手机设备资源的限制，所以一般容易出bug的操作是功能交互或者是资源不足的情况下。在手机测试中最容易出error的测试方法是边界值测试，交互测试，错误值测试，中断测试（用另一个程序中断当前运行的程序）和返回测试（在运行程序的过程中有多级目录那种，不断地返回）。
这些方法是相对容易出error的测试方法，当然所测的手机情况不同，还需要你自己多总结总结。

如何连接手机测试android应用

当当网--余易--建筑与风水,先从这书学起.我感觉比沈氏和中洲编排的较好.

如何设计Android APP测试用例

在当今竞争激烈的市场上一个APP的成功离不开一个可靠的用户界面（UI）。因此，对功能和用户体验有一些特殊关注和照顾的UI的全面测试是必不可少的。当涉及到安卓平台及其提出的独特问题的数量（安卓就UI提出显著挑战）时，挑战变得更加复杂。关键字“碎片化”象征着移动应用全面测试的最大障碍，还表明了发布到市场上的所有形态、大小、配置类型的安卓设备所引起的困难。本文将介绍安卓模拟器如何能通过使用一些技巧和简单的实践提供覆盖大量设备类型的广泛测试。
简介—分散装置里的测试

一般安卓开发者在其日常工作中面临的最大挑战之一是：终端设备和[url=]操作系统[/url]版本的范围太广。OpenSignal进行的一项研究表明，2013年7月市场上有超过11，828的不同安卓终端设备，所有设备在类型/大小/屏幕分辨率以及特定配置方面有所不同。考虑到前一年的调查仅记录有3，997款不同设备，这实在是一个越来越大的挑战障碍。
图1. 11，828 款安卓设备类型（ OpenSignal研究， 2013年7月[ 1 ] ）分布
从一个移动APP开发角度出发，定义终端设备有四个基本特征：
1．操作系统：由“API指标”（ 1 ～18 ）专业定义的安卓操作系统版本（ 1.1～ 4.3 ），。
2．显示器：屏幕主要是由屏幕分辨率（以像素为单位），屏幕像素密度（ 以DPI为单位），和/或屏幕尺寸（以英寸为单位）定义的。
3．CPU：该“应用程序二进制接口” （ABI ）定义CPU的指令集。这里的主要区别是ARM和基于Intel的CPU。
4．内存：一个设备包括内存储器（ RAM）和Dalvik 虚拟存储器（ VM堆）的预定义的堆内存。
这是前两个特点，操作系统和显示器，都需要特别注意，因为他们是直接由最终用户明显感受，且应该不断严格地被测试覆盖。至于安卓的版本， 2013年7月市场上有八个同时运行导致不可避免的碎片的不同版本。七月，近90％这些设备中的34.1 ％正在运行Gingerbread版本（ 2.3.3-2.3.7 ），32.3 ％正在运行Jelly Bean（ 4.1.x版），23.3 ％正在运行Ice Cream Sandwich（ 4.0.3 - 4.0.4 ）。
图2. 16款安卓版本分布（OpenSignal研究，2013年7月[1]）
考虑设备显示器，一项TechCrunch从2013年4月进行的研究显示，绝大多数（79.9％）有效设备正在使用尺寸为3和4.5英寸的“正常”屏幕。这些设备的屏幕密度在“MDPI”（～160 DPI），“hdpi”（～240 DPI）和“xhdpi”（～320 DPI）之间变化。也有例外， 一种只占9.5％的设备屏幕密度低“hdpi”（～120 DPI）且屏幕小。
图3. 常见的屏幕尺寸和密度的分布（谷歌研究，2013年4月）[2]
如果这种多样性在质量保证过程中被忽略了，那么绝对可以预见：bugs会潜入应用程序，然后是bug报告的风暴，最后Google Play Store中出现负面用户评论。因此，目前的问题是：你怎么使用合理水平的测试工作切实解决这一挑战？定义测试用例及一个伴随测试过程是一个应付这一挑战的有效武器。
用例—“在哪测试”、“测试什么”、“怎么测试”、“何时测试”？
“在哪测试”
为了节省你测试工作上所花的昂贵时间，我们建议首先要减少之前所提到的32个安卓版本组合及代表市场上在用的领先设备屏的5-10个版本的显示屏。选择参考设备时，你应该确保覆盖了足够广范围的版本和屏幕类型。作为参考，您可以使用OpenSignal的调查或使用手机检测的信息图[3]，来帮助选择使用最广的设备。
为了满足好奇心，可以从安卓文件[5]将屏幕的尺寸和分辨率映射到上面数据的密度（“ldpi”，“mdpi”等）及分辨率（“小的”，“标准的”，等等）上。
图5. 多样性及分布很高的安卓终端设备的六个例子（手机检测研究，2013年2月）[3]
有了2013手机检测研究的帮助，很容易就找到了代表性的一系列设备。有一件有趣的琐事：30％印度安卓用户的设备分辨率很低只有240×320像素，如上面列表中看到的，三星Galaxy Y S5360也在其中。另外，480×800分辨率像素现在最常用（上表中三星Galaxy S II中可见）。
“测试什么”
移动APP必须提供最佳用户体验，以及在不同尺寸和分辨率（关键字“响应式设计”）的各种智能手机和平板电脑上被正确显示（UI测试）。与此同时，apps必须是功能性的和兼容的（兼容性测试），有尽可能多的设备规格（内存，CPU，传感器等）。加上先前获得的“直接”碎片化问题（关于安卓的版本和屏幕的特性）， “环境相关的”碎片化有着举足轻重的作用。这种作用涉及到多种不同的情况或环境，其中用户正在自己的环境中使用的终端设备。作为一个例子，如果网络连接不稳定，来电中断，屏幕锁定等情况出现，你应该慎重考虑压力测试[4]和探索性测试以确保完美无错。
图6. 测试安卓设备的各个方面
有必要提前准备覆盖app最常用功能的所有可能的测试场景。早期bug检测和源代码中的简单修改，只能通过不断的测试才能实现。
“怎么测试”
将这种广泛的多样性考虑在内的一种务实方法是， 安卓模拟器 - 提供了一个可调节的工具，该工具几乎可以模仿标准PC上安卓的终端用户设备。简而言之，安卓模拟器是QA流程中用各种设备配置（兼容性测试）进行连续回归测试（用户界面，单元和集成测试）的理想工具。探索性测试中，模拟器可以被配置到一个范围广泛的不同场景中。例如，模拟器可以用一种能模拟连接速度或质量中变化的方式来设定。然而，真实设备上的QA是不可缺少的。实践中，用作参考的虚拟设备依然可以在一些小的（但对于某些应用程序来说非常重要）方面有所不同，比如安卓操作系统中没有提供程序特定的调整或不支持耳机和蓝牙。真实硬件上的性能在评价过程中发挥了自身的显著作用，它还应该在考虑了触摸硬件支持和设备物理形式等方面的所有可能终端设备上进行测试（可用性测试）。
“何时测试”
既然我们已经定义了在哪里（参考设备）测试 ，测试什么（测试场景），以及如何（ 安卓模拟器和真实设备）测试，简述一个过程并确定何时执行哪一个测试场景就至关重要了。因此，我们建议下面的两级流程：
1 ．用虚拟设备进行的回归测试。
这包括虚拟参考设备上用来在早期识别出基本错误的连续自动化回归测试。这里的理念是快速地、成本高效地识别bugs。
2 ．用真实设备进行的验收测试。
这涉及到：“策划推广”期间将之发布到Google Play Store前在真实设备上的密集测试（主要是手动测试），（例如，Google Play[ 5 ]中的 alpha和beta测试组） 。
在第一阶段，测试自动化极大地有助于以经济实惠的方式实现这一策略。在这一阶段，只有能轻易被自动化（即可以每日执行）的测试用例才能包含在内。
在一个app的持续开发过程中，这种自动化测试为开发人员和测试人员提供了一个安全网。日常测试运行确保了核心功能正常工作，app的整体稳定性和质量由测试数据透明地反映出来，认证回归可以轻易地与最近的变化关联。这种测试可以很轻易地被设计并使用SaaS解决方案（如云中的TestObject的UI移动app测试）从测试人员电脑上被记录下来。
当且仅当这个阶段已被成功执行了，这个过程才会在第二阶段继续劳动密集测试。这里的想法是：如果核心功能通过自动测试就只投入测试资源，使测试人员能够专注于先进场景。这个阶段可能包括测试用例，例如性能测试，可用性测试，或兼容性测试。这两种方法相结合产生了一个强大的移动apps质量保证策略[ 7 ] 。
结论 - 做对测试
用正确的方式使用，测试可以在对抗零散的安卓的斗争中成为一个有力的工具。一个有效的测试策略的关键之处在于定义手头app的定制测试用例，并定义一个简化测试的工作流程或过程。测试一个移动app是一个重大的挑战，但它可以用一个结构化的方法和正确的工具集合以及专业知识被有效解决掉。