对于测试人员来讲，有2个方面的内容是基础而又常陪伴的：编写测试用例(case)、反馈并管理缺陷(bug)。
这篇文章讲与"编写测试用例(case)"有关的内容，那么编写测试用例除了常提到的方法，工作过程使我也想到一些其它的内容--与产品人员沟通需求，这当然很有价值所以记录在这里当作积累。
某1天风和日丽的，组长Email过来一个项目，意味着测试工作要开始了：沟通需求-->设计用例-->评审用例-->执行测试-->提交bug-->沟通bug-->回归bug-->测试报告-->项目结束。我想说说"沟通需求"，这里可以分为2个情况：（1）在有《需求文档》的情况下，（2）在没有《需求文档》的情况下。
- 首先说（1）在有《需求文档》的情况下
这个时候我会去与开发人员确认这份产品人员提供的《需求文档》是不是最新版本的。这样做的目的很简单：如果不是最新的，那么功能固然会有变化，所以你按照这份《需求文档》设计的测试用例也就作废了。
另外，当有《需求文档》了以后，再问问产品人员是否已经有了可以试用的功能。这样做的目的是：测试人员在"用"的过程中，往往能够启发出"更有价值的用例"设计想法。
- 其次说（2）在没有《需求文档》的情况下
找产品人员面对面沟通确认需求，而不要首先想到Email或者仅仅使用Email沟通。这样做的目的是：产品人员在某种角度上，也可以被看作是测试人员，所以产品人员遇到的bug会顺口告诉你，这非常有价值，能够开阔测试人员的测试思路，同时产品人员的演示也会使测试人员快速了解待测试的系统。
总之，在没有《需求文档》的前提下不要泄气，也别抱怨，毕竟产品人员是比较忙碌的一个角色。去找他们沟通就好了，在工作的时间能说说话难道不是一件幸福的事儿吗，走来走去身体好。最后需要补充一点测试过程中的体会：项目进度要与开发人员沟通。原因是：有些项目可能做着做着就没有信儿了，起码半数的开发人员属于内向的人，他可能不会主动告诉你"这个项目暂且停止"，所以还是多主动沟通一下"这个版本什么时候可以做好"、"这个项目还在继续吗"等等，你要知道人是健忘的所以沟通吧。