http://www.jackxiang.com/index.php zh-cn http://www.jackxiang.com/post/10753/ jack <xdy108@126.com> Mon, 09 Nov 2020 00:41:37 +0000 http://www.jackxiang.com/post/10753/ 一  手机APP测试前的准备：
手机APP测试，主要针对的是android和ios两大主流操作系统，主要考虑的就是功能性、兼容性、稳定性、易用性（也就是人机交互）、性能。
测试前的准备：1.使用同类型的产品，不仅仅是使用，应该是测试同类型的产品。2.熟悉我们产品的spec文档，积极和pm交流。3，写测试用例，没有时间至少要有一个checklist。
二  手机APP测试测试要点：
功能测试（流程测试、功能点测试）、兼容性测试、交叉测试、安装卸载测试（包括应用的升级）、压力测试（接口压力测试）；
功能测试：对具体功能点一一测试，确保每个点都能正确实现相应功能；功能方面目前市场上还没达到自动化的水平，主要用手工来测。出现问题最多的也就是特殊符号、边界值、按钮之类的。基本功能，主要指app是否完成了设计的所有功能。分清模块，写一份checklist，避免漏测。考虑横竖屏切换，不过很多app现在只支持竖屏。
兼容性测试：对市场上主流的设备安装应用执行测试，确保都能正常运行；兼容性方面考虑手机的版本、型号、分辨率。不同的版本是存在差异的，一般低版本容易出现问题。
稳定性测试：主要是闪退、系统崩溃、没响应之类的。
    易用性测试：需要考虑界面是否吸引人、容易理解、界面整洁、简单、无错别字。点击范围确定等。这部分测试中，如果测试认为有不合理的地方通常会提交需求bug。
    性能测试：主要是靠工具来实现的CPU占用、内存占用、电池温度等。
交叉测试：对于正在运行的应用，若进入短信、电话等其他软件响应的情况，不会影响所测试应用，且会保证应用都能正确运行；主要考虑范围包括电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等。
安装卸载测试：确保应用都能正确安装、卸载，且能正确运行（注意应用的升级测试：升级前后的状态）；
压力测试：用户量大，交互性高的应用需对接口执行压力测试，确保不会应用在大用户量的情况下能正常运行。
外场：网络切换，网络信号强和弱情况下的app运行情况。

三  注意事项：
闪退（内存不足等情况），在手机上，该类问题出现的几率很大，应着重测试，比如，返回访问某个模块(数据时时获取的模块)，切换应用，重复提交、来电交互等都是闪退几率大的原因。
以下是功能测试时需要注意的点：
　　1、登录
　　●登录用户名和密码错误时，界面有提示信息
　　●用户主动退出登录后，下次启动APP时，应该进入登录界面
　　●对于支持自动登录的APP，数据交换时，是否能自动登录成功且数据库操作无误
　　●密码更改后，登录时是否做到了有效数据的校验
　　●对于未登录时一些页面的操作，是否做了控制
　　●切换账号登录，检验登录的信息是否做到及时更新
　　●对于多个端都进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新
　　●对于一些软件，支持一个账号只允许登录一台机器，这时，需要检查账号登录多个手机时，是否将原用户剔除，且能够给出提示信息
　　● APP切换到后台时，再次切换到前台的测试，如登录时，有电话打进来
　　2、离线
　　离线是应用程序在本地的客户端会缓存一部分数据以功程序下次调用
　　●对于一些程序，需要在登录进来后，这时没有网络的情况下可以浏览本地数据
　　●对于无网络时，刷新获取新数据时，不能获取数据且能给出友好提示
　　●切换到后台，再次切换到前台时，可以正常查看
　　●离线后又连上网，这时对数据有更新时，需要从服务器端获取新数据来更新客户端数据，且要更新本地缓存信息
　　●对于一些界面的数据不提供离线查看，需要给出相应提示且界面更新后无任何数据
　　3、数据库
　　android和IOS客户端都采用了数据库，
当APP需要在客户端保存数据时，它们会创建相应的数据库表，最常见的就是对账号的保存，这时的测试点主要有：
　　●跟一般数据库一样，需要检查数据的增，删，改，查
　　●客户端即用即建，当表不存在时，是否会自动创建
　　●数据表被删除后，新建的表中的数据能否自动从服务器端中获取回来并保存
　　●当对数据进行了修改，删除，客户端和服务器端能否有相应的更新
　　●获取数据，客户端是从直接从客户端获取还是和服务器端的数据进行比较
　　●对于客户端从服务器端更新的数据，客户端是否有保存于本地。

来自：https://blog.51cto.com/jjwenle/2437444 ]]> http://www.jackxiang.com/post/10548/ jack <xdy108@126.com> Thu, 14 May 2020 00:52:20 +0000 http://www.jackxiang.com/post/10548/
不管是手动发送 HTTP 请求或是使用 Swagger 客户端，相关的测试用例都需要由测试人员来编写。当应用的业务逻辑比较复杂时，测试人员可能需要了解很多的业务知识，才能编写出正确的测试用例。以保险业务为例，一个理赔申请能否被批准，背后有复杂的业务逻辑来确定。这样的测试用例，如果由测试人员来编写，则可能的结果是测试用例所验证的情况，从业务逻辑上来说是错误的，起不到测试的效果。

更好的做法是由业务人员来编写测试用例，这样可以保证应用的实际行为，满足真实业务的期望。但是业务人员并不懂得编写代码。为了解决这个问题， 我们需要让业务人员以他们所能理解的方式来描述对不同行为的期望，这就是行为驱动开发（Behaviour Driven Development，BDD）的思想。

BDD 的出发点是提供了一种自然语言的方式来描述应用的行为，对行为的描述由 3 个部分组成，分别是前置条件、动作和期望结果，也就是 Given-When-Then 结构，该结构表达的是当对象处于某个状态中时，如果执行该对象的某个动作，所应该产生的结果是什么。比如，对于一个数据结构中常用的栈对象来说，在栈为空的前提下，如果执行栈的弹出动作，那么应该抛出异常；在栈不为空的前提下，如果执行栈的弹出动作，那么返回值应该是栈顶的元素。这样的行为描述，可以很容易转换成测试用例，来验证对象的实际行为。

BDD 一般使用自然语言来描述行为，业务人员使用自然语言来描述行为，形成 BDD 文档，这个文档是业务知识的具体化。我们只需要把这个文档转换成可执行的测试用例，就可以验证代码实现是否满足业务的需求。这个转换的过程需要工具的支持，本课时介绍的工具是 Cucumber。

Cucumber 使用名为 Gherkin 的语言来描述行为，Gherkin 语言使用半结构化的形式。下表给出了 Gherkin 语言中的常用结构。
清单表格：

]]>