测试工作中发现一个bug，而开发人员说不是一个bug，你该怎么处理？
先将问题暂提缺陷库。再确认判断依据和标准(根据需求说明书、产品说明书、设计文档等、确认实际结果是否与需求计划有不一致的地方,如果文档数据不充足，可以从竞品分析或者用户使用习惯来确认),如果必要的话，进行会议评审；向开发说明自己判断的理由，注意客观严谨，对事不对人。
说法一：1、首先明确开发说不是bug的理由。2、如果是需求变更， 那就找产品经理确认是否是需求变更。3、如果开发说测试环境问题， 让他说明清楚测试环境问题是什么，按照他说的验证一遍， 如果确实如他所说， 关闭bug，但是不是他说的那样，继续激活bug给开发解决，确保产品质量。4、如果开发说用户不存在这种使用场景， 但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理去判定。说法二：1.告知开发bug的判断依据，同时明确开发说不是bug的理由。2.对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量
一、软件测试概念
A.1 经典定义
软件测试(Software Testing)，在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
A.2 标准定义(IEEE)
软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
A.3 测试目的
软件测试的目的是发现问题，发现至今未发现的问题。检查系统是否满足需求。
Grenford J.Myers观点
（1）测试是程序的执行过程，目的在于发现错误；
（2）一个好的测试用例在于能发现至今未发现的错误；
（3）一个成功的测试是发现了至今未发现的错误的测试；
A.4 测试的对象
程序、数据、文档。
A.5 软件错误占比
据业界著名的统计公司的统计表明，属于需求分析和软件设计错误的约占64%，属于程序编写错误的仅占36％。
A.6 其他基础知识
V模型
RAD（Rap Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型，V模型大体可以划分为以下几个不同的阶段步骤：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。
测试流程及规范
一 目标
结合公司的项目情况制定合理的测试流程，提高测试效率和产品质量。核心还是要加强项目成员之间的沟通，弱化文档。
二 测试流程说明
三 测试流程
需求评审（可选）
参与人员：开发，测试，设计，产品
并不是所有的项目都要进行需求评审，可对适当的需求进行合适的需求评审。
需求评审过程中，开发从技术角度来分析实现方案，实现难易程度。设计从交互角度给出适当的建议，有没有不合理的交互流程，是否存在可优化的地方？测试从用户角度来给出产品逻辑上是否存在不合理的建议。
在需求评审的结束之后，明确相关人员的职责，评估设计，开发，测试周期，制定项目计划
项目计划内容：项目成员职责，项目进度计划
输出：项目计划，功能列表
测试计划
根据项目计划及开发人员工期安排，制定测试计划。
测试计划内容：
引言：目的、背景、范围、定义
测试内容：测试功能清单
测试规则：通用规则，测试方法、测试要点、测试工具
测试环境：硬件环境、软件环境、特定测试环境要求
项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结
文档输出：测试计划
测试人员根据需求设计编写测试用例
用例管理用工具：
1） Excel：便于编写和维护，工作效率高。不便于管理
2） 华为云：编写不方便，便于管理
文档输出：测试用例
用例评审（可选）
参与人员：项目成员全部参与（产品，开发，测试）
目的：确认细节规则和测试结果的准确性，避免功能点遗漏
根据项目大小或项目时间决定是否需要进行用例评审，可通过邮件发送，或者开评审会。
开发人员开发完成后进行自测，自测通过后提交测试版本给测试人员，并提供测试环境。
版本控制：一轮测试结束后，开发人员将bug修复后提交新的版本给测试人员。
输出：接口文档，测试环境，测试数据
测试人员执行测试用例，提交缺陷，跟踪缺陷至缺陷关闭
测试内容：
1）功能测试（app，后台）,核心业务流程，功能完整性，需求覆盖性，体验性能。
2）兼容性测试，多个测试平台覆盖多机型。
3）接口测试，权限处理，状态约束，关系约束
4）性能测试，压力测试，并发测试
5）系统测试，上线
测试工具：
1） 兼容性测试：免费测试平台
2） 接口测试：
a）fiddler(抓包工具，可模拟弱网测试，打断点)
b）Postman，接口测试
c）jmeter（接口测试,可以做压力测试，并发测试）
文档输出：缺陷记录，测试数据
缺陷管理：
缺陷流程：
缺陷管理工具：华为云-缺陷管理
Bug内容：编号，功能模块，缺陷描述，截图，优先级，严重程度，版本号，处理人，状态，开始时间，结束时间，环境（线上，测试）
缺陷状态：新建，已处理，已拒绝，已解决，已关闭，延迟处理，重复缺陷
缺陷处理流程：
1） 开发认为是缺陷的处理
测试人员发现并提交缺陷，由开发人员进行处理，开发人员修改了这个缺陷就会将这个缺陷的状态置为已解决状态让测试人员进行验证。测试人员对这个已修复的缺陷进行回归测试，如果回归测试通过，则将缺陷状态置为已关闭，如果回归测试没有通过，则将缺陷状态置为新建状态等待开发再次修复，直到修复成功。
2）开发认为不是缺陷的处理
测试人员发现并提交缺陷，由开发人员进行处理。但是开发人员认为不是缺陷，则将该缺陷的状态置为已拒绝状态并提交回测试人员，可简单描述拒绝原因。测试人员如果认为确实误报了缺陷，则直接关闭，如果经过测试、开发沟通认为是bug，则测试人员重新打开（新建）让开发人员继续修改，开发人员修复这个缺陷置为已解决，提交给到测试人员进行回归测试，直到回归测试通过为止。
开发认为重复缺陷的处理
测试人员发现并提交缺陷，由开发人员进行处理。但是开发人员认为是重复缺陷，则将该缺陷状态置为重复缺陷，测试人员一定要确认该缺陷是否确实重复，如果确实是同一个缺陷，则将重复的缺陷直接关闭。如果不是同一个缺陷，则重新打开该缺陷，继续跟踪。
延迟缺陷的处理
测试人员发现并提交缺陷，由开发人员进行处理。但是因为项目和时间等因素，某些缺陷无法在项目周期内完成，则需要进行延迟处理（备注：延迟处理的缺陷本身被确定为有效缺陷），对于延迟的缺陷需要经过开发、测试、项目经理、客户代表共同认可方可延迟。对于延迟的缺陷，置状态为延迟处理。到了下一个版本，测试人员就应该把所有延迟处理状态的缺陷重新置为新建状态，让开发人员继续修复。
6，测试结束—测试报告
经过两到三轮或四轮的测试后，直到没发现新的问题。或暂时无法解决，或不紧急的问题，跟项目负责人确认后，可以通过。
测试报告内容（重点）：
1） 测试项目的版本，测试项目内容的概述
2） 测试用例的执行情况
3） 测试结果的统计：总bug数，bug级别分类统计，已解决数，遗留数。
4） 测试评估：基于软件缺陷的质量评估，写明在当前版本，已实现的功能和未实现的功能。
上线后的线上测试
上线后，为避免因环境因素产生的一些问题，可视情况进行通测或者关联功能测试
软件测试分类
1、按开发阶段：单元测试、集成测试、系统测试、验收测试
2、按测试实施组织：α、β、第三方
3、按测试执行方式：静态测试、动态测试
4、按是否查看代码：黑盒测试、白盒测试、灰盒测试
5、按是否手工执行划分：手工测试、自动化测试
6、按测试对象划分：性能测试、安全测试、兼容性测试、文档测试、易用性测试（用户体验测试）、业务测试、界面测试、安装测试
7、按测试地域划分：本地化测试、国际化测试
1）单元测试
单元测试是对软件组成进行的测试。其目的是检验软件基本组成单位的正确性。测试对象是软件设计的最小单元：模块，又称为模块测试。
测试阶段：编码后或者编码前（TDD）
测试对象：最小模块
测试人员：白盒测试工程师或开发人员
测试依据：代码和注释+设计详细文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
单元测试是白盒测试，但是白盒测试不是单元测试
2）集成测试
集成测试（也成联合测试，联调）、组装测试，将程序模块采用适当的集成策略组装起来，
测试阶段：一般的单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试模块+概要设计文档
测试方法：黑盒测试和白盒测试相互结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能的正确性、全局数据结构、单模块缺陷对系统的影响。
3）系统测试
将软件系统看成一个系统测试。包括对功能、性能以及软件所运行的硬软件环境进行测试。时间大部分在系统测试执行阶段，，包括了回归测试和冒烟测试
测试阶段：集成测试之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全等
回归测试（Regression Tesing）
回归测试指的就是你修改了旧的代码之后。重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误，自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
在整个软件的过程中占有很大的工作量比重，软件开发的各个阶段都会运行多次回归测试。
冒烟测试（Regression Tesing）
对一个硬件或硬件组件进行更改或修复后，直接给设备加电，如果没有冒烟就认为该组件通过了测试，
冒烟测试的对象都是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，可以进行后续的测试工作，冒烟测试的执行者是版本编译人员。
冒烟测试一般是开发人员开发完毕之后送给测试人员进行测试时，测试人员要先进行冒烟，用以保证基本功能是正确的，不会阻碍后续的测试。
4）验收测试
验收测试是部署软件之前的最后一个测试操作，它是技术测试室的最后一个阶段，也叫做交付测试，验收测试的目的是保证软件的准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件的购买者展示该软件的原始的需求。
测试阶段：系统测试之后
测试对象：整个的系统（包括软硬件）
测试人员：最终的用户或者需求方
测试依据：用户需求和验收标准
测试方法：黑盒测试
测试内容：同系统测试一样（功能。。。。文档等）
三、测试实施组织
1）α测试
主要是由一个用户在开发环境进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
主要的目的是：评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）；
预发布环：和生产环境是一样的，由本项目以外的研发和测试人员进行的测试、公司内部的客户不参与，项目以外的人员都可以进行与
2）β测试
β测试：由软件的最终的用户们在一个或者多个客户场所进行的测试。
α测试和β测试的区别：
测试的场所是不同的：α测试是把用户请到开发方的场所进行的测试，β测试值的是就是在一个用户或者多个用户场所所进行的测试。
α测试的测试环境是由开发方进行控制的，用户的数量是相对比较少的，时间也是相对比较集中的。β测试的测试场所也不是由开发方进行控制的，相对来说用户的数量是相对比较多的，但是时间也不是很集中的。
α测试是先与β测试的，通用的软件产品时需要大规模的β测试，猜测是的周期是相对是比较长的。
第三方测试;
介于开发方和用户之间的组织测试。
四、按是否运行进行划分
静态测试:
静态测试值的是不运行程序本身，仅通过分析和检查源程序的语法、结构、过程、接口来检查程序的正确性。对需求规格说明书、软件设计说明书、流程图分析、符号执行来进行找错。
检查项：代码的风格和规则审核；程序设计和结构审核；业务逻辑的审核、走查、审查与技术复审手册
静态质量：软件的质量主要有以下六个方面来衡量：功能性、可靠性、可移植性、可用性、有效性、可维护性。
代码静态分析和文档测试都是属于静态测试
动态测试
动态测试指的就是运行被测的程序。检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性的等性能，这种方法主要是由三部分进行组成的：测试用例、执行程序、分析程序运行输出的结果。
大多数的软件测试就是属于动态测试的。
五、按是否进行手工
手工测试：是由人一个一个的输入测试用例，然后观察结果、和机器测试相对应，属于比较原始，大事需要一个一个步骤进行测试。
优点：自动化无法替代探索性测试、发散思维类无既定结果的测试。
缺点：执行的效率比较慢。量大易错。
自动化测试
在预设条件下运行系统或应用程序，评估运行结果、预先条件应该包括正常的条件和异常条件。简单的说自动化测试是把人为驱动的测试行为转化为机器执行的一种过程。
自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化
通常我们所说的自动化测试就是指的是功能自动化测试
自动化测试按照测试的对象来分：分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。
自动化实施的步骤
1、完成功能测试，版本基本稳定
2、根据项目特性、选择合适的项目自动化工具，并搭建环境
3、提取手工测试的测试用例转化为自动化测试的用例
4、通过工具，代码实现自动化的构造输入，自动检测输出结果是否符合预期
5、生成自动化的构造输入，自动的检测世界古是否符合预期
6、生成自动测试报告
7、持续改进、脚本优化
六、按是否查看代码
1）黑盒测试（Black-box-Testing）
黑盒测试也称为功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，指关心软件的输入数据和输出数据。
2）白盒测试（White-box-Testing）
白盒测试又称结构测试，透明盒测试、逻辑驱动测试或基于代码的测试。白盒值的是打开的盒子，去研究里面的源代码和程序结果。
接口测试也是一种白盒测试。
3）灰盒测试（White-box-Testing）
灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，主要用于集成测试阶段。不仅观念朱输入输出的正确性。同时也关注程序内部的情况。
七、按照地域进行划分
1）国际化测试（White-box-Testing）
软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是这类软件产品进行测试。由于软件的全球普及。还有软外包行业的兴起，软件的本地化和软件的国际化俨然称为了一种软件测试的专门领域。
本地化和国际化的软件测试的一些测试要点。
1、本地化后的软件在外观上与原来版本存在着一些差异，外观是否整齐、不定样。
2、是否对界面元素进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示、日志等）。
3、在不同分辨率界面下是否显示的是正常的。
4、是否存在不同的字体的大小，字体设置的是否恰当。
5、日期、数字格式、货币等是否能够适应不同的国家的文化习俗。例如年、月、日，而英文是月日年。
6、排序的方式是否考虑到了不同语言的特点。
7、在不同个的国家采用的是不同的度量单位，软件是否能够自适应和转换。
8、软件是否能够在不同类型的硬件上正常运行。正文翻译是否正确，恰当是否有语法的错误。
9、软件是否能够适应不同的操作系统的平台。
10、联机帮助和文档是否已经进行翻译，翻译后链接是否正常。正文翻译是否正确，恰当是否有语法的错误。
本地化测试
之前所有我们将的都是基于本地化进行测试的。
测试对象划分
1）业务测试
是测试人员将系统的各个模块串接起来运行、模拟真是用户实际的工作流程，满足永续需求定义的功能进行测试的过程。
2）界面测试
界面测试也成为UI测试。测试用户界面的功能模块的布局是否合理，整体风格是否一致、各个控件的放置位置是否符合客户的使用习惯，还要测试操作界面操作便捷性、导航简单易懂性、页面元素的可用性，页面元素的可用性、界面中文字是否正确，命名是否统一，页面是否美观、文字、图片组合是否完美。
3）容错性测试
容错性测试：检查软件在异常条件下自身是否具有防护性的措施或密谋中灾难性恢复的手段
划分为容错性测试和非容错性的测试。
4）文档测试
文档测试的关注点
文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性
5）兼容性测试
兼容线性主要指的就是软件之间很好的运作，会不会有影响、软件和硬件之间是否能够发挥很好的效率工作，会不会影响导致系统的奔溃
6）平台测试
7）浏览器测试
8）易用性测试
易用性指的即使我们对于平时所使用的东西是否放在了合适的位置在我们是用的时候能够进行很好的找到。满足人体天生的人体工程学的范畴。
9）安装测试
测试程序的安装、卸载
典型的就是测试APP的测试的安装和卸载
10）安全测试
安全测试是一个相当于来说独立的领域，需更多的专业知识，例如Web的安全测试、需要熟悉各种网络协议，Tcp/Http,防火墙、CDN、熟悉各种操作系统的漏洞。 熟悉路由器等。从软件来说熟悉各种的攻击手段，例如sql注入、Xss等。
11）性能测试
检查系统是否满足需求规格说明书中规定的性能
通常表现在以下的几个方面
- 对资源的利用（如内存、处理机周期等）进行精确地度量。
- 对执行间隔、日志文件（如中断、报错）
- 响应时间
- 吞吐量（TPS）
- 辅助存储区（例如缓冲区、工作区的大小）
-处理精度等进行检测
12）内存泄漏测试
造成内存泄漏的原因
内存分配完了忘记进行了回收
程序写法有问题
某些API函数的使用不正确，造成内存泄漏
没有及时的进行释放
测试分类占比
软件测试的原则
1. 所有测试的标准都是建立在用户需求之上。正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的
角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些，导致程序无法满足用户需求的缺陷有那些。
2. 必须基于 “ 质量第一 ” 的思想去开展各项软件测试工作，当时间和质量冲突时，时间要服从质量。强烈质量的意识、理念和文化（如零缺陷、足够好的目标）同样是软件测试工作的基础。
3. 事先定义好产品的质量标准。有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。同样，功能及其它测试也应该事先定义好标准，包括测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
4. 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。这个观念现在越来越受重视了，在代码完成之前，测试人员要参与需求分析、系统或程序设计的审查工作，而且要准备测试计划、测试用例、测试脚本和测试环境，测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作为测试人员的座右铭。
5. 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，包括业务逻辑、数据流程逻辑等，并确保程序设计中使用的所有条件是有可能的。
6. 第三方进行测试会更客观，更有效。程序员应避免测试自己的程序，为达到最佳的效果，应由第三方来进行测试。测试是带有 ”挑剔性” 的行为，心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。 要做出“经得起考验和测试的产品”。
7. 软件测试计划是做好软件测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。 有效的测试策略和明确的测试目标。
8. 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。 要知道好的测试用例真的会有效且事半功倍。
9. 不可将测试用例置之度外，排除随意性。特别是对于做了修改之后的程序进行重新测试时，如不严格执行测试用例，将有可能忽略由修改错误而引起的大量的新错误。所以，回归测试的关联性也应引起充分的注意，有相当一部分最终发现的错误是在早期测试结果中遗漏的。 其它所有工作都应该避免随意性。
10. 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。越需要深入和多次测试。
在实际的测试中时刻牵记这些基本原则，不仅会让工作更充分，而且会让工作越来越轻松，关键是有效果。所以让我们做有“原则性”的测试工作吧！
一、如果给你一台电梯，请问你如何测试它，分析如下
1.功能：上升、下降、停止、开门、关门、梯内电话、灯光、指示灯等；
2.性能：速度、反应时间、关门时间等；
3.压力：超载、尖锐物碰撞电梯壁等；
4.安全：停电、报警装置、轿箱停靠位置、有人扒门时的情况等；
5.可用性：按键高度、操作是否方便、舒适程度等；
6.UI：美观程度、光滑程度、形状、质感等；
7.稳定性：长时间运行情况等；
8.兼容性：不同电压是否可工作、不同类型电话是否可安装等。
其实在简单分析的过程中，发现许多东西根本测试不全，比如电话、灯光、材质、调度程序、可维修性等，当发现在一个用例中无法说清楚时，这些应该拆分开来分别测试。可以告诉主考官，你需要模块化地测试电话、灯光等。再有在一起的组装测试。
二、下面是详细的测试点：
需求测试： 查看电梯使用说明书、安全说明书等
界面测试： 查看电梯外观
功能测试：
1.测试电梯能否实现正常的上升和下降功能。
2.电梯的按钮是否都可以使用。
3.电梯门的打开，关闭是否正常。
4.报警装置是否可用。
5.与其他电梯之间是否协作良好。
6.通风状况如何。
7.突然停电时的情况。
8.上升途中的响应。
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来；
2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
9.是否有手机信号
可靠性：
1.门关上的一刹那出现障碍物。
2.同时按关门和开门按钮。
3.点击当前楼层号码
4.多次点击同一楼层号码
5.同时按上键和下键
易用性：
电梯的按钮的设计符合一般人的习惯吗
用户文档：
使用手册是否对电梯的用法、限制、使用条件等有详细的描述
压力测试：
1.看电梯的最大承重量，在负载过重时报警装置是否有提醒
2.在一定时间内不断让电梯上升、下降
稳定性测试：
看电梯在最大负载下平稳运行的最长时间
微信发红包-测试用例
功能
1.在红包钱数，和红包个数的输入框中只能输入数字
2.红包里最多和最少可以输入的钱数 200 0.01
3.拼手气红包最多可以发多少个红包 100
3.1超过最大拼手气红包的个数是否有提醒
4.当红包钱数超过最大范围是不是有对应的提示
5.当发送的红包个数超过最大范围是不是有提示
6.当余额不足时，红包发送失败
7.在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，
7.1是否可以输入它们的混合搭配
8.输入红包钱数是不是只能输入数字
9.红包描述里许多能有多少个字符 10个
10.红包描述，金额，红包个数框里是否支持复制粘贴操作
12.红包描述里的表情可以删除
13.发送的红包别人是否可以领取
13.1发的红包自己可不可以领取 2人
14. 24小时内没有领取的红包是否可以退回到原来的账户
14.1 超过24小时没有领取的红包，是否还可以领取
15.用户是否可以多次抢一个红包
16.发红包的人是否还可以抢红包 多人
17.红包的金额里的小数位数是否有限制
18.可以按返回键，取消发红包
19. 断网时，无法抢红包
20.可不可以自己选择支付方式
21.余额不足时，会不会自动匹配支付方式
22.在发红包界面能否看到以前的收发红包的记录
23.红包记录里的信息与实际收发红包记录是否匹配
24.支付时可以密码支付也可以指纹支付
25.如果直接输入小数点，那么小数点之前应该有个0
26.支付成功后，退回聊天界面
27.发红包金额和收到的红包金额应该匹配
28.是否可以连续多次发红包
29.输入钱数为0，"塞钱进红包"置灰
性能
1.弱网时抢红包，发红包时间
2.不同网速时抢红包，发红包的时间
3.发红包和收红包成功后的跳转时间
4.收发红包的耗电量
5.退款到账的时间
兼容
1.苹果，安卓是否都可以发送红包
2.电脑端可以抢微信红包
界面
1.发红包界面没有错别字
2.抢完红包界面没有错别字
3.发红包和收红包界面排版合理，
4.发红包和收到红包界面颜色搭配合理
安全
1.对方微信号异地登录，是否会有提醒 2人
2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加
3.发送红包失败，余额和银行卡里的钱数不会少
4.红包发送成功，是否会收到微信支付的通知
易用性(有点重复)
1.红包描述，可以通过语音输入
2.可以指纹支付也可以密码支付