深圳外贸建站与推广,网络传媒网站,连云港今天的新消息,2021网页qq登陆目录
#x1f33c;前言
一#xff0c;实习经历怎么写简历
#x1f339;业务理解
#x1f382;结构化表达
二#xff0c;实习
#x1f982;技术和流程卡点
#x1f511;实习收获 / 代码风格
三#xff0c;测试理论#xff0c;用例设计#xff0c;工具链
前言
一实习经历怎么写简历
业务理解
结构化表达
二实习
技术和流程卡点
实习收获 / 代码风格
三测试理论用例设计工具链
测试理论 / 用例设计
工作内容
四交互式 / 非交互式自动化测试实践
交互式自动化测试
非交互式自动化测试
手动确定覆盖率
五测试工程构建 / 主要业务
测试工程构建
主要业务API 的二次开发
概念
客户如何工作
API 和 平台的关系
六测试分级 / bug 排查 / 单元测试规范
测试用例分级
BUG排查 / 定位
测试模式
单元测试规范
优秀的单元测试
单元测试细节 / 项目单测流程
七代码质量问题案例
案例
POD 对象 前言 3个月的实习之前就面了 15 分钟闲聊 5 分钟隔天发的 offer 毕竟只是任务重招点实习生来打杂以下总结下实习经验 一实习经历怎么写简历
业务理解 ① 业务全套首先要弄清楚因为面试官不了解这个行业你能把前前后后的产品逻辑讲清楚他就觉得你学习能力还不错 ② 结合公司文档将公司文档中一些和自己平时工作有关联的东西加以记录和理解 不是在内网拷贝而且用自己话记录下来 后面面试时能讲清楚逻辑和细节就行 比如 RAII 机制的一些宏具体怎么实现的涉及 C11 的哪些特性解决了什么问题等等 ③ 实习中一整套的工作流程是怎样的有什么比较热门的技术在日常的功能测试交互式非交互式测试中使用了 ④ 或者你平时测试的那些 API 接口在整个业务的上下游整天的链路逻辑你处于哪个位置等 ⑤ 实习的一些收获比如干活前需要明确需求和 ddl防止返工大胆问 或者怎么处理分支冲突以及 Git Extension, GitLab 的使用还有宏失败了怎么处理 结构化表达 ① 实习经历分工作职责 / 技术和框架 / 实习收获三个方面去写 ② 比如使用 C Catch2 测试框架GenCMake 自动添加 CMake.mac 宏录制和自动化测试跑宏遇到一个新的接口怎么区测试的完整流程 ③ 实习做的东西比如写了 100 不同类型接口的测试用例完成 30 个接口覆盖率的提升发现 9 个接口 BUG3 天时间熟悉产品的基本操作 二实习
技术和流程卡点 ① 技术上最开始的宏录制容易失败因为存在无关操作比如点击了无关的点缩放了屏幕大小覆盖已保存的文件 或者没有区分不同类型的变量误判了父类型和子类型等等 ② 测试流程上不熟悉整个从 VS 检索接口注释到平台尝试复现 API 功能再到 VScode 搜索历史代码的整个流程 ③ 出现分支冲突不知道如何处理比如常见的 commit, pull merge, fetch all以及 stash, stash pop 等 分支冲突时可以注释他人的代码或者询问 mentor 谁修改了这个文件 ④ 部门沟通上你要和产品测试开发进行对接需要频繁的沟通以保证自己的工作效率比如人均 3 次 / 天 某个功能点产品比你了解的更清楚某个接口的具体实现问开发也是最好的选择 比如接口返回值位于平台哪里函数调用需要注意的点某些没跑进覆盖率的代码实现 ⑤ 遇到困惑的点积极跟 mentor 沟通不要闭门造车 实习收获 / 代码风格 ① 技术上熟悉了 Catch2 的部分操作学会处理分支冲突宏失败怎么排查以及记录遇到的问题避免重复提问还有 P1P2 功能性无效等价类边界异常场景的测试用例怎么写 ② 代码风格上首先避免使用 new / delete, malloc / free 这一套容易忘记释放导致内存泄露而应该使用 C_AUTO 类宏来声明指针数组句柄锁等 但是部分接口需要接收已有的地址就不能用 C_AUTO 宏来初始化而应该使用 C 自带的初始化比如 svxDeskFace deskFace{}; ③ 频繁被调用的代码可以封装为函数放到公用的头文件里 ④ 代码中注释不要太多但是基本的接下来上百行代码别人知道你在干什么就行比如 Catch2 的 WHEN(niu bi plus) 三测试理论用例设计工具链
测试理论 / 用例设计 ① 从公司文档学习白盒测试黑盒测试测试流程测试用例的设计过程 ② 讲讲你们自动化测试这一块的内容 ③ 实习时git 如何协作 ④ 公司的工具链是怎样的 工作内容 ① 主要工作API 二次开发自动化测试 ② 负责公司 API 的自动化测试优化覆盖率确保 API 功能与平台一致 ③ 使用 C 和 Catch2 框架进行单元测试和集成测试 ④ 使用 Git 进行版本控制参与 GitLab 分支管理合并分支冲突 ⑤ 通过录宏 / 跑宏交互式 / 非交互式相结合的方式测试 ⑥ 在 GitLab 登记问题提供详细复现步骤和日志文件便于开发快速定位问题 四交互式 / 非交互式自动化测试实践
交互式自动化测试 ① 利用公司平台已有的宏测试系统实现自动化测试 ② 优点测试上下文易构建通过平台操作测试场景容易扩展直接在平台添加测试宏 缺点交互式只能构建正常场景测试接口容易受其他模块干扰不贴合客户真实使用场景 ③ 适用场景平台命令封装类接口UI 界面相关的显示接口 非交互式自动化测试 ① 使用 Catch2 单元测试框架实现 ② 优点贴合客户使用场景更容易实现参数层面的枚举 缺点 测试上下文难构建只能调用其他 API 进行 部分入参难以确定 部分命令场景对入参有要求时难以使用现有 API 指定 ③ 适用场景数据查询类接口数学计算类接口 手动确定覆盖率 ① 当 OpenCppCoverage 的覆盖率还未更新需要手动获取覆盖率时 ② 可以在测试用例中每个调用 API 的位置打断点f11step into 源码 ③ 找到 API 的实现后在每个小分支的入口处都打上断点然后针对测试用例中调用的 API不断 step into在源码中 continue ④ 每跑进源码的一个小分支就取消分支入口处断点 ⑤ 最后源码中尚未取消的断点就是源码未覆盖的分支然后针对未覆盖分支处调用的其他 API 和 参数找开发问一下 五测试工程构建 / 主要业务
测试工程构建 ① 类似启动 vs 工程时双击 .sln 的操作双击 generate.bat 构建出对应的 msbuild 工程并启动 VS2019 ② 一个测试用例的构建包括 a. 测试场景的初始化测试上下文的构建 b. 执行被测试的 API 接口 c. 对测试结果断言检查 ③ 对于 Catch2 测试框架平台的运行环境属于全局变量声明周期存在于整个测试流程中所以每个测试场景运行结束时无法自动还原环境需要手动还原 主要业务API 的二次开发
概念 ① 二次开发就是在现有软件的基础上进行定制修改和功能扩展实现自己想要的功能 ② 客户需要借助二次开发的 API 进行开发 ③ 这个 API 接口可以理解为根据客户的要求将平台内部的某个函数再做一层封装和处理后再给用户使用 ④ 二次开发的 API 接口一般对应平台的一个功能或子功能而对于客户来说他只需要知道 API 的函数名功能以及输入输出 客户如何工作 ① 客户在开发环境中引用二次开发 API 的头文件声明链接静态库 .lib实现就可以直接使用这批接口 ② 客户通过这批 API实现自己的功能并且把代码封装成一个函数将函数注册成自定义命令然后编译生成动态库.dll也就是二次开发插件 ③ 接着运行我们的平台加载 .dll 插件就能使用用户自定义的功能了 API 和 平台的关系 ① API 测试一般对应界面上某个功能与平台交互就能测试 或者通过调用平台内部的功能函数进行测试 所以对 API 进行测试也能测到平台的功能 ② API 测试用例失败可能是二次开发 API 的问题也可能是对应功能的内部函数出了问题 ③ 平台命令 / 底层函数的变更也会对 API 产生影响 a. 显示影响api 对应某个命令命令发生了变化比如增加了入参选项对应的 api 也要同步更新 b. 隐式影响 api 使用了某个内部函数 或 底层机制额你不函数逻辑变更或机制变更 ④ 在不确定项目对 api 是否有影响时 a. 开发要主动向 api 开发进行确认 b. 测试也要提升 api 的覆盖率并且及时全量地运行 api 自动化测试检测项目是否引入 api 问题master 主干分支每周进行集成测试 六测试分级 / bug 排查 / 单元测试规范
测试用例分级 ① 功能性有效等价类输入性 功能性边界对平台运行环境的影响 a. 有些接口会影响全局变量导致当前接口运行正常但是其他测试用例因此失败 ② 健壮性无效等价类 其他常见错误异常场景 a. 接口会针对不同的错误场景返回不同的错误码 一类错误码客户经常犯的非法输入便于客户调试问题 另一类错误码针对接口内部或平台底层代码的处理出现异常内存错误读取对象数据失败便于开发排查问题 b. 还要根据接口本身的功能测试的经验反推可能存在的错误场景 ③ 易用性命令规范接口易用注释正确 ④ 兼容性 ⑤ 效率测试 ⑥ 回归测试 BUG排查 / 定位 ① 逐步排查接口 bug 时不要用 for会增大排查难度 ② 复现问题定位问题用例 / 环境 / 接口实现 / 平台功能查阅文档和源码覆盖率分析和断点测试和开发产品测试沟通猜想与验证查看日志内存检测 ③ 特别注意接口的依赖关系 前置条件 易混淆类型 测试模式 ① 传统测试模式 使用 TEST_CASE 定义单元测试 (test_name [,tags]) {} test_name测试用例名称任意的需要全局唯一 tags标签名用 [] 将每个标签抱起来逗号分隔不用全局唯一 ② BDD模式 行为驱动开发behaviour driven development通过在 GIVENWHENTHEN 中自然语言书写测试用例的信息扩展了测试驱动开发的方法 Ⅰ 其中GIVEN 前提条件 测试场景初始化 构建入参 Ⅱ 然后WHEN 做的事情 执行被测试 api Ⅲ 最后THEN 结果 对 api 调用后的返回值入参出餐进行检测 单元测试规范 ① 平台的测试案例使用 BDD-style一个完整的单元测试案例包括 Arrange初始化Action执行Assert断言 ② 编码原则边界正确输入设计与需求相结合错误输入预期结果 ③ 编码规范每个文件只对应一个接口 所有单元测试案例必须有描述 ④ 测试维度 接口功能性接口的正确性 一定条件下正常被调用 返回预期结果 局部数据结构变量是否有初始值 变量是否溢出、 边界指针 数值 字符串 集合 异常处理异常可否被识别 识别后是否有处理 ⑤ 使用 OpenCppCoverage 工具分析测试用例对代码的覆盖率 优秀的单元测试 a. 自动化的 b. 很容易实现 c. 第二天还有意义 d. 任何人都可以一键运行 e. 运行速度很快 f. 结果稳定多次运行同一个测试用例总是返回相同的结果 g. 能够完全控制被测试的单元 h. 完全隔离的不依赖其他所有测试用例 i. 如果它失败了可以很容易发现什么是预期的结果可以很快定位问题所在 单元测试细节 / 项目单测流程 单元测试细节 a. 底层遗留代码的测试静态测试开发自己代码走查 动态测试编写测试用例 b. 是否为所有共有接口编写用例资源有限时有限覆盖高频关键危险接口 c. 推动开发改造接口剔除非必要接口提高接口容错能力重构复杂接口配套demo测试 d. 测试方案确定子模块测试顺序获取接口清单 和 调用频次重点关注危险行为 e. 测试过程对照接口标注和注释检查逻辑完整性异常处理全局变量使用边界等 f. 测试用例编写结合黑盒 / 白盒逻辑覆盖边界错误场景补充模拟平台实际调用发挥想象力设计异常输入 项目单测流程 Ⅰ 输入项目核心文档 设计方案 Ⅱ 输出测试方案 测试报告 用例代码 Ⅲ 执行流程 a. 初步拟定测试方案用例清单 b. 用例评审上级项目经理项目开发 c. 搭建测试环境测试场景构建 d. 引入开发代码运行测试用例 e. 反馈测试结果bug 跟踪生成测试报告 f. 开发人员处理 bug 后进行回归测试 g. 测试代码集成开发源码集成后 -- 集成多个组件模块合并到同一个系统 h. 测试用例加入主干定期测试 七代码质量问题案例
案例 ① 超大文件 单个源文件几千行很难维护和理解如果某个超大的 .cpp被多个人同时修改合并冲突的概率就会大大增加影响开发效率 ② 超长函数 函数超过 200 行逻辑复杂难以测试和复用如果某个超长函数被修改容易引发连锁 bug导致回滚上线 void processOrder() {// ... 500行代码 ...} ③ 超长的类 类中成员变量和方法过多违反单一职责原则最好拆分为多个小的类按功能聚合 ④ 单个函数多个职责 一个函数既做数据校验又做业务处理还做日志记录 void handleUserRequest() {validateInput();processBusiness();logOperation();
}
// 建议拆分为 validate(), process(), log() 三个函数 ⑤ 需要频繁更新的函数 频繁变动的函数容易引入回归 bug如果某个函数的逻辑频繁变动未做好单元测试容易导致线上事故 ⑥ 不必要的接口依赖 如果模块 A 依赖模块 B 内部的实现导致 A 的变更影响 B最好进行接口隔离减少耦合 ⑦ 不必要的实现依赖 如果项目直接依赖第三方库的实现细节升级时风险很大容易产生大量编译错误 ⑧ 逆模块依赖的接口调用 如果低层模块反向依赖高层模块会破坏分层结构 ⑨ 模块私有接口被外部调用 本应只在模块内部使用的函数被外部调用导致维护困难 ⑩ 滥用全局变量 全局变量被多处修改难以追踪和调试比如被多线程同时修改导致数据错乱 ① 不必要的局部静态变量 静态变量声明周期长容易引发资源泄露或线程安全问题 ② 难理解的名称缩写 比如 tmp, foo, bar ③ 抽象的函数命名 比如 doTask(), handle()无法体现具体功能 ④ 不必要的模板编程 追求泛型而滥用模板编程导致代码复杂难懂新人难以上手维护 ⑤ 无意义的函数注释 注释应说明返回值入参出参边界注意事项等 // this is a function ⑥ 过长的参数列表 函数参数不要超过 5 个否则易出错考虑封装为结构体或对象传参 ⑦ 缺乏单元测试 无单元测试线上热修复容易引发故障 ⑧ 重复代码 同样的逻辑在多个地方实现维护成本高最好提取为公共函数或工具类 ⑨ 通用处理方法--插入大量针对个别对象的特殊处理逻辑 如主流程代码被特殊 case 污染导致难以阅读和修改 ⑩ 对非 pod 对象进行裸内存操作 如直接 memcpy, memset 非 POD 类型对象容易产生 undefined 行为 ⑩① 混合编码风格 C/C 混用代码风格不统一容易内存泄露 POD 对象
什么是 POD
Plain Old Data普通的旧的数据 POD 类型像 C 语言结构体那样没有复杂构造 / 析构函数没有虚函数没有继承没有非静态 C类 或 结构体 本质内存布局简单和 C 语言的 struct 一样可以安全使用 memcpy, memset 等 C 函数直接操作内存的对象 裸内存操作 直接对内存进行原始的字节级别的操作而不是经过对象的构造析构拷贝等 C 语义 比如 memcpy拷贝一段内存memset填充一段内存 malloc / free直接分配 / 释放原始内存块不调用构造 / 析构函数 realloc直接调整内存块大小 本质 ① 只关心内存的字节内容不关心对象的声明周期构造析构拷贝等 C 语义 ② 适用于 C 语言风格的 POD 老古董类型对象 ③ 对于有复杂成员std::string, vector, 虚函数, 继承等的 C 对象裸内存操作会破坏对象内部的状态导致 Undefined 行为 建议 ① 判断 POD 场景 a. 只有简单结构体全是 int, float, char 等基础类型的 struct b. 只要有 C 特性string, vector, 虚函数, 继承, 构造, 析构等就不是 POD ② 不要对非 POD 对象用 memcpy / memset 比如 struct User {std::string name;int age;
};User u1, u2;memcpy(u2, u1, sizeof(User)); // wrong! User not POD! ③ 安全做法 a. 对于非 POD 对象通过拷贝构造赋值运算符swap 等 C 标准方法不用 memxxx() b. 如果需要序列化 / 反序列化用 protobuf, json 等库不要直接 dump 内存 ④ 工程建议 a. 写工具类 / 测试代码时如果需要内存填充清零二进制比较需要确认对象是 POD b. 代码评审时看到 memcpy / memset 操作对象需要确认必须是 POD c. 如果对含 std::string 的 struct 做 memcpy()会导致线上服务频繁 core dump
