企业官网建设流程全解析

1. Web项目测试：Day02的核心定位与整体思路

先说结论：Web功能测试是软件测试这条路上绕不开的坎儿，几乎所有做这行的人都在它上面花过大量时间。Day02这个阶段，重点已经不是“什么是功能测试”“测试流程分几步”这种入门概念了，而是真正上手Web项目，把一个真实业务系统的功能点拆开、揉碎、逐项验证的过程。也就是说，Day02的核心不是理论，是“能用一套系统的方法把一个Web项目测明白”。

很多同学在这个阶段容易犯一个毛病：拿着测试用例一条条执行，执行完了就算完事，问他测的是什么业务，说不清楚；问他某个功能为什么这么设计，也答不上来。这就是所谓的“执行型测试”，机械、低效，测完对整个项目的质量心里没底。Day02要解决的问题，恰恰是从“照着用例点鼠标”过渡到“带着业务理解去设计用例、执行验证、判断结果”。

适配的对象也分两类：一是已经在培训机构或刚入行的测试新手，需要通过一个完整的Web项目实例串起基本功；二是做了一两年执行测试、缺少系统方法论的初级测试工程师，需要对已有经验做一次整理和升级。这天练好了，后面接触接口测试、自动化测试、性能测试时，你才有一个扎实的“业务底盘”。

那为什么非得是Web项目？原因很简单：Web项目的功能测试覆盖了最典型的测试场景——界面操作、数据交互、权限控制、状态流转、异常处理，这些东西在APP测试、小程序测试里同样存在，但Web项目在环境搭建和调试手段上更方便，浏览器开发者工具就是最好的“显微镜”，适合学习者建立完整的排查思路。

Day02常见的练习项目，一般是电商后台、员工管理系统、信息发布平台这类业务清晰的系统。我习惯用一个“员工信息管理系统”来演示，它麻雀虽小但五脏俱全，登录、增删改查、权限分配、搜索筛选、导入导出全都有，非常适合走完整套测试流程。下文的所有实例，我都基于这类系统展开。

2. 测试前的准备工作：先看需求，再定用例

2.1 需求文档和原型图怎么读

很多人拿到项目第一件事就是打开系统、开始点，这是效率最低的方式。正规的做法是先拿需求文档和原型图“磨刀”。

什么叫把需求文档读透？我给自己定了三条标准：

一是能说清楚这个系统给谁用。员工信息系统的话，使用人群有管理员、HR专员、普通员工，不同角色能做的事完全不一样。

二是能画出核心业务流程图。拿员工管理系统来说，核心流程就是“新增员工→录入信息→提交审核→审核通过→信息生效”，这个主链路里又有审批分支：审核不通过时要退回修改；员工离职时要关停账号且保留历史记录。

三是能圈出需求里的“隐含细节”。需求文档往往不会把每条规则都写上，比如手机号校验规则、身份证号格式校验、入职日期不能晚于当前日期等等，这些隐含约束是最容易漏测的地方。

读完需求后，我建议顺手列一份“业务规则清单”。不用太长，每条规则一行字，比如“手机号字段必须以1开头，共11位”“【员工姓名】字段必填，最长50个字符”“权限为普通员工的账号只能查看本人信息，不可查看薪资字段”。这份清单就是你设计用例的原始素材，后面写出来的每条用例都能在清单里找到出处。

2.2 环境搭建与冒烟测试

环境问题永远是测试新手的第一大坑。Day02做Web项目测试，至少要确认三件事：测试环境地址能访问、数据库里有预设的测试数据、浏览器版本和系统要求的版本一致。

我第一次带新人做这类练习时，光环境就折腾了好一阵——有人用旧版浏览器打开高版本应用，页面直接白屏；有人账号密码输错三次被锁了还以为是系统bug；有人数据库没初始化，一登录就报“查询无数据”的错。这些问题都不是产品缺陷，但会白白消耗测试时间，还会干扰判断。

所以，我强烈建议执行正式测试之前先做一轮“冒烟测试”。流程很简单：挑主流程的主功能，比如登录、打开首页、进入列表页、新增一条数据、退出登录，花半小时左右把“系统能否跑通”验证一遍。冒烟测试的作用不是找bug，是确认“这栋楼能不能进去”，如果连主流程都走不通，后面那些细致的用例测试根本没意义。

2.3 测试用例编写：覆盖到什么程度才算够

