b---browser 浏览器
c---clent 客户端
s---server 服务端
比较：
标准：相对于cs架构来说bs架构的两端都是在使用现成的成熟产品。所以bs会显示的标准一些
效率：相对bs架构来说cs中的客户端可以分担一些数据的处理，因此执行效率会高一些
安全：bs架构当中得到的数据传输都是以HTTP协议进行的输出，而HTTP协议又是明文传输。可以被抓包，所以相对于cs架构来说bs就显得不那么安全（相对的）
升级：bs架构只需要在服务器端将数据进地更新，前台只需要刷新页面就可以完成升级，而cs架构当中必须要将两端都进行更新
开发成本：相对于bs架构来说cs当中的客户端需要自己开发，所以相对于来说成本会高一些
cs又有一些特殊的测试：热启动，消息推送，中断测试。。。。
http协议又叫超文本传输协议，在网络请求的时候，我们基本上是使用http协议
http协议包括请求和响应
请求中包括：请求地址，请求方式，请求方式包括get请求和post请求，get和post的区别是get请求是在地址栏后边
跟随请求参数，但是请求参数大小是有限制，不同浏览器是不同的。一般是4KB。post请求主要用于
向服务器提交请求参数。post请求的参数是放到请求实体内容中的，相对get请求较为安全一些
另外请求中会有各种请求头信息，比如支持的申诉局类型，请求的来源位置，以及Cookie头等相关头信息
响应，主要包含响应的状态码，像200（），404（），500（），304（），307（）
还有各种响应头信息，比如设置缓存的响应头，Content-Type内容类型，设置cookie头信息
1.get使用url或cookie传参，而post将数据放在body中
2.get的url会有长度上的限制，则post的数据则可以非常大
3.post比get安全，因为数据在地址栏上不可见
4.一般ge请求用来获取数据，post请求用来发送数据
客户端技术 Cookie
服务端技术 Session
Cookie是把数据保存在浏览器端的内存中
Session把数据保存在服务器端的内存中
cookie与session的联系：
当服务器端生成一个session时就会向客户端发送一个cookie保存在客户端，这个cookie保存的是session的sessionld。这样才能保证客户端发起请求后客户端已经登录
的用户能够与服务器端成千上万的session中准确匹配到已经保存了该用户信息的session，同时也能够确保不同页面之间传值时的正确匹配。
1.发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心
2.记录软件运行过程中产生的一些数据，从而为决策提供数据支持
3.降低同类产品开发遇到问题的风险
1.测试证明软件存在缺陷：无论执行什么样的测试操作都能证明当前软件是有缺陷的
2.不能执行穷尽测试：有些功能是没有办法将所有的测试情况都逻辑出来，所以任何的测试操作都有结束的时间
3.缺陷存在群集现象：对于软件功能说，核心功能占20%，非核心80%。在实际工作中我们会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%
因此我们就会遇到缺陷都集中在20%功能模块里的现象
4.某些测试需要依赖特殊的环境
5.测试应尽早介入：为了更多的发现和更好的解决软件中的缺陷。我们追求测试工作尽早
6.杀虫剂现象：同样的一个测试用例不能重的执行多次，因此软件会对它产生免疫
不存在缺陷谬论：任何软件不可能是完美的
单元测试：是指对软件中最小可测试单元进行检查和验证
单元测试当一段代码完成后，是由白盒测试工程师或者开发人员自行测试，比如java中执行单元测试叫做junit测试
目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序，没有相应的单元测试计划
单元测试方式：先静态地观察代码是否符合规范，然后动态地运行一下代码，检查运行结果
集成测试：是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分
集成测试也是由白盒测试或者开发人员来完成
系统测试：（黑盒测试）在经过集成测试的单元模块，按照整体需求规格说明书，进行一套有效严格的测试，保证软件的正常运行。（集成测试偏重于技术角度，系统测试偏重于业务角度）
回归测试：（回归测试在测试生命周期中是很重要的一部分，会进行多次回归测试），是指在发生修改之后，再重新回去测试一下，避免修改的内容导致了其他的错误。验证之前出现过但已修复好的缺陷不再重新出现。
冒烟测试：（是自由测试的一种）是指开发者功能完成后的完整性功能测试，发现问题后反馈给开发者进行修改，然后看这次修改是否真的修复解决了这bug，或者对其他模块造成了影响，这个时候就需要冒烟测试来进行验证，缺点就是覆盖率低。
验收测试：也叫交付测试，是针对用户需求、业务流程进行的整体测试，确认是否满足验收标准，由用户、客户看是否接受系统，可以部署上线。
Alpha测试：用户在开发者的场所进行测试，是一个可控的环境中测试的。
Beta测试：是用户在对软件产品进行测试，开发者不在现场，用户对测试过程中遇到的bug进行记录，开发并对它进行修改，再测试，直到用户觉得可以了，就部署上线
单元测试是对程序最小可测的模块进行测试
集成测试是把各个模块连接起来时，穿越模块接口的数据是否会丢失
功能测试，用户体验测试，性能测试，ui测试兼容性测试，安装测试，文档测试，稳定性测试等
a测试：公司组织的内部人员进行的测试
ß测试：公司组织的典型客户在实际生活中使用。
在UAT测试之前，我们会制定测试方案，选择基线用例，即级别高的用例，在UAT测试环境上进行测试，如果测试通过，验收测试就通过了。
白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接口所实现的功能，是否和需求一致。
检查程序的基本功能是否正常
首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。
全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
澄清需求，提取测试点
借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，
保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更
需求分析之后
一般都是由测试经理或者测试组长来编写
1.简介 项目的介绍 测试负责人和开发负责人 项目的起始日期。。。。
2.参考文档和提交文件
3.进度安排 模块安排 对应负责人 时间安排。。。。
4.测试资源
5.严重程度和优先级
6.风险分析 比如说项目优先级不高 开发人员数量不足或者开发技术不到家 节假日。。。。
7.测试策略 功能测试 性能测试 接口测试。。。。
需求德覆盖率、用例的执行率和缺陷的遗留率达到质量目标。
通常来说：需求覆盖率和用例执行率需要达到100%
致命/严重的缺陷需要当天解决，轻微/一般遗留率不得超过30%
进度风险、质量风险和需求变更
用例编号 用例描述 执行条件 预期结果 测试输入 实际结果
一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定
项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之
后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。
判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表什么时候用到场景法
使用场景法通常是在冒烟测试中或者 一些流程性比较强的软件/功能(比如安装，卸载等等)
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是
java编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了
1.找到需求文档或者是原型图进行匹对
2.尝试多种测试环境和多种测试方式来确认是否为bug
3.整理bug的复现的步骤和出现的频率
4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug
5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug
6.测试人员需要将bug整理并写入测试总结中
80%的缺陷出现在 20%的模块
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，
问题修复后，要及时进行回归测试。
激活，确认,已解决,关闭
崩溃，严重，一般，建议，
缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。
人力投入，用例统计，问题单分类统计，遗留bug情况，测试风险，测试对象评估，测试结论
1.功能测试：
圆珠笔按下是否能正常书写。
2.性能测试：
笔芯弹出弹回的快慢。
3.负载测试：
连续按，看弹簧能经受多少次伸缩。
4.兼容性测试：
看是否可以使用其他笔芯。
5.强度测试：
用力过度会有什么影响
6.可恢复性测试：
长时间按住弹簧，松开后看弹簧是否可以恢复
7.界面测试：
笔的外观，舒适度
8.安全性测试：
是否会对使用者造成伤害
一步：确定测试策略。
（1）判断能否组成三角形；
（2）识别等边三角形；
（3）识别等腰三角形；
（4）识别任意三角形。因此可首先用黑盒法设计测试用例，然后用白盒法验证其完整性，必要时再进行补充。
第二步：根据本例的实际情况，在黑盒法中首先可用等价分类法划分输入的等价类，然后用边界值分析法和猜错法作补充。
等价分类法：
有效等价类
输入3个正整数：
（1）3数相等
（2）3数中有2个数相等，比如AB相等
（3）3数中有2个数相等，比如BC相等
（4）3数中有2个数相等，比如AC相等
（5）3数均不相等
（6）2数之和不大于第3数，比如最大数是A
（7）2数之和不大于第3数，比如最大数是B
（8）2数之和不大于第3数，比如最大数是C
无效等价类：
（9）含有零数据
（10）含有负整数
（11）少于3个整数
（12）含有非整数
（13）含有非数字符
边界值法：
（14）2数之和等于第3数
猜错法：
（15）输入3个零
（16）输入3个负数
第三步：提出一组初步的测试用例，如下表所示：
第四步：用白盒法验证第三步产生的测试用例的充分性
1.兼容性问题，在ie浏览器，提交订单按钮可以点击，到了谷歌，火狐就不能了
2.查询订单页面，根据条件筛选的结果不是想要的结果，还有某些字段的值没有显示出来或者显示错误（因为开发从库表取值有误）
3.付款成功后，订单状态一直不翻转为交易成功。（因为代码没有正确获取库表中付款成功纪录的状态码）
4.修改支付密码，新密码和原密码一致，也通过了，系统没有做新旧密码的校验
5.付款时候的手机验证码，可以一直使用，没有成功做有效期控制
6.手机app断开网络后，再去点击，没有友好的错误页面提示网络已断开，只有undefined返回
测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%。
不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。
将程序放在其他的windows上运行，如果运行的还是很慢则是程序的问题。
发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。
从功能方面考虑：
从性能方面考虑：
从安全性方面考虑
从用户体验方面考虑
兼容性
基本功能测试：
界面测试
界面是否清晰明了
页面的布局是否合理，是否完整
不同卖家的商品在不同的table区域显示，区分明显。
购物车中如果存在有商品降价、库存不足、限购件数等，在商品详情的下面，会有对应的字体展示。
向下滑动页面，在购物车顶端展示“购物车”。
商品的最下方显示失效宝贝。
兼容性测试
iOS：不同型号，不同的iOS系统。
安卓：不同品牌，不同型号，不同的安卓系统
不同分辨率下，显示的样式是否一样
不同浏览器上的测试功能是否正常
低配置情况下，是否能满足需求
反复操作某一个功能，不断点击和刷新，是否出现闪退。
在2g网络情况下，商品显示的速度
在3g网络情况下，商品显示的速度
在4g网络情况下，商品显示的速度
在5g网络情况下，商品显示的速度
在wifi网络情况下，商品显示的速度
安全性测试
易用性测试
性能性测试:
1.搜索按钮功能是否实现；
2.点搜索后，原先的搜索条件是否清空；
3.注意验证搜索框的功能是否与需求一致，即是模糊搜索，还是完全搜索。如果支持模糊查询，搜索名称中任意一个字符，要能搜索到；如果支持完全搜索，点击“搜索”，查询结果正确；中%国，查询结果是不是都包含中国两个字的信息
4.比较长的名称是否能查到,输入过长查询数据，看其有没判断，报错;系统是否会截取允许的长度来检索结果;只能输入允许的字符串长度？
5.空;默认查询条件结果集
6.空格;
7.是否有忽略空格的功能，有的搜索框是需要有忽略前置空格和后置空格的功能，但不能把中间空格忽略;
8.输入各种字符，譬如输入范围是09，AZ的看输入中文是什么效果,字符（尤其是英文单引号），数字，特殊符号以及组合情况（特殊符号就是键盘上的那些）;中文值，字母大、小写值、数字类型值、全角、半角值，
9.输入系统中存在的与之匹配的条件,看其的查询后数据的完整性;显示记录条数正确、文字折行显示正确、页面布局美观,列标题项、列显示内容、排序方式符合需求定义;搜索出的结果页面是否与其他页面风格一致；
10.焦点放置搜索框中，搜索框默认内容是否自动被清空；
11.输入系统中不存在的与之匹配的条件;本站内搜索输入域中不输入任何内容，是否搜索出的是全部信息或者给予提示信息
12.用快捷键或鼠标粘贴内容看，测试搜索框是否能执行;
13.查询结果超过一页可以下滑，并选中;
14.注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方;
15.用户进行查询操作时，一般情况是不进行查询条件的清空，除非需求特殊说明。
16.反复输入相同的数据（5次以上）看是否报错
17.在输入结束后直接按回车键,看系统处理如何,会否报错
18.敏感词汇，提示用户无权限等信息
1.不同查询条件之间来回选择，是否出现页面错误（单选框和多选框最容易出错）
2.测试多个查询条件时，要注意查询条件的组合测试，可能不同组合的测试会报错。
3.组合各个文本域查询条件，点击“搜索”，查询结果正确
4.多个关键词中间加入空格，tab，逗号后，验证系统的结果是否正确
其他苛刻要求：
1、于输入框处双击鼠标是否出现下拉菜单记忆已搜索过的内容
2、特殊数字的判定,如输入"10101010"二进制字符系统的判断与报错
3、于输入框单击鼠标左键,是否有光标出现
4、承上,光标出现后使用"Tab"键后,"搜索"按钮是否出现选定TIP
5、于输入框点击鼠标右键是否出现Menu,Menu内容依次为"撤消"、"复制"、"粘贴"、"删除"、"全选"(具体情况视实际情况而定)
6、检查以上Menu出现的选择模块是否可正常使用
7、于输入框输入任意长度字母、数字、文字,双击鼠标左键,观察输入项目能否被全部选中
8、输入正则表达式
9、写段select查询语句，插入语句等，看看执行结果ctrl+z,+x,+c,+v快捷键操作等是否可行
10、特殊字符，转义符，html脚本等需作处理
11、键盘回车键、Tab键
12、边界值验证，在允许的字符串范围内外，验证系统的处理
一、测试方法
查询类型包含单个查询、组合查询、输入框输入查询、时间控件查询四种场景：
1、功能实现
2、组合查询
3、时间控件查询
二、主要测试点
（1）默认查询
（2）正常查询功能
（3）边界值查询
（4）异常查询与相关提示
（5）模糊查询
（6）查询后是否清空查询记录
（7）空查询
（8）组合查询
（9）时间查询
（10）数据库验证
界面测试
1.查看UI是否显示正确，布局是否合理
2.是否有错别字
3.搜索结果显示的布局是否美观
4.已查看的结果链接，链接的颜色要灰化处理，
5.结果数量庞大时，页面的分页布局是否合理
6.界面的颜色搭配是否合理
安全性测试
1.脚本的禁用
2.SQL的注入，检索SQL SELECT语句等
3.敏感内容的检索是禁止的
4.特殊字符的检索
5.被删除、加密、授权的数据，不允许被查出来，6.是否有安全设计控制
兼容性测试
1.多平台Windows，mac
2.移动平台android，ios
3.多浏览器火狐、chrome、IE等
性能测试
1.搜索页面的链接打开速度的时间
2.搜索出结果消耗时间
3.弱网时搜索的响应时间
4.不同网速下搜索时的响应时间3g,4g,WIFI
易用性
1.有联想功能
2.搜索内容与搜索结果的匹配程度
3.支持拍照搜索，语音搜索
页面
页面美观性、易用性（键盘和鼠标的操作、tab跳转的顺序是否正确）
按钮文字正确性
说明文字是否正确
正确/错误的提示文字是否正确
提示当前位置是否正确，并且和其他页面保持一致格式
必填项的标示是否正确
功能
路径是否可以手工输入（手工输入的时候有没有限长）
上传文件超过最大值是在提交前校验还是提交后校验
上传文件格式是否全部支持（图片：gif/jpg/bmp…文档：doc/sxw/xls…压缩包：zip/rar…安装文件：exe/msi）
上传文件是否支持中文名称
文件名称的最大值、最小值、特殊字符（包含空格）、使用程序语句是否会对其造成影响、中文名称是否能正常显示
对于是否发布的设置是否正确（前台校验）
简介最大值、特殊字符、使用程序语句是否会对其造成影响
上传文件名测试，检查不符合文件名规范
上传文件名类型测试，检查不同文件类型是否支持如：.rar,.mp3,avi等
上传文件大小测试，检查不同文件规格大小如：0字节文件, 1kb, 200kb, 2mb, 20mb,2g等
上传文件容错性测试：如检查覆盖同文件操作；
上传文件异常情况测试：如硬盘空间不足
上传文件速率性能测试：检查上传不同的文件在不同的网络环境响应速度，及系统资源占用
上传文件安全性测试：如上传常见木马
上传文件易用性测试：检查上传文件操作是否让用户易于学习和理解使用等
上传文件特性测试：如果支持如断点续传等一些特性
上传文件后，检查是否与源文件一致，包含目录设置等
上传文件，是否能打开等
按钮
保存按钮
对输入项有错误提示后光标提示是否正确
对输入项的错误提示是否描述正确
对必添项是否进行校验
清空按钮
是否清除（或还原）了填写内容
返回按钮
是否返回上一页面
功能性测试：
1. 输入已注册的用户名和正确的密码，验证是否成功登录
2. 输入已注册的用户名和不正确的密码，验证是否成功失败，且提示信息正确
3. 输入未注册的用户名和任意密码，验证是否登录失败，且提示信息正确
4. 使用未激活账户登录，验证是否登录失败
5. 使用被停用用户登录，验证是否登录失败
6. 用户名和密码两者都为空，验证是否登录失败，且提示信息正确
7. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确
8. 如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入正确的验证码，验证是否登录成功
9. 如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入错误的验证码，验证是否登录失败，且提示信息正确
10.用户名和密码是否大小写敏感
11.页面上的密码框是否加密显示、或者是否需要有明暗码切换按钮
12.后台系统创建的用户第一次登录成功时，是否提示修改密码
13.忘记用户名和忘记密码的功能是否可用
14.前端页面是否根据设计需求限制用户名和密码长度
15.如果登录功能需要验证码，点击验证码图片或者点击换一张是否可以更换验证码，更换后的验证码是否可用
16.刷新页面是否会刷新验证码
17.如果验证码有时效性，需要分别时效性内和时效性外验证码的有效性
18.用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面
19.不同级别的用户，比如管理员和普通用户，登录系统后权限是否正确
20.页面默认焦点是否定位在用户输入框中
21.快捷键Tab和Enter等，是否可以正常使用
22.为空和输入空格字符串的校验是否一致
23.使用中文键盘输入字母和使用英文键盘输入字母传入后端的字符长度是否一致
24.成功登录后的session的时效设置
25.输入栏是否设置快速删除按钮
26.用户名和密码是否支持特殊字符和中文
27.浏览器的前进后退按钮，是否有效
28.成功登出后，点击浏览器回退按钮，是否可以继续操作系统
29.需求中是否有登录时间限制，如果有验证时间限制是否有效
30.验证不同登录方式的正确性：扫码、账号密码、第三方……
31.若支持手机号+验证码登录，验证码是否有时间限制，移动设备是否可以直接获取验证码
32.操作错误提示信息是否简单明了
兼容性测试：
1. 不同浏览器下，验证登录页面的显示以及功能正确性
2. 相同浏览器的不同版本下验证登录页面的显示以及功能正确性
3. 不同移动设备终端的不同浏览器下，验证登录页面显示以及功能的正确性
4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性
安全性测试
1. 用户密码后台存储是否加密
2. 用户密码在网络传输过程中是否加密
3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码
4. 不登录的情况下，在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面
5. 密码输入框是否不支持复制粘贴
6. 密码输入框内输入的密码是否都可以在页面源码模式下被查看
7. 用户名和密码输入框分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面
8. 用户名和密码输入框分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改
9. 连续多次登录失败的情况下，系统是否会阻止后续的尝试以应对暴力破解
10.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期
11.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性
12.是否可以记住密码，记住的密码保存是否加密，记住的密码是否有有效期，过了有效期后是否清空密码
13.是否支持第三方登录
14.密码的强弱性，复杂度校验
15.异地登录校验、更换设备登录校验、登陆信息异常是否考虑账户冻结停用、是否允许第三方平台存储密码
16.是否可以使用登录的api发送登录请求，并绕开验证码校验
17.是否可以用抓包工具抓到的请求包直接登录
18.截取到的token等信息，是否可以在其他终端上直接使用，绕开登录，token过期时间校验
19.登录错误后的提示是否存在安全隐患
性能压力测试
1. 单用户登录的响应时间是否小于3秒
2. 单用户登录时，后台请求数量是否过多
3. 高并发场景下用户登录的响应时间是否小于5秒
4. 高并发场景下服务端的监控指标是否符合预期
5. 高集合点并发场景下，是否存在资源死锁和不合理资源等待
6. 长时间大量用户连续登录和登出，服务器是否存在内存泄露
7. 输入内容校验是否加入了函数防抖
我们系统的订单生成的流程是这样子的，用户下单后，系统会在用户端和卖家端生成一个待付款的订单，同时在数据库也会生成一个待付款的订单；当用户付款之后，用户端显示待发货状态，卖家端显示已付款待发货状态，订单在数据库的状态为待发货，产品相应的库存量会减少，用户的账户金额减少相应的金额；当卖家发货后，用户端和卖家端的订单状态都显示为配送中，数据库中的订单状态也同时发生变化；当用户确认收货后，订单状态会显示为已完成，待评价状态，数据库中的订单状态也同时发生变化，买家支付的款项会打入到卖家的账户；当用户评论完后，订单状态显示为已结束，数据库中的订单状态也同时发生变化。这是一个正常的流程，我们测试的时候，要优先把这个流程测试通过。
然后再考虑用户的其他使用场景，比如：
1.订单界面是否整洁，清晰，文字大小是否适中，订单编号是否能复制；
2.下单，取消订单，申请退款等功能是否有响应的提示，提示是否合理；
3.超时时长是否有倒计时提示；
4.只对订单的部分商品进行发货，订单里的商品发货状态是否分开展示；
5.是否支持Enter，tab等快捷键。
版权声明：本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
工作时间：8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态
![[AWS] [Root User] 分配一个IAM账号](/upload/rand_pic/2-1403.jpg)
