如何设计Android App测试用例

如何设计Android App测试用例

您好，Android APP测试用例一般需要设计以下几个内容：
用例编号、模块、测试描述、前提条件、测试步骤、预期结果、影响等级、用例类型、测试数据、用例属性、设计人、执行人、测试结果、备注。

一般安卓开发者在其日常工作中面临的最大挑战之一是：终端设备和[url=]操作系统[/url]版本的范围太广。opensignal进行的一项研究表明，2013年7月市场上有超过11，828的不同安卓终端设备，所有设备在类型/大小/屏幕分辨率以及特定配置方面有所不同。考虑到前一年的调查仅记录有3，997款不同设备，这实在是一个越来越大的挑战障碍。 从一个移动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 ）。 考虑设备显示器，一项techcrunch从2013年4月进行的研究显示，绝大多数（79.9％）有效设备正在使用尺寸为3和4.5英寸的“正常”屏幕。这些设备的屏幕密度在“mdpi”（～160 dpi），“hdpi”（～240 dpi）和“xhdpi”（～320 dpi）之间变化。也有例外， 一种只占9.5％的设备屏幕密度低“hdpi”（～120 dpi）且屏幕小。 如果这种多样性在质量保证过程中被忽略了，那么绝对可以预见：bugs会潜入应用程序，然后是bug报告的风暴，最后google play store中出现负面用户评论。因此，目前的问题是：你怎么使用合理水平的测试工作切实解决这一挑战？定义测试用例及一个伴随测试过程是一个应付这一挑战的有效武器。 用例—“在哪测试”、“测试什么”、“怎么测试”、“何时测试”？ “在哪测试” 为了节省你测试工作上所花的昂贵时间，我们建议首先要减少之前所提到的32个安卓版本组合及代表市场上在用的领先设备屏的5-10个版本的显示屏。选择参考设备时，你应该确保覆盖了足够广范围的版本和屏幕类型。作为参考，您可以使用opensignal的调查或使用手机检测的信息图[3]，来帮助选择使用最广的设备。 为了满足好奇心，可以从安卓文件[5]将屏幕的尺寸和分辨率映射到上面数据的密度（“ldpi”，“mdpi”等）及分辨率（“小的”，“标准的”，等等）上。 有了2013手机检测研究的帮助，很容易就找到了代表性的一系列设备。有一件有趣的琐事：30％印度安卓用户的设备分辨率很低只有240×320像素，如上面列表中看到的，三星galaxy y s5360也在其中。另外，480×800分辨率像素现在最常用（上表中三星galaxy s ii中可见）。 “测试什么” 移动app必须提供最佳用户体验，以及在不同尺寸和分辨率（关键字“响应式设计”）的各种智能手机和平板电脑上被正确显示（ui测试）。与此同时，apps必须是功能性的和兼容的（兼容性测试），有尽可能多的设备规格（内存，cpu，传感器等）。加上先前获得的“直接”碎片化问题（关于安卓的版本和屏幕的特性）， “环境相关的”碎片化有着举足轻重的作用。这种作用涉及到多种不同的情况或环境，其中用户正在自己的环境中使用的终端设备。作为一个例子，如果网络连接不稳定，来电中断，屏幕锁定等情况出现，你应该慎重考虑压力测试[4]和探索性测试以确保完美无错。 有必要提前准备覆盖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是一个重大的挑战，但它可以用一个结构化的方法和正确的工具集合以及专业知识被有效解决掉。 转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