[学术/精华文章] 【转载】App测试经验分享

集成测试

按照模块上下集关系，进行从上到下或者从下到上的集成测试方法进行集成测试，单元测试与集成测试主要考虑功能性测试。同时也要对模个模块或者集成模块进行非功能性的抽样测试。

系统测试

对整合系统进行整合测试，这时的测试主要测试系统的整体功能和全部非功能性的需求。

测试的主要工作

测试人员的工作开展是在需求下发后，需求下发后，测试人员要先熟悉需求，根据需求设计文档设计相关的测试案例，测试案例需要覆盖所有业务场景，包括功能方面以及业务方面的。

测试案例设计

（1） 首先针对页面的功能设计功能测试案例，常见的方法有：等价类划分方法、边界值分析方法、错误推测方法、因果图方法、正交实验设计方法。

（2） 充分掌握业务知识，业务流程以及业务的数据流向。站在用户的角度思考，而不仅仅考虑在系统中如何操作业务流程；搞清楚每一项业务中的详细流程和各个环节涉及的角色，一项比较复杂的业务其详细流程往往比较多，只有了彻底掌握了这项业务，才能对当前业务环节进行全方位的测试，才能设计完整的测试案例。

（3） 从需求人员或者客户那里了解到各业务流程的重要程度和使用频率。（这点对把握测试重点很重要），设置好用例的优先级

（4） 了解业务流程在系统中对应的功能。（建立业务与系统的映射，为编写测试用例做好准备）

（5） 绘制业务流程图（对于较简单的流程，也可以用文字描述的形式，但流程图比较直观，也便于进行路径的分析）。

测试执行

测试过程中主要分成两种类型，一种是系统的功能性测试，一种是对需求实现的业务流程测试。

功能测试

（1） 页面链接检查，每一个链接是否有对应的界面

（2） 相关性检查，删除/增加一项会不会对其他项产生影响，如果产生影响，是否正确

（3） 检查按钮功能是否正确

（4） 字符串长度检查，输入超出需求所说明的字符串长度的内容，看系统是否检查，会不会出错。

（5） 字符类型检查

（6） 标点符号检查

（7） 中文字符处理，乱码或出错

（8） 检查带出信息的完整性，在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。

（9） 信息重复，在一些需要命名，且名字唯一的信息输入重复的名字或ID，看系统有没有处理，重名包括是否区分大小写，以及在输入内容的前后输入空格，看系统是否处理。

（10） 检查删除功能，在一些可删除多个的地方，不选任何内容按删除按钮看系统如何处理

（11） 选择一个或多个时又如何处理

（12） 检查添加修改是否一致，检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

（13） 检查修改重名，修改时把不能重名的项改为已存在的内容，看会否处理，报错，同时看会否报和自己重名的错。

（14） 重复提交表单，一条已成功提交的记录，back后在提交，看系统是否进行处理。

（15） 检查多次处理back键的情况

（16） Search检查:在有search功能的地方输入系统存在和不存在的内容，看结果是否正确；

（17） 如果可以输入多个search条件，同时可以添加合理和不合理的条件，看系统是否处理正确。

（18） 输入信息的位置，输入信息时，光标的位置

（19） 上传和下载文件的检查，上传下载的功能是否实现，上传文件是否能打开，上传文件的格式规定，系统是否有解释信息。

（20） 必填项检查，必填项是否有提示信息

（21） 快捷键检查，是否支持常用快捷键检查

（22） 回车键检查，在输入结束后直接按回车键，看系统处理如何，会否报错。

业务流程测试

业务流程测试是测试人员把系统各个模块连贯起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程。

业务流程测试过程中可以通过以下几点：

(1)站在用户的角度：优秀的需求应该是站在用户的角度来思考问题，是用户能够利用系统完成什么，而不是系统自己完成。因此在需求理解时要多和App的最终用户进行交流，了解他们的诉求，以便有针对性的进行测试。

(2)重视业务的连贯性，整个业务流程：尽可能全面的收集需求要点、了解整体的业务流程、分析主体业务流程和重点业务流程等，将整个业务流程全量进行测试。

(3)相关联业务测试：工作上业务实现过程中，有可能会影响到相关联的业务，在进行当前需求的业务流程测试时，需要对相关联的业务进行测试。

缺陷管理

App测试的主要目的在于发现App存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除App错误，保证要发布的App符合需求设计的目标。在实际App测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是App测试的重要环节。

Bug管理的流程

（1） 测试人员提交新的Bug入库，错误状态为New。

（2） 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。

（3） 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。

（4） 对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

（5） 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为

（6） Closed，如没有解决置状态为Reopen

转自：测试之道