Day 6 测试报告讲义

Day 6 测试报告讲义

0 主要内容

• 1 T4_测试结项报告
• 2 P2_敏捷项目流程
• 3 P3_禅道使用建议

1 T4_测试结项报告

1.1 什么是结项报告

结项，指的是测试活动的终止，close. 结项报告就是在测试活动终止的时候，输出的纸质文档。结项报告是整个测试过程收尾的一环，以下是结项报告建议的内容。

1.2 报告内容

• 项目概述
  • 被测试的项目（需求）具体内容
  • 该需求需要使用自动化测试的原因
  • 涉及到的自动化测试边界
• 测试方案
  • 使用的工具
  • 处理第三方代码
  • 测试用例脚本
    • 步骤
    • 断言
    • 执行
  • 组织业务逻辑
  • 参数化数据输入
  • 运行与测试报告生成
  • 设计结构图
  • 代码目录结构
• 测试结论
  • 项目能力描述
  • 项目风险评估
  • 项目缺陷问题
• 经验总结
  • 落地实施问题
    • 测试数据
      • 数据准备
      • 数据清理
      • 数据还原
    • 测试脚本
    • 业务抽离
    • 封装驱动
  • 代码技巧问题
    • 定位元素
    • 实例化驱动
    • 驱动的传递
    • 测试前置条件与测试清理操作
    • 断言的设置
    • 定位元素
      • frame
      • select
      • 动态id
      • 元素自动隐藏
    • 数据库验证
  • 编程规范问题
    • 命名引发的类级别常亮被重写
    • 方法命名
    • 方法操作的定义范围
    • 参数传递（传递字典）
  • 代码调试问题
    • 常见报错
    • 如何调试
  • 源代码管理的问题
    • 冲突？
      • 养成习惯，打开电脑，就 update
      • 修改之前，先update
      • 提交之前，同样 update
      • 修改以后，立刻提交 commit
    • PyCharm 中无法使用 subversion，提示命令行缺失：重新安装 TortoiseSVN，勾选所有的模块（命令行工具）
  • 测试分工的问题
    • 编写测试脚本
    • 编写Page
    • 维护定位符

1.3 报告作用

• 分析测试活动的优秀实践
• 整理测试过程的收获
• 描述被测试需求的真实情况
• 指导公司管理层的决策
• 提升敏捷团队的工作能力

2 P2_敏捷项目流程

2.1 敏捷 Scrum 知识

Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。

Snap1.jpg

不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周。

在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目。

在每次迭代的第一天，召开迭代计划会(Sprint Planning Meeting)。产品负责人会逐一挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和。一旦迭代开始，这些任务将不会发生大的变化。

在迭代期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的站立会议即每日立会 Daily Stand-up Meeting，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一张“燃烧图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，以观察和预测所有任务是否会按期完成。

在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开反思会(Retrospective Meeting)，对本次迭代中的成功与失败之处做出总结，并在以后迭代中进行改进。

• 两个清单

  • Product Backlog

    产品待开发项 Product Backlog是从客户价值角度理解的产品功能列表。

    • 功能、缺陷、增强等都可以是待开发项。
    • 一般以条目化的方式描述。
    • 客户和用户必须能够理解。
    • 描述怎样使用而非怎样制造。
    • 整体上从客户价值优先级排序。
    • 总工作量一般需要0.5～10人天。
    • 高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。

  • Sprint Backlog

    冲刺待开发项 Sprint Backlog是从开发技术角度理解的迭代开发任务。

    • 在简单的纯软件环境中，可以直接把产品待开发项当作冲刺待开发项分配到迭代中。
    • 在复杂的开发环境中，可以把一个产品待开发项分解为Web/后台……软件/硬件……程序/美术……等开发任务。

