android测试用例文档

㈠ android音乐播放器的测试怎么写

软件工程数据库课程设计——测试报告 1 引言 1.1 编写目的 编写该测试报告主要由以下几个目的 1.通过对测试结果的分析，得到对软件质量的评价 2.分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考 3.评估测试执行和测试计划是否符合 4.分析系统存在的缺陷，为修复和预防 bug 提供建议 1.2 背景说明 说明： 1. 被测试软件系统的名称：android 音乐播放器 2. 该软件的任务提出者：android 老师。 1.3 定义 严重 bug：出现以下缺陷，测试定义为严重 bug 系统无响应，处于死机状态，需要其他人工修复系统才可复原。 点击某个按钮后出现“ Unexpect error，the application has been stopped”或 者返回异常错误。 进行某个操作后，出现“ Unexpect error，the application has been stopped” 或者返回异常错误。 当切换音乐时，出现” Unexpect error，the application has been stopped”或 者返回异常错误。 1.4 参考资料 列出要用到的参考资料，如： 1. 2. 《android 需求和实际和说明书》 《android 项目数据字典》 第1页 软件工程数据库课程设计——测试报告 3. 《android 后台管理系统测试计划》 4. 《android 项目计划》 5. 《android 程序设计基础》 2 测试概要 Android 音乐播放器系统测试从 2014 年 5 月 25 日开始到 2014 年 6 月 1 日结束， 共持续 6 天，测试功能点 6 个，执行 10 个测试用例，平均每个功能点执行测试用例 2 个，测试共发现 5 个 bug，其中严重级别的 1 个，无效 1 个，平均每个测试功能点 1 个 bug。 3 测试结果及发现 3.1 测试 1（功能键测试） 在本次测试中对各个功能键进行了相关的测试，并把各个功能键该有的功能给体现出来。 最后的测试结果是，各个功能键基本符合预想的要求，但是在测试中间，不时会出现一些系 统错误。 3.2 测试 2（音乐清单测试） 在对音乐清单模块进行测试时，先了解音乐清单的具体功能的体现与要求。音乐清单模 块具备自动扫描功能，自动更新，删除重复，删除错误功能。测试过程比较繁琐，不停更换 音乐，增加重复音乐，增加错误来对该项进行测试。对音乐清单界面转变，字体等还需改进。 4 对软件功能的结论 4.1 功能 1（功能键） 名称：播放 参与者：用户 目标：用户点击播放音乐列表中的歌曲 前置条件：播放器正在运行 基本事件：1.用户单击列表中歌曲 2.播放器将播放列表中的点击 的歌曲 名称：暂停 参与者：用户 目标：使得用户可以暂停正在播放的歌曲 第2页 软件工程数据库课程设计——测试报告 前置条件：歌曲正在播放且未停止和暂停 基本事件：1.用户单击“暂停”按钮 2.播放器将暂停当前的歌曲 名称：上一首/下一首 参与者：用户 目标：使得用户可以点播上一首或下一首音乐 前置条件：歌曲正在播放或歌曲暂停中 基本事件：1.用户单击“上一首或下一首”按钮 2.播放器将播放上一首歌曲或下一首歌曲 4.1.1 能力 本部分是对播放音乐时的一些简单的操作，如播放，暂停，切歌。为满足这部分功能， 进行不断的测试已将可以预料到的错误，进行了修改，大体上不会再出现此类错误。 4.2 功能 2（音乐清单） 名称：音乐列表 参与者：用户 目标：使得用户可以进入音乐列表 前置条件：程序在运行 基本事件：1.用户单击“音乐”分区 2.播放器进入音乐列表 4.2.1 能力 本部分是对音乐列表的功能的测试，此项目的音乐列表的基本功能可以实现。对于一些 界面方面的操作，在测试中始终出现错误，排除不了。相对来说测试是成功的，界面上的操 作与音乐播放器的主要功能没有影响，所以可以删除此部分。 5 分析摘要 5.1 能力 Android 音乐播放器的测试今本上是成功的。对于一些基本功能，都能够实现。本软件的 可移植性还是比较强的，只要是 android 手机都可以安装本软件，并且不会出现系统不兼容 第3页 软件工程数据库课程设计——测试报告 的问题。最终的测试结果，也暴露了一些问题，与要求的差一些。就是在音乐清单部分，对 于字体的修改以及界面的转换方面没有完全实现。本软件本就是 android 软件，在测试环境 与运行环境上不存在差异，这完全是因为 android 太强大了。 5.2 缺陷和限制 1． 缺陷描述：音乐清单有乱码，音乐无名称，查看不方便 缺陷影响：其他音乐都有名称，音乐无名称，查看不方便 推迟原因：目前的日志 为了调试方便，显示了很多其它信息，在项目正式发布时会统一处理的。 2． 缺陷描述：数据字典种类修改，默认值设置后，在调用该数据字典种类的数据字典， 默 认值无显示 缺陷影响：数据字典种类的默认值设置后，不能显示设置的默认值，相当于数据字 典种类默认值设置功能未实现 推迟原因：该功能暂时不好实现，需要和和系统的默认语种一起处理。 3. 缺陷描述：多媒体添加，文件上传功能未实现 缺陷影响：文件上传功能未实现 推迟原因：该功能暂时不好完成，在下个版本中完成 5.3 建议 在项目开始的时候应该制定编码标准，数据库标准，需求变更标准，开发和测 试人员都 严格按照标准进行，可以在后期减少因为开发，测试不一致而导致的问题，同时也可以降低 沟通成本。 发布版本的时候，正确布置测试环境，减少因为测试环境，测试数据库数据的 问题而出 现的无效 bug。 开发人员解决 bug 的时候，填写 bug 原因以及解决方式，方便 bug 的跟踪。 开发人员在开发版本上发现 bug，可以通知测试人员，因为开发人员发现的 bug 很有可 能在测试版本上出现，而测试人员和开发人员的思路不同，有可能测试人员没有发现该 bug， 而且，这样可以保证发现的 bug 都能够被跟踪。 。 5.4 评价 本软件经测试，可以在任何 android 设备上运行，安全性得到了保证，可以交付使用。 第4页

