Post by "Christine", 10-06-2008, 15:50
-----------------------------------------------------
大家好，
在一些项目总结中，大家对Unit Test、Code Review、测试人员做的测试之间的目的和区别还是有点迷惑。
我查了网上的资料，跟大家分享一下。
正确的顺序是： Unit Test (NUnit等) -> Code Review -> Testing (被测试人员执行的)
1） Unit Test目的
Unit Testing－－单元测试。测试单个的软件组件，属于白盒测试范畴，其测试基础是软件内部的逻辑。
“传统”的单元测试理论的目标和相关的工具最关心的问题是程序的正确性,所以非常讲究覆盖率.目的是寻找代码中存在的bug. 一个转载文章 - Unit Test研究报告
单元测试的新看法，参加后面的附录二。
2） Code Review目的
详细看转载文章 - Code Review 理论与实战，我列出来核心3点思想：
①Review在unit test之后. 在Code Review之前开发人员是否对代码做了单元测试，这一点也是为了保证Code Review前一些语法和功能问题已经得到解决，Code Review人员可以将精力集中在代码的质量上。
②Code Review人员也不负责检查代码的功能是否正确，也就是说，需要复查的代码必须由开发人员或质量人员负责该代码的功能的正确性。
③Code Review主要检查代码中是否存在以下方面问题：代码的一致性、编码风格、代码的安全问题、代码冗余、是否正确设计以满足需求（性能、功能等等）。
2.1）Code Review的一些实践（转载）
1、CodeReview应该分为几个步骤来进行，首先是初级的审查，审查的内容应是对代码命名、风格、逻辑等，查看是否合乎编码规范，是否有明显的逻辑问题及错误。
2、第二步应该是按照前期的设计文档(类图、顺序图、状态图等)进行审查，查看是否达到了设计要求。
3、CodeReview不可能查看全部的代码，只能对其比较关键核心的代码进行审查。
项目的认知在开始阶段比较粗浅，问题较多，因此需要及时的纠正；而当项目成员随着进展而成长后，有很多问题可以为成员自己所避免，因此安排code review的次数应该减少。
除了纠正错误和问题之外，code review可以通过相关人员的参与，来交流一些技巧和宝贵的经验，以讲解和讨论的形式获得提高，因此成员的参与积极性应该比较高。
大家对Code Review有两种意见，一种是依照编码规范进行审查，另外一种以检查代码是否存在缺陷（提高性能，优化函数内部的结构，减少堆栈的开销。使代码整洁，易读懂，使函数内的异常都能捕捉到，成为一个健壮的函数。等等）为主。 编码规范不仅仅是编码风格，还包含了很多写程序的习惯和要求。
重点评审“菜鸟”提交的代码的低级错误，以示警戒；重点评审“高手”提交的代码是否存在逻辑错误，防止给系统留下隐患；
实话讲，我们做不到100％覆盖的代码评审，实际上，覆盖到60％——70％就不错了，评审成本是比较高的，而且中国的公司一般不肯在这方面多花成本，正因为如此，评审表格要合理，好操作，评审结果要立即通报出来；
3） 问题：都做了Unit Test了，还有必要做Code Review吗？
(转载)
如果程序员完成单元测试和refactoring的工作，code review就成为在时间充裕情况下的附加工作。
如果我们的单元测试已经通过，在对代码的refactoring过程中，就已经作了review的工作。这样，单独的code review阶段就不会有多大的实际意义。
我个人的理解，如果没有做Unit Test, 需要重点安排Code Review。
如果做了Unit Test, 并且Code Review中的一些检查点，也被覆盖了，Code Review的安排可以减少一些。
4） 测试和技术评审的区别
摘录了附录一的关键语句，详细请看后面的附录。
a. 评审是一种在产品开发过程中尽早发现缺陷的手段，通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。
b. 评审的目的在于：越早发现问题，总体成本越低，因此要评审，评审，再评审！等到测试已经太迟了！
c. 测试和技术评审都是有效的质量控制手段，但也有明显的区别。类似地，技术评审和测试的目的都是为了寻找缺陷，寻找缺陷的目标不是证明它是正确的，而是证明产品不能工作。
测试是在产品运行时进行的动态分析，测试的对象为原型、中间产品和最终产品。相对地，评审是一种静态分析，评审对象通常是技术文档、代码、计划、测试用例和测试数据、测试结果等。
附录一：技术评审
在工作中，我们经常可以听到以下的声音：
“我们不进行评审，是因为我们项目比较特殊，没有时间……”。
“我们的项目已经进行了测试，不需要再进行评审了”。
“评审都是在走过场，没有效果……”。
业界公认评审是质量控制最有效的手段之一，但评审在很多公司却没能很好地实施，甚至没有实施，公司也未能从中获益。一方面因为员工不清楚评审的目的、评审和测试的区别，认为评审只不过是除了测试以外的锦上添花的过场。另一方面也因为许多公司制定的评审流程流于形式，缺乏可操作性，也未对员工进行评审流程的培训，未能在评审流程执行过程中提供适当的指导和监督。
Why-为什么要技术评审？
测试无疑是质量控制最常用的方法之一，因此很多公司认为对产品进行了测试就万事大吉了。而评审是一种在产品开发过程中尽早发现缺陷的手段。根据IBM的统计数据显示：大多数企业的产品开发中，2/3的缺陷都是在需求和设计阶段引入的。因此，通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。
缺乏技术评审，或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”，开发人员不得不拼命加班“救火”，而最终由于缺陷越来越多，产品上市时间也所剩无几，不得不遗憾地放弃——产品只能带着缺陷发布给客户，听天由命了。
案例：某产品由于未经严格评审，而匆促上市，结果发现设计指标不符合规格书要求，设计中未考虑工程和维护的问题，产品质量问题多多，生产的单板直通率低，生产效率不高，结果开发工作重新回炉，导致客户投诉不断，用户怨声载道，严重影响用户关系和公司产品形象；导致所有开发人员全部出去救火，开发周期大大加长，开发投入增加，库存积压占用资金。
评审的目的在于：越早发现问题，总体成本越低，因此要评审，评审，再评审！等到测试已经太迟了！
What-什么是技术评审？
测试和技术评审都是有效的质量控制手段，但也有明显的区别。
类似地，技术评审和测试的目的都是为了寻找缺陷，寻找缺陷的目标不是证明它是正确的，而是证明产品不能工作。
测试是在产品运行时进行的动态分析，测试的对象为原型、中间产品和最终产品。相对地，评审是一种静态分析，评审对象通常是技术文档、代码、计划、测试用例和测试数据、测试结果等。
How- 如何做好技术评审？
1、技术评审常见的问题
许多公司虽然执行了技术评审，但却未能从中获益，这往往是因为以下的原因导致的：
没有评审计划，没有充分的准备
专家选择不合适
评审会议偏离主题和重点，过多争论占用大量时间
没有使用Checklist作为指导
问题修改后跟踪不力……
由此可见，评审效率不高的原因主要是因为缺乏可操作的评审规程、评审执行和跟踪不力导致的。因此，针对不同类型的工作产品，应制定包括多种评审类型的规程，并借助检查单的使用来提高评审的可操作性。
附录二：单元测试
单元测试是一种设计,而不单单是”测试”
在XP和refactoring中,单元测试编写过程其实就是表达设计的过程.接着所写的代码是为了测试你的单元测试是否正确,也就是说代码的实现是否符合设计的过程.在接着refactoring的过程中,单元测试肩负了两种责任:传统的,refactoring没有产生bug.和设计的,refactoring不破环你原先的设计,也就是不破坏程序的可观察行为.
回顾一下最初的refactoring步骤也许能够让我们看得更清楚:
1. 首先编写单元测试(表达设计或者说声明接口)
2. 编写代码通过单元测试(测试设计)
3. Refactoring
4. 重新运行测试(不产生bug,不破坏设计)
显然,这与传统的单元测试是一个颠倒的过程.一个用单元测试来测试代码,另一个让代码来测试单元测试.这种顺序颠倒引发的一个有意思的现象是你很难把单元测试归入到白箱或者黑箱测试
单元级别的功能测试具体实施，既可以用白盒的方法，也可以用黑盒的方法，这一点和和传统的功能测试定义有点出入。 |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图