Day02阶段最常被问到的问题就是：一个功能到底要写多少条用例才算够？我的回答是：看风险，而不是看数量。

所谓风险，就是这个功能如果出问题，影响面有多大。拿员工信息系统举例，登录功能影响所有人，支付、薪资相关功能影响财务流程，这类必须重点覆盖；而像“修改个人头像”这类低风险功能，覆盖正常流程加一个异常分支就够了。我一般给新手一个参考比例：核心业务模块的用例占总用例量的60%以上，边缘功能只占20%以内，剩下的用于跨模块的关联场景。

用例设计方法方面，Day02至少要熟练用上这三种：等价类划分、边界值分析和场景法。

以“员工姓名”字段举例，用等价类可以划出三类输入：长度在1到50之间的有效姓名、空值、超过50个字符的无效输入。边界值法补充的是“1位、50位、51位”这几个临界值场景。为什么边界值这么重要？因为开发在写校验逻辑时，最容易在边界条件的判断上写错，很典型的就是把“大于等于”写成了“大于”，导致50个字符的合法输入被拒绝。

场景法更复杂一些，它要求按业务流程组合操作步骤，验证完整链路。比如“新增以’财务部’为部门的新员工，提交后由经理账号审核通过”，这个场景比单纯测表单校验更能暴露系统集成层面的问题。

Day02练习时，可以拿一张Excel表记录用例，字段至少包含：用例编号、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级、执行结果。这套格式看起来朴素，但足够真实，绝大多数中小型团队用的就是这类模板。

3. 功能测试用例设计：四个必须覆盖的方向

3.1 流程分支类用例：主流程通畅，分支流程更要通畅

Web项目的核心业务大多可以归纳为“一条主流程 + N条分支流程”。测试时最容易出现的偏差是只把主流程测顺了，分支流程草草带过。

拿员工管理系统的“新增员工”功能来拆解。主流程是：管理员登录→进入员工管理→点击新增员工→填写表单→提交→系统提示“新增成功”→列表中出现该员工记录。这个流程要测，但分支流程更多：

• 表单必填项未填写时点击提交，系统应给出明确的错误提示，且焦点定位到第一个错误字段；
• 员工编号已存在时提交，系统应拦截并提示“编号重复”；
• 填完表单后超过一定时间再提交，会话超时如何处理；
• 提交过程中网络中断，页面的表现是什么，重新操作后有没有产生一条半截数据。

分支流程中特别值得关注的是“中途放弃”和“重复提交”。中途放弃是指填写到一半用户点击取消或直接关闭页面，此时系统不应产生无效数据；重复提交是指用户对某个操作连续点击，比如双击提交按钮，这个场景在真实环境里非常常见，如果前端没有做防重复提交处理，后台就会出现两条一模一样的记录。

3.2 输入验证与边界值分析：表单测试的核心战场

Web项目中最常见的功能模块就是表单。只要涉及用户输入，输入验证就是测试的重中之重。

按字段类型来梳理，常见的需要验证的维度如下：

• 文本类字段：必填性、最大长度、特殊字符、首尾空格处理、HTML标签的过滤；
• 数字类字段：取值范围、整数/小数限制、负数是否允许、精度位数；
• 日期类字段：格式合法性、开始日期是否早于结束日期、闰年与跨年场景；
• 下拉类字段：选项数量、联动刷新、默认值是否正确；
• 上传类字段：类型限制、大小限制、文件名包含特殊字符的情况。

边界值的选取有一条经验法则：如果需求规定某个字段的最小值是1、最大值是100，那测试数据至少要覆盖0、1、2、99、100、101这六个数。这六个值分别对应“小于最小值、等于最小值、略大于最小值、略小于最大值、等于最大值、大于最大值”，基本能把开发最常见的判断错误全部暴露出来。

特别提醒一个细节：很多系统在前后端各做了一层校验，前端限制输入长度只能输入50字符，这种限制是用JS实现的，测试时不可以只在前端随便输几个字就算通过，必须用抓包工具绕过前端限制直接向后端提交超长数据，验证后端是否也有同样的校验逻辑。这个场景在真实项目中是出了名的“重灾区”。

3.3 权限与状态类用例：隐藏最深的坑往往在这里

Web项目测试里，权限和状态是最容易出现“开发自己都没想到”问题的领域。

