代码评审

软件的生命周期（prdctrm） 计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码（coding）->测试（testing）->运行与维护（running maintrnacne） 1 ，问：你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。 答： 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2 ，问：给你一个网站，你如何测试？ 答： 首先，查找需求说明、网站设计 m 等相关文档，分析测试需求，制定测试计划，确定测试范围和测试策略，一般包括以下几个部分： 功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面：

C++开源库大全 程序员要站在巨人的肩膀上，C++拥有丰富的开源库，这里包括：标准库、Web应用框架、人工智能、数据库、图片处理、机器学习、日志、代码分析等。 标准库 C++ Standard Library ：是一系列类和函数的集合，使用核心语言编写，也是C++ISO自身标准的一部分。 Standard Template Library ：标准模板库 C POSIX library ： POSIX系统的C标准库规范 ISO C++ Standards Committee ：C++标准委员会 框架 C++通用框架和库 Apache C++ Standard Library ：是一系列算法，容器，迭代器和其他基本组件的集合 ASL ：Adobe源代码库提供了同行的评审和可移植的C++源代码库。 Boost ：大量通用C++库的集合。 BDE ：来自于彭博资讯实验室的开发环境。 Cinder ：提供专业品质创造性编码的开源开发社区。 Cxxomfort ：轻量级的，只包含头文件的库，将C++ 11的一些新特性移植到C++03中。 Dlib ：使用契约式编程和现代C++科技设计的通用的跨平台的C++库。 EASTL ：EA-STL公共部分 ffead-cpp ：企业应用程序开发框架 Folly ：由Facebook开发和使用的开源C++库 JUCE ：包罗万象的C++类库

转自： http://pm.readthedocs.org/zh_CN/latest/codereview/howto.html 如何进行code review？ code reivew是保障代码质量的实用方法之一，这里简单分享下个人code review的经验。建议只当案例来看，因为不同项目、不同团队所做的事情、所具备的技术背景也是不同的，当然也会有些通用的点。 现实情况 先问下，你所在的公司有code review的习惯不？你所在的团队呢？你个人呢？如果没有的话，为啥会忽略这个环节呢？ 来说下现实情况，大多数公司做的项目，如果按项目规模来看，都是很小的项目，即使是很大的项目，正确的做法也必然会拆分成多个小项目，由多个团队同时合作完成。在这个前提下，实际每天每个程序员提交的代码量是很少的，对这么少的代码变更进行code review其实是花不了个人多少时间的。 我觉得完全每天可以抽出半小时，乃至一小时的时间来对别人的代码进行review，比如： 或每天上班正式开始自己的工作前，边吃早点边code review别人昨天的几次提交。 或中午大桌聚餐在大液晶屏，边吃边评论互相的代码 或每天下班前花半个小时review下别人代码 只是随便举几个场景的例子，code review形式不限、时间、地点更无所谓。 不同的团队，不同的项目，在不同的时期，可能对代码发布的要求不同： 有的团队

Code Review 做软件开发的时间转眼也有三年有余，所在的团队也使用了各种各样的代码质量控制方法，个人觉得Code Review是一个最有效的方法，同时也是“性价比”最高的代码质量控制方法。现将个人的一些观点和看法总结一下 什么是Code Review Code Review 中文的翻译方式有很多种“代码审查”，“代码评审”，“代码走查”等，个人更喜欢“代码走查”这种翻译。代码走查是一个流程，从开发人员在一个开发阶段写好代码后开始，之后需要别人以发现bug和技术交流为目的review一下他的代码。它是集代码审查，找出问题，改进代码和改后督查为一体的完整的流程。代码走查一般在代码刚刚出炉为最好，因为在这个时候也是代码重构和调整的最佳时候。 Code Review的目的及内容 功能性Review: 通过Review检查当前代码是否全部实现了需求里面全部的功能点，且功能正确。找出代码中的bug，每个人在写和读代码的时候都有固有的习惯，这样的一些习惯往往会影响代码的质量。比如：我们在代码编写过程中都出现过类似的问题，自己代码中的问题自己无论看了多少遍都发现不了，但别人一眼就能发现问题。出现这样的情况并不是说写代码的人水平不高而是个人编程中的“无意识”错误。当然这也就是结队编程的妙处。 可读性Review: 代码做为软件开发过程中最实时的文档，同时为了以后维护方便一定要有高度的可读性

1、单元测试概念 1）单元测试是对软件基本组成单元进行的测试，如函数（fuction或procedure）或一个类的方法（method）。这里，基本单元不一定是指一个具体的函数（fuction或procedure）或一个类的方法（method），在具体实现时，也可能对应的是多个程序文件中的一组函数。 2）在软件系统中，单元也具有一些基本属性，如：明确的功能、规格定义、明确的与其他部分的接口定义等，可清晰的与同一程序的其他单元划分开来。 2、单元测试的目的 1)单元测试的目的在于发现各模板内部可能存在的各种错误，主要是基于白盒测试。 2)软件产品不仅仅包含代码，还包含各种文档，因此测试应从三方面考虑: a.针对文档的测试; b.针对代码的测试; c.针对文档和代码是否一致的测试。 3）单元测试阶段，对应的文档时详细设计说明书，对应的代码是单元代码，因此单元测试的目的主要有三方面： a.验证单元代码和详细设计文档的一致性; b.跟踪详细设计文档中设计的实现，发现详细设计文档中存在的错误; c.发现在编码过程中引入的错误(编码过程中引入的错误包含两类:和设计不符引入的错误;和设计相符但由于编码出现疏漏导致错误),这里其实是针对文档和代码是否一致的测试。 3、单元测试中常见错误（单元测试关注重点） 单元的常见错误一般出现在5个方面：代码的稳定、易读、规范、易维护、专业。 因此

