title: 浅谈测试驱动开发
date: 2017-02-05 21:58:28
tags:
- 设计模式
categories: 设计模式
近两日参加了名为“软件测试质量体系最佳实践”的分享，其中着重介绍了质量体系的建设，测试的经验以及方法，就我个人最大的收获更多的是关于TDD的思考，在此简单记录。
Bug的影响
不成熟的团队中一个常见情况：
频繁被突发问题打断，响应式的处理，目标达成率低，可以称这样的团队为响应式的团队。
为什么频繁的响应Bug会严重消耗团队资源？
- 完整的Bug处理的过程时间长
- 一个Bug导致多个Bug的产生
- 人员缺乏动力
预防Bug
然而解决Bug并不能算作突出的贡献，针对Bug的预防工作要优于Bug解决。从被动的救火到主动的预防问题发生，减少突发问题。
一个团队的重要指标，是有效代码的产出，而不是代码的产出。
有效代码，如同字面意思，有效的，可复用的，没有大量Bug，可以赚钱的代码。
如何保证代码有效？测试！
测试
手工测试无法做到连续提供测试服务，存在间断，代码修改后测试报告随即失效。为了解决测试的间断问题，必须引入自动化测试。
开发工作中耗时最多的是在调试，如果能减少问题的出现，避免反复调试，可以节省大量的时间、精力。
因此，测试并不会让团队的工作量出现明显增加，最终开发与测试的人数趋于接近。
测试短期可以帮助我们找Bug，长期可以帮助我们建设质量体系。
质量体系
系统的健康状况，项目的完成情况应当从质量体系中直观，实时的获取，而不是通过大量的会议，讨论得出。
数据的三个来源
-
用例库
积累的测试用例
要求能复用（良好的测试框架）
能够与其它平台，系统方便集成（一个test case对应多个test Run）
-
缺陷库
Bug的完整生命周期记录
-
结果库
每次自动化测试的结果
最小的单位不是test case，而是test run
质量体系，不仅用于预防问题，长远看还需要提供数据支持，需要辅助决策，辅助管理。
团队
当一个团队可以很好的预防问题的发生时，可以称这样的团队为建设型的团队。
传统的瀑布模型中开发完成开始测试是导致项目进度缓慢的一个重要原因。
如何让开发与测试并行？测试始终伴随开发，甚至优先于开发。
开发，测试并行的三个重要保障：需求文档，开发文档，测试文档
TDD
文档评审
从执行过程上来看，当需求文档出来后，开发和测试需要同时整理对应文档，然后进入评审环节。
需求作为开发，测试的输入项，要求需求文档不能出现偏差。
从制度上可以做出一些规范化，例如：
- 需求文档、开发文档、测试文档作为三个关键文档，任何一个都一定不能或缺
- 三个关键文档都要有评审，三次的评审都要求产品、开发、测试负责的人员到场确认
- 文档可以驳回，但确认后的文档不可更改
- 任何一个文档出现滞后，都要记录，分析问题
文档内容要细致，需求文档作为开发文档和测试文档输入，尤其重要。
各个文档的基本标准：
- 需求文档：明确各步骤输入输出
- 测试文档：明确各个测试点，需要进行什么测试，是否要求自动化等信息，设计（复用）测试框架
- 开发文档：提供设计架构，需要细致到开发阶段填充代码就可以了
一个优秀文档的重要标准：评审打回次数。
开发，测试并行
三个文档评审结束后，开发和测试同时开始工作。
其它
关于需求分析
需求分析需要专业的人专门处理，需求分析的过程如同医生看病：
医生不能问病人想吃什么药，想怎么治疗，而是需要找到病人病因
产品不能表面的询问用户想要什么，而是要发现用户的真实需求
需求分析过程展开：
-
获取
得到最原始的需求，这些需求可能是凌乱的，甚至是矛盾的，不能直接用来开发
-
分析
剔除原始需求中的噪音，获取真实的需求，这个阶段产品应该基本确认需求
-
细化
产出原型，与美术，设计确认沟通，明确每步的输入输出
-
固化
与用户确认，得到最终版本的需求文档
关于团队成员能力
- 不能迁就最低能力人员，要推动团队成长，进步
- 开发与测试要互相促进，测试需要考虑开发设计的文档是否可以进行测试，有哪些改进，开发需要考虑代码的覆盖
- 通过模板让人员能力可流动，可转化。总结高质量方法，模板，流程给团队复用，提高整体质量
关于测试
- Bug分级
- 不要首先搞UI测试
- 尽量使用真实数据，边界数据
- 避免对其它模块，代码的依赖
- 发布时不一定就能做到所有测试都通过
- 测试要可复用，粒度，范围要注意
