软件测试工程师的评审可以通过以下几种方法进行：
企业内部评定
企业根据自身的评价体系，对软件测试工程师的工作表现、技能水平、项目经验等方面进行综合考核，给予相应的职称。
社会化评定
通过参加国家组织的软件水平考试（软考）等社会化评定方式，获得相应级别的职称。
非正式评审方法
临时评审：设计、开发和测试人员在工作过程中会自发地使用这种方法。
轮查（E-mail pass-around review）：通过邮件将需要评审的内容分发下去，然后再收集大家的反馈意见。这种方法简单、方便，但可能无法保证反馈的准确性和及时性。
正式评审方法
互为复审：也称为同行评审，是一种常用的办法，例如软件代码的互为评审已成为软件工程的实践之一。
走查：强调对评审的对象要从头到尾检查一遍，保证评审范围全面。
会议审查：一种系统化、严密的集体评审方法，包括制定计划、准备和组织会议、跟踪和分析结果等。
评审流程
预备会议：由作者向评审组概要介绍评审材料，包括工作产品的目标、实现细节、开发标准等。
逐条审查：评审团队应逐条审查需求文档，确保每个需求都被充分理解。
讨论和澄清：对于不明确或模糊的需求，应及时与产品经理或开发人员沟通，确保需求的准确性和完整性。
标记疑问：对于有疑问或不确定的地方，应在文档中标记，并在评审结束后寻求进一步澄清。
确定测试范围：根据评审结果，确定测试的范围和重点，为后续测试工作提供指导。
评审技巧
批判性阅读：测试人员可以参考“结构—主张—评估”这些批判性阅读的步骤，来评审需求文档。
全面理解：测试人员需要从需求文档中抽取信息，进行归纳和总结，以获得更内聚、更精炼的信息表示。
记录和整理：使用笔记、批注、思维导图等软件来记录和整理自己获得的信息。
讨论和对齐：评审会议可以提供一个契机，针对一些争议点进行讨论对齐，做到统一思想。
评审检查项
需求规格说明书是否评审并建立了基线。
测试计划时间是否按照计划完成用例编写。
需求新增和变更是否进行了对应的调整。
用例编写是否按照公司定义的模板进行编写。
测试用例覆盖：用例是否覆盖了《需求规格说明书》。
用例编号是否和需求进行对应。
非功能测试需求是否在用例中列出并说明。
用例设计：是否包含了正面、反面的用例，是否针对需求不同部分设计使用不同设计方法。
测试用例填写：每个测试用例是否清楚地填写了测试特性、步骤、预期结果。
测试数据：测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述。
用例覆盖率和 预期缺陷率是否达到相应质量指标。
通过以上方法，软件测试工程师可以全面、系统地进行评审工作，确保软件质量和项目顺利进行。