㈡ 如何进行android兼容性测试cts

二、运行CTS的方法，步骤如下：
（1）进入目录android-cts，该目录是通过上面那两种方法获得的。在android-cts目录下会有3个文件夹，其中一个是tools。
（2）进入tools目录，输入./startcts来启动CTS。
（3）如果运行成功会出现Android CTS version 2.3_r1的字样（我的android的版本是2.3的）。如果有连接设备到PC上还会出现Device(设备ID)connected的字样。这里设备可以是连接PC的android的机器，也可以是模拟器。
三、CTS测试的方法：
（1）在cts_host>下敲入help，会显示cts下的许多命令。ls –plan命令显示google自带的测试方案，如：Java、Signature、Android、CTS、VM、RefApp、Performance、AppSecurity。其中Performance这个方案是google暂不要求的。Java、Signature、Android、VM、RefApp、Appsecurity方案都是CTS方案的子集。
（2）用命令ls -d来查看已连接的设备，CTS测试之前我们必须保证至少有一个设备连接上。
（3）输入命令start –plan CTS来执行CTS测试方案，该方案有两万多条测试项目，需要很长时间，因此除了第一次测试之外，不建议这么做。我做的都是针对某些包的测试。如果连接了多个设备的话需加上-d参数，后面跟上设备id来告诉CTS需要测试的设备。
（4）对单独一个包进行测试的方法：start –plan CTS –p 包名；推荐用这种方法来进行针对性的测试。需要知道有哪些包名，可以输入命令：ls –plan CTS
（5）也可以针对单独一个case进行测试：start –plan CTS –test 类名#方法名
四、查看测试的结果：
测试生成的log在\android-cts\repository目录下以log+测试时间.txt命名。测试报告在android-cts\repository\results目录下，也是以测试时间命名。
五、注意事项：
（1）测试前需要安装一个apk：adb install -r android-cts/repository/testcases/.apk 然后在设置里面