权限类测试的核心方法是“角色对照法”。先把系统中的所有角色列全，再列出每个角色可操作的菜单和按钮，然后逐个角色去验证：这个角色能访问哪些页面、能操作哪些按钮、不能看到哪些字段。我在练习项目里一定会设置至少三种角色：系统管理员、部门经理、普通员工。测试时重点验证三类问题：越权访问、越权操作、数据隔离。

举一个实际的例子：普通员工A登录后，直接修改URL中的员工ID参数为B的ID，是否就能看到B的薪资信息？很多系统这一关过不去——页面上虽然不显示菜单入口，但只要知道接口地址或修改参数就能拿到别人的数据。这类问题通过界面点选很难发现，需要测试人员具备“参数猜测”的意识。

状态类测试则需要梳理业务对象的状态机。比如一条员工记录，在“新增-审核-生效-离职”这几个状态之间流转，测试时要覆盖每一个状态转换场景，尤其是“不允许的转换”。比如已经离职的员工记录，理论上不应该再允许修改其基本薪资，如果系统没有做状态限制，这就是状态控制缺陷。

3.4 异常与容错场景补充：稳定性的试金石

异常场景测试是Day02拉开层次的分水岭。新手只测正常流程，有经验的测试一定会专门测“操作错了会怎样”。

常用的异常场景包括：

• 服务器返回500错误时，页面有没有定制化的友好提示，还是直接展示一大段堆栈信息；
• 超时请求时，系统是卡死还是给出“请求超时，请重试”的提示；
• 后端返回数据格式异常时，比如接口约定返回JSON却返回了HTML，前端页面会不会渲染错乱；
• 删除某条数据后按浏览器的后退按钮，页面是否能正常显示。

这些场景每一条都可能花费不少时间，但判断项目产品质量时，它们往往是决定性因素。一个操作卡死、报错一堆乱码的系统，即使业务流程全部正确，用户依然会认为它是个“烂系统”。

4. 实操过程实录：从登录到核心业务场景的完整测试执行

4.1 登录模块的完整测试流程

以Day02的练习项目为例，我完整走一遍登录模块的测试执行过程，各位可以跟着这个思路复现。

第一阶段是“正常流程下的功能验证”。输入正确的管理员账号和密码，点击登录按钮，系统跳转到首页，右上角显示当前登录人的姓名和角色。这条用例通过后，再做“记住密码”和“自动登录”等附加功能的检查。这些附加功能也有自己的分支场景：比如不要勾选“记住密码”直接关闭浏览器，下次打开是否还保存账号信息。

第二阶段是“异常输入的验证”。错误密码、不存在账号、空账号、账号含前后空格、密码大小写混输，这些用例逐项执行，每一条都要记录实际结果。这里会遇到第一类常见bug：部分系统的登录接口对密码错误提示过于具体，比如“密码长度必须在8位以上”，这种提示虽然方便了用户，却也方便了攻击者试探密码规则，严格来说属于信息安全风险项。

第三阶段是“账号状态与安全的验证”。包括：账号锁定策略，连续输错N次密码后账号是否锁定、锁定时长是多少；密码加密传输，爬包看密码字段在请求中是否明文传输；退出登录后点击浏览器回退按钮，能否重新看到之前登录后的页面内容。

第四阶段是“兼容性与环境验证”。换不同浏览器分别执行一遍登录操作，记录页面显示和交互差异。很多系统在Chrome下正常，但到了旧版本Edge或某个特定版本浏览器下，界面错位、按钮无法点击的问题就会暴露。

每个阶段的执行结果都按“通过/未通过/阻塞/未执行”四种状态记录，未通过的用例必须关联缺陷记录。

4.2 核心业务场景：员工信息增删改查的操作细节

登录验证通过之后，进入核心业务模块。这里以“员工信息管理”为例，把一套标准的执行流程写出来。

先看“新增员工”的用例设计。我列的核心用例包括：

• 正确填写所有必填项，各项格式均合法，点击提交，系统给出“新增成功”的提示；
• 只填写必填项，可填项全部留空，提交是否允许通过；
• 某一个必填项未填写，点击提交，页面是否有明确提示，是否在该字段附近给出校验错误；
• 填写已存在的员工编号，点击提交，系统是否提示编号冲突；
• 填写超长姓名、非法手机号、未满18周岁的出生日期，系统是否能逐项拦截；
• 上传头像时选择超过大小限制的图片，系统是否有明确提示，且不影响其他字段的已填内容。