• 三个角色

  • Product Owner

    Product Owner（产品负责人）负责产品需求的提炼、条目化、优先级排序。
    现实世界的产品负责人

    • 部门经理、产品经理、策划人员等都可能做产品负责人。
    • 产品负责人是产品的指路人，必须对产品有长远的规划和深入了解，因此不能简单地选择销售人员甚至客户作为产品负责人。
    • 大型产品如嵌入式产品和网络游戏，常常使用有层级的产品负责人团队，来解决广度与深度的矛盾，如产品总监-产品经理 / 主策划-策划团队。

  • Scrum Master

    Scrum Master（Scrum“大师”）负责维护Scrum方法的秩序，并协助解决非技术问题。
    现实世界的Scrum Master

    • Scrum Master的工作方式是靠领导力(leadership)而非权力工作，因此首先应服务于团队。
    • 一种人选是原来的项目经理转型，保留原有的管理和技术职能，但弱化指派任务、下达时间点指令等内容，而增强其组织协调能力。
    • 另一种人选是企业原有的过程改进人员，协助不太了解Scrum的项目经理按照Scrum的方法工作，可以每人负责多个项目，接近全职的Scrum Master。

  • The Team

    Team（团队）以“自组织”的相对扁平方式进行管理，负责完成开发工作。
    现实世界的开发团队

    • 实际团队常常不是“扁平的”，而是仍有项目经理、小组长等职位。
    • 工作中他们以“共同估算”“跨职能工作”“共同跟进”等方式自组织工作，而不是完全依赖层层指令。
    • 项目经理、小组长的领导、指导、协同职能大于其指令职能。

• 四个仪式

  • 计划会：Sprint Planning Meeting
    • 迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
    • 产品负责人逐条讲解最重要的产品功能。
    • 开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。
    • 产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。
  • 每日立会：Standup Meeting
    • 队员认领任务（或由组长协商分发），独立或与别人一起完成任务。
    • 团队内部利用每日立会来沟通进度。
    • 开发团队利用燃尽图来展示整体进度。
    • 如无特殊原因，迭代期内无变更。
  • 评审会：Review Meeting
    • 小组向产品负责人展示迭代工作结果。
    • 产品负责人给出评价和反馈。
    • 以用户故事是否能成功交付来评价任务完成情况。
  • 反思会：Retrospective Meeting
    • 在每个迭代后召开简短的反思会。
    • 总结哪些事情做的好，哪些事情做的不好。
    • 制定改进计划。

Scrum 的使用有一些需要了解的基础知识背景，主要是角色和构件的介绍。

2.2 Scrum 角色

接下来主要介绍3个角色

敏捷三大角色.jpg

1. PO，Product Owner，产品负责人

   产品负责人是整个产品的负责人，主要做的事情是负责产品的进度、计划、需求和发布。对应禅道的“产品”功能。

2. SM，Scrum Master，敏捷教练

   这个是敏捷团队特有的角色，并不是项目经理，而是独立的个体，任务和职责是保证团队足够“敏捷”。这一点是禅道与Scrum 不一致的地方。禅道这里对应的是“迭代”或者“项目”。

3. TM，Team Member，团队成员

   敏捷团队中，包括项目经理，开发与测试。对应禅道的是：项目经理负责“迭代”里面的任务，任务是分配给开发和测试。同时禅道又单独区分了测试。提出了测试模块。

禅道与敏捷的对应，主要体现在“产品”和“迭代”这两块。

• 产品模块
  • 需求列表：对应 Product Backlog
  • 需求（用户故事）：对应 User Story
  • 发布计划：对应 Product Sprint 优先级
• 迭代（项目）模块
  • 需求列表：对应 Sprint Backlog
  • 需求细分任务：
    • 开发
    • 测试
    • UI
    • ……
  • 需求分解用例：
    • 测试
  • 版本：Sprint 发布

2.3 Scrum 流程

1. 迭代开始

• 每个小组：

1. 按照 计划会的文档 画燃尽图

2. 开站会（每天）

   1. 昨天做了什么
   2. 今天准备做什么（开始测试哪个需求？）
   3. 对目前的工作有无困难（阻碍）

3. 组长更新燃尽图

4. 组长在禅道中新建项目（迭代），关联产品，关联开计划会的需求。

   1. 登录禅道，组长新建项目（迭代），并且关联产品，设置团队成员。

      Snap3.jpg

   2. 根据计划会的内容（计划会挑选的需求），关联需求

      Snap4.jpg

      以接下来的一条需求为例，操作第五步

      Snap5.jpg

1. 根据计划会认领的需求（需求141，如上图），对指定的需求，创建测试任务，指派给相关人员

   Snap6.jpg
   Snap7.jpg

2. 根据计划会认领的测试任务，由组长或者测试人员自己添加任务

   以下图的 APP压力测试和WEB UI自动化验收测试为例，讲解此步骤

   编号	需求名称	所属模块	开发	开发时间	测试人员	测试时间
   105	普通用户注册	注册			XXX	1
   106	普通用户密码登录	登录				2
   120	新建项目	项目列表				1
   134	任务编辑
   109	邀请新成员	团队				1
   111	成员列表
   -	APP压力测试（monkey）
   -	WebUI自动化测试（验收）
   汇总	14个					14

   以上列表中，有编号的是需求，直接按照第五步，对需求，创建测试任务，指派给测试人员。

   无编号的，是针对产品的任务，直接在 项目（迭代） | 任务 中创建任务。

   Snap8.jpg
   Snap9.jpg