㈢ 如何设计Android APP测试用例

从一个移动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 ）。

如果这种多样性在质量保证过程中被忽略了，那么绝对可以预见：bugs会潜入应用程序，然后是bug报告的风暴，最后GooglePlay Store中出现负面用户评论。因此，目前的问题是：你怎么使用合理水平的测试工作切实解决这一挑战？定义测试用例及一个伴随测试过程是一个应付这一挑战的有效武器。

㈣ 如何设计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是一个重大的挑战，但它可以用一个结构化的方法和正确的工具集合以及专业知识被有效解决掉。

㈤ 怎么写Android手机游戏测试用例

第一项：游戏安装

1. 游戏安装后是否与安卓软件版本（手机环境）兼容

2. 游戏安装后是否会影响到其他软件的使用

3. 游戏安装后是否有优化功能

4. 游戏安装包是否过大

5. 游戏安装包是否安全，无病毒、木马等恶意破坏性程序
   

6. 游戏安装后显示的游戏图标（App Icon）是否显示正常

   ......

第二项：游戏画面与文字

1. 游戏界面是否能依照手机的屏幕摆放位置来进行有效的横/竖屏切换

2. 游戏画面是否在游戏开启后运行流畅

3. 游戏画面是否符合游戏风格

4. 游戏画面是否符合大众的审美观，并无敏感性因素

5. 游戏画面是否符合屏幕分辨率的标准，无显示不完整等异常现象

6. 游戏文字是否显示清晰

7. 游戏文字是否美观，并与游戏画面相匹配

8. 游戏文字是否符合大众人的审美观，并没有敏感性词汇

9. 游戏文字是否汉化完整

10. 游戏文字是否能根据语言的设置进行多国语言文字的切换

11. 游戏文字是否出现错别字、繁体字（某些状况可以考虑使用繁体字）、火星文等文字

    ......

    
    

第三项：游戏声音

1. 游戏背景音乐是否能在游戏运行时播放

2. 游戏背景音乐是否出现播放延迟、播放提前等播放不同步现象

3. 游戏背景音乐是否与游戏风格相符合

4. 游戏音效是否能在游戏运行时播放，并无不同步现象

5. 游戏背景音乐和音效是否符合大众的审美观，并没有敏感性因素

6. 当进入通话状态时，是否出现声音混合现象

7. 游戏声音是否出现变形

   ......

   
   

   
   

   
   

第四项：游戏核心功能（可玩性）

1. 游戏玩家基本动画（站立、行走、奔跑、基本攻击、技能攻击等）播放是否正常

2. 游戏在运行时是否出现死机、黑屏、崩溃等严重影响游戏体验的现象
   

3. 任务系统是否完善、是否出现描述错误、当前任务与进行中的任务不匹配等现象，达到任务要求后能否提交任务，提交任务后任务能否完成，任务完成的奖励是否正确

4. 游戏剧情（世界观）是否符合大众的审美观，并没有敏感性因素

5. 游戏玩家能否正常的攻击怪物、拾取物品、受到伤害，玩家生命值为0时能否正常死亡

6. 游戏敌人（怪物或对手）能否正常的攻击玩家、受到伤害，敌人（怪物或对手）生命值为0时能否正常死亡

7. 玩家与敌人（怪物或对手）的生命值、法力值等是否显示正常（包括数值和血条），受到攻击后，生命值是否下降，释放技能后，法力值是否下降（包括数值和血条）

8. 杀死敌人（怪物或对手）后，物品的掉落和经验值的奖励是否正常
   

9. 玩家的攻击力、防御力等数值计算是否正确，当玩家强化装备后，攻击力、防御力等数值能否上升

