APP测试准备

最新推荐文章于 2022-10-17 15:57:06 发布

BronQQ

最新推荐文章于 2022-10-17 15:57:06 发布

阅读量552

点赞数

分类专栏：测试

测试专栏收录该内容

6 篇文章 0 订阅

订阅专栏

APP测试准备

1. APP项目周期

 App 项目生命周期分为三个阶段，开发阶段，测试阶段，发布阶段。测试人员是需要全程参与的。

这里写图片描述

2.测试的基本思路

 测试范围－测试内容－测试计划－测试方案－测试用例－测试执行

 测试并不是一种拿到手就可以直接做的工作，测试的执行是需要贯穿整个项目的，我们需要先熟悉整个项目的流程，心中有个大体的框架才能入手。
     1. 了解测试的范围
            在一个项目的测试任务被告知前，作为测试的我们需要通过邮件、会议之类了解新项目的框架范围，需要知道接下来整个团队的任务，
        知道我们应该如何去完善这份项目计划。

     2. 和开发的沟通
            我们对自己的测试任务有个基本的概念，但是在一些细节方面还会存在问题，接下来我们要做的就是和开发进行沟通。
        测试和开发是相辅相成的，开发少不了测试帮助优化，测试也需要开发的支持才能顺利地完成测试任务，双方沟通越细。后续能够
        避免的问题越多。

     3. 对需求文档立项
            和开发沟通完毕后，开始准备测试计划方案，列出每个功能模块，大致的功能点和执行方法。个人认为，此时可以列出测试用例雏形，
        后续在测试过程中再加以完善
           （当然，每一个测试工程师的想法、操作手法以及思维角度不一致，随时都可能会产生新的操作手法，所以测试用例是不可能补全的。）
            我们只需要列出基本的功能点，后续的一些特殊操作可以作为测试用例附加，但不包含在基础用例的范畴。对于测试人员来说，
        更方便测试用例的管理，对于公司来说，APP 模块更新变动较大，测试用例过于详细的话维护成本会比较高，同时也节省了公司项目的执行时间。

3.APP 测试用例设计思路

  测试项目：     APP 应用软件
  需求测试：     查看 APP 的需求文档，原型图
  界面测试：     查看 APP 的界面外观是否符合标准
  功能测试：     查看 APP 的功能是否可以使用

  可靠性测试：   使用 APP 过程中是否发生异常退出等情况
  兼容性测试：   安装 APP 到平台（不同 Android 系统）上，不同分辨率设备上使用，是否正常使用
  疲劳测试：     安装 APP 程序一直置于后台，查看是否会发生异常退出或闪退等情况，进行 IDLE 测试    
  易用性测试:    APP 程序是否容易操作、人性化，从用户角度体验，也就是简约便捷的趋势

  压力测试：     重复安装、卸载 APP 程序或不断点击某一个按钮是否退出等情况
  并发测试：     安装、卸载 APP 程序过程中或操作 APP 程序功能是受到第三方用用的干扰
  回归测试：     对 APP 过程中 Bug 进行回归测试，在回归测试的同时要注意在 Bug 是否修复的基础上有没有产生新的 Bug
  数据连接测试： 数据、WIFI、热点等情况下测试，包括网络切换等各种情况
  用户手册测试： 查看使用手册是否对于 APP 程序用法、限制、条件等有详细描述

4.测试常用方法

等价类划分、边界值、场景法、错误推测法

 1.等价类划分
        等价类划分法原则是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。
    然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例
    具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和
    推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。等价类划分法是一种系统性的确定要输入的测试条件的方法。

 2.边界值
        长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。
    因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。
    通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，
    而不是选取等价类中的典型值或任意值作为测试数据。

 3.场景法
        通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。
    用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
    我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来
    确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场
    景，假定推测的场景。

 4.错误推测法
        列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例. 
    例如， 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等，这些就是经验的总结。总之，就是进行错误的操作。

5.测试用例误区

 1.测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试。

       这句话并不是不正确，而是它有一个前提。对于测试用例，写得过于简单，会使使用者无法明白测试用例点，导致每一个点都需要问询，
   这样反而耗费了太多时间。写得太详细，对于测试用例的编写者而言又会耗费太多时间。在一个互联网时代，版本更新迭代速度太快，这样
   测试用例的更新也会随之频繁。我们大多都会忽略一点，我们之所以为了让测试用例尽可能详细，是为了达成完善产品的测试目的。

       测试的目的是为了尽可能发现程序中存在的 Bug，测试活动本身也可以被看做是一个项目，也需要在给定的资源条件下，尽可能地达成
   目标，一切都是在围绕着测试的目标进行。

       测试用例的详细程度也需要确定。如果测试用例的执行者、测试用例的设计者、测试活动相关人对需要被测试的项目了解深刻，那么测试
   用例就没有必要太详细，文档的本身在于沟通，只要能达到沟通的目的就可以。在测试计划阶段，一般建议用项目 30% ~ 40% 左右的时间进行
   测试用例设计，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

 2.测试用例是一劳永逸的事情

       这种说法就显得有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中却是时有发生的，测试用例文档是有可能随产品更新而
   更新的，这一点应该被测试人员所牢记。

 3.能发现到目前为止没有发现的 Bug 的用例是好的用例。

       作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不该针对单个的测试用例去评判它的好坏。

       测试需要保证以下两点：
           1. 程序作了它应该做的事情
           2. 程序没有做它不该做的事情

摘自《金阳光自动化测试》(http://mp.weixin.qq.com/s?__biz=MzA4MTcyOTEwMw==&mid=2650611055&idx=2&sn=0ef63fa1c32e5945335c906fc39b40d4&scene=4#wechat_redirect)