测试用例及测试分析
测试用例示例笔试题：你用到的测试方法/测试策略有哪些？等价类划分边界值因果图场景法正交表
确定边界值的方法（）确定边界情况（输入或输出等价类的边界）
选取正好等于、刚刚大于或刚刚小于边界值作为测试数据
概念:
因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。
因果图基本图形符号恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。
非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。
或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。
测试用例设计的思想正交表法
评审内容
评审的内容有以下几个方面
1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2)优先极安排是否合理。
3)是否覆盖测试需求上的所有功能点。
4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。
5)是否已经删除了冗余的用例。
6)是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。
7)是否从用户层面来设计用户使用场景和使用流程的测试用例。
8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
需求分析
1.用户需求：关注系统是否满足用户习惯2.行业业务需求（界面提示信息为行业术语，处理和操作模式为行业从业人员习惯模式等）3.实际使用环境需求（网络带宽，速率，断电数据备份，软件部署设置等）4.操作使用需求（类似快捷键，紧急关闭，数据恢复保护，回退机制，安装兼容性，语言环境等）5.用户需求引发的测试需求（按软件测试质量模型进行划分）6.功能需求：关注系统是否满足功能要求
最后：可以关注公众号：伤心的辣条！进去有许多资料共享！资料都是面试时面试官必问的知识点，也包括了很多测试行业常见知识，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
如果我的博客对你有帮助、如果你喜欢我的博客内容，请“点赞”“评论”“收藏”一键三连哦！推荐软件测试交流学习群：914172719里面会分享一些资深架构师录制的视频录像
好文推荐转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！
面试经：一线城市搬砖！又面软件测试岗，5000就知足了…
面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…
什么样的人适合从事软件测试工作？
那个准点下班的人，比我先升职了…
测试岗反复跳槽，跳着跳着就跳没了…
测试用例13
软件测试点分析基本原则——通用第一步:先了解产品的基本的业务流程逻辑:是个什么项目，做什么的,怎么工作的?画出流程图，业务逻辑梳理第二步：细分模块,针对每个小功能模块进行详细的划分:注意:确保不遗漏，列出输入项异常输入项正常：覆盖正常核心业务流程--优先测试??--单个功能冒烟测试异常：各种异常??--贴近用户使用场景,确保产品正确处理，提示友好!第三步：针对具体功能，寻找每个输入项，从以下角度来具体分析测试点长度，数据类型，必填项，重复需求的约束条件+隐形需求结合业务流程的步骤功能交互——交叉第四步：考虑非功能测试点包括界面、易用性、兼容性、安全性、性能压力京东产品的核心业务流程聊天功能需求（红框需要测试）：聊天功能测试点一、确认聊天的联系人类型：包括个人账号，公共号，机构号，群组等。
2.确认联系人具有的特征：个人主页---头像、昵称、性别、地区、签名、管理的群、2维码
群------------头像、创建人、群成员、群名称、群类型、消息设置、2维码
公共号------头像、名称、简介、消息设置、2维码
3、确认联系人要做哪些操作消息发送--------单聊、群聊、语音、文字、图片、表情、链接、字符及长度
消息管理--------发布通知、接受通知、发文件、消息提醒、通知提醒、声音、震动、好友请求、请求处理
消息推送--------在线、离线、收发、时序
权限管理--------开放群（任何人入群），半开放群（验证入群），验证加好友，不需验证加好友
隐私管理--------黑名单，允许好友查看动态，允许陌生人查看动态，允许通过手机号查找，允许真实姓名查找
成员管理--------加人，被加，退出，被动退出，编辑，删除
群组管理--------创建群，消息设置，申请入群，扫二维码入群，退群，通知提醒，头像编辑，名称编辑，简介编辑，权限编辑，成员编辑
好友管理--------扫二维码加人，加好友，查好友，好友推荐，群组推荐，联系人导入，拉黑名单，解除好友，备注名
动态管理--------发动态，发投票，点赞，表情，评论，增加，删除，分享，隐藏，编辑
登录退出--------忘记密码，更换账号
文件管理--------接收，离线接收，预览，删除，分享，转存，文件格式，大小
4.缓存缓存这个东西需要检查的，关系到用户体验，如果页面没做缓存，打开很慢。可以清除缓存测测。
5.升级安装，卸载，升级一定要测。有的时候需要直接升级测试，因为开发可能改了表结构而没告诉你，导致升级后部分数据丢失，后果很严重。还要看升级后消息记录是否有丢失（如果可能，需要去查看数据库。）还有可能升级过程中发现签名不一致哦，抓狂吧？
6.网络要覆盖(2G,3G,4G,wifi)，使用Charles模拟慢网、弱网等条件，验证消息是否成功发送，或者retry几次，没发出去是否有提示等，各种响应速度是否可以接受
7.中断要测试启动，静置，活动中等状态下的中断，看错误的操作是否有保护现场机制。。。
8.兼容性布局检查，分辨率检查，各种代表性机型检查
9.闪退10、不同平台间的交叉测试真正的黑盒测试自动化：用机器人测试移动应用程序
关键摘要Axiz的原型使用成品硬件组件搭建而成，包括基于3D视觉的自校准系统和基于Arduino的四轴机器人手臂。它通过外置的CMOS1080像素的摄像头监控测试执行。基于机器人的测试可以解决从桌面到移动计算的巨大转变所带来的挑战，并且可以更轻松地对UI手势和传感器输入等特性进行测试。诸如Appium、Robotium和UIAutomator之类的框架可以实现一定程度的自动测试执行。然而，它们依赖人工来设计测试脚本，就会成为瓶颈。手持设备的出现使我们需要重新考虑黑盒测试的真正含义，这涉及到增强真实性、设备独立性、成本效益比和减少对假设的依赖等诸多因素。实验证明，Axiz准确地执行了机器人测试生成的用例中包含的每个测试事件，并通过了所需的预置检查点。本文最初发表于IEEESoftware杂志。IEEESoftware杂志提供了有关当今战略技术问题的可靠的、经过同行评审的信息。为了应对运营可靠而又灵活的企业的挑战，IT经理和技术主管需要依靠IT专业人员提供最先进的解决方案。
机器人被广泛应用于大量重复性任务。那为什么不将它用于软件测试？机器人测试向测试人员展现了一种新的测试形式，比以前所见过的都更接近黑盒测试。为此，我们开发了Axiz，用于移动应用的机器人测试生成器。在这篇文章中，我们将我们的方法与基于模拟的测试自动化进行比较，描述了一些能从使用机器人测试中获益（甚至是必须使用机器人测试）的场景，并展示了我们如何将Axiz应用于Google计算器应用程序的测试。
为什么要使用机器人测试？基于机器人的测试可以解决从桌面到移动计算的巨大转变所带来的挑战[1][2]。随着人们的常用设备从桌面设备转变为移动设备，这一转变趋势预计将会加速爆发[3]。在这个新兴的移动世界中，我们比以往任何时候都需要自动化软件测试。但是，我们可能需要重新考虑软件测试的一些原则。
移动设备支持丰富的用户交互输入，比如通过触摸屏进行手势操作、通过传感器（GPS、加速度计、气压计、NearId通信等）得到各种信号。它们为异构和动态环境中的大量用户提供服务，例如地理位置和网络基础设施。为了全面地探索和发现缺陷，测试必须考虑在各种测试场景下与各种传感器的复杂交互。一项关于移动应用程序开发的调查表明，目前移动应用测试实践主要依赖手工测试，而手工测试本身是低效且存在偏差的[4]。诸如Appium、Robotium和UIAutomator等框架可以实现一定程度的测试自动化。然而，它们依赖人工来设计测试脚本，就会成为瓶颈。
幸运的是，Android测试自动化相关研究最近有了很多新进展[5][6][7][8]。然而，这些技术使用侵入式（部分或全部白盒）方法执行测试用例，并且假设测试工具享有开发者权限，而实际情况并不总是如此。
这些技术中很多需要修改应用程序代码甚至操作系统，而最接近黑盒测试的方法仍需要通过测试套件与被测应用程序（AUT）通信。这不是真正的黑盒测试，因为它依赖于测试套件与被测应用程序之间的机器对机器接口。
真正的黑盒测试方法将不会作假设，而只依赖于人与应用之间的设备级网络物理接口。在这个抽象级别进行测试能更好地模拟真实用户的体验，从而可以得到更接近真实场景的测试用例。此外，这种方法本质上是与设备无关的，在可能涉及2000多个不同待测设备的情况下可以带来相当大的好处[9]。
机器人测试宣言手持设备的出现使我们需要重新考虑黑盒测试的真正含义。移动应用程序的用户体验与桌面应用程序截然不同，现有的机器对机器黑盒测试缺乏真实性、使用情况敏感度以及快速并廉价地生成可操作的测试用例所需的跨平台灵活性。
本节列出了机器人测试的宣言，采用这套方法生成的测试用例能以真正的黑盒（完全非侵入式）方式执行。表1对手动测试、基于模拟的测试和机器人测试进行了比较。
增强真实性对于Android测试，MonkeyLab基于应用使用数据生成测试用例[10]。研究人员还发布了几种方法用于为Web系统提供真实的自动化测试输入[11]。然而，这些基于自动化测试输入的系统并不是针对移动平台的，而在关于如何生成自动化测试输入的文献中对测试用例的真实性几乎没怎么提到。
如果开发人员认为测试集与真实情况不一致，他们就不会对出现崩溃的测试集采取任何行动。此外，由于缺乏领域知识，与真实情况不符的测试会让自动测试数据的生成变得很困难。移动计算还引入了另外一个问题：人类可能无法执行测试。例如，测试可能需要使用超过五个手指同时点击屏幕。
相比之下，机器人测试套件可以模拟人的手势操作。虽然可能有一部分手势是机器人无法模拟的（还有一些手势可能机器人可以操作但人类无法重复），但至少机器人手势同为身体手势。因此，相比现在的非机器人测试环境模拟的虚拟手势——只是简单地在被测设备端生成一系列事件，机器人手势更接近真实的人机交互。
设备独立性目前已有的白盒自动化测试和（声称的）黑盒自动化测试都需要修改被测设备和操作平台中的一个或两者皆要修改。即使是所谓的黑盒技术也是通过模拟信号与应用程序通信，而不是通过移动设备上真实存在的传感器（例如触摸屏或重力传感器）触发的信号。
如前所述，机器人测试使用与人类用户相同的网络物理接口。它不太容易受到底层平台、API接口和实现细节的变化的影响。在如今这个上市时间至关重要的世界，能够在不同平台上进行快速部署是一个相当大的优势。
更好的成本效益比人工测试是相当昂贵的，虽然它有更好的真实性和设备独立性。反之，目前的自动化测试数据生成则相对便宜，仅依赖于计算时间，但它缺乏真实性和设备独立性。机器人测试则能达到最佳的成本效益比，它结合了人工测试和机器对机器自动测试的优点。
虽然从历史上来看机器人技术曾经非常昂贵，但如今机器人技术的成本正在迅速下降。虽然众包也可以降低人工测试的成本[12]，但说到底还是不可能比机器人测试更便宜。
减少对假设的依赖传统的自动化测试对被测系统提出了许多假设，而人工测试生成测试数据时提出的假设较少。机器人测试在提出假设的数量上更接近人工测试，但是它能够低成本地生成大量测试用例这一点则更接近现有的自动化测试。
Axiz图1展示了Axiz的架构，包括两个高级组件：机器人测试生成器和机器人测试执行器。
机器人测试生成器机器人测试生成器分析被测设备，并使用提取到的信息（包括应用程序类别、静态字符串和API）来调整真实性模型。该模型使用之前收集的经验数据，其中包括已知的真实场景测试用例。
表1：选择手动测试、基于模拟的测试或机器人测试的参考标准
基于对用户使用情况的观察结果，我们得到了一个完整的属性列表（例如两个相邻事件之间的延迟、事件类型和事件模式），其中涵盖了潜在的真实场景测试用例的特征和属性。我们希望这些特征能够反应真实用户环境中发生的情况，以便Axiz利用它们来指导和约束自动化测试数据生成。
图1.Axiz机器人测试系统的架构。机器人测试生成器生成基于真实场景的测试用例。机器人测试执行器剔除无法执行的测试用例并执行其余的测试用例。
机器人测试生成器将真实性模型和被测设备信息传递给进化搜索组件，以生成和改进测试用例。这些测试用例的真实性来源于两个方面。首先，我们通过重用和扩展基于真实场景的测试用例（例如Robotium或Appium测试脚本），改进应用程序测试人员以前手动编写的测试。其次，通过搜索由真实性模型约束的解决方案空间，重点生成满足早先由众包测试确定的约束条件的测试用例。
我们基于测试用例的性能（如代码覆盖率和故障发现率）和由真实性模型评定的真实性来评估生成的测试用例的质量。
机器人测试执行器我们通过在真实设备上执行用例来进一步验证候选的测试用例，使这些用例与用户或手动测试人员操作的方式大致相同。机器人测试执行器将代码形式的测试脚本转换为机器可执行的命令，然后在机器人手臂上执行它们。
机器人手臂可以与移动设备进行非侵入式地交互，就像人类一样。这个过程需要利用反向运动学和校准组件使操纵器的动作更准确。摄像头监控移动设备的状态。机器人测试执行器通过计算机视觉技术进一步处理来自摄像头的图像数据，包括执行对象检测和预测点对照。
最后，机器人测试执行器将执行过程中记录的所有过程数据发送到测试筛选器，以确定候选测试用例是否可以在真实场景中执行。如果无法执行，测试执行器会将其过滤掉。否则，Axiz将保存该测试用例以便后续再次使用。
Axiz原型实现我们开发了Axiz的原型来演示这套系统的可行性（见图2）。我们使用一套廉价、适用性广且通用的成品硬件组件来开发这个原型。我们使用3D视觉自校准功能[13]来校准和调整机器人的机械手，使系统得以可靠运行，并为预测点对照器提供输入。
机械手是一个基于Arduino的四轴机器人手臂。它由重复定位精度为0.2mm的步进电机驱动。每个轴的最大移动速度从115至210度/秒不等（这是负载为200克时的计算结果，这个最大移动速度对于大多数移动设备来说都已经足够大了）。在机械手的末端是用于模拟手指手势的触控笔。
一个外置的CMOS1080像素摄像头监控测试执行。我们在配置有2.3GHzCPU和16GBRAM的MacBookPro笔记本电脑上运行测试生成器和机器人控制器。
我们利用Python中的反向运动学组件控制机器人手臂。对象检测器和预测点对照器则基于OpenCV库实现。机器人测试生成器使用（目前最先进的）工具Sapienz[14]并应用NSGA-II（非支配排序遗传算法II）——一种广泛使用的多目标遗传算法，进行基于多目标搜索的软件测试。这个工具可以生成一系列测试事件，用最少的测试事件实现更高的测试覆盖率和故障发现率。
Axiz与Google计算器应用程序Google计算器应用程序的安装数已经达到了500万到1000万次[15]。虽然Google计算器的功能很简单，但不失为一个非常重要的基于真实场景的应用程序，因此通过它能够展示真正的黑盒机器人测试的潜力。
我们使用机器人测试生成器来生成与真实场景相符的测试用例，并用机械手臂执行测试。被测设备是Nexus7平板电脑，配置了普通的用户权限和Android官方操作系统（无需修改）。作为对比，我们使用另一台Nexus7，并对它进行更传统的侵入式测试。第二台Nexus7直接连接到MacBook上的机器人控制器。它对应的测试工具具有开发者权限，并且可以修改操作系统。
图3展示了整个测试过程。MacBook的解释器组件将事件指令转换为机器人手臂控制器的运动规律。然后该控制器基于反向运动学将运动规律转换为关节角度指令。如图3所示，机器人手臂点击第一台Nexus7上的按钮执行测试。预测点对照器监控每一个测试事件。在执行每一个测试步骤之后，预测点对照器通过外置摄像头捕获图像并验证移动GUI的状态。
Axiz准确地执行了生成的机器人测试用例中每一个测试事件，并通过了所需的预置检查点，使Sapienz的能力得以发挥到极致。
图2：用四轴机器人手臂测试移动应用程序。我们使用一套廉价、适用性广且通用的成品硬件组件进行开发。
图3：使用Axiz测试一个真实的计算器应用程序。Axiz准确地执行了生成的机器人测试用例中每一个测试事件，并且通过了所需的预置检查点。
Axiz执行测试的视频可以在这里查看。在这个视频中，我们将Axiz与传统的自动化测试工具并排展示，后者不使用机器人手臂，而只是产生一系列测试事件。该视频表明，用廉价的成品硬件开发的机器人手臂可以产生一组相同的测试事件，但更接近真实的使用场景，从而实现更好的设备独立性和真实性。
致谢我们感谢AndreasZeller在第36届CREST（进化、搜索和测试研究中心）开放研讨会[16]上所作的演讲，在演讲中他展示了一个有趣的视频，视频中一款人造手臂自动与移动设备进行交互。这成为了我们研究的灵感之一。
参考资料F.Richter,“GlobalPCSalesFalltoEight-YearLow,”14Jan.2016.“GlobalSmartphoneShipmentsForcastfrom2010to2019(inMillionUnits)“WorldwideDeviceShipmentstoGrow1.9Percentin2016,WhileEnd-UserSpendingtoDeclinefortheFirstTime,”Gartner,20Jan.2016.M.E.Joorabchi,A.Mesbah,andP.Kruchten,“RealChallengesinMobileAppDevelopment,”Proc.2013ACM/IEEEInt’lSymp.EmpiricalSoftwareEng.andMeasurement(ESEM13),2013,pp.15–24.A.Machiry,R.Tahiliani,andM.Naik,“Dynodroid:AnInputGenerationSystemforAndroidApps,”Proc.9thJointMeetingFoundationsofSoftwareEng.(ESEC/FSE13),2013,pp.224–234.D.Amalfitanoetal.,“UsingGUIRippingforAutomatedTestingofAndroidApplications,”Proc.27thIEEE/ACMInt’lConf.AutomatedSoftwareEng.(ASE12),2012,pp.258–261.10.W.Choi,G.Necula,andK.Sen,“GuidedGUITestingofAndroidAppswithMinimalRestartandApproximateLearning,”Proc.2013ACMSIGPLANInt’lConf.ObjectOrientedProgrammingSystemsLanguages&Applications(OOPSLA13),2013,pp.623–640.K.Mao,M.Harman,andY.Jia,“Sapienz:Multi-objectiveAutomatedTestingforAndroidApplications,”Proc.25thInt’lSymp.SoftwareTestingandAnalysis(ISSTA16),2016,pp.94–105.A.Reversat,“TheMobileDeviceLabatthePrinevilleDataCenter,”Facebook,13July2016.M.Linares-Vasquezetal.,“MiningAndroidAppUsagesforGeneratingActionableGUI-BasedExecutionScenarios,”Proc.12thWorkingConf.MiningSoftwareRepositories(MSR15),2015,pp.111–122.M.BozkurtandM.Harman,“AutomaticallyGeneratingRealisticTestInputfromWebServices,”Proc.IEEE6thInt’lSymp.ServiceOrientedSystemEng.(SOSE11),2011,pp.13–24.K.Maoetal.,“ASurveyoftheUseofCrowdsourcinginSoftwareEngineering,”J.SystemsandSoftware,2016.J.M.S.Motta,G.C.deCarvalho,andR.McMaster,“RobotCalibrationUsinga3DVision-BasedMeasurementSystemwithaSingleCamera,”RoboticsandComputer-IntegratedManufacturing,vol.17,no.6,2001,pp.487–497.“Calculator,”Google,2016.A.Zeller,“WhereDoesMySensitiveDataGo?MiningAppsforAbnormalInformationFlow,”presentationat36thCRESTOpenWorkshop(COW36),2014.关于作者KeMao是伦敦大学学院进化、搜索与测试研究中心（CREST）的研究生。读者可以通过k.mao@cs.ucl.ac.uk与他联系。
MarkHarman是伦敦大学学院进化、搜索与测试研究中心（CREST）的主任。读者可以通过mark.harman@ucl.ac.uk与他联系。
YueJia是伦敦大学学院进化、搜索与测试研究中心（CREST）的软件工程讲师。读者可以通过yue.jia@ucl.ac.uk与他联系。
本文最初发表于IEEESoftware杂志。IEEESoftware杂志提供了有关当今战略技术问题的可靠的、经过同行评审的信息。为了应对运营可靠而又灵活的企业的挑战，IT经理和技术主管需要依靠IT专业人员提供最先进的解决方案。
查看英文原文：RoboticTestingofMobileAppsforTrulyBlack-BoxAutomation
感谢薛命灯对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。