测试设计开展流程

• 需求文档学习、输出问题确认列表、问题确认与汇总；
• 需求文档评审、开发讲解，测试提问、输出评审结论，归档；
• 制定测试设计计划、制定设计任务分配表；
• 启动设计输出思维导图、思维导图评审，汇总意见、输出修改后的思维导图；
• 评审启动后启动设计、输出测试用例初稿、启动测试用例评审、汇总评审意见、启动更新、第一次更新完成，再评审、汇总形成测试用例、归档，设计完成。

如何多方面考虑测试一个系统

---

用例设计原则：

• 按照测试类型分析法，按功能、压力、稳定性、性能、安全性、兼容性进行测试类型划分；
• 针对场景分析法，进行基于流程的功能遍历；
• 针对单个点，进行边界值，等价类相关测试点的考虑；
• 考虑流程中的异常操作；
• 考虑环境中可能出现的异常情况，如断开电源，断开网络，网络带宽被占用；
• 考虑其他设备对软件的影响；
• 考虑压力的积累，功能使用的稳定性；
• 考虑性能；
• 考虑存储空间即将满，已经满的情况下的数据处理；
• 考虑安装、卸载、升级、反复安装等实际使用场景中遇到的情况。

存在关联业务的测试点的考虑：

重点关注在当前业务走通的情况下，对其他相关联页面的影响，主要考虑如下几个方面：

• 当前业务正常走通，其他相关模块是否能正常显示对应数据；
• 当前业务执行过程中出现异常情况，对自身及其他模块数据的影响是否正常；
• 考虑积累作用：长时间，重复操作本模块，是否对其他模块的数据处理造成影响，相关模块数据处理是否正常；
• 几个模块共同作用，都发生数据变更，查看彼此间的影响是否正常，数据处理是否正确。

常用测试设计方法：

• 整体把握 【测试类型分析法】
• 单个功能点【测试类型分析法】【测试场景分析法】【模块关联】【等价类边界值分析法】
• 单个界面【测试类型分析法】【模块关联】【表间关联】【等价类边界值分析法】【不同出入口遍历】
• 单个输入框、选择框等【表间关联】【等价类边界值分析法】

测试类型分析法：将一个功能点按照不同的测试类型进行划分，针对每一个测试类型都进行测试点设计的分析方法。

举例说明：功能测试、性能测试、压力测试、可靠性测试、兼容性测试、安全性测试、容错测试；

功能测试常规测试点：

• 正常流程测试

　　　　　　基本流程测试

　　　　　　单个输入框测试【边界值、等价类划分】

　　　　　　多个关联输入框测试

　　　　　　关联表测试

　　　　　　实际使用场景测试

　　　　　　关联模块功能验证　

• 异常流程_外部环境异常测试

　　　　　　异常测试_使用过程中断开网络连接

　　　　　　异常测试_使用过程中断开电源重启

　　　　　　异常测试_使用过程中断开启占用资源的进程

　　　　　　异常测试_使用过程中杀死后台管理系统进程

　　　　　　内存占用高的情况下的功能验证

　　　　　　磁盘空间满的情况下的功能验证

• 异常流程_内部逻辑异常测试

　　　　　　填写不符合规范的数据，查看是否能正常处理

　　　　　　不符合关联模块的业务逻辑的操作，查看是否能正常处理

　　　　　　超出使用期限的日期，查看其它功能是否能正常使用

　　　　　　重复操作同一个步骤对系统的影响验证

• 外设影响测试：满配、容量满的情况下的功能验证

性能测试&压力测试&稳定性测试

• 长时间重复某一个功能，查看功能是否使用正常
• 不同时间间隔内进行某一个功能的测试，查看响应时间是否正常
• 在存储空间满，接近满的情况下，查看功能模块的处理是否正常
• 多次开关某一个功能，查看是否正常使用
• 多次插拔硬件，查看功能是否正常
• 长时间待机后进行相关操作，查看基本功能是否正常
• 长时间使用不同功能后进行相关操作，查看基本功能使用是否正常

---

 使用思维导图设计格式的原则

整体把握：使用【测试类型分析法】建立第一级目录。

单类型测试点：

• 首先以小的功能模块进行分级
• 小的功能模块里按照“执行成功”“执行失败”“关联性测试”“异常情况测试”等若干模块
• “执行成功”里面分为“一次执行成功”“多次执行成功”

最后一级描述规则

• 【测试点】+【测试步骤】+隔断符号+【预期结果】

　　“验证客户名称长度：点击进入客户信息新增界面，输入客户名称允许输入的最大长度，其他信息符合规范，点击保存。------对应客户信息能够正常保存，显示正常。”