执行方式上，我建议每一条用例执行时都打开浏览器开发者工具的网络面板，观察提交数据。这个习惯很重要，尤其是检查表单提交的数据与界面填写内容是否一致，比如界面上电话号码显示为“13812345678”，但实际提交到后台的可能是“138 1234 5678”，说明前端做了格式转换但未在界面上回显。这类前后端数据不吻合的问题，光看界面很难发现。

再看“查询”功能。查询类功能测试的关键在于组合条件。员工列表页一般有多个筛选条件：部门、职位、入职时间区间、姓名关键字。测试时不能只测单个条件，要测条件组合。比如“部门=财务部 + 姓名包含’张’”时，结果是否同时满足两个条件；“部门=财务部 + 入职时间=2023年6月”无匹配记录时，是展示“暂无数据”还是空白页；清空条件后列表是否恢复全量数据。这些用例能有效验证查询SQL的拼接逻辑是否正确，特别是多条件用AND还是OR的关系极易出错。

执行“编辑”和“删除”时也有共性的检查点。编辑功能要验证：修改之前的数据在修改后是否保留历史记录；编辑后列表展示的数据是否立即刷新；编辑保存后的数据和详情页展示的数据是否一致。删除功能要验证：删除前是否有二次确认弹窗；删除后关联数据如何处理——比如员工被删除后，其名下历史操作记录是被同步删除还是保留“已删除员工”的占位信息，这个业务决策直接决定了系统数据的完整度。

4.3 缺陷的记录、分级与追踪闭环

测试过程中发现的问题，不能只在本地记一句“这个功能不行”，必须走缺陷记录流程。标准的缺陷单至少包含以下字段：

• 缺陷编号、标题和所属模块；
• 复现步骤、预期结果、实际结果；
• 严重程度（致命/严重/一般/轻微）和优先级（紧急/高/中/低）；
• 涉及的环境信息（浏览器、操作系统、测试地址）；
• 附件信息（截图、日志、报文数据）。

严重程度和优先级的区别常被混淆。严重程度衡量的是“这个问题给系统带来多大损害”，比如所有用户无法登录属于致命；优先级衡量的是“这个问题需要多快解决”，比如一个只在极低概率下出现的界面跳转错误，严重程度偏低，优先级也跟着低。但有一种情况要特殊处理：严重程度不高、但影响客户验收的问题，优先级会被人为调高，这就是测试人员需要积累的业务判断力。

我见过不少新人记录缺陷时只写“页面报错”四个字，这种缺陷单让开发去查要花大量时间，效率很差。好的缺陷标题应该写清楚“何地、何种操作、何种结果”，比如：“员工管理新增页面，录入50个字符的姓名保存后，列表页该字段被截断显示为30字符”。标题即结论，开发拿到后不需要追问就能开始定位。

缺陷提交后要追踪闭环：开发修复完成、更新状态后，测试人员必须在新版本环境上复测，确认“修复了旧问题且没有引入新问题”。这个“没有引入新问题”非常关键，所以复测时除了验证缺陷单描述的步骤，还要把同模块相关的几条主要用例一并回归。逻辑很简单：开发改动了一个函数，影响范围往往不止这一个点。

5. 常见陷阱与排查技巧：Day02最容易踩的坑，我都替你们踩过了

5.1 “环境问题”和“产品缺陷”的快速区分

测试过程中遇到一个报错，第一反应应该是：这个错是环境导致的，还是代码导致的？新手最容易在这个问题上纠结半天。

我的排查顺序是固定的：先看网络请求是否正常返回（F12开发者工具中的Network面板），再看请求的响应状态码（404、500、502、超时是不同含义），然后看报错信息是系统生成的提示还是后端返回的原始异常，最后检查测试数据本身有没有问题。

举个真实的例子：系统登录后首页数据始终加载不出来，页面一直转圈。我第一反应不是报bug，而是先用另一个账号登录看看。结果用管理员账号登录正常，只有当前账号不行，再查数据库，发现这个账号关联的员工数据被人为删除了，属于“孤儿数据”问题。这个问题的根源是测试环境中前一位测试同事操作时把关联数据删掉了，而不是系统缺陷。所以碰到类似场景，一定要先换账号、换浏览器、清缓存多试几次，排除个人环境因素后再决定要不要提交缺陷单。

