###软件产品/项目开发流程
需求评审/Debug
|
需求冻结
|
敏捷开发/敏捷测试 <----
| | 需求迭代
定期演示 ——————
|
自测+产品验收 <——
| |不通过冒烟测试
提测 ------------
| |
提交到测试环境 |
| bug记录 |
测试 ------------
| |
提交到预发布环境 |
| bug记录 |
测试 ------------
| |
提交到生产环境 |
| bug记录 |
跑测 ----------
####【过程】
- 需求讨论后，给出结论，并记录变更
- 确定对应问题的开发人员及相关对接人，负责人
- 评估需求风险点、工时
- 确定需求冻结时间点
####【思考】
- 新功能添加的必要性
- 整理流程图，以发现逻辑及过渡缺失
- 功能模块是否与其他模块冲突，冲突的处理方式
- 体验产品原型图的交互状态是否齐全
- 交互操作后的效果是否有所体现
- 交互操作是否冗余（如操作路径深、步骤多、操作复杂）
- 文字、按钮、logo是否能说明功能、表达是否明确、是否有歧义
- 文字、图片静态元素的颜色、大小、类型、显示位置、长度、显示的形式是否有说明、效果是否统一
- 动画效果的展示是否有助于用户感知功能、是否有助于用户体验、是否耗时
- 是否有避免误操作的提示
- 容错处理、异常处理的相关流程是否清晰全面
- 是否有优化空间（数据加载、逻辑流程、性能等）
- 确定：80%的需求冻结
- 确定： 各个环节负责人
- 确定： 关键点里程牌时间节点
- 0.1跑通版本：主流程功能完整，可以跑通，可以不考虑数据真实性、可以跳过非必要流程
- 0.2跑通版本：主流程功能完整，数据真实，操作有效，交互完整，流程完整
- 0.5完善版本：所有功能完整，数据真实，操作有效，交互完整，流程完整
- 1.0上线版本：做到以上所有，无阻断性bug，无优先级较高的bug
- 确定： 关键功能是否存在风险点，是否需要做demo进行复验
- 输出：功能分解（各个功能责任人、预估工时）
- 输出： 主流程冒烟用例，并确定用例评审时间表
- 输出： 前后端协议文档
####【评审内容】（分阶段进行）
- 冒烟用例
- 单元用例
- 系统用例
- 性能测试方案
####【评审结果】（分阶段进行）
- 输出：0.1版本测试用例
- 输出： 0.5版本测试用例
- 输出： 1.0上线版本测试用例
####【开发】
开发人员需按照先期跑通为目标进行分层实现（而非传统的分模块分页面实现）
- 主流程页面跑通，交互正常 3天
- 所有页面跑通，交互正常 3天
- 主流程功能跑通，交互正常，流程正常（可以使用假数据）3天 达成0.1/0.2版本
- 跑通所有功能，交互正常，流程正常 达成0.5版本
####【测试】
测试人员介入开发，以0.x版本目标为基础
- 进行用例完善
- 协助开发人员进行单元测试，接口测试（需要相关的工具）
- 代码审查/代码review机制
####【目标】
- 是否存在潜在的安全问题
- 有没有监管的需求要满足
- 有没有自动化测试未覆盖的区域
- 新的代码是否有性能问题
- 有没有不必要的接口调用
- 用户交互信息是否有进行正确性的检查
- 是否有明显的错误将导致生产终止
- 是否有冗余代码
####【架构及设计】
- 新代码是否符合总体架构
- 代码是否遵循团队设计风格
- 是否使用了合适的设计模式
- 新旧代码是否符合同一标准
- 代码是否在其应该在的正确位置
- 是否考虑可复用可扩展
- 代码是否过度工程化
####【可读性/可维护性】
- 新代码是否符合总体架构
- 字段、变量、参数、方法以及类名，是否能真实反映其所代码的事务
- 通过阅读代码能否理解业务逻辑
- 能否理解测试代码在做什么
- 测试用例是否覆盖全面，是否覆盖了正常场景和异常场景、是否有特殊场景
- 令人困惑的代码段，是否有文档描述或注释
####【功能性】
- 代码是否在做预期的事情
- 测试代码是否按照需求及用例来编写
- 是否包含隐藏的bug
- 是否使用了错误的变量
- 逻辑分支的判断条件是否正确
####【目标】
- 跟进每个功能的进展
- 解答/讲解开发过程中的疑问
- 每个人参与开发任务的评估，共同工作
- 每个人参与核心工作
- 产品目标透明、工作任务透明、代码透明、版本透明
####【思考】
- 组员都可以提问、组员都可以解答
- 判断任务遗漏点、判断剩余工作量
- 随时挑战其他人的估算与评估，以期暴露含糊不清的问题
####【记录】
- 当前工作任务进度
- 剩余工作任务
- 哪些任务需要迫切被完成
- 需要什么外部帮助
- 关键点提醒
####【转化】
- 将问题点汇总转化为：需求点、优化点、迭代任务
- 将踩过的坑转化为经验，以确定改进版本
####【输出】
- 迭代需求、产品改进方案、并体现在jira上
- 调整并评定当前jira任务的优先级
- 昨天做了什么
- 昨天是否已经完成
- 已经完成的任务是否已经关闭
- 今天要做什么
- 今天的任务板领取
- 需要什么帮助
- 关键点提醒
- 面对团队成员说出你的贡献
- 确认其是否符合规范（单元测试、手工测试、代码审查）
- 获得知识（A/B测试）
- 用户会购买你的产品吗？
- 一个设计的改变会带来有更多的注册吗？
- 用户会理解你的软件是如何工作的吗？
- 可用性测试
- 最低可行产品测试
- A/B测试
- 你的软件在负载下的表现如何？
- 你的软件有资源竞争吗？
- 当有非法输入时，你的软件是否会崩溃？
- 压力测试和浸泡测试
- 从产品日志中收集异常及跟踪信息
- 你的软件是否真正符合规范？
- 你的软件是否做了它应该做的事？
- 手动用户界面测试
- 代码审查
- 对于同样的输入，你的公开接口（API）是否总能返回相同的结果？
- 你的代码是否提供了它应该提供的保证？
- 单元测试、集成测试和其他类似的自动化接口测试
- 自动化用户界面测试（如Selenium测试）
- 编译器检查和静态检查
- 开发人员编写必要的单元测试
- 针对接口文档，给出接口测试工具
- 针对开发环境，进行体验性测试
- 针对测试环境，工具、结合用例进行测试
- 单点测试
- 数据是否被正确记录到数据库
- 接口测试，输入/输出
- 前端表现是否正确
- 记录bug、截图
- 测试工具 switchhosts Fiddle
- 浏览器兼容性
- 移动设备兼容性
- 网络种类
- 屏幕限制
- 手势
- 加载
- 反应时间
- 加载完成时间
- 等待时间
- 资源请求情况
- 请求数
- http状态码 300、400、500
- 资源总大小
- 资源占比
- 异步请求数量
- 限速测试
- 破坏法，对于一切能访问的资源及功能，进行破坏性试验
- 极限法，对软件功能提出难以回答的问题，以了解其极限，比如文本框是否有字数限制、是否支持emoji等
- 取消法，就是不停的取消，启动/执行
- 暴力法，进行非常规，非正常手速，非正常输入的操作
- 逆向思维法，在本应该开启后才使用的功能上，故意保持关闭后使用
- 问题就在于，怎样将测试人员介入开发，调动开发人员进行测试？
- 也就是转化为，测试人员如何介入到敏捷开发流程中，即敏捷测试！