严格控制思维导图横向层级：横向分级不宜过多。

最后一级测试描述颗粒度：一个用例永远只关注一个测试点，比如，关注一个输入框的输入内容的时候，就不考虑长度，不考了其他单元框对他的影响；

 

---

用例设计原则说明

• 单个功能的用例设计条数需要考虑其重要程度、重要性为高的功能，用例设计就相对完善，相对丰富些，重要性比较低的功能，用例设计的力度就小一些；
• 高优先级的用例多考虑正常流，少考虑异常流；
• 单条用例执行的步骤和预期结果的条数要控制，步骤太多的话，容易引起遗漏，一般不要超过3个步骤；
• 一个用例只有一个测试点

测试思维导图设计步骤

• 用例级别定义说明：
• LEVEL1：最常用操作、测试用例为正向反向的对应用例。40%  （反向用例即为系统不支持的输入或状态）
• LEVEL2：不太常用操作或者不太常用的比如边界值、冷僻输入的检查、不停点击按钮等类似的操作的对用用例；50%
• LEVEL3：操作方法比较复杂、测试环境比较生僻。且执行起来有较大难度的对应用例 10%

用例执行结果标注说明

• 通过：按照测试用例的操作步骤执行，实际执行结果与预期结果一致
• 失败：按照测试用例的操作步骤执行，实际执行结果与预期结果不一致，出现界面显示异常，处理异常，死机，功能失效等异常情况
• 跳过：由于测试环境或者其他外部条件的限制，导致用例无法执行，或者用例不适用，需要更新用例的情况
• 未实现：软件对应功能未实现，导致对应用例无法执行的情况
• 待确认：不确定测试结果的对错，还需要再确认的情况

用例执行说明

• 执行结果为失败的测试用例，需要提交bug跟踪，执行结果处附上bug ID
• 测试负责人在一轮版本测试完成后，要组织进行测试用例的活动分析，根据分析结果修改用例，保持用例的最新

测试用例更新及维护

• 根据需求输出的测试用例，一般在软件功能交付后，就会存在需求变更导致用例与系统功能实现对不上的情况，需要刷新用例
• 测试用例执行一遍后，发现问题的能力降低，缺陷有了免疫力，需要更新新的内容
• 客观承认测试用例设计的不全面性，只要是设计，就会存在遗漏，通过一段时间的测试加深理解后，可以更好的完善用例
• 对发现的问题进行分析，将之间测试设计遗漏点补充到测试用例中

用例维护的方式

• 根据刷新后的需求说明书，更新用例
• 根据提交给测试的软件版本具体实现，刷新用例
• 根据非通过的用例执行结果，进行分析后，更新用例
• 对版本发现的问题进行分析，找到测试设计的遗漏点，刷新用例
• 软件功能转测试后，出现变更，追加或删除，刷新用例
• 需要掌握深度加深后，发现测试设计遗漏点，刷新用例

用例维护时间

• 一般在全面用例执行后，进行用例的第一次刷新
• 每轮执行后，进行缺陷分析后的用例更新
• 测试执行完成后，规范化刷新后归档

用例维护的方式

• 由项目测试负责人进行用例的刷新的组织，组内人员协助刷新

漏测分析

• 一种质量改进活动，一般发生在第二轮以及之后的版本测试后，由测试负责人发起，其他人员配合开展的一个问题回溯，借以调查每轮问题出现的原因，是新引入，还是漏测，然后根据分析结果，进行相应改进的一种质量提升活动

漏测分析发起人：

　　由项目测试负责人进行漏测分析

漏测分析流程：

• 由项目测试负责人汇总输出当前版本发现问题列表
• 由本轮提单人员去上个版本验证，填写验证结
• 如果是测试人员遗漏，需对应上一轮的测试人员撰写漏测分析报告，如果是新引入，需要对应开发人员撰写问题引入报告原因
• 由QA组织回溯会议，对相关问题进行回溯，输出会议结论，形成改进意见
• 通知相关领域，相关改进意见的落实

---

测试过程

　　测试计划+测试设计+测试实现+测试执行

　　测试计划：完成系统测试计划

　　测试设计：完成系统测试方案

　　测试实现：完成系统测试用例和脚本，系统测试规程、系统测试预测试项

　　测试执行：执行测试用例，提交测试报告，发现问题提交缺陷

测试设计方法

• 等价类划分法：　从大量数据里划分范围，然后从每个范围中挑选代表数据，这些代表数据能反应这个范围内数据的测试结果，分为有效等价类和无效等价类，注意细化每个等价类。

  

  • 边界值分析法：选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。也就是边界值方法中常说的边界5点，即上点、内点和离点。

