了解业务需求。这个说简单也简单，是参加立项会，然后看看PRD和UC。但是同时，这个也是一个复杂的过程，从单薄的PRD和UC中获取自己有用的信息是考验个人的能力的。

　　我记得罗仲涛上次说过，UC是开发人员整理自己的思路，同时呢也是为了让测试人员通过评审他的UC，将UC与PRD分离，让项目变得更加直观和细化。那么PRD和UC是开发和测试人员理解项目的基础，也是项目日后开发的蓝本。

　　了解业务需求对于开发人员和测试人员同样重要。我一直有一个想法，让开发和测试共同参与UC的编写，开发的同学从项目实现的角度，而测试同学可以从用户使用的角度共同绘制这个项目的图谱。这个会对测试同学的要求会比较高啦。

　　不过目前的情况，我在熟悉UC的时候，比较喜欢将一个个原型图片前后联系起来，然后假设执行这个页面，会跳转到哪个页面，然后流程性的东西都串起来了。至少大方向不会有错误。而因为我们对这些的了解，说不定会在评审的时候提出更多属于自己的想法，要不感觉被开发牵着鼻子在走，开发说要这么做，好吧，我默认这么做。目前在评审UC的时候比较侧重于每个页面，每个功能的讲评，关于流程性的讲述倒比较少。

　　详细的测试设计，测试设计我觉得越详细越好，好把我们所能发掘的信息点都表示在上面，这样我们在编写测试用例的时候可以参照我们的测试设计，而不是继续从UC和PRD上找出校验点。另外呢，在画设计图的时候，我们也可以借此约束自己合理利用设计的时间。

　　在这次项目中，我测试设计图有两种类型：一种是流程类的设计图，有开始的实心圆点，有结束的同心圆点，中间由若干个动作和判断分值组成。这种设计图我们在大学里都有学过，但是这次项目中，前台都是展示型的页面，与用户几乎没有交互，所要校验的也都是一些细节性的东西。此类设计图，应该横向画，用方框型的状态图表示一个页面，然后可以从这个页面中横向的拉出若干个校验模块，对每一个模块又可以分出若干个校验点。如此细分下去，不过此类设计图因为不是流程性的，是以只有开始的点，而没有结束的点，其他的画法和第一类流程图相似。