项目过程中可能会遇到这样的项目：

　　1） 该项目跨产品线；

　　2） 该项目隶属于A产品线，且A线新功能点多，B产品线回归功能点远远多于新功能点；

　　3） A、B产品线测试资源有限

　　4） B产品线测试人员对回归功能点业务不熟悉

　　对于这样的项目，风险最大的是B产品线，测试资源紧张、回归工作量大、业务不够熟悉，这里申明一下，前提是该条线仅此一个测试资源可用。所以，最主要的是 B产品线的测试人员要迅速掌握回归功能点业务，找到学习途径，如查看知识沉淀，执行老的测试用例，了解与B产品线该业务相关的子产品，咨询业务专家……总之就是在UC评审前迅速掌握业务，宏观把控风险，要做到这点确实比较辛苦，但是这是一个迅速成长的好机会。

　　其次，UC评审时一定要邀请老的业务专家帮忙评审把关，记录UC中的问题及难点，及时分析，并跟进解决。特别注意对于回归的功能点在UC中避免出现模糊性的、概括性的语句，如“跟线上一样”，“该功能点不变”，“现在是怎样展示就怎样展示”等，因为这时候你不确定你所对应的开发人员是否也了解这部分回归的功能点，如果他比你更不清楚这块业务，那你就只能等着承担两人都误解的风险，或者等着他来问你这块业务是如何如何的，你得苦口婆心的为他讲解数遍。但是这里有个解决办法，一旦遇到对方不了解该部分业务，在双方与第三方确认后将该点立即补充在UC中，双方依照UC办事，以保有据可查。

　　再次，TC评审时记得叫上老的业务专家，且对于老的用例不能轻易放过，仍然要一个一个用例过关，因为老的用例也许存在错误，误导新手。

　　同时，要做好回归用例评审，确定需要执行的回归功能点以及TC数，尤其是覆盖到子产品的TC，利于测试组分配测试资源，安排测试时间及进度，以防回归测试资源需求量大，测试经理安排资源紧张，影响产品线整体测试进度和效率。

　　最后，负责B产品线的测试人员要在随着项目过程不断熟悉业务及经验增长的同时关注及分析每个时间段可能产生的风险，及时与各老大们反馈，如测试负责人、测试经理、项目经理等，并养成填写测试日报的好习惯，以便各产品线及负责人了解你的测试进展及遇到的问题，存在的风险等。

　　总之，对于这样特殊的项目，我们需要高度的责任心、警惕性及良好的学习能力，同样这是一个极其锻炼人的项目，业务的掌握、资源及进度的安排、风险的把控与分析、沟通与合作，都可以在这样的项目中得到极大的提高。