• 判定表法：列出所有的条件桩和动作桩；填入条件项；填入动作项，得到初始判定表；简化判定表（合并相似规则（相同动作））。

• 因果图法：

  1.分析软件规格说明书中哪些是原因，哪些是结果。原因是输入条件的等价类，结果是输出条件。 给每个原因和结果赋予一个标识符。

  2.画出因果图。分左右俩列，分别列出原因，结果。用一些记号表明约束关系或因果关系。

  3.把因果图转换成判定表。

  4.将判定表的每一列作为依据，设计测试用例。

• 状态迁移图法：

  1.分析需求，找到状态节点；

  2.画出状态迁移图；

  3.画出状态迁移树；

  4.转化为用例（找到状态迁移树的路径）。

• 流程分析法：

       1.  需要理解需求，分析业务流程，提炼出什么是基本、备选流、异常流；

        2.尝试画出流程图，图形化展示以上三类流程；

        3.根据流程图，分析各种不同的业务场景路径；

        4.编写测试用例。

• 正交试验法：？
• 输入域测试法

• 输出域覆盖法

• 异常分析法

• 错误猜测法

• 　白盒测试需要遵循的原则有： 1. 保证一个模块中的所有独立路径至少被测试一次；2. 所有逻辑值均需要测试真（true）和假（false）；两种情况；3. 检查程序的内部数据结构，保证其结构的有效性；4. 在上下边界及可操作范围内运行所有循环。

  白盒测试方法有： 静态测试&动态测试

  　　静态测试是不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。动态测试则需要执行代码，也是我们用的最多的一种测试，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

• 用例编号
• 测试点 用例描述 测试步骤 预期结果 环境图   用例级别
• 平台产品 备注 关键配置 用例执行时间 状态 创建人 修改人

参考:https://www.cnblogs.com/zhaoyujiao/p/7891617.html

文章目录

前言

性能测试流程

1． 制定目标和分析系统

2． 选择测试度量的方法

3． 学习的相关技术和工具

4． 制定评估标准

5． 设计测试用例

6． 运行测试用例

7． 分析测试结果

结束语

---

前言

        在每种不同的系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。不可能对每种技术都详细解说，这里只是介绍一种方法提供如何选择测试策略，从而帮助分析软件不同部分的性能指标，进而分析出整体架构的性能指标和性能瓶颈。

        不同公司流程规范不一样，众观全局看整体流程也不尽相同。

        由于工程和项目的不同，所选用的度量，评估方法也有不同之处。不过仍然有一些通用的步骤帮助完成一个性能测试项目。

---

性能测试流程

1． 制定目标和分析系统

        每一个性能测试计划中第一步都会制定目标和分析系统构成。只有明确目标和了解系统构成才会澄清测试范围，知道在测试中要掌握什么样的技术。

目标

1． 确定需求和期望

2． 实际业务需求

3． 系统需求

系统组成

        系统组成这里包含几方面含义：系统类别，系统构成，系统功能等。了解这些内容的本质其实是帮助我们明确测试的范围，选者适当的测试方法来进行测试。

系统类别：

        分清系统类别是我们掌握什么样的技术的前提，掌握相应技术做性能测试才可能成功。例如：系统类别是bs结构，需要掌握 http协议，java，html等技术。或者是cs结构，可能要了解操作系统，winsock，com等。所以甄别系统类别对于我们来说很重要。
 

系统构成：

        硬件设置，操作系统设置是性能测试的制约条件，一般性能测试都是利用测试工具模仿大量的实际用户操作，系统在超负荷情形下运作。不同的系统构成性能测试就会得到不同的结果。

系统功能：

        系统功能指系统提供的不同子系统，办公管理系统中的公文子系统，会议子系统等，系统功能是性能测试中要模拟的环节，了解这些是必要的

2． 选择测试度量的方法

        经过制定目标和分析系统，将会对系统有清醒的认识。软件度量软件度量软件度，收集系统相关的数据。

度量的相关方面：

        * 制定规范

        * 制定相关流程，角色，职责

        * 制定改进策略

        * 制定结果对比标准

3． 学习的相关技术和工具

        性能测试是通过工具，模拟大量用户操作，对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过winsock,http等协议记录用户操作。而协议选择是基于软件的系统架构实现（web一般选择http协议，cs选择winsock协议），不同的性能测试工具，脚本语言也不同。

        开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软件架构的性能测试工具。确定测试工具后，需要测试人员进行工具的学习，培训相关技术。

4． 制定评估标准

        任何测试的目的都是确保软件符合预先规定的目标和要求。性能测试也不例外。所以必须制定一套标准。

