测试人员代码审查(现场审查抽取测试人员数量)

代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。 走查与代码审查基本相同，其过程分为两步。第一步把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当计算机”，即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。

评审尤其是同行评审，是提前发现缺陷，降低开发成本的有效方法；但是很多企业并不重视，或者效果不佳。原因有很多：没有获得合适的专家、组织不合理、方法不当等。针对代码评审，我想简单地谈几点（其实其它工程文档的评审存在同样问题）：1、评审要计划。因为大家都很忙，各领域的专家也都有各自的工作，评审结果的好坏对他们工作绩效没有影响，所以专家投入多少精力来用于评审不受控，完全靠他们自己的职业精神。 所以，这就要求项目经理比较有影响力，能够争取到足够的、合适的专家来参与评审。专家最好要提前协调，当然项目经理首先要知道要请哪些专家（如系统专家、领域专家、测试人员、QA等），这些专家在哪里？能否获得专家资源的支持，是项目经理的项目管理能力一个重要体现。评审时间的投入比例，一般是第一次版本准备时间的3/5以上。2、评审要分层次和重点。作为项目成员，在代码编写完成后，首先是自检，这时发现的缺陷不计算；然后是项目组内的评审，这时发现的缺陷应计算；最后才是外部评审。应提前把相关文档和代码交给评审专家，让他们各自评审；根据项目和评审结果的情况，决定是否召开评审会议，评审会议以确认问题为主，而不是讨论解决方案。对于重要的核心的代码，要投入重点评审力量；另外，对于能力不足的成员所完成的代码，也要重点评审。每个角色也应明白各自评审重点，如QA重点放在编程规范、测试人员侧重在可测性、系统专家侧重在从整体来考虑（如对其它功能的影响、性能等）。3、问题的确认与跟踪。评审专家发现问题后，首先与该代码的完成人进行确认，如果大家达成一致认可这个问题，然后由代码完成人提出解决方案，这个解决方案要得到问题发现者的同意，然后编程人员编码实现该方案，并进行测试和验证，并将验证结果提交问题发现人，问题发现人确认无误后，该问题就可关闭。所以，评审专家发现问题后并没有结束，而是要负责跟踪该问题。总之，评审活动的组织其实比较复杂，也是项目经理项目管理能力的一个重要体现，项目经理对评审活动负有重要责任。
代码review主要就是事前的准备，执行，和后期的跟踪事前的准备也叫做review的输入，这个输入是在什么条件下可以做为输入，可以是个人检查完了，也可以是相互交叉的检查，这里有个检查的标准，如有个检查单什么的，等规定的输入完成之后，进行review的执行在review中，主要就是首先保证什么人参加，这是最主要的，如果找几个没有什么经验的，那review的效果肯定是打折扣的，review的多少时间跟踪，主要是问题的跟踪和后期的数据的度量你上面说的相互评审，主要是项目内部的review，review分好几种，有内部的，专家的，客户的review代码时主要看是否符合编码规范，特别是是否符合设计书（需求）的要求，逻辑是否正确，主要是专家级！！

通过工具来进行code review不在本次讨论范围内。编码规范问题：命名不规范、magic number、 System.out……代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合工具、框架使用不当：Spring、Hibernate、AJAX实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好测试问题：测试覆盖度不够、可测试性不好代码评审不负责检查功能、逻辑是否正确，这些要靠单元测试和QA工作来解决

