软件测试理论和APP测试案例

1、软件测试的系统流程

软件工程模型基本就是业务建模-〉系统分析-〉概要设计-〉详细设计-〉编码-〉测试-〉部署。其中测试过程按4个步骤进行，即单元测试、集成测试、系统及发版测试和回归测试。

 (1)、单元测试，集中对每一个程序单元进行测试，检查各个程序模块是否正确地实现了预定的功能，属于白盒测试，测试范围为单元内部的源代码和程序结构(如数据结构，逻辑控制，异常处理等)。

 (2)、集成测试把已测试过的模块组装起来，检查模块间接口是否正确，检查各个模块之间的通信和相互调用是否符合需求。属于灰盒测试，测试范围为模块接口之间的数据传递，以及模块组合后的功能。

(3)、系统测试把被测软件系统和计算机硬件、数据库、外设、前端和后端以及其它软件结合在一起，在实际运行环境下对软件系统进行一系列的组装测试和运行测试。目的在于检测软件对《需求规格说明书》的符合程度。属于黑盒测试，只关心输入和输出结果，测试范围为整个系统。

       (4)、回归测试：是软件上线后的维护阶段或者是研发修复Bug之后进行确认测试。目的在于验证缺陷已经得到修复，并检测是否引入新的缺陷。

2、测试用例及编写方法

测试用例是一份描述具体测试步骤的文档，包括测试的输入参数、条件及配置、预期的输出结果等，用以判断被测软件的工作是否正常。

2.1、测试用例设计的三大原则

(1)、设计测试用例要力求最大的覆盖率，参考《需求规格说明书》对每个功能点进行操作上的细化，尽可能趋向最大需求覆盖率。

(2)、用例要对测试功能点、测试条件、测试步骤、输入值和预期结果准确描述。

(3)、在设计测试用例的时候，除了满足系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受压力的能力等。

2.2、设计测试用例设计方法

设计测试用例时要根据具体的产品和需求所明书，比如NetSign C接口普遍得就是根据输入和输出参数的不同情况设计用例，但也有通用的情况。

(1)、等价类划分。把程序的输入域划分成若干部分子集，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，比如传输IP地址时，可以分为A类地址、B类地址和C类地址。既能减少用例总数，又能提高测试覆盖率。

(2)、边界值分析法。通常边界值分析法是作为对等价类划分法的补充，其测试条件来自等价类的边界。因为 很多错误是发生在输入或输出范围的边界上，而不是发生在输入/输出范围的中间区域。因此针对各种边界情况设计测试用例，可以查出更多的错误。

(3)、错误推断法。基于测试人员的经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例。比如字符串和普通的字符数组结尾’\0’的区别，内存拷贝函数stycpy和memecpy必须要进行+1或-1的操作。

3、APP测试中经常出现的基础案例

3.1、APP的安装、卸载测试

（1）、软件在不同操作系统及版本（Android的EMUI\Flyme\MIUI、iOS、WindowsPhone）下安装是否正常

（2）、软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里，安装后没有生成多余的目录结构和文件

（3）、软件安装过程是否可以取消

（4）、软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）

（5）、安装空间不足时是否有相应提示

（6）、对于需要通过网络验证之类的安装，在断网情况下尝试一下

（7）、重复安装应该有提示，

（8）、升级安装时，版本更新链接有效，比如后台设置的版本白名单

（a）、使用各种方式卸载程序，如直接删除安装文件夹卸载是否有提示信息、长按图标卸载、手机设置里卸载、第三方应用卸载

（b）、测试卸载后文件是否全部删除所有的安装文件夹

（c）、卸载过程中出现的意外情况的测试（如死机、断电、重启）

（d）、卸载是否支持取消功能，单击取消后软件卸载的情况

3.2、APP的注册、登录和修改密码测试

3.3、核对rp原型图和效果图，进行UI测试

（1）、观察APP的用户界面(如菜单、对话框、窗口和其它可规控件)是否符合UI稿

（2）、不同的连接页面之间导航链接是否有效，是否跳转是否正确。

（3）、旋转手机，确保程序不退出，页面排版无异常。

（5）、输入框说明文字的内容与产品需求一致

（6）、某页无数据时、断网时、有网但接口异常时的状态页是否和UI一致

3.4、核对需求文档，进行功能测试

功能测试的用例要根据具体产品设计，这里只提供通用点。APP端测试最关心的是流程和数据，避免Crash和ANR问题。

（1）、App安装完成后是否能正常启动，且打开速度控制在预期时间内。

（2）、切换后台再切换前台的操作对当前状态如登陆、当前页、数据刷新的影响

（3）、强制杀掉APP进程再启动对当前状态如登陆、当前页、数据刷新的影响

（4）、登陆验证/免密登陆时的手势密码和指纹是否符合产品需求

（5）、对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏解锁的测试，这种页面最容易出现崩溃。

（6）、同一用户在多个终端先后登陆时，APP是否有符合产品需求的处理

（7）、App使用过程中有电话进来的中断测试，与文件下载、音乐播放、等应用的交叉情况测试。

（8）、很多应用会支持缓存数据，测试在断网启动或从有网到无网时是否可以浏览缓存数据

3.5、安全性测试

a、软件权限 

          扣费风险：包括短信、拨打电话、连接网络等。 

          限制/允许使用手机拍照或录音

          限制/允许使用手机读取用户数据，手机信息、联系人信息等

          限制/允许使用手机写入用户数据 

         没有用户的允许, 应用程序不能预先设定自动启动。

          对App的输入有效性校验、认证、授权、数据加密等方面进行检测 

         没有用户的允许, 应用程序不能预先设定自动启动

         手机能控制该APP能否使用Wi-Fi和移动数据

b、数据安全性 

         如果数据库中重要的数据正要被重写，应及时告知用户。 

         在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作。 

         对密码长度和复杂度的要求，

         当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码。

         当应用程序处理信用卡明细或其它的敏感数据时，不以明文形式将数据写到其他单独的文件或者临时文件中

3.6、性能压力测试

（1）、APP端性能测试：在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应

（2）、Server端性能测试：通过测试接口的执行效率，如http接口

3.7、兼容性测试

（1）、与本机已经安装的App是否兼容

（2）、在各种系统、系统版本的不同手机上测试注册、登陆、修改密码等功能

  （3）、UI层的兼容，界面的显示根据不同尺寸手机是否自适应

（4）、在各种系统、系统版本的不同手机上进行全方面的功能测试，如使用每一个iOS版本的iPhone上测试“我的银行卡”模块的提现功能。

（5）、基于开发环境和生产环境的不同，检验在各种网络连接下(WiFi、2G/3G/4G等)，App的数据和运用是否正确