通常性能测试有四种模型技术可用于评估：

* 线性投射：

        用大量的过去的，扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况对比。

* 分析模型：

        用排队论公式和算法预测响应时间，利用描述工作量的数据和系统本质关联起来

* 模仿：

        模仿实际用户的使用方法测试你的系统

* 基准：

        定义测试和你最初的测试作为标准，利用它和所有后来进行的测试结果进行对比

5． 设计测试用例

        设计测试用例是在了解软件业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可能发现软件的性能瓶颈。

6． 运行测试用例

        通过性能测试工具运行测试用例。同一环境下作的性能测试得到的测试结果是不准确的，所以在运行这些测试用例的时候，需要用不同的测试环境，不同的机器配置上运行。

7． 分析测试结果

        运行测试用例后，收集相关信息，进行数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网络带宽，流量对用户操作响应的影响，而cs结构我们可能更关心会系统整体配置对用户操作的影响。

---

结束语

        学习，在多数时候，对于绝大多数同学来说，并不是一件快乐的事情，恰恰相反，是件非常艰苦乃至痛苦的事情！

        所以，如果你静不下那颗心，沉不住那口气，吃不得那份苦，耐不住那分寂寞，那么，你就永远不可能……

前言-----

对于测试流程基本很多做过测试的大牛，小哥哥，小姐姐都能说出个十之八九，但是对于细节，可能还需要一些整理文件，这不，我整理了一些测试的全部流程，希望能给大家带来帮助，有不妥的地方，请大家指正。

测试准备阶段

 一.测试需求文档

1. 产品需求文档、产品原型图、接口说明文档以及设计说明文档等应齐全

---重点：需求文档分析
 了解熟悉业务，分析需求测试点

