|
我们的优势：
|
1、语种齐全(现在已经可以翻译全球一百多种语言)
2、质量保证(
专业的翻译译员
3、快捷守时(大量的译员完全可以为您做到快速翻译)
4、机密性(严格的翻译资料保密制度，严守客户商业机密,确保客户利益) |
|
软件测试中用到的中英文用语
技术评审
在工作中，我们经常可以听到以下的声音：
“我们不进行评审，是因为我们项目比较特殊，没有时间……”。
“我们的项目已经进行了测试，不需要再进行评审了”。
“评审都是在走过场，没有效果……”。
业界公认评审是质量控制最有效的手段之一，但评审在很多公司却没能很好地实施，甚至没有实施，公司也未能从中获益。一方面因为员工不清楚评审的目的、评审和测试的区别，认为评审只不过是除了测试以外的锦上添花的过场。另一方面也因为许多公司制定的评审流程流于形式，缺乏可操作性，也未对员工进行评审流程的培训，未能在评审流程执行过程中提供适当的指导和监督。
Why-为什么要技术评审？
测试无疑是质量控制最常用的方法之一，因此很多公司认为对产品进行了测试就万事大吉了。而评审是一种在产品开发过程中尽早发现缺陷的手段。根据IBM的统计数据显示：大多数企业的产品开发中，2/3的缺陷都是在需求和设计阶段引入的。因此，通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。
缺乏技术评审，或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”，开发人员不得不拼命加班“救火”，而最终由于缺陷越来越多，产品上市时间也所剩无几，不得不遗憾地放弃——产品只能带着缺陷发布给客户，听天由命了。
案例：某产品由于未经严格评审，而匆促上市，结果发现设计指标不符合规格书要求，设计中未考虑工程和维护的问题，产品质量问题多多，生产的单板直通率低，生产效率不高，结果开发工作重新回炉，导致客户投诉不断，用户怨声载道，严重影响用户关系和公司产品形象；导致所有开发人员全部出去救火，开发周期大大加长，开发投入增加，库存积压占用资金。
评审的目的在于：越早发现问题，总体成本越低，因此要评审，评审，再评审！等到测试已经太迟了！
What-什么是技术评审？
测试和技术评审都是有效的质量控制手段，但也有明显的区别。
类似地，技术评审和测试的目的都是为了寻找缺陷，寻找缺陷的目标不是证明它是正确的，而是证明产品不能工作。
测试是在产品运行时进行的动态分析，测试的对象为原型、中间产品和最终产品。相对地，评审是一种静态分析，评审对象通常是技术文档、计划、测试用例和测试数据、测试结果等。
How- 如何做好技术评审？
1、技术评审常见的问题
许多公司虽然执行了技术评审，但却未能从中获益，这往往是因为以下的原因导致的：
没有评审计划，没有充分的准备
专家选择不合适
评审会议偏离主题和重点，过多争论占用大量时间
没有使用Checklist作为指导
问题修改后跟踪不力……
由此可见，评审效率不高的原因主要是因为缺乏可操作的评审规程、评审执行和跟踪不力导致的。因此，针对不同类型的工作产品，应制定包括多种评审类型的规程，并借助检查单的使用来提高评审的可操作性。
2、常见的技术评审的类型
常见的技术评审包括了走查（Walkthrough）、轮查（Pass Around）、正式的同行评审（Peer Reviews）等。
1)走查（Walkthrough）：是大名鼎鼎的面向对象方法学的开发者之一Yourdon 定义的方法，它由作者启动和主持评审，作者向评审者展示文档。优点是启动快，成本低，缺点是容易被作者误导过程。
2)轮查（Pass Around）：作者向评审者作简要介绍，但不参加评审过程；评审者独立进行评审，并记录发现结果、准备报告。
3)同行评审：评审者与作者是地位平等的同行/专家，而不是领导对员工的评价；是最为结构化的评审方法；可以作为同行之间学习和分享经验的机会。
3、同行评审简介
在软件CMM中首次提出了同行评审（Peer Reviews）这个概念，它的目标是在产品开发过程中尽早发现缺陷，从而以较低的成本尽早解决缺陷。这种方法借鉴了IBM的范根检查法（Fagan Inspection）的优点，是一种结构化的正式的评审方法。
同行评审有明确的角色定义：
协调员（Moderator）：保证评审按流程进行。
朗读者（Reader）：评审的技术领导，把焦点放在有争议的问题方面。
记录员（Recorder）：负责记录缺陷。
评审员（Reviewer）：负责发现缺陷，除了作者外，所有的其他角色都可以担任评审员。
作者（Author）：负责修正缺陷。
同行评审通常包括六个步骤：制定计划、召开准备会议、评审人员独立预审、召开评审会议、返工、跟进返工结果。各个步骤的活动说明如下：
1)计划：选择参与者；准备检查单。
2)准备会：分配各参与人员的角色；作者对产品作概要介绍。
3)个人预审：评审者研究评审文档，使用检查单寻找缺陷，记录发现结果。
4)评审会议：读者阅读评审文档，评审员发现缺陷，对有争议的问题进行讨论；作者一般保持沉默，除非读者要求对产品作解释。
5)返工：作者修正错误。
6)跟进：检查修正工作的进展；分析错误原因；分析评审过程，补充完善检查单。
附：做好技术评审的小贴士
不因为时间紧迫和缺少预算而省略评审
评审前充分准备和沟通
安排合理的预审时间以便评审人员阅读评审材料
技术评审应当“就是论事”，不要把评审会开成“批斗会”，不要打击有失误的开发人员的工作积极性，更不准搞人身攻击，如挖苦、讽刺等
评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消除缺陷的办法，而不是替开发人员消除缺陷
把技术评审作为交流、提高的机会
记录评审中出现的问题，跟踪改进
定期改进技术评审检查单，把检查单作为持续改进的重要载体
评审者必须是领域内的专家
When-常见的技术评审点举例
在对工作产品建立基线之前进行评审，目的是发现缺陷。
|
同行评审过程描述（一）——概述
1. Overview（概述）
·In a peer review, co-workers of a person who created a software work product examine that product to identify defects and correct shortcomings. A review:
·在同行评审中，由软件工作产品创建者的同行们检查该工作产品，识别产品的缺陷，改进产品的不足。评审：
· verifies whether the work product correctly satisfies the specifications found in any predecessor work product, such as requirements or design documents
· 检验工作产品是否正确的满足了以往的工作产品中建立的规范，如需求或设计文档
· identifies any deviation from standards, including issues that may affect maintainability of the software
· 识别工作产品相对于标准的偏差，包括可能影响软件可维护性的问题
· suggests improvement opportunities to the author
· 向创建者提出改进建议
· promotes the exchange of techniques and education of the participants.
· 促进参与者之间的技术交流和学习
All interim and final development work products are candidates for review, including:
所有中间和最终的开发工作产品都可以进行评审，包括：
· requirements specifications
· 需求规格说明书
· user interface specifications and designs
· 用户界面规范及设计
· architecture, high-level design, and detailed designs and models
· 架构，概要设计，详细设计及模型
· source code
· 源代码
· test plans, designs, cases, and procedures
· 测试计划，设计，用例及步骤
· software development plans, including project management plan, configuration management plan, and quality assurance plan
· 软件开发计划，包括项目管理计划，配置管理计划和质量保证计划
This document defines an overall peer review process. It includes procedures for conducting inspections and two types of informal peer review, a walkthrough and a passaround, as well as guidance for selecting the appropriate approach for each review.
该文档定义了一个全面的同行评审过程。包括了执行评审的步骤和两种非正式的同行评审，走查和轮查，以及对每个评审选择适当方法的指南。
2. Work Aids（工作辅助项）
The following peer review work aids are available from :
<场所>中，需要有如下的同行评审工作辅助项：
· Inspection Summary Report
· 评审总结报告
· Issue Log
· 问题日志
· Typo List
· 微错清单
· Inspection Moderator’s Checklist
· 评审负责人的检查表
· Inspection Lessons Learned Questionnaire
· 评审经验教训问卷
· defect checklists for several types of software work products
· 各种软件工作产品的缺陷检查表
3. Risk Assessment Guidance（风险评估指南）
To judge which software components (or portions of components) to review and what type of review method to use, consider the following risk criteria:
在判断哪些软件组件（或组件的部分）需要评审及使用哪种评审方法的时候，需要考虑如下的风险条件：
· components that use new technology, techniques, or tools
· 使用了新技术，方法，工具的组件
· key architectural components
· 关键的架构性的组件
· complex logic or algorithms that are difficult to understand but must be accurate and optimized
· 难以理解，却又必须准确和优化的复杂逻辑或算法
· mission-, security-, or safety-critical components with dangerous failure modes
· 具有危险失败模式的组件，而且是任务、可靠性、安全性关键的
· components having many exception conditions or failure modes
· 具有多个异常条件或失败模式的组件
· exception handling code that cannot easily be tested
· 不易测试的异常处理代码
· components that are intended to be reused
· 打算复用的组件
· components that will serve as models or templates for other components
· 将作为其他组件的模型或模板的组件
· components that affect multiple portions of the product
· 影响产品多个部分的组件
· complex user interfaces
· 复杂的用户界面
· components created by less experienced developers
· 由缺乏经验的开发者创建的组件
· code modules having high cyclomatic complexity
· 具有高度圈复杂性的代码模块
· modules having a history of many defects or changes
· 以往具有很多缺陷或变更的模块
Work products that fit in one or more of these categories are considered high risk. A product is considered low risk if an undetected error will not significant affect the project’s ability to meet its schedule, quality, cost, and feature objectives. Use inspections for high-risk work products, or the high-risk portions of large products, and for major work products that are about to be baselined. Less formal reviews are acceptable for other work products
符合这些条件中一种或几种的工作产品被认为是高风险的。如果未发现的缺陷对项目达成进度，质量，成本及特征目标的能力没有重大影响，则该工作产品被认为是低风险的。评审只用于高风险的工作产品或大产品的高风险部分或将要被基线化的主要工作产品。对其他的工作产品可以进行不太正式的评审。
4. Participants（参与者）
Table 1 suggests project roles who might review different work products. Not all of these perspectives need to be represented. In general, a work product should be reviewed by:
不是所有这些角度都必须表现出来。通常，一项工作产品的评审需要有：
· the author of any predecessor document or specification
· 以往的文档或规范的创建者
· someone who must base their subsequent work on the work product
· 以该工作产品为基础进行后续工作的人。
· peers of the author
· 创建者的同行们
· anyone responsible for a component to which the work product interfaces
· 使用该工作产品接口的组件的负责人
Attendance by anyone with supervisory authority over the author is by invitation of the author only.
对工作产品创建者具有监督权力的人只能在创建者的邀请下参加评审。
Work Product Type工作产品类型 Work Product Type工作产品类型
Architecture or High-Level Design架构或概要设计 architect, requirements analyst, designer, project manager, integration test engineer架构师，需求分析师，设计师，项目经理，集成测试工程师
Detail Design详细设计 designer, architect, programmer, integration test engineer设计师，架构师，程序员，集成测试工程师
Process Documentation过程文档 process improvement group leader, process improvement working group members, management-level process owner, practitioner representatives who will use the process过程改进组负责人，过程改进工作组成员，管理级的过程拥有者，使用过程的实践者的代表
Project Plans项目计划 project manager, program manager, business sponsor, marketing or sales representative, technical lead, quality assurance manager项目经理，产品经理，需求提出者，市场或销售代表，技术负责人，质量保证工程师
Requirements Specification需求规格说明书 requirements analyst, project manager, architect, designer, system test engineer, quality assurance manager, user or marketing representative, documentation writer, subject matter expert, technical support representative需求分析师，项目经理，架构师，设计师，系统测试工程师，质量保证经理，用户或市场代表，文档编写者，业务专家，技术支持代表
Source Code源代码 programmer, designer, unit test engineer, maintainer, requirements analyst, coding standards expert程序员，设计师，单元测试工程师，维护者，需求分析师，编码标准专家
System Technical Documentation系统技术文档 author, project manager, maintainer, programmer创建者，项目经理，维护者，程序员
Test Documentation测试文档 test engineer, programmer (unit testing) or architect (integration testing) or requirements analyst (system testing), quality assurance representative测试工程师，程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试），质量保证代表
User Interface Design用户界面设计 user interface designer, requirements analyst, user, application domain expert, usability or human factors expert, system test engineer用户界面设计师，需求分析师，用户，应用领域专家，可用性或人体专家，系统测试工程师
User Manual用户手册 ocumentation writer, requirements analyst, user or marketing representative, system test engineer, maintainer, designer, instructional designer, trainer, technical support representative文档编写者，需求分析师，用户或市场代表，系统测试工程师，维护人员，设计师，用户教育设计师，培训师，技术支持代表 |
5. Inspection Procedure（评审步骤）
Participants
参与者 The roles and responsibilities shown below pertain to the inspection process. All participants are inspectors, in addition to any specialized role they might have. At least three participants, including the author, are required for an inspection. If only three people participate in an inspection, the moderator shall also serve as recorder or reader. The author may not serve as reader, moderator, or recorder.下面是评审过程中涉及的角色及责任。所有参与者除了自身担任的特定角色外，也都是检查者。一次评审需要至少三个参与者，包括创建者。如果只有三个人参与评审，那么评审负责人还要兼作记录人或阅读人。创建者一般不作阅读人，评审负责人或记录人。
Role角色 Responsibilities责任
Author
创建者 · Creator or maintainer of the work product to be inspected. Initiates the inspection process by asking the peer review coordinator to assign a moderator.
· 被评审的工作产品的创建者或维护者请求同行评审协调者分配一位评审负责人，从而发起评审过程。
· States his or objectives for the inspection.
· 陈述评审目标· Delivers work product and its specification or predecessor document to moderator.
· 提交工作产品及其规范或以往的文档给评审负责人。
· Works with moderator to select inspectors and assign roles.
· 与评审负责人一起选择检查者，并分配角色。
· Addresses items on the Issue Log and Typo Lists.
· 对应问题日志和微错清单上的项目。
· Reports rework time and defect counts to moderator.
· 向评审负责人报告返工时间和缺陷数。
Moderator
评审负责人 · Uses Inspection Moderator’s Checklist as a work aid.
· 使用评审负责人检查表作为工作辅助。
· Plans, schedules, and leads the inspection events.
· 计划，安排，组织评审活动。
· Works with author to select inspectors and assign roles.
· 与创建者一起选择检查者，并分配角色。
· Assembles inspection package and delivers it to inspectors at least 3 days prior to the inspection meeting.
· 提前评审会议至少三天，将评审项目打包并发送给检查者。
· Determines whether preparation is sufficient to hold the meeting. If not, reschedules the meeting.
· 确定会议准备是否充分。如果不充分，重新安排会议时间。
· Facilitates inspection meeting. Corrects any inappropriate behavior. Solicits input from inspectors as reader presents each section of the work product. Records any action items or side issues that arise during the inspection.
· 促进评审会议进行。纠正任何不适当的行为。随着阅读人展现工作产品的各部分，引导检查者提出问题。记录评审过程中提出的行动决议或问题。
· Leads inspection team in determining the work product appraisal.
· 领导评审小组确定工作产品的评估结果。
· Serves as verifier or delegates this responsibility to someone else.
· 作为审核者或指派其他人承担该责任。
· Delivers completed Inspection Summary Report to the organization’s peer review coordinator.
· 提交完成的评审总结报告给组织的同行评审协调者。
Reader
阅读人 Presents portions of the work product to the inspection team to elicit comments, issues, or questions from inspectors.向评审小组展示工作产品的各部分，引导检查者进行评论，提出问题或疑问。
Recorder
记录人 Records and classifies issues raised during inspection meeting.记录并分类评审会议中提出的问题。
Inspector
检查者 Examines work product prior to the inspection meeting to find defects and prepare for contributing to the meeting. Records preparation time. Participates during the meeting to identify defects, raise issues, and suggest improvements.在评审会议之前检查工作产品，发现其缺陷，为参加评审会议做准备。记录准备时间。参加评审，识别缺陷，提出问题，给出改进建议。
Verifier
审核者 Performs follow-up to determine whether rework has been performed appropriately and correctly.
进行跟踪，确认返工工作被正确执行。
Peer Review Coordinator
同行评审协调者 Custodian of the project’s inspection metrics database. Maintains records of inspections conducted and data from the Inspection Summary Report for each inspection. Generates reports on inspection data for management, process improvement team, and peer review process owner.项目评审度量数据库的拥有者。维护每次评审的评审记录及来自评审总结报告中的数据。根据评审数据形成报告，提交给管理层、过程改进组及同行评审过程的拥有者。
Entry Criteria
入口条件 o The author selected an inspection approach for the product being reviewed.
o 创建者为待评审的工作产品选择了评审方法。
同行评审过程描述（二）——评审步骤
o All necessary supporting documentation is available
o 准备好所有必需的支持文档。
o The author has stated his or her objectives for this inspection.
o 创建者陈述了该次评审的目标。
o Reviewers are trained in the peer review process.
o 评审者接受了同行评审过程的培训。
o Documents to be inspected are identified with a version number. All pages are numbered and line numbers are displayed. The documents have been spell-checked.
o 为待评审的文档分配了版本号。所有页面都标明了页号和行号。文档经过了拼写错误检查。
o Source code to be inspected is identified with a version number. Listings have line numbers and page numbers. Code compiles with no errors or warning messages using the project's standard compiler switches. Errors found using code analyzer tools have been corrected.
o 为待评审的源代码分配了版本号。代码清单标明了行号和页码。代码已经使用项目标准编译转换器编译过，并且没有错误和警告信息。使用代码分析器发现的错误已经被改正。
o For a re-inspection, all issues from the previous inspection were resolved.
o 对于二次评审，前一次评审中发现的所有问题都已经解决。
o Any additional entry criteria defined for the specific type of work product are also satisfied.
o 满足所有针对特定的工作产品定义的附加入口条件。
|
|