• 个人：

1. 在禅道中，进入 项目（迭代）| 任务，挑选目前需要做的任务，选定一条，点击开始。

   Snap10.jpg
   Snap11.jpg

2. 针对你要开始做的需求，编写一页纸测试计划，提交SVN。30分钟以内。并且在禅道的任务中，做相关工时记录。

   记录工时：

   Snap12.jpg
   Snap13.jpg

3. 在禅道中，针对指定的需求，创建用例，同时在禅道的任务中，做相关工时记录。

4. 如果开发没有完成需求规定的任务，可以暂定该任务，同时在禅道的任务中，做相关工时记录。

   Snap14.jpg
   Snap15.jpg

   ​

5. 等待开发完成需求规定的任务后，请开发创建版本，关联需求，并提测。

6. 测试人员在版本中，找到该版本。对其需求关联用例，并开始执行测试。同时在禅道的任务中，做相关工时记录。

   Snap16.jpg
   Snap17.jpg

• Scrum项目流程图示意

  Scrum项目流程图.png
  Scrum流程图.png

3 P3_禅道使用建议

2.2 系统使用流程

敏捷的主要流程如下：

1030887-20161022224425123-1825836340.png

1. 用管理员登录系统，找到【组织】页面，维护公司信息，创建部门，再创建用户。用户至少需要包括：

   • 产品经理
   • 项目经理
   • 研发主管
   • 测试主管
   • 研发人员（若干）
   • 测试人员（若干）
   Capture.PNG

   角色	主要工作	备注说明
   管理员	维护公司信息和模块，管理用户和权限
   产品经理Product Owner	给产品提需求
   项目经理Scrum Master	给当前迭代SPRINT挑选需求，并分解需求为任务
   开发人员Developer	完成项目经理分解的任务
   测试人员Tester	对当前挑选的需求建立用例，执行用例并提交缺陷

2. 禅道由三大模块组成：产品、项目和测试。

   img

3. 产品经理登录系统，创建一个新的产品：

   • 产品的负责人、测试的负责人（测试主管）、发布的负责人（项目经理或者研发主管）

   • 产品的类型：正常、多分支(基础版、旗舰版、开源版……)、多平台（Windows PC、Android、iOS(iPhone,iPad)、BlackBerry、Mac、Windows Phone、Symbian……）

   • 维护产品的平台和模块（注意功能整合和重复性）

   • 创建产品的计划，按照产品的发布进度进行划分

   • 产品经理提需求（单独和批量），需求的计划需要选择；然后需求的描述“作为XXX，我希望可以XXX，实现XXX”-- 用户故事（User Story），需求要写的笼统一些。验收标准需要量化或者清晰。验收标准是测试标准。

     注意的点：

     • 产品模块需要产品经理登录
     • 产品有多分支和多平台之分。在写模块的时候，需要注意区分
     • 产品的模块，是拆分产品的功能的重要依据
     • 产品的需求，就是用户故事（User Story），也就是一句话需求
       • As a <type of user>, I want <some goal> so that <some reason>.
       • 作为一名<*某种类型的用户*>，我希望<*达成某些目的*>，这样可以<*开发的价值*>。
     • 产品的需求中，对验收标准的描述，需要确定和详细
     • 添加需求的时候，注意需求是否需要评审
     • 添加需求的时候，注意产品的预估时间
     • 需求的变更 vs 需求的编辑
       1. 需求变更可以改变需求的描述和验收标准
       2. 需求编辑只能改变需求的基本信息和备注

4. 项目经理登录系统，创建一个项目，该项目务必关联刚刚创建的产品，如果这个产品是多分支的或者多平台的，需要关联具体的平台或者分支。

   • 创建项目，关联产品
   • 创建团队：需要选择研发主管(可选)、测试主管（可选）、研发人员、测试人员，并需要统计各位的可用人时。
   • 关联需求，选中之前产品经理创建的需求。