（1）确认功能(业务功能，辅助功能，数据约束，易用性需求，编辑约束，参数需求，权限需求，性能约束）

（2）场景分析（考虑场景调用者和系统内部各个场景之间联系）

（3）挖掘隐性需求（常用业务流程以及各分支）

二.测试计划

1.编写目的
此文档根据项目需求文档，制定测试策略、评估测试风险，确定所需的资源，并对测试的工作量进行估计，进行人员和进度安排，并且列出测试项目的可交付元素。
2.参考文档
详细设计文档，设计原型
3.测试概要
（1）测试目标
通过测试，达到以下目标：
测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。
产品规定的操作和系统运行稳定。
Bug数和缺陷率控制在可接收的范围之内，遗留BUG一般不超过所有BUG的10%
（2）测试范围
列出测试最终需要交付的功能模块列表
（3）测试人力资源
（4）测试环境：服务器环境，终端环境，网络环境
（5）bug管理工具
4.测试规范
开始测试标准：代码编译通过，软件可以争取安装运行，实现功能与产品设计出人，冒烟测试通过
中断测试标准：安装无法正确完成，程序代码编译不通过，系统服务异常，发现阻塞功能的bug
5.bug规范
致命，严重，一般，建议
6.测试策略
冒烟测试：依据开发提测时间变动
第一轮功能测试：执行测试用例，包括边界值测试，兼容性测试，易用性测试，用户界面测试，安全性测试
第二轮功能测试：bug复测及功能验证
回归测试：全面回归测试
性能测试：需确认具体性能测试方案和工具
发布测试
测试报告总结
7.测试风险
测试本身（测试时间/测试技术/开发进度延误/难以修复缺陷/其它原因）
8.测试输出文档
测试计划
测试用例
测试bug单
测试报告

三.测试用例

测试需求分析和业务流程分析

1.设计方法：
等价类划分法（将测试的范围划分成几个互不相交的子集）
边界值分析法（选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值）
错误推测法（在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误）
判定表法（适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略）
正交实验法（在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例）
还有其它场景法和状态迁移法等

2.测试用例八要素：用例编号，测试项目，测试标题，重要级别，预置条件，测试输入，操作步骤，预期输出
（1） 用例编号（规则：由字符和数字组成的字符串，具有唯一性，易识别性）
（2） 测试项目（对应测试用例编号中的测试子项名 系统测试
（3） 测试标题（体现测试出发点关注点以及测试用例期盼的测试结果）
（4） 重要级别、优先级别（重要级别一般分为高中低 ）
（5） 预置条件：测试用例在执行时需要满足一些前提条件，环境的设置
（6） 测试输入（测试执行中需要加工的外部信息，避免用描述性语言，要具体，根据测试用例具体情况，有手工输入，文件，数据库记录）
（7） 操作步骤：执行当前用例需要经过的操作步骤，需要明确的给出每一个步骤的描述
（8） 预期输出：需要判断测试对象是否正常工作

测试阶段

一.测试执行

1.测试环境搭建
测试环境：硬件环境，软件环境
硬件环境：测试必须的服务器，客户端，网络连接设备，以及打印机/扫描仪等辅助硬件设备构成的环境
软件环境：被测软件运行的操作系统，数据库以及其它应用软件构成的环境
搭建测试环境的准备工作：
安装工具：虚拟机
虚拟机优点：运行在主机上

二.执行测试用例
根据测试用例优先级来执行测试用例

-----测试关注点

1. 根据UI效果图进行UI测试

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

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

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

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

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

2. 功能测试时主要依据编写的功能测试用例进行软件功能的测试

3. 涉及的测试主要包括基本功能测试，逻辑测试，安装、卸载、运行测试，中断测试，异常处理（包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理）测试

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

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

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

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

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

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

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

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

（9）、软件在不同操作系统及版本（Android、iOS、）下安装是否正常

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

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

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

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

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

（15）、重复安装应该有提示iOS没有提示

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

（17）、使用各种方式卸载程序，如直接删除安装文件夹卸载是否有提示信息、长按图标卸载、手机设置里卸载、第三方应用卸载iOS卸载没有提示，Android安装时会闪退（偶现）

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

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

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

4. 兼容性及适配测试

1. 硬件的适配：不同手机厂商、硬件性能，不同屏幕大小的适配；

如：

厂商：华为，型号：mate30Pro，Android版本：Android10，屏幕：6.0英寸，分辨率：2400x1176像素

厂商：苹果，型号：苹果XSmax,手机版本：iOS11，屏幕：6.0英寸，分辨率：2688x1224像素

（2） iOS版本的兼容：IOS 6版本以上；Andriod 5版本以上等

（3） 不同分辨率屏幕的适配：移动设备的分辨率多种多样，如果app没有做比较合适的处理就可能会显示不好，甚至影响功能的操作。

（4） 兼容性测试必须在一定数量的真机上进行，由于真机类型过多，尤其Android在做兼容性测试时，可以选取典型的几种运用较多的真机，进行兼容性测试

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

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

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

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

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

5. 安全性测试
1.软件权限 

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

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

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

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

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

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

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

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

2.数据安全性 

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

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

（3）对密码长度和复杂度的安全要求

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

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

6. 接口测试

（1）测试api网关接口是否请求正常

（2）Get,post发送和返回是否请求正常

（3）查看请求参数和返回参数结果是否正常

（测试接口工具：APIpost jmeter）

7. 性能测试

（1） 客户端性能测试重点关注：安装卸载时间、启动时间、页面加载时间、主要功能占用的CPU、内存、流量、耗电量等，以及与同类产品相比较是否有优势；

（2） 运行过程中主要功能占用的CPU、内存、流量等可以借助开源工具emmagee（适用于Android）获取到；

（4） 至于服务器端的性能，主要利用接口对服务器施加压力，重点关注响应时间、吞吐量、并发数、事物通过率等，可以用loadrunner、jmeter进行测试，也可以用fiddler Charles抓包来查看域名等是否正常。

8. 核心链路

-------核心链路测试

三.测试执行流程

冒烟测试-迭代测试（先功能后性能，回归测试）-发布测试
注：对应测试产出对应测试报告和bug清单，可以把bug提到缺陷管理库里
 

四.测试报告

测试结论（是否达到发布标准，是否可发布）
测试时间，测试人员（测试起止时间）
测试环境，测试设备（用到哪些测试收集，客户端环境，浏览器）
需求大纲（当前这个版本，包含哪些需求点）

测试用例报告（报告用例情况）
Bug数据分析（从多个维度分析：bug等级分布，遗留bug分析，bug类型分布。模块bug分布，bug激活次数分析）

已知风险、未知风险
测试总结（从测试角度，对版本存在的问题，提出建议）

线上阶段

        

 一.线上测试注意事项

1.如果没有白名单，这个时候是不能随便操作做数据的，测试人员能做的也就是点点，保证按钮、界面正常。如果是业务人员做好数据，测试人员要验证数据的准确性和界面显示无误。
2.如果有白名单，也不能随便操作数据，但是可以在容许的情况下，回归一遍线上测试，保证线上测试无误。

 二.后期维护

1.日常关注客诉和相关反馈，如果有线上bug，可以通过日志，后台奔溃记录来定位问题，之后商讨出修复策略

2.整理该项目测试总结

（1）整理该项目遗留，可推广等问题

（2）项目流程优化及功能优化等文档整理

（3）整理该项目相关文档并总结报告