需求评审对于软件测试人员来说就像是最初的“产品测试”，在理解的基础上发现产品设计上缺陷，其中包括逻辑错误，功能缺失，细节问题等等，这样就会有效的在前期规避很多后期开发中产生的bug，减少了很多后期返工的成本。可偏偏需求评审往往是最不重视的一环，甚至可以说是没有这个环节，追其原因无非因为项目时间紧迫或者觉得没有必要，其实这是本末倒置和得不偿失的。 产品需求作为程序的源头，只有控制好最开始部分，才不会到最后去亡羊补牢。我有过很多血的教训，所以才深深的体会到需求评审的重要性。说了需求评审的重要性，接着就来谈谈如何进行需求评审，一般还是分为3步：第一步就是要完全读懂产品需求，这个过程只需要理解而不是去挑刺，因为要明白这个需求的目的是什么，为什么这样做，怎么做等等，只有在理解的基础上才能去发现问题，而不是一知半解的去挑毛病，有些需求设计的是不合理，但也许有其特殊的用意，或者只是没有更好的方案，不能为了挑毛病而去挑。第二步就是分析和找问题；这就有点类似写测试用例的时候设计测试方案了，把逻辑梳理出来，看看有没有不对或者遗漏的点，整理出来反馈给产品经理。除了考虑有问题的地方，没问题的地方也是需要分析的，比如有些设计非常合理，但会增加代码的复杂度或者不利于后续的扩展和修改，同时也可能会给测试带来成倍的工作量，这些也是需要指出的，因为测试要考虑的东西一定要比产品经理多，用户使用习惯，程序复杂度，与线上系统的兼容性等等，不然直接让产品经理做测试不就好了吗？第三步就是细节问题的纠正，可以是界面，可以是文字，开发一般都是复制黏贴或者照着样子画葫芦，这些小问题后期其实也可以测试出来的，但其锅不在于开发，早点发现问题早点解决也是好事一件，至少不用提bug走一套bug处理流程了，也算给大家省点工作量，积少成多也是极好的。 当然需求评审能解决的问题也是有限的，一方面计划往往赶不上变化，中间会有部分需求的改动，另外一方面有些深层次的问题只有在测试之后才会发现。但无论如何对于测试来说还是非常有必要的，如果能重视起来不仅仅对项目的效率提高不少，而且也能让后期测试压力减小，何乐而不为呢？
你好， 【1】规划型产品经理规划产品从0到1，规划方向、目标人群、特性及产品价值。【2】管理型产品经理负责产品过程，以结果为导向。为最后产品实现盈利作保证。参与产品设计等。【3】设计型产品经理设计产品原型、协调产品PRD文档，协调产品资源等，保证产品迭代节奏，每个版本产品能够如期上线和如期交付【4】全能型产品经理能独立完成产品过程中的每一项工作，就好像纽带一样，链接每一个模块【5】技术型产品经理现在很多产品都是技术决定的，比如数据算法等软件、还有大多数的复杂APP，都是技术和研发共同努力的结果【6】运营型产品经理民间流传这么一句话，懂得运营的产品经理是非常“值钱”的、好产品是运营出来的。能看出这两句话的意思吧，产品运营是多么重要，而懂得运营的产品经理又是多么神一般的存在。入门产品经理，可以从工具学起，推荐以下这些：1.脑图工具：百度脑图2.文档共享：蓝湖、Axure等软件3.项目管理：jira 可以在网上找每个工具的教程，一边看一边练习
需求评审的参与人员：领导+产品经理+项目经理+开发人员+测试人员+运维人员等 需求评审是一个对软件需求进行确认和评估的一个活动，测试人员虽然不是主角，但要积极的参与。评审前： 认真的阅读需求说明，业务流程图等资料；整理出测试点，一定要突出业务逻辑评审过程中：对于需求是否合理，是否可以实现，咱们看着产品和开发人员讨论即可。咱们要关注的：1. 主要关注需求是否具有可测试性，也就是需求是不是存在自相矛盾和二义性。2. 还要分析目标用户的操作习惯。3. 对需求存在疑惑，或者理解不是很透彻，一定要问清楚4. 估算测试过程需要的时间和资源，这也最难把控的。（往往会变化）评审后，提交工作计划，突出时间节点和产物。 以上内容均来自黑马程序员社区

通常现在团队内部都是不需要签字审批的，git管理分支的方式来进行
程序员写代码是不需要零点签字审批的，这个代码呢是生成一些文件之类的东西，是自己可以更改。
一般是通过流程来控制的，比如要单元测试覆盖率，要开发部署文档等，经理管你要这些流程，你都做完了自然就相当于审核通过了。
写的代码需要单元测试，再提交测试人员测试，代码上线需要审批，有小组长执行代码审核