一、软件测试的目的：
发现缺陷错误，并且尽最大可能找出最多的错误，也是对软件质量进行评估，以提高软件质量。
二、什么是软件：
软件=程序+文档+数据
软件是计算机系统中与硬件相互依存的一部分，它是包括程序、文档的完整集合。
程序（program）是按事先设计的功能和性能要求执行的指令序列。
文档（document）是与开发、维护和使用有关的图文材料。
三、软件缺陷的定义：
1、软件没有实现产品说明书要求的功能；
2、出现了产品说明书指明的不应该出现的错误；
3、实现了说明书中未提及的功能；
4、未实现产品说明书虽未明确，但应实现的功能；
5、软件难以理解，不易操作，运行缓慢等问题；
6、缺陷是系统在开发或者维护过程中就存在的错误；
7、缺陷是系统某种功能失效；
四、什么是软件测试：
1、找bug；
2、找到【预期结果】和【实际结果】的差异，保证项目质量；
3、根据需求文档（客户要求）进行测试；
P.s：一般把软件缺陷（defect）称为bug（臭虫）
五、操作系统：
1、Windows
2、Linux
3、Android
4、IOS
5、Unix
六、BS架构和CS架构：
1、BS架构——基于浏览器；
优点：分布性强，维护方便，成本低；
缺点：个性化特点明显降低，跨浏览器实现差，响应速度低，容易给服务器造成较大的压力；
2、CS架构——基于客户端；
优点：用户体验佳，速度快，处理能力强；
缺点：需要专门的客户端安装程序，开发、维护成本高，升级一次所有的客户端程序都需要改变。
七、职业素质要求：
1、专业知识
2、沟通能力
3、团结合作能力
4、耐心、细心、自信心
5、责任心
6、不管做什么测试，基础一定要牢，才能继续提升
八、V模型：
【用户需求】由需求人员（BA）根据客户需求整理一个文档叫需求文档
【需求分析】项目经理—测试经理—开发—测试—BA
开会讨论：
1、需求怎么做？——开发
2、需求是否合理？——两个方面：需求、时间
3、测试人员的作用？
（1）搞清楚这个需求的来源是做什么的；
（2）通过测试思维去考虑它，如何去测试它；
4、需求讨论阶段也是需求确认的一个阶段
【概要设计】开发人员对需求进行梳理；
——开会评审，检查开发人员对需求的理解程度；
【详细设计】开发人员需要通过什么样的技术去实现这个功能，用文档的形式写出来
——后期也需要评审
【编码】编程。
【单元测试】开发人员对自己编写的程序进行自检
——通过代码的形式进行测试
【集成测试】也叫组装测试，先测试单个模块，再进行组合测试，查看是否能正常运行
——主要是做功能和接口测试
【系统测试】也叫全面测试
——除了功能和接口测试，根据项目要求，进行性能、自动化、兼容性等测试
【验收测试】
正式验收：其他的第三方测试团队再测试一次
非正式验收：
1、Alpha测试：是由用户、测试人员、开发人员等共同参与的内部测试
2、Beta测试：β测试指的是内测后的公测，即完全交给最终用户的测试
冒烟测试：测试项目的主流程是否通过
交叉测试：
1、系统功能比较稳定的情况下才会做交叉测试
2、项目时间比较充裕的情况下做交叉测试
为什么要做交叉测试？
1、长时间测试一个系统会产生视觉和习惯上的疲劳
2、换个人测试，由每个人的测试习惯能够发现新的问题
3、从而保证项目的质量
V模型也叫一个项目的生命周期；
V模型的缺点：没有明确说明早期测试，在测试原则中：测试人员应该尽早的投入测试，与开发同步进行；
提出了优化后的模型：W模型
V模型的优点：明确标注了测试阶段与开发各阶段的对应关系；
九、黑盒测试
1、只关注输入条件和预期结果
2、不关注程序内部结构，主要做功能测试
十、白盒测试
1、需要关注程序的内部结构，主要是做自动化测试
2、单元测试也属于白盒测试的一种
十一、白盒测试的常用方法
语句覆盖，判断覆盖，条件覆盖，判断/条件覆盖，基本路径覆盖，循环覆盖，模块接口覆盖
十二、黑盒测试的常用方法
等价类划分、边界值分析法、因果图法、状态转换法等
十三、软件测试的种类
1、界面测试：也叫UI测试，对系统页面进行检查
2、功能测试：测试系统中所有的功能（在公司中，界面属于功能测试的一种）
3、回归测试：重复测试，也叫返测。
（1）开发修复bug后，测试人员重新测试，叫回归测试
（2）上期版本的项目已经做好了，这期无大变化，那么我们可以使用上一个版本的测试用例进行回归测试。
P.s.要注意回归测试的时候有无新问题出现
4、接口测试：
（1）主要测试服务通不通；
（2）含义：查看模块与模块之间、系统与系统之间能不能关联；
（3）工具：SOAPUI、POSTMAN、JMETER
5、性能测试：
（1）模拟我们真实的用户并发——测试系统最大的承受能力；
——简单来说，就是看我们的系统是怎么死的
（2）工具：LOADRUNNER（付费）,JMETER（开源）
6、自动化测试：
（1）把以人为驱动的测试行为转化为机器执行的一种过程；
（2）优点：可以模拟人工测试，减少重复机械的测试工作量，大量用于回归测试；
（3）工具：QTP、ROBOT、SELENIUM
7、安全测试：
（1）权限测试：主要是各种角色登录系统，查看各角色的权限是否得到控制；
（2）跨站脚本
（3）跨目录访问
（4）SQL注入
后三个在公司里一般是由专门负责安全测试人员去进行测试，会用到静态代码扫描工具（APPSCAN）进行测试。
8、兼容性测试：
BS架构——web项目——浏览器的兼容性；
CS架构——app项目——操作系统和硬件设备版本不同；
9、易用性测试：
（1）文字表达要清晰清楚；
（2）操作习惯等；
10、验收测试
11、随机测试：“猴子”测试，随意向系统输入操作，模拟真实用户操作。
十四、SIT和UAT阶段测试
1、SIT——集成测试——功能、接口 2-3轮
2、UAT——系统测试——全面测试（功能、性能、接口、测试、自动化、兼容性等）
2-3轮
1轮=1周
P.s. SIT阶段的功能至少要完成80%，并且提出的bug已经修复才能进入UAT阶段。
3、UT——冒烟测试——系统可以允许没有完成，达到70%的功能已经实现，至少主流程已经实现
十五、测试思维
1、先从测试种类方面去考虑。（界面、功能、接口、性能、兼容性、易用性、安全等）
2、根据这个产品的特色考虑到他的一些异常情况
十六、测试的原则
1、项目中要尽早投入测试人员；
2、在发现错误多的地方投入更多的精力和时间（二八原则）；
3、发现问题一定要指出；
4、并非所有的bug都能修复；
（1）轻微的问题，不影响项目功能使用可以放在下个版本去修复，但要请示领导，并且得到同意
（2）项目A数据有误，但已上线，我们是B项目，用到了A项目的数据，导致B项目数据有误，那么这种只能等到A项目把数据修正了，我们这边才能展示
5、追溯用户需求规格；
6、测试人员应该比开发人员更熟悉也无需求；
十七、相关职位缩写
DBA——数据库
PM——项目经理
SPM——部门经理
BA——需求人员
QA——质量管理员
QC——评审
1、QA：监督、跟踪我们项目过程中的每一步，审核我们所有的文档
2、项目组：
项目经理（必备）、测试经理、架构师、开发（必备）、测试（必备）、助理、运维、QA、BA（必备）
3、公司开发人员与测试人员的比例：3-4个开发——1个测试
十八、测试流程与阶段
1、需求文档——由BA根据客户需求写出的文档
2、需求分析——开发、测试、BA、项目经理或测试经理
3、测试计划——由测试经理或者测试组长编写的
4、测试方案——由测试经理输出
5、编写测试用例——测试人员
6、评审测试用例——修改测试用例（QC报告——相当于会议纪要）——再次评审
7、合格开始执行测试用例——相当于找bug的过程
8、发现bug——记录缺陷——提交至缺陷管理库
9、开发修复缺陷——回归测试——关闭缺陷
10、输出测试报告——测试经理或测试组长输出
十九、测试文档
测试计划、测试用例、测试报告、测试日报、测试周报、会议纪要、性能测试报告、用户使用手册
二十、静态测试
1、对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查
2、静态测试包括：代码测试、界面测试、文档测试等
二十一、动态测试
简单的理解：检查系统运行，输入数据和预测结果是否符合
二十二、测试用例方法
1等价类、2边界值
3因果图、4判定表
5场景法
6状态转换图
7大纲法
8正交排列法
9错误判断法
二十三、测试用例内容
1、需求编号——从需求文档上复制下来
2、需求名称——从需求文档中复制（例如淘宝中的男装、女装）
3、模块名称——复制（例如：女装中的连衣裙，短裙，上衣）
4、用例编号——根据需求编号往后+001开始递增（例如：需求编号FN08——用例编号FN08_001）
5、用例名称——唯一性，代表整条测试用例的核心
6、优先级——高、中、低
7、前置条件——特殊情况下使用
8、测试步骤——如何到达系统的页面，详细的记录下来
9、输入数据——使用到测试用例的方法和思维，决定整条测试用例质量
10、预测结果——跟需求文档保持一致
二十四、什么是测试用例
1、测试用例主要记录了测试的过程、步骤、输入的数据、预期结果等内容
2、它是在执行测试之前由测试人员编写的指导测试的重要文档
——测试用例=用例名称+操作步骤+输入数据+预期结果
二十五、测试用例的用途
1、防止遗漏功能点未测试
2、监督测试的过程
3、评估系统的质量
4、提高测试效率
5、缩短周期
二十六、编写测试用例参考文档
1、需求文档
2、用户手册
3、与BA（需求人员）、开发人员、测试人员等相关人员进行讨论
二十七、测试用例模板
1、Word或Excel（常用）
2、Quality Center中的TEXT PLAN模块（测试管理工具）
二十八、测试用例编写思路
1、正向思维
2、逆向思维
3、组合思维
4、全局思维
5、两极思维
6、简单思维
7、比较思维
8、发散思维
二十九、测试用例方法——等价类、边界值
1、等价类：
有效等价类：在取值范围内属于有效
无效等价类：在取值范围以外属于无效
优点：可以清晰的梳理被测对象
等价类随意挑选2-3组数据进行测试
2、边界值：
上点：需求设定点
内点、离点：±1的区别（边界值核心）
主要用于数值范围的使用
等价类、边界值需配合使用
三十、测试用例方法——因果图
1、通过画图的方式表达输入条件和输出条件之间的约束关系
2、“因”（原因）——输入条件 “果”（结果）——输出结果
3、一般——输入与输入的关系、输入与输出的关系
4、因果图的思想：因为什么原因产生了什么样的结果
5、因果图的基本符号（输入与输出的关系）：
恒等：（1）当输入条件发生时，结果一定会出现；
（2）当输入条件不发生时，结果一定不出现；
非：取反；（1）当输入条件发生时，结果一定不会出现；
（2）当输入条件不发生时，结果一定会出现；
或：（1）当多个输入条件，只要有一个条件满足，结果就出现；
（2）如果输入条件都不满足，则结果不满足；
与：（1）若几个输入条件都满足，结果才出现
6、因果图的约束条件（输入与输入的关系）：
E互斥（异）：如果选，只能选一个，可以不选
I包含（或）：至少选一个，可以多选但不能不选
O唯一：必须选，且只能选一个
R要求：如果a=1，则要求b必须是1
M屏蔽（非）：取反
7、因果图的优缺点
优点：可以快速的梳理业务逻辑关系。条件、组合、限制关系
缺点：每个人的想法有差异，导致用例的条数不一致
三十一、测试用例方法——判定表
1条件桩、条件项、动作桩、动作项
2条件=条件桩
3用例条数：结果状态的（条件数）次方
结果的状态=动作桩
3、9种测试用例方法，没有哪一种是完胜的，需要配合使用
4、判定表的应用步骤
（1）理解需求，确定条件桩和动作桩
条件桩=输入条件 ，动作桩=输出结果的状态
（2）设计和优化我们的判定表
（3）填写动作项，也就是它的业务逻辑
（4）根据判定表中输出结果的表现，进行判定表的合并（不一定非得做此操作）
——简化判定表（如果输出相同，在其对应的输入中，有且只有一个条件的取值，对动作不产生任何影响的，则可以合并）
（5）抽取测试用例
判定表给出的只是规则，不像边界值、等价类可以直接给出测试用例
（6）编写测试用例
5、判定表的优点
（1）能够将复杂的问题按照各种可能的情况全部列举出来；
（2）简单并避免遗漏；
（3）能够通过公式计算出测试用例总条数；
6、判定表的缺点
（1）输入条件之间的限制条件关系不好表达 解决方案：填写备注来描述限制关系；
（2）当输入次数过多，规则以2的N次方剧增时，判定表就会很庞大，这时候判定表会造成逻辑缺失，业务混乱，需要细致分析，尽可能划分多个需求项，再使用判定表；
（3）有重复的测试场景 解决方案：简化判定表
三十二、测试用例方法——场景法
1、基本流：按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）
2、备选流：导致程序出现错误的操作流程（模拟错误的操作流程）
三十三、测试用例方法——大纲法
1、在一个程序或程序的某个模块中，涉及到多个窗口，每个窗口中能够完成多个动作，这些窗口又互相联系。为了弄清楚窗口和窗口之间的关系，或者说动作与动作之间的关系，可以使用到测试大纲法。
2、大纲法适用于软件的安装程序测试，检查界面测试要点以及窗口之间的变化。
三十四、测试用例方法——正交排列法（正交实验法/优选法）
1、因子：所有参与实验的影响实验结果的条件——条件桩（例如：QQ登录，用户名字段）
2、水平：影响实验因子的取值或输入——条件项（输入框内输入的值）
3、正交表记为：
L是正交表的符号；
n是测试组合的次数（测试用例条数）；
k是表的列数（因子个数）；
m是水平数；
4、种类：
（1）水平相同正交表——公式：n=k*(m-1)+1（常用）
（2）混合水平正交表
5、正交表的优点：经过严格的数学推理而来，可以提高效率，正交排列法计算的测试用例是最优的，因此也叫优选法。
6、正交表的缺点：会漏掉一些测试场景 解决方案：根据错误推断法增加测试用例。
7、正交排列的步骤：
（1）看需求
（2）找出因子和水平个数
（3）通过公式计算出测试用例条数
（4）找到对应的试验号
（5）把控件及其取值映射到正交排列表中
（6）编写测试用例
（7）如果缺少测试场景，需要补充
9种测试方法总结
在工作中经常使用到的方法有：
等价类+边界值+因果图+场景法+错误推断法
【你是不是项目中的骨干？】
是。
1.测试的模块是项目的核心内容
2.我们项目组的测试计划报告都是我来出的，包括周报、日报的汇总
3.我会用Jmeter做性能测试，我们项目组的性能测试基本上都是我主导的
4.我自学了Python，然后会给项目组的其他成员进行技术分享
5.对接开发和其他系统的沟通基本也是我做的
【Web项目实战——美萍酒店管理系统】
三十五、测试流程与阶段
1.需求分析
2.测试计划
3.测试方案
4.编写测试用例、评审
5.执行测试用例、提bug单
6.回归测试输出测试报告
三十六、需求分析
1先看需求文档，了解整个项目的架构，找到自己所负责的模块
2将自己负责的模块，整体的流程弄清楚，然后再去了解细节内容
3再找到跟自己负责的模块有关联的模块，搞清楚他们之间的关系
和数据流通。
4找到自己测试模块对应的开发，然后进行需求确认，需求串讲
需求文档：
1.需求文档的目的是将需求的功能点梳理并且细化
2.是BA进行编写，但是要通俗易懂
3.为开发和测试人员提供依据
————在公司当中，不是所有的公司都有现成的项目给你进行参考的
需求确认：
确认、整理自己的模块功能，确保需求一致
1.整理不清晰需求
2.分别将以上需求点与需求人员和开发人员进行确认，保证需求的一致性和清晰性
三十七、测试计划
测试计划是描述了要进行的测试活动的范围、方法、资源和进度的文档
是对整个信息系统应用软件组装测试和确认测试
它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险
内容：
1.简介
1.1 产品简介
1.2 测试目的
1.3 测试范围
2.测试参考文档和测试提交文档
2.1 测试参考文档
2.2 测试提交文档
3.测试进度
4.测试资源
4.1 人力资源
4.2 测试环境
4.3 测试工具
5.问题严重性及优先级描述
5.1 缺陷严重级别定义
5.2 缺陷优先级定义
5.3 缺陷跟踪及测试版本
6.测试风险
6.1 时间资源
6.2 人力资源
6.3 测试版本
6.4 需求变更
6.5 其他
7.测试策略
7.1 用户界面测试
7.2 功能测试
7.3 性能评测
7.4 数据库测试
7.5 兼容性测试
7.6 安全性测试
8.总结
本次测试计划保证了项目地正常进行，但具体还需根据项目的进度操作。
目的：
测试计划可以有效预防计划的风险，保障计划的顺利实施
三十八、测试方案
目的：在方向上明确要怎么测，以及达到什么样的质量标准
（测试工程师需要基于产品功能和测试方案来设计和执行测试用例，同时也要参考产品设计说明文档）
软件测试方案有助于软件项目成员理解和执行测试过程中的各项活动，同时测试方案也有助于测试活动的管理
测试计划和测试方案的区别：
|
测试计划 |
测试方案 |
|
|
组织方式不同 |
管理文件 |
技术文件 |
|
目的不同 |
强调“做什么” |
强调“怎么做” |
|
具体要求不同 |
组织架构、工作任务分配、工作量评估、人力物力资源分配、进度的安排、风险把控和规避、以及各任务通过的准则等。 |
测试需求的细化、测试组流程设计、自动化测试框架设计、测试数据和测试脚本设计、测试用例设计的方法等。 |
总而言之，测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，而测试方案明确“怎么做”
测试方案总结：
此方案明确了测试方向，细化了需求与业务流程，并在技术方面写出了具体测试方法和应有的验收质量标准，也为后续编写测试用例提供参考。
三十九、测试用例
【基本规范】
1.首行冻结
2.边框为虚线
3.标题要设置背景颜色并且加粗
4.折叠栏以模块的形式划分
5.不能有错别字，错的标点符号
6.字体统一，最好为11
7.从需求编号——预期结果为电脑屏幕正常显示，不需要拖动查看
8.风格统一
【思路】
1.界面
2.控件
3.功能
4.关联、组合功能
5.数据的校验
大颗粒度——归类清晰
小颗粒度——覆盖全面
【你一天能写多少测试用例？】
大颗粒度——40-50条
小颗粒度——200条
【测试用例的文件名】
项目名+版本号+测试用例
【说明】
机密等级：绝密（只能高层领导查看）、机密（本项目组的人查看）、秘密、公开
四十、测试用例的评审
测试用例评审之后，我们将有问题的地方进行修改
【测试用例需要随时更新？】
需求变更、代码改动，测试用例随时改变
四十一、缺陷报告的处理流程
【bug的标题】
【模块名称】进入xxx页面，类型与身份证号码不匹配也能查询成功
提bug单的原则：有图有真相（截图）
缺陷报告——bug单
严重程度：致命、严重、一般、轻微
【如果出现问题一定会提单吗？】
1.先看一下是属于什么样的问题。界面的问题，我们可以先记录下来，进行跟踪。
2.其他的问题，一定要提单
四十二、禅道
赋予权限——赋予测试人员的权限
——可以提bug单，也可以查询我们项目组甚至我们公司内部所有项目的bug单
——不能删除自己的bug单，也不能删除别人的bug单
——不能提重复和无效的bug单（再三检查和确认）
——不允许修改
——可以到处查看测试用例
【到公司的第一步】打开电脑
【第二步】打开邮箱和沟通工具
【问题】
测试这边测试的第一个模块出现的问题跟第二个模块出现的问题一致，是要归类为一个问题还是分开写两个问题？
具体问题具体分析
1.两个模块出现同样的问题，两个模块是由同一个开发人员做的，只需要提一个bug单
2.两个模块出现同样的问题，两个模块是由不同的开发人员做的，可以提2个bug单，方便跟踪
3.比如说，第一个模块和第二个模块出现同一个问题，你可以提一个单，然后马上在工作群把这个问题暴露出来
注意：如果一个问题在多个模块出现，那么就要注意这个问题，并且在工作群知会其他人
补充：
在工作中你发现了一个bug，但是开发不承认，你如何跟他沟通，处理这个事情？
1、截图，找出问题，重现给开发人员看
2、如果这个时候开发还是不承认，就找自己的直接领导测试经理去说明这个问题的重要性，让他进行沟通
3、测试经理这时候一般会找项目经理沟通
测试报告：
含义：
测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。
APP项目
常见缺陷：功能实现错误，功能未实现或只实现了部分，APP崩溃（最常见问题，影响比较严重）
四十三、安装，卸载测试要点
常见缺陷：
1. 安装过程中出现闪退
2. 安装完成后，点击APP无反应
3. 安装完成后，点击APP出现闪退
4. 已存在旧版本但不卸载旧版本，进行新版覆盖时，版本号更新，内容没有更新
测试要点：
1. 应用是否可以在IOS、Andriod不同系统版本上安装
2. 软件安装后是否可以正常运行，安装后的文件夹及文件是否有相应提示
3. 安装过程中是否可以取消，安装空间不足时是否有相应提示
4. 检查安装包是否齐全
5. 如果应用需要通过网络验证之类的安装，需测试在断网时有无相应提示
6. 是否可以删除程序（通过桌面删除和软件卸载）
7. 卸载后是否会会删除全部文件
8. 卸载过程异常（死机，来电，闹钟弹窗等），在环境恢复后是否可以正确卸载
9. 卸载过程是否支持取消功能，单击取消之后软件情况是否正常
四十四、软件更新测试要点
1. 当客户端有新版本时，有更新提示
2. 确保Android软件更新版本时，安装运行正常
3. 确保IOS更新会有限制，正式版只有上了商店且有新版本才能更新
4. 用户取消更新旧，旧版本可正常使用，下次启动时仍提示更新
5. 有新版本时，不删除客户端的情况下，可直接更新，更新后版本正确
6. 必须支持跨版本更新
四十五、用户界面
1. 不符合UI设计或与界面原型不一致
2. 图片显示不完全，按钮显示错乱，请求新页面的内容成功返回后和原来的页面内容重叠，在编辑框输入过长的内容等
3. 上拉刷新或者下拉刷新时出现页面加载错误
四十六、功能测试要点
1. 验证在不同的屏幕分辨率、操作系统和运营商等多个设备上的APP行为
2. 用新发布的操作系统验证APP行为
3. 验证在如隧道、电梯等网络质量突然变差的环境中的APP行为
4. 通过手动改变手机网络（从Wi-Fi—手机网络或反过来）验证APP行为
5. 验证在没有网络的环境中APP的行为
6. 验证来电/短信和设备特定提醒（如闹钟）和通知时APP的行为
7. 通过改变设备的方向，以不同的视图模式，验证APP行为
8. 验证内存不足时APP的行为
9. 通过测试工具施加荷载验证APP行为
10. 用不同的支持语言验证APP行为
四十七、性能测试要点
1. 首次启动时长
2. 运行加载时间
3. 进入某个页面的时间
4. 启动某一有动画效果的界面，动画执行过程
5. 响应某一用户事件时的响应时间
6. 长时间运行后，随机出现卡顿现象
7. APP出现黑白屏
8. APP崩溃
9. APP使用时，电量、流量消耗
10. APP使用时对CPU、内存的消耗情况
11. 服务器无法响应，报HTTP500错误等
四十八、交叉事件（交叉测试、冲突测试）
测试要点（APP的优先级不能高于手机的主要功能电话，短信，闹钟等）
1. 多个APP同时运行是否影响正常功能
2. APP运行时前/后台切换是否影响正常功能
3. APP运行时拨打/接听电话
4. APP运行时发送/接收短信
5. APP运行时发送/接收邮件
6. APP运行时切换手机网络（2G,3G,4G,WIFI等）
7. APP运行时浏览网络
8. APP运行时使用蓝牙传送/接收数据
9. APP运行时使用相机、计算器等手机自带工具
四十九、用户体验测试要点
1. 界面不美观，不符合主流用户使用习惯，菜单层次太深，相关的选项离得太远
2. 页面加载时间过长（2-5-10原则）
3. 页面排版过长
4. 不友好的导航，缺少返回按钮
5. 过期的内容或信息
6. 死链接或错误链接
7. 缺少互动内容（意见反馈、客服通道等）
