目前的支付宝要想发展的一个框架是：STA写完测试分析后，交由测试工程师进行用例设计和执行。所以需要测试分析师的输出要很明确，但实际情况测试分析师和测试工程师的交互可能有盲点。本文档描述的是STA的产出有哪些原因造成不明析，及建议。
正文：
目前在各个项目中，测试分析担当的角色从已前的单纯PRD translator转变为更为专业的各业务系统间的分析及各种异常情况分析人员。但有些情况会导致分析师的产出不全面，从而导致测试工程师编写用例不全面。
情况1
测试分析师的分析没有明确到测试分析文档中。有时想到的没有及时反映到文档中。过了段时间自己也就忘了。这样会造成后继测试工程师的用例覆盖不全。
解决方案：
养成习惯，在写文档时目录的框架先搭好，突发奇想的可以随时记录在文档中。其实先把各个测试模块框架先列出来，发散性的编写测试分析对覆盖不全有所帮助，同时也最大程度保证了STA的想法全部保留在文档中。
情况2
需求变更或是其他修改，测试分析师没有更新文档。或者是测试分析文档从初版更新来最终版。造成后继测试工程师也没有按新的需求来编写。到后期发现，成本比较大。
解决方案：
养成在文档中加入修改记录表的习惯，对于新增或更新都记录下来，严格执行对于后期人员的阅读有一定的帮助。remember文档是写给别人看的J
情况3
有些项目可能涉及到多个产品线，如果有一位测试分析师进行分析时会有一种情况出现：那就是对于不熟悉的业务，测试分析师通过看以前的文档或是请教熟悉的人进行业务了解，但还是会造成对别的系统的理解错误或是遗漏。
解决方案：
对于一些跨产品线的项目由一个测试分测师来负责是不科学的，现在很多情况都是由一个人来分析，我个人觉得在产品KICKOFF或是PM确定资源时就应该把相关测试分析锁定，跨线的业务由相对的测试分析师提供支持。现实情况可能做不到几个测分FULLTIME一个项目，考虑可以让跨线业务的测试分析分时投入，在测试分析时，在用例REVIEW时投入既可。但很重要一点：多名测分的计划、配合，需要主要主要测分负责，不能说这块业务我不懂，你全帮我分析一下。
总结：
有关于测试分析师容易遗忘的想法，我个人就总结了这几点。可能不是很全面，希望大家看过之后能给一下建议或对上述解决方案感觉不对的地方请指正。
STA将来会越来越专业，美好的目标是让STA DOC可以标准化，最大限度上减少因测分遗漏造成线上BUG。但产品线也决定了STA业务的局限性,所以另一个方向是多个STA在项目中完美的配合。
文章来源于领测软件测试网 https://www.ltesting.net/