深入理解测试计划
原创作者： 九宸@到家 DeepTesting测试计划是在了解了需求之后进行的第一步工作，所以如何制定一个合理的测试计划就是在接到一个任务后进行的第一件事情。那如何制定一个合理的测试计划？应该从哪些方面考虑计划的要点呢？我希望通过本文的分享，抛砖引玉让大家一起来关注一下测试计划。
【测试计划--首要任务】其实测试计划就是要说清楚两件事情：
[*]要我做什么？
[*]我要做什么？
讲起来很简单，但是，其实做起来因为站在不同行业的公司角度去回答这两个问题，要考虑的重点还真是不一样。我这里只以互联网公司的测试计划的分解为例（当然其他类型的公司，比如项目型或者产品型的测试计划，要做的话，考虑的因素会更多，互联网公司其实是比较简单的一种基于业务需求型的测试计划方案）。
互联网公司的测试计划
[*]了解要我做什么
对于互联网公司有专门的产品经理（PM/PD)去描述要做什么，但是由于互联网公司的产品或者服务有快速迭代发布的特点，其实大部分互联网公司的需求理解，都是针对一段简单描述性文字（或者脑图、demo）等的快速理解，这个时候就要搞清楚如下图的几个事情：因此，互联网公司从整体来看做测试计划其实是对测试人员能力的核心考验，主要考验的人员能力就是三块方向上的能力：
[*]对需求的理解度
[*]对业务的熟悉度
[*]对技术的熟悉度
所以在互联网公司，如果在一个业务线做的时间长，业务的熟悉度积累多了，又有了一定的技术能力，其实做需求测试区了解要我做什么还是较为容易的。
[*]了解我要做什么
对于互联网公司，去分析我要做什么就是在分解测试整个过程，一般分解测试过程有这样的几个分类诀窍：
[*]设计测试策略
[*]把握测试场景和数据构造
[*]给出实施方案的工作排期
因此整个一个需求的测试可以分成如下图的几个分解任务：
【好的测试计划还需要有鲜明的自我观点！】其实大部分的测试计划，项目成员想看到的东西就是测试人员对“要我做的事情”的理解是否到位，以及对“我要做的事情”是否有很好的规划。基于此，我们考虑整个测试计划本身就是自己对业务、需求分解和理解的过程，因此整篇测试计划要看到的就是测试人员这个个体（或者团队），对这件事情的鲜明观点，包括：
[*]对业务的理解（你对业务的关联度和技术关联度的思考建议）
[*]对目标用户的理解（你对核心用户的场景判断）
[*]对风险的理解（哪些做法会带来风险，如何控制风险）
因此，不建议照抄照搬别人的测试计划，或者按照测试计划模板填写出来一个冗长的文档，对于测试来说，要鲜明的表达出自己对做这件事的看法和设计即可。但是还要注意一件事情，此处观点的表达，不是为了去否定需求，对需求的观点表达，应该是在需求评审时就进行的事情，此处应该是对需求细节理解、技术设计这些方面的一些观点表达。
【测试计划应该包含的内容】说了以上这么多内容，综合来说一个好的测试计划应该包含的内容主要如下：
[*]业务分析
[*]需求理解
[*]模块分析
[*]技术分析
[*]测试策略
[*]针对各阶段的质量控制方案（Code、测试、上线发布）
[*]哪些测试方式做，哪些测试方式不做或者少做，为什么
[*]测试设计
[*]主要构造数据场景
[*]边界值、等价类等方法构造测试场景中的数据
[*]正/反向流程逻辑的需求验证类用例设计
[*]主业务测试用例设计
[*]核心用户场景用例设计
[*]核心场景分析
[*]逻辑场景设计
[*]数据类场景构造和设计
[*]测试排期
[*]用例评审
[*]冒烟测试排期
[*]测试阶段划分、排期
[*]上线过程设计和评审
[*]线上回归时间排期
[*]风险评估和其他
以上是我对测试计划整体的理解，当然，针对互联网行业，其实测试无需真的要做一个详细的测试分析和测试计划，但是理论上来说，即时不做，我们也要从心里确确实实明白在整个测试过程中，我们需要做的事情有哪些，其中重要的点是什么，只有这样才能做好一个也无需求或者项目的测试！
666 写的不错，有参考价值。赞。 收藏了 收藏了 写的很好
页:
[1]