软件测试-测试分类 一、按软件测试阶段： a. 单元测试 b. 集成测试 c. 系统测试 d. 验收测试 1、单元测试 单元测试的原则： 1、尽可能保证部没测测试用例相互独立 2、一般由代码的编写人员来实施 单元测试的优点： 1、能尽早发现缺陷 2、有利于重构 3、可以简化集成 单元测试的缺陷 1、不可能穷尽测试，即测试用例不可能覆盖所有的执行路径，不可能捕捉到所有的错误 2、每一行代码需要3-5行测试代码来完成测试 单元测试框架 xUnit，比如：JUnit 例：eclipse->new->Java project->(finish)->右键项目->properties->Java Build Path->Add library->选择JUnit->next->选择Junit版本->finish 选中需要测试的类，在上右键->new->junit test case(勾选setUp()和tearDown() )->next( 选择需要测试类中待测试的方法 ) -> finish() 2、集成测试 在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块，子系统或者系统的过程中各部分工作是否达到或者实现相应3技术指标及要求的活动。 集成测试实施方案 1、BIg Bang（一次性集成/大爆炸）：把大部分开发模块耦合起来，形成一个完整的软件系统

下面开始本书第三部分的读书笔记部分 第三部分 软件测试中的人工测试方法 　　包括第3章 代码检查、走查与评审 第3章 代码检查、走查与评审 　　1、代码检查和代码走查 　　代码检查和代码走查是一种人工测试方法，这种测试技术在编码之后计算机测试之前使用，要求人们组成一个小组来阅读和检查程序，可以有效的在项目早期发现错误，并改正错误。代码检查和代码走查有以下的相同点： 三到四人的小组对程序进行审核 成员包括：代码作者、协调人、其他程序专家、测试专家 目标是发现错误而非改正错误 与使用计算机的测试互补 　　1.1 代码检查 　　代码检查是以组为单位阅读代码，有一系列的规程和错误检查技术。 　　1）代码检查小组 　　通常包括四个人：协调人、代码作者、其他程序设计人员、测试专家。 　　协调人职责：1.分发材料、安排进程；2.记录发现的错误；3.确保错误随后的改正。 　　代码作者职责：逐条讲解程序代码的逻辑结构。 　　其他程序设计人员：提问题，并判断程序是否存在错误。 　　测试专家：熟悉软件测试，并知道大部分的常见编码错误。 　　2）检查议程与注意事项 　　a) 代码评审之前：协调人将程序清单和设计规范分发给其他成员 　　b) 代码评审时： 　　　　1.编码人员对程序进行讲解； 　　　　2.其他程序人员提问题，并参考常见编码错误列表分析程序； 　　　　3.协调人确保会议高效进行； 　　c)

1. 接口 测试 的流程一般是怎么样的？ 　　 小刀： 接口 测试 的流程其实和 功能 测试 的流程类似，因为 接口 测试 依赖的主要对象也是需求说明书，所以，最初的流程就是参与需求讨论，评审需求。 　　需求确定以后，开发会根据需求进行 接口 设计，会产出 接口 定义，在开发设计过程中，有能力的话，可以给出一些针对设计的建议，提高可测性，针对需求及设计，进行 测试 计划， 测试 设计，然后还需要和配管确定 测试 环境相关的事情。 　　在开发完成 接口 定义之后，就根据需求文档及 接口 定义进行 测试 用例设计， 测试 用例设计主要从业务场景，功能，以及异常 测试 几个方面考虑。 　　 测试 用例设计完成后，针对 测试 用例进行评审，然后，如果开发代码部分可测时，即可进入 测试 了，因为是部分可测，可能会使用到mock方法。 　　已有 测试 代码时，就要进行 测试 代码的持续集成了，我们是使用hudson来进行持续集成的 　　在项目结束后，会对每个项目进行总结。 2. 接口 可以分下面几种： 1）系统与系统之间的调用，比如银行会提供 接口 供电子商务网站调用，或者说，支付宝会提供 接口 给淘宝调用 　　2）上层服务对下层服务的调用，比如service层会调用DAO层的 接口 ，而应用层又会调用服务层提供的 接口 ，一般会通过 　　3）服务之间的调用，比如注册用户时

1.软件的生命周期（prdctrm） 计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码 （coding）->测试（testing）->运行与维护（running maintrnacne） 2、问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准：根据需求说明书、产品说明、原型图、设计文档等，确认实际结果 是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据， 1）可以根据同行或类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 2）根据用户的一般使用习惯，来确认是否是缺陷； 3）与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 3、给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性 能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转