10. 玩家的背包系统是否完善，能否实现拾取物品后物品出现在背包内，当背包超出负重上限或物品栏满栏的时候是否还能捡取物品，能否在背包内实现物品出售、物品修理等功能，背包内的物品信息是否显示正确，使用后能否出现效果。

11. 游戏是否具备自动寻路等导航功能，若有，该功能是否完善，玩家、宠物、坐骑和怪物的跟踪是否正常
    

12. 当玩家的装备的持久度不足时，攻击力、防御力能否受到影响

13. 进入游戏后，游戏场景的渲染、纹理是否显示正常

14. NPC的功能是否能实现
    

15. 游戏每个功能按键是否可以点击，点击后是否出现点击后的效果

16. 游戏虚拟杆是否可以正常的控制玩家的移动，游戏的虚拟按钮是否可以正常的控制玩家的攻击

17. 行会系统、好友系统以及结婚系统是否完善，玩家列表是否是当前状态的玩家列表

18. 游戏是否有PK系统（PVE、PVP），若有，该功能是否完善

19. 游戏是否具备组队功能，若有，该功能是否完善
    

20. 物品出售时金币计算是否正确

21. 游戏关卡的小地图显示是否正常，地图图标是否和玩家、敌人（怪物或对手）同步
    

22. 游戏的记时是否连续、一致（指来电后时间继续，从来电时刻开始计时）

23. 玩家的游戏体验是否方便

24. 游戏说明是否与游戏操作功能保持一致

25. 游戏界面的跳转是否正常

26. 新手玩家的前期体验是否快速方便，玩家等级的提升是否快速，是否能给玩家带来一定的紧张刺激感

27. 退出游戏后，游戏信息能否正确存档

    ......

    
    

    
    

第五项：充值与商城系统

1. 商城内物品价格是否合理

2. 能否通过花费的现金来兑换一定量的虚拟游戏币（基本充值功能的实现）
   

3. 购买商品后，商品信息能否正确显示，使用后能否出现效果

4. 能否通过游戏官方、支付宝、微信等支付现金来实现充值交易

5. 点击充值按钮后能否进入官方充值网站

6. 商城内物品的上架/下架是否及时，是否有折扣等福利性活动

   ......

第六项：游戏中断测试

1. 被测游若与时间相关（游戏中有记时功能），来电后时间是否与来电前一致

2. 游戏待机后，游戏能否暂停并关闭屏幕，并且来电或其他优先操作后，游戏能否暂停，并无其他异常现象（死机、黑屏、崩溃等）。

3. 游戏中不同的界面来电时，来电提示正常，接听，挂断电话等操作后，返回游戏是否出现异常。

4. 游戏中不同的界面手机来短信时，短信提示正常，回复短信后返回游戏是否出现异常

5. 游戏中不同的界面来电时，来电提示正常，接听，挂断电话等操作后，返回游戏后游戏音效是否出现异常

6. 游戏中不同的界面手机来短信时，短信提示正常，回复短信后返回游戏后游戏音效是否出现异常

   ......

第七项：游戏其他功能

1. 游戏注册是否有实名制

2. 游戏是否有未成年人防沉迷系统

3. 游戏的安全防护措施是否到位（仓库锁、登录锁、游戏物品锁等）

4. 游戏获得的成就能否通过QQ、微信、支付宝等与联系人分享

   ......

㈥ 如何使用python做android的自动化测试

