软件测试的目的：
通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。
软件测试的原则：
1.证明软件存在缺陷；
2.不能执行穷尽测试；
3.缺陷存在群集现象；
4.某些测试需要依赖特殊的环境；
5.测试应尽早介入；
6.杀虫剂现象。
1.尽可能早的找出系统中的bug；
2.避免软件开发过程中缺陷的出现；
3.衡量软件的品质，保证系统的质量；
4.关注用户的需求，并保证系统符合用户需求。
总的目标是：确保软件的质量
目的：主要是为了展开测试用例评审工作提供指引，规范测试用例管理工作。
流程：
1.测试用例是否按照公司定义的模板进行编写的；
2.测试用例的本身的描述是否清晰，是否存在二义性；
3.测试用例内容是否正确，是否与需求目标相一致；
4.测试用例的期望结果是否确定、唯一的；
5. *** 作步骤应与描述是否相一致；
6.测试用例是否覆盖了所有的需求；
7.测试设计是否存在冗余性；
8.测试用例是否具有可执行性；
9.是否从用户层面来设计用户使用场景和业务流程的测试用例；
10.场景测试用例是否覆盖最负载的业务流程；
11.用例设计是否包含了正面、反面的用例；
12.对于由系统自动生成的输出项是否注明了生成规则；
13.用例应包含对中间和后台数据的检查；
14.测试用例应有正确的名称和编号；
15.测试用例应标注有执行的优先级；
16.测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等；
17.每个测试用例步骤应<=15 step；
18.自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结果等）；
19.非功能测试需求或不可测试需求是否在用例中列出并说明。
和bug产生对应的软件版本；
开发的接口人员；
bug的优先级；
bug的严重程度；
bug可能属于的模块，如果不能确定，可以找开发人员来判断；
bug标题，需要清晰的描述现象；
bug描述，需要尽量给出bug的步骤；
bug附件中能给出相关的日志和截图。
1.首先考虑环境问题，看是否能够还原原来的环境；
2.遇到问题就要提，不能放过任何一个bug，在提交的bug描述中加上一句话，那就是复现概率，交给开发，开发会根据bug的复现概率，调整bug的优先级；
3.尽量回想发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤尝试复现；
4.与开发人员配合，让开发人员对相应的代码检查，看是否通过代码层面检查出问题；
5.保留发生bug时的log，附加到提交的bug中，希望可以通过log中找到一些蛛丝马迹；
6.查看代码，也许是代码变更引起的bug。
http协议又叫做超文本传输协议，在做网络请求的时候，我们基本上是使用http协议。
请求方式包括get请求和post请求。
http协议与https协议的区别：
1.http协议需要ca申请证书，一般免费证书较少，需要一定费用。
2.http的链接简单，是无状态的，而https协议是由SSL+http洗衣构建的可进行加密传输，身份认证的网络协议要比http协议安全。
3.http协议是超文本协议，又叫明码传输，而https是具有安全性的SSL加密传输协议。
4.http协议与https协议使用的链接方式不同，http用的端口是80，https用的端口是443。
get请求使用URL或cookie传参，而post将数据放到body中；
get的URL会有长度上的限制，而post的数据则可以非常大；
post比get安全，因为数据在地址栏上不可见；
一般get请求用来获取数据，post请求用来发送数据。
重载是定义相同的方法名，参数不同，重写是子类重写父类的方法；
重载是在一个类中，重写是在子类与父类之间；
重载是编译时的多态性，重写是运行时的多态性。
相同点：
同样的测试用例设计方法；
同样的测试方法：都会依据原型图来检查UI；
测试页面载入和翻页的速度、登陆时长、内存是否溢出等；
测试应用系统的稳定性。
不同点：
App的中断测试：来电中断、短信中断、蓝牙中断、闹钟等；
App的安装卸载：全部安装、升级安装、第三方工具安装卸载、消息推送、前后台切换、网络环境等；
兼容性测试：web项目考虑不同浏览器兼容，App考虑不同 *** 作系统、不同机型、不同屏幕等；
网络测试：不同网络与运营商，不同的网络制式，如GSM，CDMA，3G等，在不好或无网络的情况下的app行为；
web自动化测试工具较常用selenium，而手机自动化monkey、appium；
App测试平台：百度云测、PerfDog、testin云测
概念：
所谓的架构就是用来指导我们软件开发的一种思维，目前最常见的就是BS/CS。
B——browser浏览器
C——clent客户端
S——server服务端
区别：
1.标准：相对于CS架构来说BS架构的两端都是在使用现成的成熟产品，所以BS会显示的标准一些。
2.效率：相对BS架构来说CS中的客户端可以分担一些数据的处理，因此执行效率会高一些。
3.安全：BS架构当中得到数据传输都是以http协议进行的输出，而http协议又是明文输出，可以被抓包，所以相对于CS架构来说BS就显得不那么安全（相对的）
4.升级：BS架构只需要在服务器端将数据进行更新，前台只需要刷新页面就可以完成升级，而CS架构当中必须将两端都进行更新。
5.开发成本：相对于BS架构来说，CS当中的客户端需要自己开发，所以相对来说成本会高一些。
1.两者运行机制不同：iOS采用的是沙盒机制，安卓采用的是虚拟机运行机制；
2.两者后台机制不同：iOS中任何第三方程序都不能在后台运行，安卓任何程序都能在后台运行，直到没有内存才会关闭；
3.iOS中用于UI指令权限最高，安卓中数据处理指令权限最高。
需求分析——>设计用例——>评审用例——>配置环境——>执行用例——>回归测试及缺陷跟踪——>输出测试报告——>测试结果
当你参加评审时，你的评审原则是什么？正确性：每一条需求都必须准确的陈述其要开发的功能；
一致性：必须与其他软件需求或高层需求不相矛盾；
可行性：其每一项需求都必须是以系统和环境的权能和限制范围可以来实施的；
必要性：每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回溯至某项客户的输入；
可测试性：每项需求都能够通过设计测试用例或其他的验证方法来进行测试；
可修改性：每项需求只应在SRS中出现一次，这样更改会容易保持一致性；
可跟踪性：在每项软件需求与它的根源与设计元素，源代码，测试用例之间建立起链接，而这种可跟踪性要求每项需求都必须以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的陈述；
分配优先级：应当对所有的需求分配优先级，如把所有需求都看作同样重要，那么项目管理者在开发或节省预算或调度中丧失控制自由度。
文档版本信息：包含文档版本、作者、完成日期，如果是修订版需要加上修订记录
目录：目录结构要清晰
产品架构：一般包括功能架构和信息架构，可根据项目性质来确定
角色定义
功能摘要：列出一级功能——>二级功能。不需要细分
详细功能描述（即产品特性）：包括功能列表、原型界面、详细设计等
其他产品需求：依据公司产品要求来定，一般包含系统兼容性要求、产品运营要求、性能要求等
1.问题确认与评估；
2.明确开发不修改该缺陷的确切原因；
3.具体问题具体分析；
4.发挥TM与PM的沟通职责
1.通用UI要统一、准确；
2.尽量使用业界惯用的表达术语和表达方法；
3.每条缺陷报告只包括一个缺陷；
4.不可重现的缺陷也要报告；
5.明确指明缺陷类型；
6.明确指明缺陷严重等级和优先等级；
7.描述简洁、准确、完整，揭示缺陷实质，记录缺陷或缺陷出现的位置；
8.短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业；
9.没一个步骤尽量只记录一个 *** 作；
10.确认步骤完整，准确，简短；
11.根据缺陷，可选择是否进行图像捕捉。
ui测试、功能测试、性能测试、安装卸载测试、软件升级测试、登录测试、安全性测试、消息推送、前后台切换、兼容性测试、网络环境测试、monkey测试。
web测试的方法有哪些？ 测试用例的方法有哪些以及包含的内容？方法：等价类划分法，边界值，场景法，因果图，正交表。
内容：
等价类：有效等价类，无效等价类；
边界值：上点（边界上的点），离点（离上点最近的点），内点（边界有效范围内的任意一点）
场景法：基本流，备选流，异常流
因果图：输入与输入的关系（异：所有输入条件中最多有一个产生，也可以一个没有；或：所有输入条件中，最少有一个产生、或者多个、或者没有；唯一：有且只有一个条件产生；要求：只要有一个产生，其他跟着也会出现）
正交表：因子（所有参与试验的影响试验结果的条件），水平（影响试验因子的取值或输入）
1.功能性：软件需要满足用户显示或者隐式的功能；
2.易用性：软件易于上手和学习；
3.可靠性：软件必须实现需求文档中指明的具体功能；
4.效率性：类似于软件的性能；
5.可维护性：软件具有将某一个功能修复之后继续使用的功能；
6.可移植性：软件具有从一个平台移植到另一个平台上去使用的能力。
测试计划工作的目的：借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程中的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划文档包括：测试背景、测试的目的、人员的安排、时间的分配、测试环境情况、风险评估等。
企业用的是Java开发的，搭建测试环境是用Linux+MySQL数据库+Tomcat+war包。
还有持续集成，这个方式引入Jenkins，把手动的方式转变成自动化部署
像安装配置的时候就在网上找一份文档，按照文档进行配置
项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都根据各自的流程图，各个功能点有哪些限制条件来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；
用例编写完成之后，再进行用例的评审，看看测试点有没有遗漏，对需求理解有没有错误，测试场景是否覆盖完全。
开发环境是程序员们专门用于开发的服务器，配置可以比较随意，一般为了开发调试方便，一般打开全部错误报告。
测试环境一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。
200：请求发送成功；
302：代表重定向；
400：客户端发送的请求语法错误；
401：请求的页面没有授权；
403：没有权限访问这个页面；
404：没有这个页面；
500：服务器内部异常；
501：当前不能处理客户端的请求；
504：服务器端超时，没返回结果。
压力测试通常是在高负载的情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。
负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。
get和SVN都用过
get *** 作：get add . 添加所有文件
get commit -m “描述” 提交
get push origin 分支名 上传分支
SVN *** 作： Checkout（提取）
Commit（提交）
Update (更新)
略
如果回归测试不通过怎么办？分析问题，明确为什么没通过；
如果不是明确提交的缺陷确实存在，缺陷报告返回开发人员；
开发人员重新修改问题；
再次提交测试人员回归测试。
项目的概要描述；
测试过程缺陷的统计，一定程度反映项目的质量；
整个项目过程有需要改善的地方，提出建议；
给出结论，项目是否可以上线。
1.兼容性问题，在IE浏览器提交按钮可以点击，到了谷歌，火狐就不能了
2.字段的值显示不是想要的结果，或没有显示。（开发从库表取值有误）
3.提交数据之后，状态没有转变为已提交。（代码没有正确获取库表中记录状态改变的状态码）
4.修改密码，新密码与旧密码一致也能成功，没有做新旧密码的校验。
略
性能测试 性能测试关注的指标是什么？从外部看，性能测试主要关注如下三个指标：
吞吐量：每秒钟系统能够处理的请求数、任务数
响应时间：服务处理一个请求或一个任务的耗时
错误率：一批请求中结果出错的请求所占比例
从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等。
1.确定关键业务，关键路径；
2.确定测试的关键数据。比如并发量，响应时间，循环次数等；
3.准备测试环境，完成脚本录制或脚本开发；
4.执行测试，观察或监控输出参数，比如吞吐量，响应时间，资源占有率等；
5.对执行结果进行分析，分析性能问题。
1.查看聚合报告和服务器的资源使用图，检查响应时间，事务成功率，CPU，内存和IO使用率是否达到要求，如果出错率达到了总请求的3%，我们会检查是什么原因导致的，修改好后，重新测试；
2.如果出现了性能瓶颈，比如响应时间，或者CPU使用率不达标，我们会从服务器上导出日志，分析是哪个地方导致响应时间过长，如果分析不出来，就叫上开发一起讨论，确定问题后，就提单给代发修复，修复好了就进行回归测试。
略
如何判断网络是否存在瓶颈？查看在整个性能测试过程中，网络的吞吐量是多少，如果网络的吞吐量占到了服务器的70%以上，我们就认为网络存在瓶颈，通常会增加带宽或者压缩传输数据。
如何判断响应时间不达标？根据性能测试结果先检查看下是否是服务器带宽存在问题，如果带宽存在瓶颈，则会考虑增加带宽或者压缩传输数据，如果带宽没有问题的话，我们会从服务器上导出日志，开发一起讨论分析是哪个地方导致响应时间过长，确定问题后，就提单给开发修复，修复好了就进行回归测试。
如何判断CPU使用率不达标？CPU使用率不达标，我们会从服务器上导出日志，分析是哪个地方导致CPU使用率不达标，如果分析不出来，就叫上开发一起讨论，确定问题后，就提单给开发修复，修复好了就进行回归测试。
app的性能测试怎么做的？APP的性能测试分为服务器端的性能和手机端的性能。
服务器端的性能：jmeter工具进行测试的，和web端性能测试的方法一样的。
手机端APP的稳定测试：使用monkey做。
1.先使用 adb logcat -c 清空手机的logcat日志；
2.接下来使用 adb logcat -v time 获取logcat 日志，并导入本地文件使用 monkey 运行被测应用 adb shell monkey -p 包名 -v 3.100000 并将执行结果导入到本地测试；
4.如果中途失败了就要去看monkey日志中有没有crash或者anr的关键字；
5.如果还需要定位到是什么原因导致的anr或者crash的问题，将相关日志和logcat日志与进程号提交给开发定位；
6.如果是anr的问题，还需要从安卓中获取/data/anr/traces.txt文件提交给开发定位。
线程阻塞，内存不足，CPU满负荷（现在手机基本都是8核CPU，基本不会出现CPU满负荷的情况）
app出现CRASH的原因？空指针值，数组越界，内存不足，CPU满负荷（现在手机基本都是8核CPU，基本不会出现CPU满负荷的情况）
APP常见崩溃原因？1.设备碎片化：由于设备极具多样性，App在不同的设备上可能有不同表现形式；
2.宽带限制：宽带不佳的网络对App所需的快速响应时间不够；
3.网络的变化：不同网络的切换可能会影响App的稳定性；
4.内存管理：可能内存过低，或者是授权的内存位置的使用可能会导致App失败；
5.用户过多：连续数量过多可能会导致App崩溃；
6.代码错误：没有经过测试的新功能，可能会导致App在生产环境中失败；
7.第三方服务：广告或d出屏幕可能会导致App崩溃。
adb install（apk的文件路径） 安装软件到手机或者模拟器
adb uninstall（包名） 卸载手机或模拟器上的某款软件
adb devices 查看与当前电脑连接的移动设备
adb ,adb start-server 启动
adb,adb kill-server 杀死
adb logcat 查看日志
adb logcat -v time process >
adb install -r xx.apk 覆盖低版本的
adb install -r -d 覆盖高版本的
adb shell dumpsys cpuinfo 查看手机cpu的使用情况
adb shell getprop|findstr dalvik 手机系统自己运行的内存使用
Adb shell monkey -p 包名
Adb-shell–ignore-crashes 忽略崩溃
Adb-shell–ignore-timeouts 忽略延时
Adb-shell–ignore-throttle 延时毫秒值
Adb-shell–pct-touch–pct-motion 触摸与滑动事件的比例
1.2G的网速150kbps，折合下载速度15-20k/s
2.3G的网速1-6mbps，折合下载速度120k/s-600k/s
3.4G的网速10-100mbps，折合下载速度1.5m/s-10m/s
4.使用真实的SIM卡，运营商网络来进行测试
5.通过代理的方式模拟弱网环境下进行测试（Charles延迟）
6.链接模拟弱网的热点进行测试（如360WiFi助手可以设置）
1.后端完成开发，输出接口文档；
2.前端开发和后端开发进行前后端联调，结束后后端开发人员提测接口；
3.测试人员进行接口测试；
4.进行验收测试；
5.利用持续集成技术进行持续的校验。
1.通过性验证：保证接口好使，能正常传入且返回正确的结果；
参数组合：有必传项时检查必传项；
接口安全：①绕过验证（比如商品价格不能被外部修改）②绕过身份授权（商品必须商家本人才能修改）③参数是否加密（用户名密码加密）④密码复杂程度校验
2.根据业务逻辑来设计用例
3.工具：postman和jmeter。一般用postman测接口，jmeter也能侧，但一般不用。
先看接口文档，根据接口文档进行测试，包含接口的URL，请求参数，响应结果。如果没有接口文档，就自己抓包。我们是用jmeter来做接口测试的，首先，要新建一个线程组，在线程组下面添加一个http请求，然后填写好服务器地址，接口路径，请求方式，请求参数。如果需要参数化，先在本地创建一个TXT文档，把参数填写到文档里面，在jmeter中添加一个csv文件设置，填写好TXT文档的路径，然后在请求参数中使用json提取器把token值关联出来，然后在下单接口中使用${参数名}的方式引用；接下来添加断言，检查服务器返回的结果和预期结果是不是一致的。最后，添加查看结果数查看测试结果。
请描述下接口测试与UI测试是如何协同测试的？1.有一部分是重叠的，UI测试是通过前端写的界面，是来调用接口的，而接口测试是直接调用接口；
2.排除前端的处理逻辑与调用的正确性，在理论上接口测试是可以覆盖所有的UI测试，但实际中，如几口层覆盖所有的业务流，在UI上只测试前端的逻辑，而最终的结果会忽视很多原有的功能点，导致了UI测试的不充分，那么会存在人多分工且实践充分的时候可以尝试接口去做业务流的全覆盖，否则不要轻易地去尝试。
1.有些公司没有标准的接口文档，只能通过抓包获取接口信息；
2.通过抓包可以查看整个请求过程以及相应过程，从而分辨是前台bug还是后台bug；
3.可以查看是否有敏感信息泄漏；
4.抓包进行测试，拦截请求，修改请求数据，查看响应结果本来就是接口测试的一部分。
Charles。
在工具设置http代理，设置端口号，在手机上设置同一网段，设置代理IP，设置代理端口，手机上的请求就可以抓取到了。
可以设置过滤，找到自己域名下的请求，通过分析请求地址，请求参数，响应结果来查找问题。
https，下载证书就可以抓取到请求了。
1.打开jmeter；
2.创建线程组；
3.设置线程数和循环次数；
4.配置元件；
5.配置我们需要进行测试的程序协议、地址和端口；
6.构造http请求；
7.添加http请求头；
8.添加断言；
9.添加查看结果树；
10.添加Summary Report；
11.执行测试计划，执行测试计划不能用GUI，需要用命令来执行；
12.web报告。
1.在jmeter的线程组中分别添加JDBC Connection ConfigConfiguration 、JDBC Request 、 Debug Sampler 、 查看结果数。
2.在测试计划中将连接mysql需要的包加到classpath中。
3.在JDBC Connection Configuration 中添加JDBC的配置。
做压力测试时，我们经常需要替换参数，在jmeter中，有多种参数化的形式。可以在测试计划中设置全局参数，可以设置用户参数，还可以在前置处理器中设置用户参数。在进行多线程并发的时候，如果需要多个参数，可以使用csv配置元件。比如做登录 *** 作，后台有可能会限制一个用户不能重复登录多次，如果演示登录的并发 *** 作，可以使用jmeter中的csv元件，将用户信息导出来，放到文件中，就可以让线程共享这些数据。另外，对于一些随机变化的参数，可以使用jmeter中的函数助手，生成随机函数，进行参数化测试。比如注册这样的 *** 作，用户名要求唯一的，那就可以使用随机函数模拟出来。
jmeter如何进行压力测试？当测试接口的时候，发现某个接口性能比较差，需要进一步判定问题的时候，会压测数据库。压测数据库需要配置驱动，设置连接池大小，需要使用sql去 *** 作数据库。具体的哪条sql问题需要问开发要具体的sql进行压测。
postman postman与jmeter的区别是什么？1.用例组织不同：jmeter的组织是比较偏扁平，首先它没有工作空间的概念，直接就是测试计划，而postman功能上更简单，组织方式是轻量级，他主要针对的是单个的http请求。
2.支持接口的类型与测试的类型不同：jmeter的功能更强大，可以通过各种类型的接口，不支持的页可以通过网上或者自己编写的插件进行扩展，而postman更轻量级，定位不同，可用来测试rest接口。
3.配置不同：jmeter可以在线程组里添加http，tcp，而postman只支持rest接口。
用它来做接口测试。
查看接口的返回结果；
查看接口是get请求还是post请求；
数据库语言最常用的是SQL
多表联查：select * from table1 t1,table2 t2 where tl.id=t2.id
这样就是多表联查。
left join
right join
inner join
增：
alter table 数据表名 add birthday datetime;
删：
alter table 表名 drop 列名;
改：
1.修改字段，不重命名，用modify
alter table 数据表名 modify birthday date;
2.修改字段，重命名，用change
alter table 表名 change 原名 新名 类型及约束
alter table 数据表名 change birthday birth date；
查：
查询表使用数据 select * from 表名;
部分查询 select * from 表名 where 条件;
可以使用as 为列表指定别名
select 字段 as 别名,字段 as 别名 from 数据表名 where…;
内关联是求交集
外关联是以主表为标准，去附表找需要的信息
不能，脚本需要通过Windows调试好之后，才能在Linux上运行，运行的时候，只能通过non GUL的形式进行启动jmeter，但需要注意的是，csv文件在Windows上与Linux上要统一路径，最好使用相对路径，放到统一目录下边。
Linux系统 *** 作的指令说一下：增加，删除，复制，移动等问题？cd:进入目录
cd app：切换到app目录
cd… ：切换到上一层目录
cd/: 切换到系统根目录
tail -10 a.txt :查看后10行数据
ifconfig :查看ip
ll:查看文件及其属性
vi: 编辑
rm-rf: 删除
car:解压及压缩命令
cp:复制
pwd:显示当前路径
mv:移动
cat:查看文件内容
touch:创建文件
tail logcat:查看日志
cat logcat:查看日志
tomcat：日志
tail ：查看日志记录信息，tail -f catinalia out
tar -xvf 文件名 :解压
tar -n logcat 查看系统日志
tar -zcvf 文件名：压缩
显示，管理执行中的程序，就是任务管理器
自动化测试 自动化测试有了解吗？自动化测试的工具有哪些？通过脚本代替一些手动化测试的步骤。unittest， web端：selenium ； app端：appium
selenium元素定位的方法有哪些？find_element_by_id()（常用）
find_element_by_name()（常用）
find_element_by_class_name()
find_element_by_tag_name()
find_element_by_link_text()
find_element_by_partial_link_text()
find_element_by_xpath()（常用）
find_element_by_css_selector()
我们的电脑（c端）上运行自动化测试脚本，调用的是appium的webdriver的接口，appium服务器（s端）接收到我们client上发送过来的命令后，它会将这些命令转换为UIautomator认识的命令，然后由UIautomator来在设备上执行自动化。
安全性测试 安全性测试包括哪些方面？1.用户程序安全；
2.系统网络安全；
3.数据库安全。
1.覆盖用户的需求；
2.从用户使用场景触发，考虑用户的各种正常和异常的使用场景；
3.用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
4.用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
5.做好用例评审，及时更新测试用例。
1.首先进行需求分析，用XMind梳理测试点，再编写案例，之后就进行案例评审，寻求他人意见。之后再完善案例，发出来给其他人检查。
2.测试点，首先是UI方面，美观度和易 *** 作性，易理解性方面进行测试。
3.然后再考虑其他功能点，注册登录，添加购物车，下单，付款，发货，确认收货，评价等。
4.性能方面：打开网页，确认订单，付款的响应时间等等
5.兼容性：支持各种主流浏览器，IE，360，火狐，谷歌等
功能：
1.在红包钱数和红包个数的输入框中只能输入数字；
2.红包最多和最少的输入钱数 200,0.01；
3.拼手气红包最多可以发多少个红包；
4.超过最大拼手气红包是否有提醒；
5.当红包钱数超过最大范围是否有提醒；
6.余额不足时，红包发送失败，或者会不会匹配切换支付方式；
7.红包描述里是否可以输入表情、汉字、英文、数字等；
8.红包描述里最多有多少个字符；
9.发送的红包别人是否能正常领取；
10.发送的红包自己可不可以领取；
11.24小时后别人没有领取的红包是否可以退回原来的账户，或者是否还可以领取；
12.用户是否可以多次抢一个红包；
13.用户在多人群里发红包是否可以抢自己的红包；
14.红包余额里的小位数是否有限制；
15.返回键可以正常取消发红包吗；
16.断网时是否可以抢红包；
17.收发红包界面是否有自己以前收发红包的记录，以及和自己实际收发红包是否匹配；
18.支付时密码支付和指纹支付是否正常；
19.支付成功是否正常返回聊天界面；
20.是否可以连续发红包。
性能：
1.网络环境差，发红包的时间；
2.不同网速时，抢红包的时间；
3.收发红包后跳转时间；
4.收发红包的耗电量；
5.退款到账的时间。
兼容：
1.苹果，安卓系统；
2.电脑端是否可以抢红包；
3.不同品牌的手机是否正常使用。
界面：
1.发红包界面有没有错别字；
2.抢完红包界面有没有错别字；
3.收发红包界面排版美观合理；
4.界面颜色搭配好。
安全：
1.发送红包领取红包后对应相关的金额是否会变化；
2.发送失败yhk或者余额会不会变；
3.发送成功后是否会收到微信支付的通知。
易用：
1.支持指纹，人脸识别支付码；
2.红包描述可以通过语音输入吗。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）