流程
电商项目测试实战（一）
cdtaogang 2019-08-15 16:46:14
24720
收藏 419
版权
说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！
目录
测试总结中都包含什么内容。
答复上基本都是：执行了多少用例、发现了多少问题、解决了多少问题，待解决的问题还有多少、bug的修复率是多少，很少有其它方面的延伸。
定义：
测试总结站的角度，更多是在整个软件研发过程中所有问题的总结，总结的范围相对更宽一些。
包含需求搜集阶段的问题、产品需求分析设计阶段的问题、开发设计编辑阶段的问题、产品测试阶段的问题、项目上线后反馈的问题的总结等等。
二、何时进行
1.需求测试或者发布测试结束后
此时进行总结更具有时效性，但缺少使用者对此版本的直接反馈，只能算是内部总结。
2.产品上线应用一段时间之后
此时总结，增加了客户使用后的反馈，更有利于从第三方视角反馈发布版本的质量情况及用户视角暴露的问题。
三、谁来组织/谁要参与
组织者：一般由测试经理或者对应项目的负责人发起。
参与者：项目经理、产品经理、开发经理、测试经理及其它相关人员。
四、总结形式/载体
1.召开总结会议（载体：word、excel、ppt、视频等），常用ppt。
2.邮件沟通反馈
3.视频会议等
具体形式因团队而已，重点要关注效果，总结后要形成可落地的改进计划。
五、总结内容
版本总结中应该包含哪些内容？
有那些量化的数据可以分析？
涉及到开发、测试计划偏离度的分析，缺陷类型、优先级、分布、质量趋势的分析,大家可以整合一份适用于自己公司的一套标准。
前边我们提到，要总结需求搜集阶段的问题、产品需求分析设计阶段的问题、开发设计编码阶段的问题、产品测试阶段的问题、项目上线后反馈的问题等。
1.需求搜集阶段
针对需求提交是否及时、是否符合提交规范、描述是否清晰、业务场景是否完备等几个维度进行统计分析。
如图中V1.0版本需求按时提交率只有75%，很有可能造成版本规划延期或者版本发布时间压缩。
根据相关数据及测试过程中产生的影响，针对需求搜集放提出相应建议，并要求需求搜集放给出相应的保障措施及计划。
一般提交需求的是客户的业务人员或者公司内部相关对接人员，相关建议和改进需要传递到这些人，并督促改善。
2.需求分析及设计
针对需求，产品是否按时审批、按时提交相关分析设计文档、组织相关需求评审沟通会议、插入需求占比等相等 。
此处插入需求占比，也可根据插入需求工时与版本规划工时进行对比统计。
此阶段的问题主要集中在产品，需要传递到产品去进行相应改进。
3.开发设计编码
针对开发设计提交及时性、开发计划按时完成情况、缺陷数量、缺陷密度、缺陷修复周期、缺陷分类、缺陷修复情况分析Vincent文章中已经说明。
下面我们从另外一个角度，人力成本投入角度去分析。
从上述看，我们能够发现开发在自测与设计阶段的投入较少，从而造成大部分精力都在修复BUG。
此阶段问题主要集中在开发，可建议开发：定期进行设计Review、代码Review，要求开发做单元测试，写自测报告等手段来提升开发质量。
4.产品测试阶段
针对测试用例、测试报告提交的及时性、版本发布内容提交的完备性、计划按时完成情况、缺陷遗留情况、客户，项目反馈问题情况进行分析。
下面我们从另外一个角度，人力成本投入角度去分析。
从上述看，测试在BUG与产品设计优化上的投入将近占了测试工作的一半，说明开发质量与产品设计存在一定的问题。这时测试工作需要左移，配合产品和开发，将一些问题扼杀在摇篮里。
5.项目上线后问题反馈
针对项目/客户反馈问题进行分析总结，类似缺陷分析，重点总结遗漏的原因及后需的规避措施。
上述看，场景遗漏导致的问题较多，需要质量部门重点关注，加强用例设计及评审，丰富完善测试场景。
六、汇总整理各部门总结并发布
基于测试总结过程中的数据分析，我们提出了对部门的建议。
针对提出的建议，各部门要配合梳理可落地的改进措施，汇总到质量部门，质量部门负责整理发布，并监督各节点的改进情况。以保障在下个版本测试过程中，相关问题能够得到有效的规避，从而提升工作的效率与质量。
针对上述各个阶段的分析总结，除了一些具体的数据以外，可以增加一些具体的案例，这样在分析总结是大家才能切身体会。
数据的背后不是吐槽那个阶段，那个环节做的不好，初衷是透过数据看本质，不断完善我们的工作流程，达到高效协作，高质输出的目标。
敏捷项目管理：人为核心+交流与合作
传统是以预测为原则，文档进行驱动开发过程，过程为核心，但一般都是不严格执行的；有边写边改的问题导致完成后需要长时间的测试阶段；
内容：4价值12准则
轻文档，根本文档是源代码
4价值：理论
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
12准则：实践
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 对技术精益求精，对设计不断完善，将提高敏捷能力。
- 以简洁为本，极力减少不必要工作量。
- 最好的架构、需求和设计出自于自组织的团队。
- 团队定期地反思如何能提高成效，并依此调整团队的行为。
支柱：
- 迭代开发（1-4周开发周期）
- 增量交付（交付可测的程序）
- 自组织团体（设计、计划人力、管理过程、进度）
- 高优先级需求驱动（待开发列表细化，高低的商业价值，先细化1-2次后面再完善）
开展：
小型、自我管理、短周期发布；
30天：功能列表优先级（产品）-开始以小组的功能开发（工作量）-每天开会检查15分钟：完成什么、承诺完成什么，有困难的事情提出；--更新自己的任务燃尽图--支持每天编译测试-会议需要产生一个用户故事，从用户角度看系统；描述一个功能，这个功能产生XX效果；为客户产生XX价值？
用户故事细化--待开发的功能列表；--所有故事完成就完成一次迭代；--演示会议，每个人演示自己完成的软件产品；
产品需要有一个：柱塞列表‘。每天进展和调整；
每周一小时的知识讲座
活动：
模型：极限编程、水晶编程、SCRuM
跟踪机制：
故事板或者SCRUM类的工具，如jira；
好的待开发的列表：--团队人都可以看
- 优先级高的需求曰清晰详细；
- 对每个项成本、复杂度、风险、功能点的评估；
- 技术支持和缺陷需要放里面，重复考虑；
- 有总体目标
- 指定一个人复制列表，管理控制列表
例子：
教师、学生登录APP查看学生成绩--粗
细化：一个用户故事分解多个用户故事：--写入EXCEL；
教师、学生登录APP流程是否一样？不一样是否需要独立的功能列表；
登录具体的过程是：关键点是：是否需要密码，密码、用户名是否区分大小写？是否记住用户名？支持下次自动登录？密码传输是否加密？
持续集成：每日编译 成功编译 打包发布不含任何缺陷通过冒烟测试---心跳图
流程：
提交-第一轮测试（自动化测试）-构建-第二轮测试（自动+人工 除第一轮的测试内容）--更新点都需要测试到；
测试人资质：
自动化+探索测试+测试驱动开发+面向业务帮助团队设计期望产品+用户验收时的用户故事？
使用真实数据
性能、健壮、安全
职责：自动化+探索测试+编写可测试的代码
标准：
持续反馈（描述用户故事与客户合作的模型或者如何思考设计运行，通过测试的图片）展示项目测试矩阵和项目进展；
为客户创造价值：核心功能把握，不能过分关注边角功能；
面对面沟通
勇气，解决其他问题如何在短时间内构建用户故事，如何跟上节奏、确认多少测试、如何面对失败；
简单化：客户提供质量标准，测试提供参考数据：性能、安全；使用EXCEL或者清单；
响应变化：不能改的BUG需要记录在卡片上下个版本实现；
关注人：提出重要的问题；
工作流程：
发布时的计划，不做大计划，明确任务和资源、评估用户故事、找核心和偏弱的模块设置优先级、设置额外的时间保障计划；
迭代的准备：客户故事达成一致；不常见的功能达成策略：
完成规划：询问和考虑所有测试点帮助团队理解故事，编写测试代码、用例；
测试-编码-回顾-真亮提交产生用户故事；简单的用例通过后再编写复杂的；
协助工具：
代码管理:git
集成环境;VS
自动化工具
单元测试工具：.NET ：NUNIT 、perl
客户端GUI：TESTNG、abbot\SWTBot
业务工具：核对表、思维导图、模型、验收测试用例：场景的测试步骤封装