开始第一个简单的Android UI自动化测试
1.使用adb命令连接真机或模拟器
2.打开uiautomatorviewer工具
3.使用uiautomatorviewer工具获取应用的元素进行定位
4.简单介绍unittest框架的使用方法
5.使用Python编写猫宁考勤应用注册模块的自动化测试
1.使用adb命令连接真机或模拟器：
手机USB连接电脑，进入开发者模式；
cmd命令：adb devices ，查看手机是否连接
这里写图片描述
显示错误
这是因为adb的端口被占用，我们需要查看是什么应用占用了这个端口（5037为adb默认端口）
cmd命令 : netstat -aon|findstr “5037”
这里写图片描述
可以看到占用5037端口对应的程序的PID号为8388;
cmd命令 : tasklist|findstr “8388”
这里写图片描述
可以看出8388对应的程序为kadb.exe，说明该程序正在使用5037端口;
这时我们需要在任务管理器中结束kadb.exe进程，按快捷键“Ctrl+Shift+Esc”调出Windows任务管理器，找到“kadb.exe”，单击下方的结束进程即可！
这里写图片描述
我们再次运行cmd命令：adb devices
这里写图片描述
这一步成功后我们才能运行sdk自带的uiautomatorviewer；
我们需要用uiautomatorviewer工具来获取元素，用于定位。
cmd命令：uiautomatorviewer，打开uiautomatorviewer界面
这里写图片描述
或者找到sdk目录：sdk\tools中找到uiautomatorviewer.bat文件双击运行
这里写图片描述
2.打开uiautomatorviewer工具
这里写图片描述
我们可以根据text，resource-id，class等元素进行定位
3.使用uiautomatorviewer工具获取应用的元素进行定位
这里我使用python自带的IDLE进行编写测试脚本，打开python文件找到IDLE（python GUI）双击打开，如图：
这里写图片描述
4.简单介绍unittest框架的使用方法
# -*- coding:utf-8 -*-
from uiautomator import device as d
import unittest
class Mytest(unittest.TestCase):
#初始化工作
def setUp(self):
print "--------------初始化工作"
#退出清理工作
def tearDown(self):
print "--------------退出清理工作"
#测试点击猫宁考勤case
def test_login(self):
d(text="猫宁考勤").click()
print "--------------测试1"
#测试2
def test_z(self):
print "--------------测试2" #这里你可以写你的第二个测试用例，
#测试3
def test_w(self):
print "--------------测试3" #这里你可以写你的第三个测试用例。。。。。。。。。。。。。
if __name__ == '__main__':
unittest.main()
结果如下：
Testing started at 21:14 …
————–初始化工作
————–测试1
————–退出清理工作
————–初始化工作
————–测试3
————–退出清理工作
————–初始化工作
————–测试2
————–退出清理工作
Process finished with exit code 0
从结果中我们可以看出unittest框架的运行方式为：
setUp 测试1 tearDown
setUp 测试2 tearDown
setUp 测试3 tearDown
5.使用Python编写猫宁考勤应用注册模块的自动化测试
# -*- coding:utf-8 -*-
from uiautomator import device as d
import time
import unittest
class MyTestSuite(unittest.TestCase):
# 初始化工作
def setUp(self):
print "--------------初始化工作"
# 退出清理工作
def tearDown(self):
print "--------------退出清理工作"
#***************************方法**************************************
# 判断控件是否存在 & text
def check_controls_exists(self, controls_text):
if d(text=controls_text).exists:
return 1
else:
return 0
# 判断按钮是否置灰 & text & clickable
def check_controls_click_text(self, controls_text):
if d(text=controls_text).info.get("clickable") is True:
return 1
else:
return 0
#assertIn(a, b) a in b
def check_ainb(self,resourceid,b):
if d(resourceId=resourceid).info.get("text") in b:
return 1
else:
return 0
#***********************************************************
# 注册模块
def test_Aregister(self):
try:
time.sleep(2)
#猫宁考勤开启全新时代
self.assertEqual(self.check_controls_click_text("注册"),1,u"猫宁考勤开启全新时代")
# 猫宁考勤开启全新时代--》点击注册按钮进入注册猫宁界面
d(text="注册").click()
time.sleep(3)
#注册猫宁界面
self.assertEqual(self.check_text("com.isentech.attendancet:id/regis_phone","请输入手机号码"),
1,u"注册页面-》请输入手机号码")
self.assertEqual(self.check_text("com.isentech.attendancet:id/regis_verifycode","请输入验证码"),
1,u"注册页面-》请输入验证码")
self.assertEqual(self.check_controls_click_text("获取验证码"), 0,u"注册页面-》获取验证码")
self.assertEqual(self.check_controls_click_text("《中科爱讯服务协议》"), 1,u"注册页面-》《中科爱讯服务协议》")
self.assertEqual(self.check_controls_click_text("注册"), 0,u"注册页面-》注册")
time.sleep(2)
#《中科爱讯服务协议》
d(text="《中科爱讯服务协议》").click()
time.sleep(2)
self.assertEqual(self.check_ainb("com.isentech.attendancet:id/title","服务协议"), 1,u"注册页面-》服务协议")
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/title_back").click()
time.sleep(1)
#手机号不输入是否能注册
d(text="注册").click()
time.sleep(3)
# 手机号只输入1个数字是否能注册&只输入1个数字是否能获取验证码
d(resourceId="com.isentech.attendancet:id/regis_phone").set_text("1")
self.assertEqual(self.check_controls_click_text("获取验证码"), 0)
time.sleep(1)
d(text="注册").click()
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/regis_phone").clear_text()
time.sleep(1)
#只输入5个数字是否能获取验证码
d(resourceId="com.isentech.attendancet:id/regis_phone").set_text("11111")
self.assertEqual(self.check_controls_click_text("获取验证码"), 0)
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/regis_phone").clear_text()
time.sleep(1)
#只输入手机号是否能注册
d(resourceId="com.isentech.attendancet:id/regis_phone").set_text(phone_number)
self.assertEqual(self.check_controls_click_text("注册"), 0)
time.sleep(1)
d(text="注册").click()
time.sleep(1)
#输入正确的验证码&获取验证码是否高亮
d(resourceId="com.isentech.attendancet:id/regis_verifycode").set_text("5648")
time.sleep(1)
self.assertEqual(self.check_controls_click_text("获取验证码"), 1)
time.sleep(2)
#密码只输入1个数字是否能注册&注册按钮是否高亮
d(resourceId="com.isentech.attendancet:id/regis_pass").set_text("1")
d(resourceId="com.isentech.attendancet:id/regis_passAgain").set_text("1")
time.sleep(1)
self.assertEqual(self.check_controls_click_text("注册"), 0,u"密码只输入1个数字是否能注册")
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/regis_pass").clear_text()
d(resourceId="com.isentech.attendancet:id/regis_passAgain").clear_text()
time.sleep(1)
#输入不相同的密码是否能注册
d(resourceId="com.isentech.attendancet:id/regis_pass").set_text("123456")
d(resourceId="com.isentech.attendancet:id/regis_passAgain").set_text("12345")
time.sleep(1)
self.assertEqual(self.check_controls_click_text("注册"), 0,u"输入不相同的密码是否能注册")
time.sleep(1)
d(resourceId="com.isentech.attendancet:id/regis_pass").clear_text()
d(resourceId="com.isentech.attendancet:id/regis_passAgain").clear_text()
time.sleep(1)
#输入正确的密码是否能注册&我已同意是否打钩
d(resourceId="com.isentech.attendancet:id/regis_pass").set_text("123456")
d(resourceId="com.isentech.attendancet:id/regis_passAgain").set_text("123456")
time.sleep(1)
self.assertEqual(self.check_controls_click_resourceId("com.isentech.attendancet:id/regis_agree"), 1)
self.assertEqual(self.check_controls_click_text("注册"), 1)
time.sleep(2)
d(text="注册").click()
time.sleep(8)
except Exception, e:
print u"Error: 注册模块有问题\n", e
def test_app():
test_unit = unittest.TestSuite()
test_unit.addTest(MyTestSuite("test_Aregister"))
if __name__ == "__main__":
# 测试app
unittest.main()