• 软件测试:Peer Review


    上节课中我们学习了PeerReview

    Peer Review 又称同行评审。是一种学术成果审查程序,即一位作者的学术著作或计划被同一领域的其他专家学者评审。[1]

    一般的评审过程如下图所示

    评审角色

    评审角色分为五种,分别是

    Moderator (主持人)

    负责评审过程的关键人物,收集检查数据错误分类、严重程度,控制评审进度、时间、内容

    防止内容发散(评审变为发牢骚、幻想、工资待遇的讨论会)

    Inspectors (评审员)

    负责从通常的视点出发 发现成果物的缺陷,以及缺陷影响到的技术领域

    局内评审人:熟知成果物的相关知识,对发现缺陷有积极性

    局外评审人:可以为评审提供客观的新的视点和见解

    Author (作者)

    成果物的(文件的)的信息做成人,为评审全过程提供评审材料的信息,在时间和成本允许的范围内,负责修改主要缺陷、及任何小的、零散的缺陷。也兼有评审员的身份。

    (当事者迷,不应该是读者,容易犯想当然的错误)

    Reader (讲解员)

    会议中负责阅读或意译成果物的细节,也兼有评审员的作用.

    Recorder (书记员)

    记录实际的评审过程中发现的缺陷,也兼有评审员的作用.

     
    心得

      在课堂中我们进行了以‘天大停车查询系统’为例的评审实验。在五人小组进行了review meeting。用时长0.3H。共发现14处缺陷,包括具体架构的缺失,特殊情况的考虑等问题。

    经过这次讨论我发现。meeting是寻找缺陷的最好方式,在讨论甚至是争论中我们能发现更多的隐藏的问题,集思广益更加能找到优化的地方。计划同行的评审,虽然只考虑缺陷

    不考虑解决办法,但是在meeting的过程中也往往能提出优秀的建议。

      提前进行同行评审,能把错误终结在其萌芽阶段。防止其扩散到后续工作中。并且能增加同行之间的交流,增长知识,是双赢的好事情。

    参考

    [1] 维基百科

  • 相关阅读:
    如何提高工作效率,重复利用时间
    好记性不如烂笔头
    如何应对面试中关于“测试框架”的问题
    通宵修复BUG的思考
    工作方法的思考
    别认为那是一件简单的事情
    开发人员需要熟悉缺陷管理办法
    不了解系统功能的思考
    如何布置任务
    事事有回音
  • 原文地址:https://www.cnblogs.com/shenbuting/p/4420900.html
Copyright © 2020-2023  润新知