简介这是一份大学生毕业实习日志合集来自西南民族大学软件工程专业学生在重庆桂珞软件开发有限公司软件测试岗位的30篇记录面向正在准备毕业实习、需要撰写实习日志或初入测试行业的在校生。日志按日期覆盖入职第一天办理手续、熟悉项目文档到后期独立进行基础指标和指标分析模块的测试、编写测试用例、使用SVN和Bugfree等版本控制与缺陷跟踪工具并包含浏览器兼容性测试、数据流图整理等具体任务。除记录工作内容外作者还针对公司文档管理混乱、理论文档与实际开发脱节等问题提出了个人观察并结合软件测试、项目管理、需求规格说明书、UML建模等知识点展开反思强调英语对学习国外技术资料的重要性。资源为1个doc格式文档压缩包大小68KB可直接借鉴日志结构与写作思路。目前已有422人学习下载适合需要参考真实软件测试实习经历、了解软件公司工作流程的大学生。1. 第一天不写用例先看文档测试基线与现实落差2013年2月我以软件测试实习生的身份进入重庆桂珞软件开发有限公司。入职当天没有代码、没有测试环境项目主管丢来一句话用一周时间熟悉正在做的项目。所谓的熟悉就是抱回几份不同版本的Word文档来回翻。更打击人的是程序员告诉我手头这份软件需求规格说明书基本不能用于开发。文档版本混乱、数据字典缺失、UML图示规则记错这些在网上查软件测试基础知识时根本不会遇到的坑在入职第一周集中爆发。这段经历给我留下一个反直觉的结论软件测试流程的第一步往往不是写用例而是先把被测对象读明白。文档基线都定不下来后面提交的每条bug都可能因为文档过期被驳回。对刚入行或中途加入存量项目的测试新手来说理清文档链路比多背几条用例模板更值钱。2. 从需求规格说明书到数据字典测试文档链路怎么读软件测试实习生上岗第一周的常态是看文档但看什么、按什么顺序看、看到什么程度算完没人会主动告诉你。我当时的顺序是需求规格说明书、详细设计说明书、数据字典中间还补画了数据流图。这套链路如果读得细后面写用例就不用到处追着开发问。2.1 多版本SRS并存基线版本由谁确认公司刚起步每个程序员都按自己的想法写过规格说明书汇总版本残缺不全。主管对此的解释很直接项目文档可以在最后按客户要求补。这句话听起来随意却暴露了测试者最容易踩的陷阱——如果连当前待测系统对应哪个版本的SRS都确认不了测试发现的所谓缺陷很可能只是文档没更新。我当时犯的错是抱着修改时间最新的版本埋头读了一整天最后被程序员告知版本不对。正确的做法是第一天就确认测试基线问项目主管当前代码对应哪个版本、上次评审是哪天、有没有在SVN上打tag。小团队如果没有tag机制就以文档修订记录加评审日期为锚点把版本号写进自己的测试计划。项目中常见的文档和测试之间的关系可以整理成下面这张对照表。文档类别内容对测试的作用需求规格说明书SRS功能边界、业务规则、页面流转编写测试用例的直接依据详细设计说明书SDS模块划分、接口定义、数据库设计构造测试数据、确认字段约束数据字典字段类型、长度、默认值、枚举值边界值、非法值用例的来源数据流图DFD数据来源、去向、存储过程报表和接口测试的路线图提示中途加入项目的测试人员开口先问当前基线版本是什么比问需求是什么更能得到有效答案。2.2 数据字典缺失时把后台元数据读出来实习期间测试系统管理模块时我发现数据字典描述和实际后台对不上导致无法判断ID字段到底允许什么格式。文档不给力测试不能停。常见的做法是直接连测试库读元数据用数据库自己提供的信息补齐数据字典缺口。-- Oracle查询目标表的字段名、类型、长度和是否可空 SELECT column_name, data_type, data_length, nullable FROM user_tab_columns WHERE table_name CUSTOMER_INFO ORDER BY column_id;这段SQL的作用是把表结构的权威信息从数据库里拉出来而不是靠文档猜。column_name返回字段名data_type返回字段类型data_length是字段最大长度nullable标记是否允许NULL。如果测试环境是MySQL需要换成information_schema.columns视图再把data_length替换为character_maximum_length逻辑一致。拿到真实字段约束后再去写用例边界值才有依据。一个长度32的字段到底该测31、32还是33完全由表结构决定而不是测试者拍脑袋。2.3 UML序列图箭头细节与数据流图工具实习第二天在详细设计文档里闹了个笑话我一直以为序列图的消息是双向箭头结果翻参考书发现不是。UML序列图中同步调用用实心三角箭头表示异步消息用开放箭头表示返回消息是虚线箭头。文档里画成双向箭头通常是把通信图的符号混了进来。这个细节看似无关紧要但读详细设计时理解错了交互方向构造出来的用例场景就会偏。数据流图同样让我吃了工具不熟练的亏。当时用Word画DFD调整连线花了大半天效率极低。画数据流图的核心是标清外部实体、处理过程、数据存储和数据流四类元素工具选draw.io这类免费软件就够用没必要在Office排版上耗时间。数据流的字段名称必须找编码人员逐一核对否则画出来的图只是纸上流程。3. Bugfree、SVN与浏览器兼容测试环境的第一张工具清单入职前我以为缺陷记录用Word就能搞定版本管理靠系统管理员手动备份浏览器兼容测试装几个浏览器就行。第一周结束发现这三种想法全都不对。缺陷跟踪、版本控制、浏览器兼容矩阵是测试环境的第一组基础设施。3.1 Bugfree里的缺陷生命周期和Word记bug差在哪Bugfree是开源缺陷管理系统界面朴素但提供了Word根本无法实现的缺陷生命周期新建、激活、解决、关闭外加回归验证。每一个缺陷从提交到关闭都有状态流转记录谁改的、什么时候改的、为什么重新打开全程留痕这比在Word里贴一张截图再敲几行描述可靠得多。字段测试者怎么填严重程度致命 / 严重 / 一般 / 轻微优先级紧急 / 高 / 中 / 低所属模块模块名称加页面入口缺陷类型功能错误 / 界面问题 / 数据问题 / 兼容性问题复现步骤前置条件、操作步骤、实际结果、期望结果缺陷报告和测试用例一样字段缺失比描述啰嗦更致命。后来在别的项目里见过测试新手只写一句页面报错没有环境信息也没有操作步骤开发根本无从下手。缺陷工具本身不解决问题规范填写字段才是协作效率的关键。3.2 SVN命令行与Eclipse不同步的坑实习时遇到一个典型问题在SVN上更新数据后Eclipse里总是显示不出来最后把工作区搞坏三个同事修了半小时。现在复盘根因是Eclipse的SVN插件和命令行SVN操作的是同一个工作副本但Eclipse资源树有本地缓存外部命令更新后界面不会自动刷新。# 进入工作副本根目录 cd /workspace/company-project # 从服务器拉取最新版本 svn update # 查看工作副本状态M已修改 A新增 D删除 ?未纳入版本控制 svn status # 提交前先看自己改了什么确认无误再提交 svn diff src/main/java/com/company/module/Calc.java svn commit -m 修复排序字段类型错误svn update不带路径参数时默认更新整个工作副本svn status用于检查本地改动svn diff是提交前自检的习惯动作避免把调试代码提交上去svn commit -m后面的提交信息必须写清楚改了什么。出现Eclipse不刷新的情况先右键项目执行Team - Synchronize或者用F5刷新后Project - Clean不要在没搞清缓存机制前乱删.metadata目录那是Eclipse的本地配置删掉后所有项目配置都会丢失。3.3 浏览器兼容矩阵Chrome容错好不代表能跳过IE当时测试基础指标模块发现IE和360浏览器里有些模块根本显示不出来Chrome却能正常打开。Chrome渲染引擎对不规范CSS和JavaScript的容错能力强IE内核在这里就严格得多。360浏览器当时采用双核模式兼容模式调用IE内核极速模式走Chromium内核同一个页面在两种内核下表现可能完全不同。做兼容性测试第一步不是装一堆浏览器逐个点而是跟项目组确认支持矩阵项目声明兼容哪些浏览器、哪些版本、哪些内核。第二步按矩阵逐模块过一遍把功能缺失问题记成高优先级把纯样式显示差异记成低优先级。第三步要理解编码阶段的兼容问题可以先记录不修复等界面冻结后再集中回归而不是每次发现显示差异就打断开发。4. 黑盒测试用例设计一个小模块为什么需要十几个用例实习时写基础指标模块的用例一个功能点编了十几个用例我当时觉得夸张。后来明白黑盒测试的用例设计是有方法拆的不是拍脑袋凑数。正常流、异常流、权限流三条线走下来十几个用例是常态不是过度测试。4.1 一个功能点拆成十几条用例正常流、异常流、权限流以基础指标录入为例一个功能点可以拆成六类场景正常录入、空值、超长、非法字符、重复提交、无权限操作。每个场景对应一条用例放到同一张表里管理。用例编号场景前置条件步骤与输入预期结果优先级TC-0521正常录入已登录且具备录入权限输入合法指标名称和单位点击保存保存成功列表刷新高TC-0522名称为空同上名称留空其余合法点击保存提示指标名称不能为空高TC-0523名称超长同上输入33个字符限制32阻断提交并提示超长中TC-0524非法字符同上名称包含英文引号、尖括号提示不能包含特殊字符或自动转义中TC-0525重复提交同上双击保存按钮只产生一条记录无重复数据高TC-0526无权限用户使用只读账号登录进入录入页面提交按钮置灰或被拒绝高表里每一行都是一个独立场景组合起来才构成完整的功能验证。TC-0524提到转义而不是直接拒绝是因为不同系统的设计取向不同预期结果要依据需求判断不能想当然。4.2 边界值与诡异字符测试成本和质量成本的平衡实习生会在ID输入框里填奇怪字符被程序员批评苛刻。现在回看这个冲突的实质是边界值分析法和项目定位之间的博弈。测试者做输入校验测试没有错但系统面向专业用户产品团队可以基于开发成本决定砍掉部分防御式校验。测试者不能默默删除用例而是把这类用例标记为建议类在评审时交给产品决策。给一个服务端入参校验的示例这是接口层面防止非法字符的常见做法也是测试者编写自动化校验用例时的参考对象# 服务端对用户ID的入参校验非空、长度不超过32、不含SQL元字符 INVALID_CHARS set(\\\;) def validate_user_id(user_id): if not user_id or len(user_id) 32: return False return all(c not in INVALID_CHARS for c in user_id) # 使用 Python 自带 unittest 框架做边界值覆盖 import unittest class UserIdValidationTest(unittest.TestCase): def test_empty(self): self.assertFalse(validate_user_id()) def test_ok_32(self): self.assertTrue(validate_user_id(u * 32)) def test_over_32(self): self.assertFalse(validate_user_id(u * 33)) def test_injection(self): self.assertFalse(validate_user_id(1; DROP TABLE users;--)) if __name__ __main__: unittest.main()validate_user_id是接口层的入参校验函数INVALID_CHARS定义了需要拦截的SQL元字符集合英文引号、反斜杠、尖括号、分号都在其中unittest是Python自带的单元测试框架assertFalse和assertTrue用于断言函数返回值。边界长度31、32、33三条用例保证限制规则被完整覆盖。测试报告里如果出现建议增加输入校验这类风险提示应写明校验规则和受影响接口产品负责人才能评估是否需要投入成本。4.3 错误扎堆先查公共包再查数据类型基础指标模块、客户数据模块、质量改进模块连续两个星期在不同模块发现同类错误。我当时很困惑不同程序员写的不同模块为什么会犯同样的错老前辈给出两个方向恰好覆盖了这类问题的常见根源。第一个方向是公共包。如果多个模块继承同一个基础包而这个包是同一个作者维护的包里的缺陷会沿着继承关系扩散到所有模块。第二个方向是数据源。排序和筛选的异常如果集中在同类型字段上而这类字段全部来自同一张数据库表或同一个接口错误也会批量出现。定位公共包问题的一个技巧是用SVN blame查看文件每行代码的版本和作者# 查看公共包文件的每一行是谁、哪个版本引入的 svn blame -v \ https://svn.company.com/project/trunk/src/common/query.py-v参数会在输出中追加版本号和作者列通过blame可以快速锁定问题代码第一次进入仓库的版本再配合svn log查看当时的提交说明基本能还原引入原因。数据侧则用SQL检查字段取值分布-- 找出字段取值中的异常分布确认问题来自脏数据还是代码 SELECT type_code, COUNT(*) FROM base_metric GROUP BY type_code ORDER BY COUNT(*) DESC;type_code是类别字段COUNT(*)统计每个类别下的记录数。如果发现某个异常取值数量明显异常说明数据写入环节可能存在问题需要开发配合排查。对测试者而言错误扎堆意味着回归范围要扩大——公共包或公共数据源修复之后所有引用方模块都要回归不能只测发现缺陷的那一个。4.4 两个标签页不同步会话问题还是开发期缓存问题实习时发现一个现象同一个浏览器开两个标签页用相同账号登录同一个系统在一个标签页里提交修改另一个标签页要延迟一段时间才能看到效果。项目组长解释这是开发期为了方便调试屏蔽了部分页面缓存。这个现象在测试中很容易误报为数据不一致缺陷。判断方法很简单换两个不同的浏览器登录同一账号如果修改能及时同步说明服务端数据没有问题差异来自页面局部状态或缓存如果不同浏览器也出现同样延迟才需要考虑会话共享或数据同步问题。并发测试时尽量使用不同浏览器或不同浏览器Profile而不是同一个浏览器开多个标签页这样可以避免把浏览器自身的会话隔离机制当成系统缺陷。5. 回归测试与报表数据核对缺陷优先级怎么定项目严重滞后之后主管把周任务改成按天排期测试也进入高强度回归状态。回归测试跑哪些、报表数据怎么验、饼图该不该换这些问题背后其实是同一件事测试者要有一套判断优先级的规则而不是发现什么就报什么。5.1 回归测试范围P0到P3四级划分项目赶进度时没有时间把整个系统每个版本完整回归一遍按风险分级是必然选择。常见的做法是把回归范围分成四级P0只验证本次修改的功能P1覆盖直接调用方P2覆盖公共包和公共数据源影响面P3做存量功能抽查。优先级回归范围执行时机P0本次修改的功能做冒烟验证每次提测P1直接关联模块和主业务流程每次提测P2公共包、公共数据源影响的所有模块每周至少一次P3存量功能抽样按核心路径抽30%里程碑版本前错误扎堆现象出现时P2范围的回归权重就要提高。如果一个公共查询方法被修复所有调用该方法的功能模块都要回归排序、筛选、分页而不是只测当初报缺陷的那一个入口。软件测试流程里的回归顺序从P0到P3逐级推进才能保证有限的测试时间花在风险最高的地方。5.2 报表中心黑盒测不准就对着数据库算报表中心模块的数据繁杂纯黑盒测试很难判断数字对错。当时我请求项目经理安排接触数据库设计小组搞清楚了报表的数据来源和接口关系再回去测报表思路完全不一样。报表测试的核心方法就是数据核对把报表页面展示的汇总值和数据库按相同口径聚合出来的结果做比对。-- 核对上月各区域订单量、订单金额是否与报表中心展示一致 SELECT region, COUNT(order_id) AS order_cnt, ROUND(SUM(amount), 2) AS total_amount FROM sales_order WHERE settle_date DATE_FORMAT(DATE_SUB(CURDATE(), INTERVAL 1 MONTH), %Y-%m-01) AND settle_date DATE_FORMAT(CURDATE(), %Y-%m-01) GROUP BY region;COUNT(order_id)统计订单行数SUM(amount)累加订单金额ROUND把金额保留两位小数DATE_SUB(CURDATE(), INTERVAL 1 MONTH)把当前日期回拨一个月再配合DATE_FORMAT格式化成当月1号。这样无论测试哪天执行查询窗口始终是上月整月SQL可以反复使用。比对结果不一致时先和开发确认报表数据源是明细表还是统计表。如果系统先把明细汇总到统计表再供报表读取统计表刷新失败就会造成页面数据与实时数据不一致。提示报表核对尽量在测试库执行涉及金额的查询不要在生产环境运行。5.3 缺陷优先级矩阵饼图该换不该换谁说了算质量监控模块的饼图开发因为找不到合适的比例图用另一张图临时替代。测试者的职责是把这个差异描述清楚而不是跟开发争论你必须换。合适的方式是把缺陷记录完整附上设计效果与实际效果的截图注明开发反馈缺少素材资源然后让产品负责人决定是否安排美工支持。严重程度出现频率建议优先级高高紧急高低高低高中低低低优先级矩阵的核心思想是严重程度和出现频率两个维度共同决定处理顺序。饼图被替代的问题严重程度为一般、频率为低按矩阵应该定级为低优先级但它直接影响客户对质量监控功能的直观理解所以要单独标注客户可见影响让产品决策时不遗漏业务视角。测试者要学会把技术事实和业务影响分开写而不是把所有问题都标成紧急。6. 测试文档的初审与复审缺陷清单如何变成交付材料测试文档第一次初审顺利通过第二次复审需要向主管们逐条解释。回头看初审和复审的区别在于初审看格式和完整性复审看表达和决策依据。测试文档既是程序员修bug的线索也是客户验收系统的依据两种读者的需求完全不同。6.1 测试文档客户看不懂是致命伤初版测试报告里我把数据库报错原文直接贴到了缺陷摘要中经理看后问了一句客户看到这个会怎么想这才意识到测试文档是交付材料不是测试笔记。缺陷描述可以包含技术细节但风险提示和客户视角结论部分必须用业务语言重写。# 测试报告质量监控模块v0.4 ## 基本信息 - 测试周期2013-03-25 至 2013-03-29 - 测试环境Windows 7 / IE9 / Chrome 31 / 360浏览器 - 用例统计120 条用例通过 112失败 5阻塞 3 ## 客户视角的结论 - 核心功能可用报表类功能存在数据展示差异。 - 建议上线前完成一轮数据核对测试。 ## 缺陷明细 | 编号 | 模块 | 严重程度 | 优先级 | 摘要 | 状态 | |------|------|----------|--------|------|------| | BUG-1024 | 质量监控 | 中 | 中 | 饼图被替代为其他图形客户可见差异 | 待产品决策 |基本信息给出测试窗口和环境客户视角的结论用两句话讲清系统现状缺陷明细保留技术定位。同一份文档里不同章节服务不同读者这是测试报告的基本结构。6.2 复审的讲述结构现象、复现、影响、建议复审时主管会挑最严重的几个缺陷提问准备阶段要按现象、复现、影响、建议四段式组织材料而不是照着缺陷列表从头念到尾。被问到你电脑上能复现、程序员机器上复现不了时先对比环境差异浏览器版本、操作系统、系统主题再复述操作步骤和时间点最后把验证手段落到换一台干净环境重试上而不是停留在我这边就是有的争论。复查要点说明环境信息完整浏览器、操作系统、分辨率复现步骤可执行每一步都有明确输入预期与实际分离不能混写在一句话里影响范围明确涉及哪个模块、哪些角色优先级设置合理严重程度高必须对应高优先级术语可读性检查客户不理解的地方是否补充了业务翻译本文还有配套的精品资源点击获取 软件测试实习手记：从文档基线到回归测试的完整实战指南
简介这是一份大学生毕业实习日志合集来自西南民族大学软件工程专业学生在重庆桂珞软件开发有限公司软件测试岗位的30篇记录面向正在准备毕业实习、需要撰写实习日志或初入测试行业的在校生。日志按日期覆盖入职第一天办理手续、熟悉项目文档到后期独立进行基础指标和指标分析模块的测试、编写测试用例、使用SVN和Bugfree等版本控制与缺陷跟踪工具并包含浏览器兼容性测试、数据流图整理等具体任务。除记录工作内容外作者还针对公司文档管理混乱、理论文档与实际开发脱节等问题提出了个人观察并结合软件测试、项目管理、需求规格说明书、UML建模等知识点展开反思强调英语对学习国外技术资料的重要性。资源为1个doc格式文档压缩包大小68KB可直接借鉴日志结构与写作思路。目前已有422人学习下载适合需要参考真实软件测试实习经历、了解软件公司工作流程的大学生。1. 第一天不写用例先看文档测试基线与现实落差2013年2月我以软件测试实习生的身份进入重庆桂珞软件开发有限公司。入职当天没有代码、没有测试环境项目主管丢来一句话用一周时间熟悉正在做的项目。所谓的熟悉就是抱回几份不同版本的Word文档来回翻。更打击人的是程序员告诉我手头这份软件需求规格说明书基本不能用于开发。文档版本混乱、数据字典缺失、UML图示规则记错这些在网上查软件测试基础知识时根本不会遇到的坑在入职第一周集中爆发。这段经历给我留下一个反直觉的结论软件测试流程的第一步往往不是写用例而是先把被测对象读明白。文档基线都定不下来后面提交的每条bug都可能因为文档过期被驳回。对刚入行或中途加入存量项目的测试新手来说理清文档链路比多背几条用例模板更值钱。2. 从需求规格说明书到数据字典测试文档链路怎么读软件测试实习生上岗第一周的常态是看文档但看什么、按什么顺序看、看到什么程度算完没人会主动告诉你。我当时的顺序是需求规格说明书、详细设计说明书、数据字典中间还补画了数据流图。这套链路如果读得细后面写用例就不用到处追着开发问。2.1 多版本SRS并存基线版本由谁确认公司刚起步每个程序员都按自己的想法写过规格说明书汇总版本残缺不全。主管对此的解释很直接项目文档可以在最后按客户要求补。这句话听起来随意却暴露了测试者最容易踩的陷阱——如果连当前待测系统对应哪个版本的SRS都确认不了测试发现的所谓缺陷很可能只是文档没更新。我当时犯的错是抱着修改时间最新的版本埋头读了一整天最后被程序员告知版本不对。正确的做法是第一天就确认测试基线问项目主管当前代码对应哪个版本、上次评审是哪天、有没有在SVN上打tag。小团队如果没有tag机制就以文档修订记录加评审日期为锚点把版本号写进自己的测试计划。项目中常见的文档和测试之间的关系可以整理成下面这张对照表。文档类别内容对测试的作用需求规格说明书SRS功能边界、业务规则、页面流转编写测试用例的直接依据详细设计说明书SDS模块划分、接口定义、数据库设计构造测试数据、确认字段约束数据字典字段类型、长度、默认值、枚举值边界值、非法值用例的来源数据流图DFD数据来源、去向、存储过程报表和接口测试的路线图提示中途加入项目的测试人员开口先问当前基线版本是什么比问需求是什么更能得到有效答案。2.2 数据字典缺失时把后台元数据读出来实习期间测试系统管理模块时我发现数据字典描述和实际后台对不上导致无法判断ID字段到底允许什么格式。文档不给力测试不能停。常见的做法是直接连测试库读元数据用数据库自己提供的信息补齐数据字典缺口。-- Oracle查询目标表的字段名、类型、长度和是否可空 SELECT column_name, data_type, data_length, nullable FROM user_tab_columns WHERE table_name CUSTOMER_INFO ORDER BY column_id;这段SQL的作用是把表结构的权威信息从数据库里拉出来而不是靠文档猜。column_name返回字段名data_type返回字段类型data_length是字段最大长度nullable标记是否允许NULL。如果测试环境是MySQL需要换成information_schema.columns视图再把data_length替换为character_maximum_length逻辑一致。拿到真实字段约束后再去写用例边界值才有依据。一个长度32的字段到底该测31、32还是33完全由表结构决定而不是测试者拍脑袋。2.3 UML序列图箭头细节与数据流图工具实习第二天在详细设计文档里闹了个笑话我一直以为序列图的消息是双向箭头结果翻参考书发现不是。UML序列图中同步调用用实心三角箭头表示异步消息用开放箭头表示返回消息是虚线箭头。文档里画成双向箭头通常是把通信图的符号混了进来。这个细节看似无关紧要但读详细设计时理解错了交互方向构造出来的用例场景就会偏。数据流图同样让我吃了工具不熟练的亏。当时用Word画DFD调整连线花了大半天效率极低。画数据流图的核心是标清外部实体、处理过程、数据存储和数据流四类元素工具选draw.io这类免费软件就够用没必要在Office排版上耗时间。数据流的字段名称必须找编码人员逐一核对否则画出来的图只是纸上流程。3. Bugfree、SVN与浏览器兼容测试环境的第一张工具清单入职前我以为缺陷记录用Word就能搞定版本管理靠系统管理员手动备份浏览器兼容测试装几个浏览器就行。第一周结束发现这三种想法全都不对。缺陷跟踪、版本控制、浏览器兼容矩阵是测试环境的第一组基础设施。3.1 Bugfree里的缺陷生命周期和Word记bug差在哪Bugfree是开源缺陷管理系统界面朴素但提供了Word根本无法实现的缺陷生命周期新建、激活、解决、关闭外加回归验证。每一个缺陷从提交到关闭都有状态流转记录谁改的、什么时候改的、为什么重新打开全程留痕这比在Word里贴一张截图再敲几行描述可靠得多。字段测试者怎么填严重程度致命 / 严重 / 一般 / 轻微优先级紧急 / 高 / 中 / 低所属模块模块名称加页面入口缺陷类型功能错误 / 界面问题 / 数据问题 / 兼容性问题复现步骤前置条件、操作步骤、实际结果、期望结果缺陷报告和测试用例一样字段缺失比描述啰嗦更致命。后来在别的项目里见过测试新手只写一句页面报错没有环境信息也没有操作步骤开发根本无从下手。缺陷工具本身不解决问题规范填写字段才是协作效率的关键。3.2 SVN命令行与Eclipse不同步的坑实习时遇到一个典型问题在SVN上更新数据后Eclipse里总是显示不出来最后把工作区搞坏三个同事修了半小时。现在复盘根因是Eclipse的SVN插件和命令行SVN操作的是同一个工作副本但Eclipse资源树有本地缓存外部命令更新后界面不会自动刷新。# 进入工作副本根目录 cd /workspace/company-project # 从服务器拉取最新版本 svn update # 查看工作副本状态M已修改 A新增 D删除 ?未纳入版本控制 svn status # 提交前先看自己改了什么确认无误再提交 svn diff src/main/java/com/company/module/Calc.java svn commit -m 修复排序字段类型错误svn update不带路径参数时默认更新整个工作副本svn status用于检查本地改动svn diff是提交前自检的习惯动作避免把调试代码提交上去svn commit -m后面的提交信息必须写清楚改了什么。出现Eclipse不刷新的情况先右键项目执行Team - Synchronize或者用F5刷新后Project - Clean不要在没搞清缓存机制前乱删.metadata目录那是Eclipse的本地配置删掉后所有项目配置都会丢失。3.3 浏览器兼容矩阵Chrome容错好不代表能跳过IE当时测试基础指标模块发现IE和360浏览器里有些模块根本显示不出来Chrome却能正常打开。Chrome渲染引擎对不规范CSS和JavaScript的容错能力强IE内核在这里就严格得多。360浏览器当时采用双核模式兼容模式调用IE内核极速模式走Chromium内核同一个页面在两种内核下表现可能完全不同。做兼容性测试第一步不是装一堆浏览器逐个点而是跟项目组确认支持矩阵项目声明兼容哪些浏览器、哪些版本、哪些内核。第二步按矩阵逐模块过一遍把功能缺失问题记成高优先级把纯样式显示差异记成低优先级。第三步要理解编码阶段的兼容问题可以先记录不修复等界面冻结后再集中回归而不是每次发现显示差异就打断开发。4. 黑盒测试用例设计一个小模块为什么需要十几个用例实习时写基础指标模块的用例一个功能点编了十几个用例我当时觉得夸张。后来明白黑盒测试的用例设计是有方法拆的不是拍脑袋凑数。正常流、异常流、权限流三条线走下来十几个用例是常态不是过度测试。4.1 一个功能点拆成十几条用例正常流、异常流、权限流以基础指标录入为例一个功能点可以拆成六类场景正常录入、空值、超长、非法字符、重复提交、无权限操作。每个场景对应一条用例放到同一张表里管理。用例编号场景前置条件步骤与输入预期结果优先级TC-0521正常录入已登录且具备录入权限输入合法指标名称和单位点击保存保存成功列表刷新高TC-0522名称为空同上名称留空其余合法点击保存提示指标名称不能为空高TC-0523名称超长同上输入33个字符限制32阻断提交并提示超长中TC-0524非法字符同上名称包含英文引号、尖括号提示不能包含特殊字符或自动转义中TC-0525重复提交同上双击保存按钮只产生一条记录无重复数据高TC-0526无权限用户使用只读账号登录进入录入页面提交按钮置灰或被拒绝高表里每一行都是一个独立场景组合起来才构成完整的功能验证。TC-0524提到转义而不是直接拒绝是因为不同系统的设计取向不同预期结果要依据需求判断不能想当然。4.2 边界值与诡异字符测试成本和质量成本的平衡实习生会在ID输入框里填奇怪字符被程序员批评苛刻。现在回看这个冲突的实质是边界值分析法和项目定位之间的博弈。测试者做输入校验测试没有错但系统面向专业用户产品团队可以基于开发成本决定砍掉部分防御式校验。测试者不能默默删除用例而是把这类用例标记为建议类在评审时交给产品决策。给一个服务端入参校验的示例这是接口层面防止非法字符的常见做法也是测试者编写自动化校验用例时的参考对象# 服务端对用户ID的入参校验非空、长度不超过32、不含SQL元字符 INVALID_CHARS set(\\\;) def validate_user_id(user_id): if not user_id or len(user_id) 32: return False return all(c not in INVALID_CHARS for c in user_id) # 使用 Python 自带 unittest 框架做边界值覆盖 import unittest class UserIdValidationTest(unittest.TestCase): def test_empty(self): self.assertFalse(validate_user_id()) def test_ok_32(self): self.assertTrue(validate_user_id(u * 32)) def test_over_32(self): self.assertFalse(validate_user_id(u * 33)) def test_injection(self): self.assertFalse(validate_user_id(1; DROP TABLE users;--)) if __name__ __main__: unittest.main()validate_user_id是接口层的入参校验函数INVALID_CHARS定义了需要拦截的SQL元字符集合英文引号、反斜杠、尖括号、分号都在其中unittest是Python自带的单元测试框架assertFalse和assertTrue用于断言函数返回值。边界长度31、32、33三条用例保证限制规则被完整覆盖。测试报告里如果出现建议增加输入校验这类风险提示应写明校验规则和受影响接口产品负责人才能评估是否需要投入成本。4.3 错误扎堆先查公共包再查数据类型基础指标模块、客户数据模块、质量改进模块连续两个星期在不同模块发现同类错误。我当时很困惑不同程序员写的不同模块为什么会犯同样的错老前辈给出两个方向恰好覆盖了这类问题的常见根源。第一个方向是公共包。如果多个模块继承同一个基础包而这个包是同一个作者维护的包里的缺陷会沿着继承关系扩散到所有模块。第二个方向是数据源。排序和筛选的异常如果集中在同类型字段上而这类字段全部来自同一张数据库表或同一个接口错误也会批量出现。定位公共包问题的一个技巧是用SVN blame查看文件每行代码的版本和作者# 查看公共包文件的每一行是谁、哪个版本引入的 svn blame -v \ https://svn.company.com/project/trunk/src/common/query.py-v参数会在输出中追加版本号和作者列通过blame可以快速锁定问题代码第一次进入仓库的版本再配合svn log查看当时的提交说明基本能还原引入原因。数据侧则用SQL检查字段取值分布-- 找出字段取值中的异常分布确认问题来自脏数据还是代码 SELECT type_code, COUNT(*) FROM base_metric GROUP BY type_code ORDER BY COUNT(*) DESC;type_code是类别字段COUNT(*)统计每个类别下的记录数。如果发现某个异常取值数量明显异常说明数据写入环节可能存在问题需要开发配合排查。对测试者而言错误扎堆意味着回归范围要扩大——公共包或公共数据源修复之后所有引用方模块都要回归不能只测发现缺陷的那一个。4.4 两个标签页不同步会话问题还是开发期缓存问题实习时发现一个现象同一个浏览器开两个标签页用相同账号登录同一个系统在一个标签页里提交修改另一个标签页要延迟一段时间才能看到效果。项目组长解释这是开发期为了方便调试屏蔽了部分页面缓存。这个现象在测试中很容易误报为数据不一致缺陷。判断方法很简单换两个不同的浏览器登录同一账号如果修改能及时同步说明服务端数据没有问题差异来自页面局部状态或缓存如果不同浏览器也出现同样延迟才需要考虑会话共享或数据同步问题。并发测试时尽量使用不同浏览器或不同浏览器Profile而不是同一个浏览器开多个标签页这样可以避免把浏览器自身的会话隔离机制当成系统缺陷。5. 回归测试与报表数据核对缺陷优先级怎么定项目严重滞后之后主管把周任务改成按天排期测试也进入高强度回归状态。回归测试跑哪些、报表数据怎么验、饼图该不该换这些问题背后其实是同一件事测试者要有一套判断优先级的规则而不是发现什么就报什么。5.1 回归测试范围P0到P3四级划分项目赶进度时没有时间把整个系统每个版本完整回归一遍按风险分级是必然选择。常见的做法是把回归范围分成四级P0只验证本次修改的功能P1覆盖直接调用方P2覆盖公共包和公共数据源影响面P3做存量功能抽查。优先级回归范围执行时机P0本次修改的功能做冒烟验证每次提测P1直接关联模块和主业务流程每次提测P2公共包、公共数据源影响的所有模块每周至少一次P3存量功能抽样按核心路径抽30%里程碑版本前错误扎堆现象出现时P2范围的回归权重就要提高。如果一个公共查询方法被修复所有调用该方法的功能模块都要回归排序、筛选、分页而不是只测当初报缺陷的那一个入口。软件测试流程里的回归顺序从P0到P3逐级推进才能保证有限的测试时间花在风险最高的地方。5.2 报表中心黑盒测不准就对着数据库算报表中心模块的数据繁杂纯黑盒测试很难判断数字对错。当时我请求项目经理安排接触数据库设计小组搞清楚了报表的数据来源和接口关系再回去测报表思路完全不一样。报表测试的核心方法就是数据核对把报表页面展示的汇总值和数据库按相同口径聚合出来的结果做比对。-- 核对上月各区域订单量、订单金额是否与报表中心展示一致 SELECT region, COUNT(order_id) AS order_cnt, ROUND(SUM(amount), 2) AS total_amount FROM sales_order WHERE settle_date DATE_FORMAT(DATE_SUB(CURDATE(), INTERVAL 1 MONTH), %Y-%m-01) AND settle_date DATE_FORMAT(CURDATE(), %Y-%m-01) GROUP BY region;COUNT(order_id)统计订单行数SUM(amount)累加订单金额ROUND把金额保留两位小数DATE_SUB(CURDATE(), INTERVAL 1 MONTH)把当前日期回拨一个月再配合DATE_FORMAT格式化成当月1号。这样无论测试哪天执行查询窗口始终是上月整月SQL可以反复使用。比对结果不一致时先和开发确认报表数据源是明细表还是统计表。如果系统先把明细汇总到统计表再供报表读取统计表刷新失败就会造成页面数据与实时数据不一致。提示报表核对尽量在测试库执行涉及金额的查询不要在生产环境运行。5.3 缺陷优先级矩阵饼图该换不该换谁说了算质量监控模块的饼图开发因为找不到合适的比例图用另一张图临时替代。测试者的职责是把这个差异描述清楚而不是跟开发争论你必须换。合适的方式是把缺陷记录完整附上设计效果与实际效果的截图注明开发反馈缺少素材资源然后让产品负责人决定是否安排美工支持。严重程度出现频率建议优先级高高紧急高低高低高中低低低优先级矩阵的核心思想是严重程度和出现频率两个维度共同决定处理顺序。饼图被替代的问题严重程度为一般、频率为低按矩阵应该定级为低优先级但它直接影响客户对质量监控功能的直观理解所以要单独标注客户可见影响让产品决策时不遗漏业务视角。测试者要学会把技术事实和业务影响分开写而不是把所有问题都标成紧急。6. 测试文档的初审与复审缺陷清单如何变成交付材料测试文档第一次初审顺利通过第二次复审需要向主管们逐条解释。回头看初审和复审的区别在于初审看格式和完整性复审看表达和决策依据。测试文档既是程序员修bug的线索也是客户验收系统的依据两种读者的需求完全不同。6.1 测试文档客户看不懂是致命伤初版测试报告里我把数据库报错原文直接贴到了缺陷摘要中经理看后问了一句客户看到这个会怎么想这才意识到测试文档是交付材料不是测试笔记。缺陷描述可以包含技术细节但风险提示和客户视角结论部分必须用业务语言重写。# 测试报告质量监控模块v0.4 ## 基本信息 - 测试周期2013-03-25 至 2013-03-29 - 测试环境Windows 7 / IE9 / Chrome 31 / 360浏览器 - 用例统计120 条用例通过 112失败 5阻塞 3 ## 客户视角的结论 - 核心功能可用报表类功能存在数据展示差异。 - 建议上线前完成一轮数据核对测试。 ## 缺陷明细 | 编号 | 模块 | 严重程度 | 优先级 | 摘要 | 状态 | |------|------|----------|--------|------|------| | BUG-1024 | 质量监控 | 中 | 中 | 饼图被替代为其他图形客户可见差异 | 待产品决策 |基本信息给出测试窗口和环境客户视角的结论用两句话讲清系统现状缺陷明细保留技术定位。同一份文档里不同章节服务不同读者这是测试报告的基本结构。6.2 复审的讲述结构现象、复现、影响、建议复审时主管会挑最严重的几个缺陷提问准备阶段要按现象、复现、影响、建议四段式组织材料而不是照着缺陷列表从头念到尾。被问到你电脑上能复现、程序员机器上复现不了时先对比环境差异浏览器版本、操作系统、系统主题再复述操作步骤和时间点最后把验证手段落到换一台干净环境重试上而不是停留在我这边就是有的争论。复查要点说明环境信息完整浏览器、操作系统、分辨率复现步骤可执行每一步都有明确输入预期与实际分离不能混写在一句话里影响范围明确涉及哪个模块、哪些角色优先级设置合理严重程度高必须对应高优先级术语可读性检查客户不理解的地方是否补充了业务翻译本文还有配套的精品资源点击获取