做好测试计划和测试用例的工作的关键是什么？

我是一个菜鸟，接触测试时间也不长，根据自己的实践说说我浅薄的理解。
分两部分来说我的感受吧。
首先是做计划，我觉得以下几点是做计划的时候需要关注的。
1.对项目基本情况的了解。基本情况主要是指整个项目或产品的范围，包括时间，成本（资源）和质量要求。作为Test Leader，需要首先和PM沟通的也是这几点。需求分析，设计，开发，测试，发布，这些都是为项目的最终成功服务的。书本上我们学到的是怎么做一个理论 上理想状态下的测试计划，但是在现实中不可能有这种理论状态出现的。时间，成本和质量本身是一个互相制约的三角关系，在制定测试计划之前我们一定要很清楚 项目的范围和目标，只有在这个前提下我们才可能定出一个满足项目要求的合理的测试计划。
2.风险评估和准备。测试阶段是整个软件开发生命周期中相对靠后的一个阶段，也是对其他阶段的依赖性最高的一个阶段。测试工作本身的成功与否，与前面几个 阶段的质量密切相关；而测试阶段又是一个项目最终能否成功的决定性阶段。风险的控制在测试阶段就显得尤为重要。我个人认为风险的评估和准备是否充分合理， 是衡量一个测试计划质量高低的关键因素。
3.重视人的作用。我们在计划中，都以人月或人日来标示工作量，而忽略了人与人之间的差异性。在我看来，这是计划过程中一个很容易被忽略的一个风险。我一般通过标示团队中成员的一个能力因子来把每个人的能力差异反应出来。

接下来说说写测试用例时需要关注的东西。版上大牛多多，像覆盖率啊这些最基本的东西我这里就不细说了，说一下大家可能会忽略或者我在实践中认为比较有用的几点。
1.提前介入。我们以前的做法是开发人员开始编码的时候我们也开始写case，但是发现效果不好，而且受需求分析的质量影响很大。后来我们在另一个项目 中，BA写好一个需求文档我们就开始写case，同时BA保证对测试团队的支持。这样我们有效的提高了case的有效性，同时在完成需求分析阶段后测试团 队就成为了除了BA外对需求最熟悉的团队。
2.避免开发人员的影响。测试团队要尽量避免因为开发过程中的原因修改case，除非BA或者客户同意进行需求变更。
3.变更控制。我们一般要求测试用例在开发阶段前基线化。之后的变更要严格遵循变更管理的流程，对于测试用例来讲，一定要保持和需求文档的同步。需求文档变化，相应的测试用例也要变化，反之，没有需求的变化，测试用例就不能变，除非是测试用例本身的缺陷。

以上是我的一些感受~~~~