5.2 测试数据的“脏”与“净”管理

功能测试里最影响效率的因素不是bug频率，而是测试数据不干净。系统里残留了之前测试时产生的半截数据，会把后续用例的执行结果全部带偏。

举例：测试员工列表的“按部门筛选”功能，预期财务部有3条数据，结果页面上显示了5条，我一查，发现其中两条是昨天测试“新增员工”时程序异常写入的脏数据。如果不先清理，这条用例就没法准确判断是对是错。

我的做法是，每个核心模块执行前先梳理数据准备清单。员工新增功能需要准备：不存在的员工编号、已存在的员工编号、长度为50的姓名、超长姓名、合法的手机号、非法的手机号、已离职员工的数据等。这些数据在正式执行前一次性准备好，按数据用途分类放进前置条件里。执行用例时尽量使用带有明确命名的数据，比如用户名用“测试员工01”，不要用“张三”“李四”这种容易混淆的名字。

此外，数据库里直接操作数据是测试人员的必备技能。练习项目中，我习惯通过数据库把某条员工记录的状态直接改为“已离职”，以便测试离职流程，而不必每次都把流程从头跑一遍。这比纯靠界面操作高效得多，但也意味着操作前必须确认数据影响范围，改错了要及时回滚。

5.3 时间不够用：如何取舍测试范围

Day02的课程时间是有限的，一个Web项目要测的内容又是海量的，不可能全部测完。取舍的关键是“风险优先”原则。

我会把要测的功能按照“影响面 × 出问题概率”排序，得分高的先测、多测。影响面指使用频率和业务关键程度，出问题概率可以根据代码复杂度和历史缺陷记录判断。拿练习项目举例，登录、员工新增、员工列表查询这几个功能得分最高，必须先测、测细；而“修改员工头像”这类低频功能，留到时间富余时再补充验证即可。

这里有个容易被人忽略的细节：无论时间多紧，冒烟测试都不能跳过。哪怕只剩半天，也要把主流程完整跑一遍。主流程都跑不通的项目，测再多细节也交付不了。这是我在项目现场得到的教训——有一次为了赶进度推迟了冒烟测试，结果把所有细节点测完之后才发现首页根本打不开，等于白干一场。

5.4 界面UI类问题的判断标准

功能测试虽然以功能为主，但UI相关的问题也会被记录。判断UI问题是否值得提交，标准不应该是“我觉得不好看”，而应该是“是否影响用户理解或操作”。

值得记录的例子包括：按钮文字被截断、必填项标识缺失、错误提示信息与当前输入框不匹配、表格列宽异常导致数据无法完整展示、页面在特定分辨率下出现水平滚动条导致操作按钮被遮挡。这些都属于可用性缺陷。

不值得记录的例子：字体颜色我不喜欢、按钮间距我觉得太大。这类主观审美体验，可以提，但不应该占用缺陷系统的正式资源。

还有一个实用技巧：发现UI问题时最好用浏览器开发者工具测量实际像素值，比如“按钮宽度只有80px，文字被截断”，而不是笼统地写“按钮看着不对劲”。带数据的描述更容易让开发信服，修复效率也更高。

6. 一点个人化的实操体会

做Web项目功能测试这两年，我最大的感触是：测试能力不是靠“测得多”堆出来的，而是靠“测之前想清楚”和“测之后复盘透”练出来的。Day02这一天，哪怕只把一个单模块测透，也比把十个模块草草点一遍有价值得多。

我习惯在每天的测试工作结束后做一件很小的事——把当天新发现的系统设计逻辑记下来，不记录bug本身，而是记录“这个系统的业务规则原来是这样的”。比如发现“离职员工不能再做过户操作”，“审核通过的员工信息不允许再直接修改”，这些规则不会出现在需求文档里，但它们决定了系统的业务边界。积攒一段时间之后你会发现，自己已经能预判一个功能可能存在的隐性规则冲突，这就是从执行者向测试设计者过渡的起点。

最后分享一个效率技巧：测试时保持“单一变量”原则。每次只改一个操作条件，比如要验证“登录后进入的是否为不同角色的对应首页”，就严格保证其他条件相同，只切换角色账号。这样可以最大限度减少变量干扰，让你记录的每一步实际结果都有据可循。这个方法看着简单，但实际执行时能坚持的人并不多，而坚持下来的人，往往也是缺陷定位最快的那一个。