5. 项目经理开计划会，准备Kanban（看板），（未开始的 | 进行中的 | 已完成的 ），全部人参加，包括产品经理

   • 计划会需要制定的内容
     • 迭代周期（sprint），一般是一周或者两周，定下来以后，所有的迭代都用这个周期
     • 安排每日立会的时间，每日开会时间都固定：
       1. “昨天做了什么”
       2. “今天要做什么”
       3. “有无问题”
     • 挑选本次迭代需要完成的需求，标准是必要的，而且可发布，并且可以构成一个可用的版本。
     • 产品经理讲解需求
     • 项目经理拆分需求为任务（分解任务）、需要开发团队的支持

6. 测试主管登录系统，分解用例。把需求分解成用例。进行用例设计

7. 指定的开发工程师登录系统，对指派过的任务进行开始、完成、关闭的操作

8. 指定的测试工程师登录系统，对用例进行编写，注意前置条件、步骤（每一步都有期望结果）、优先级

9. 项目经理登录系统，创建（构建build）版本，注意SVN等信息

   • 包括版本的具体信息、文件下载信息、源代码位置等
   • 关联需求，关联已经完成开发，并在本版本中包含的需求
   • 到测试页面 | 版本，提交测试（提测 | 转测）

10. 测试主管登录系统，到测试 | 版本 页面。

• 关联用例
• 指派测试人员
• 开始测试

11. 测试人员登录，到指派给我的用例，进行执行。执行若出现问题，就转bug.

12. 测试主管登录系统，到测试 | 版本 | 概况 页面，关闭测试

13. 开发人员登录系统，修改bug

14. 项目经理登录系统，重新创建（构建build）版本，注意SVN等信息

    • 包括版本的具体信息、文件下载信息、源代码位置等
    • 关联需求，关联已经完成开发，并在本版本中包含的需求
    • 关联上一个版本的已经修复的bug
    • 到测试页面 | 版本，提交测试（提测 | 转测），填写版本更新的清单

15. 测试主管登录系统，到测试 | 版本 页面。

    • 关联用例
    • 指派测试人员
    • 开始测试

16. 测试人员登录系统，进行测试

17. 测试主管登录系统，到测试 | 版本 | 概况 页面，关闭测试

18. 产品经理登录系统，产品 | 发布 | 创建发布，注意关联需求。本次版本完成。

    整体项目流程图

    禅道敏捷流程图.png

3.2 测试与禅道使用

禅道参与测试与两种使用方式：全流程与缺陷管理流程。

• 全流程：产品、研发团队、测试团队全部参与
• 缺陷管理流程：只是测试团队用来跟踪和管理缺陷

3.3 部署与升级

1. 升级安装
   1. 备份旧的版本，cp -r zentaopms zentaopms_bak
   2. 覆盖旧的版本
   3. 在 zentaopms/www 创建 ok.txt (注意是否显示已知文件的扩展名)
   4. 备份数据库 mysqldump -u root -p zentao > c:\zentao_20161111.bak
   5. 确认升级的版本
   6. 升级完成
2. 故障处理
   • 白屏
     MySQL 数据库没有启动，启动失败
     MySQL 数据库端口不匹配（3306）
     MySQL 用户密码不匹配
   • 404
     object not found 活该你单身
     检查端口和路径
3. 重置密码
   1. 点击忘记密码
   2. 按照指引，在 zentaopms/www 创建一个 xxxx.txt 的文件
   3. 点击指引的刷新按钮
   4. 转到重置用户密码的页面，输入用户名，如果用户名忘记了，需要打开数据库管理工具，选择 zentao 数据库的 zt_user 表，查看用户名
   5. 重置之后，在浏览器重新输入 http://[host][:port]/zentaopms/www

六天入门软件测试系列课程总纲

• 相关学习

立师兄Linty：六天入门软件测试①——测试执行讲义

立师兄Linty：六天入门软件测试①——测试执行笔记

立师兄Linty：六天入门软件测试②——测试分析讲义

立师兄Linty：六天入门软件测试②——测试分析笔记

立师兄Linty：六天入门软件测试③——测试设计讲义

立师兄Linty：六天入门软件测试③——测试设计笔记

立师兄Linty：六天入门软件测试④——测试脚本讲义

立师兄Linty：六天入门软件测试④——测试脚本笔记

立师兄Linty：六天入门软件测试⑤——测试编程讲义

立师兄Linty：六天入门软件测试⑤——测试编程笔记

立师兄Linty：六天入门软件测试⑥——测试报告讲义

立师兄Linty：六天入门软件测试⑥——测试报告笔记