软件评审方法(软件评审包括哪些内容)
1.软件评审包括哪些内容
在软件的生命周期内所实施的对软件本身的评审。
评审本身根据不同的评审阶段，分为需求评审，功能评审，质量评审，成本评审，维护评审等。一般来说，评审（Peer Review）包括下面几种检视（Inspection）团队评审（Team Review/Technical Review）走读（WalkThrough）成对编程（Pair Programming）同行检查（Peer DeskCheck）特别检查（Ad hoc Review）评审方法间的区别（1）评审方法间的区别（2）。
2.软件测试的方法都有哪些
软件测试的方法根据软件工程的组织和实现方式，有很大差别，有些是比较技术化的方法，有些则是工程方法，主要分为：
黑盒测试方法群：等价类划分、边界值、因果图、基路径法、专家测试法、smoking、场景测试等
白盒测试方法群：同行评审、需求审查、代码审查、接口测试（调用测试和返回测试，需要结合等价类和因果图方法）等。
当在单元层面黑盒而在集成层面白盒时，基本上两类方法就会有结合了，就会出现习惯上说的灰盒测试（说实话，不做到纯产品级开发，基本上都是用的灰盒测试）。
3.软件项目中如何开展有效的需求评审
2 需求评审的关键 下文根据笔者多年参与软件项目管理的切身体会及经验，从不同角度对需求评审方法进行论述。
2·1 充分准备评审 好的软件需求说明书，是进行有效需求评审的前提。首先，需求人员在与用户确认需求的过程中，一定不要放过任何一个细节，仔细体会用户的每一个要求。
对于用户的要求，需求人员需要对其加以梳理：哪些是合理的需求，哪些是不合理的需求，还有一些可能是必要的但是用户没想到的需求。软件需求说明书不应该只是用户意愿的表达，而应该是从软件层面上对用户需求的总结。
软件需求说明书对需求用例的描述一般分为基本流和扩展流，基本流是大家很容易想到的主要业务流程，而实际设计开发及测试过程中，最耗费时间的是实现扩展流的过程。因此不能只注重基本流，好的软件需求说明书，扩展流一定远远多于基本流，扩展流写得越完善，说明需求人员考虑得越周全。
而实质上，如果扩展流写得不完善，后期的设计、开发及测试人员往往在相应的细节处理上无所适从。2·2分层次评审 用户的需求是可以分层次的，一般而言分成以下层次：①目标性需求，定义整个系统需要达到的目标；②功能性需求，定义了整个系统必须完成的任务；③操作性需求，定义了完成每个任务的具体的人机交互；目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。
对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费。
分层次评审，可以让不同类型的参与人分别评审他们关注的内容，从不同的角度找到需求的异常，提高评审效率。
4.软件测试评审流程
1.什么是同行评审
同行评审是一种通过作者的同行（开发、测试、QA等）来确认缺陷和需要变更区域的检查方法。
一、计划阶段
1.项目负责人指定组织者；作者自检工作产品；组织者规划本次评审，制定Review Plan
2.检查入口准则：是否符合文档标准？是否已用工具检查？代码3.准备评审包：评审通知单；待Review产品；参考资料；评审表单（Review Form）；评审计划（Review Plan）;
4.确定评审专家3—6人，选取原则： 评审对象所处生命周期上一阶段、当前阶段和后一阶段的参与者（就是和评审对象相关的人）
5.组织者将评审包、评审通知单发给相关人员
二、介绍会议（*可选）
1.不了解流程以及产品技术难度较高，技术较新时，由专家提出，作者讲解相关产品及流程
2.时间不超过1小时，30-60分为宜
三、准备阶段（最重要、发现缺陷最多）
1.评审专家个人独立完成工作产品的审视，提出缺陷，填写评审表单；反馈评审表单给组织者
2.准备时间大于会议时间，且应于会议前2天开始
3.组织者：汇总并检查评审表单；裁决是否需要增加评审投入（增加准备时间；增加评审专家人数；更换评审专家等）
四、Review会议（只提问题，不关注解决）
1.组织者召开评审会议（不能是作者）
2.讲解员讲解工作产品（不能是作者或组织者）
3.大家共同确认问题（评审表单中记录的问题；会上发现的问题），由组织者作裁决
4记录员记录所有的问题，并发给组织者
5.组织者更新评审表单（问题确认、问题根源、预防/修正措施）
五、第三小时会议（*可选）
在Review会议上未解决或有争议的问题，由作者决定是否召开
六、返工
作者修改工作产品，更新评审表单
七、跟踪
1.组织评审专家确认各缺陷得到了修改，并且没有引入新的缺陷；
2.协助组织者确认相关问题得到了正确修改并且没有引入新的缺陷；
3. 汇总所有需要的数据到评审表单发给相关评审专家
4.是否重新Re-review
5.软件质量保证的技术评审
⑴发现功能、逻辑或实现的错误
⑵证实经过评审的软件的确满足需求
⑶保证软件的表示符合预定义的标准
⑷得到一种一致的方式开发的软件
⑸使项目更易管理 3-5人参加，不超过2小时，由评审主席、评审者和生产者参加，必须做出下列决定中的一个 ：
⑴工作产品可不可以不经修改而被接受；
⑵由于严重错误而否决工作产品；
⑶暂时接受工作产品。 评审什么？由谁评审？结论是什么？
评审总结报告是项目历史记录的一部分，标识产品中存在问题的区域，作为行政条目检查表以指导生产者进行改正。 ⑴评审产品，而不是评审生产者。注意客气地指出错误，气氛轻松。
⑵不要离题，限制争论。有异议的问题不要争论但要记录在案。
⑶对各个问题都发表见解。问题解决应该放到评审会议之后进行。
⑷为每个要评审的工作产品建立一个检查表。应为分析、设计、编码、测试文档都建立检查表。
⑸分配资源和时间。应该将评审作为软件工程任务加以调度。
⑹评审以前所做的评审
6.软件工程正式的技术评审知道原则有哪些
技术评审（Technical Review,TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除
缺陷，从而有效地提高产品的质量。包括有正式技术评审和非正式技术评审。
正式技术评审的原则：
作者答复评审员的问题，
并与评审员共同查找缺陷、商讨缺陷解决方案。评审结束后，作者应当及时消除工作成果中的缺陷。
1.要有严格的评审计划，并遵守日程安排。
2.
评审小组
☆ 评审主持人应当具备比较高的技术水平和比较丰富的评审经验，能够控制评审会议的进程。评审主持人可以是项目内的技术骨干，也可以是项目外的技术专家。评审主持人本身是一名评审员，评审结论必须有评审主持人的签字才能生效。
☆评审员主要来源于项目内和项目外的技术人员，必要时还应当要求客户和质量保证人员担任评审员。
工作成果的作者不能担任评审员。
评审员的人选以及分工都由评审主持人来确定。
评审员应当根据“检查表”认真地查找工作成果中的缺陷，并和作者共同商讨缺陷解决方案。
☆评审小组的总人数一般在3~7人之间。
记录员：由评审主持人指定一位评审员来担任记录员。记录员如实地将评审过程记录在指定的文档中。
7.软件测试方法有哪些
1、按是否查看程序内部结构分为：
(1)黑盒测试（black-box testing）：只关心输入和输出的结果
(2)白盒测试（white-box testing）：去研究里面的源代码和程序结构
2、按是否运行程序分为：
(1)静态测试（static testing）：是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档可能存在的错误的过程。
静态测试包括：
对于代码测试，主要是测试代码是否符合相应的标准和规范。
对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。
对于文档测试，主要测试用户手册和需求说明是否真正符合用户的实际需求。
(5)动态测试（dynamic testing），是指实际运行被测程序，输入相应的测试数据，检查输出结果和预期结果是否相符的过程
3、按阶段划分：
(1)单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。
桩模块（stud）是指模拟被测模块所调用的模块，驱动模块（driver）是指模拟被测模块的上级模块，驱动模块用来接收测试数据，启动被测模块并输出结果。
(2)集成测试（integration testing），是单元测试的下一阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部门。
集成测试就是用来检查各个单元模块结合到一起能否协同配合，正常运行。
(3)系统测试（system testing），指的是将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试的主要依据是《系统需求规格说明书》文档。
(4)验收测试（acceptance testing），指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。
验收测试又分为a测试和beta测试，其中a测试指的是由用户、测试人员、开发人员等共同参与的内部测试，而beta测试指的是内测后的公测，即完全交给最终用户测试。
4、黑盒测试分为功能测试和性能测试：
1）功能测试（function testing），是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。
包括逻辑功能测试（logic function testing）
界面测试（UI testing）UI=User Interface
易用性测试（usability testing）：是指从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。
兼容性测试（compatibility testing）：包括硬件兼容性测试和软件兼容性测试
2）性能测试（performance testing）
软件的性能主要有时间性能和空间性能两种
时间性能：主要指软件的一个具体事务的响应时间（respond time）。
空间性能：主要指软件运行时所消耗的系统资源。
软件性能测试分为：
一般性能测试：指的是让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
稳定性测试也叫可靠性测试（reliability testing）：是指连续运行被测系统检查系统运行时的稳定程度。
负载测试（load testing）：是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
压力测试（stress testing）：是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。（Validate the system or software can allowed the biggest stress.）
8.软件测试的方法有哪几种
《全国计算机等级考试三级教程软件测试》目录 第1章 软件测试的基本概念1.1 软件质量的概念1.1.1 软件质量的定义1.1.2 软件质量的属性1.1.3 软件质量模型1.1.4 软件质量的度量1.1.5 影响软件质量的主要因素1.2 软件测试的概念1.2.1 软件测试的定义与目的1.2.2 软件测试的原则1.3 软件的缺陷与错误1.3.1 软件缺陷的定义和类型1.3.2 软件缺陷的级别1.3.3 软件缺陷产生的原因1.3.4 软件缺陷的构成第1章 软件测试的基本概念1.1 软件质量的概念1.1.1 软件质量的定义1.1.2 软件质量的属性1.1.3 软件质量模型1.1.4 软件质量的度量1.1.5 影响软件质量的主要因素1.2 软件测试的概念1.2.1 软件测试的定义与目的1.2.2 软件测试的原则1.3 软件的缺陷与错误1.3.1 软件缺陷的定义和类型1.3.2 软件缺陷的级别1.3.3 软件缺陷产生的原因1.3.4 软件缺陷的构成1.3.5 修复软件缺陷的代价1.4 软件测试的经济学与心理学1.4.1 软件测试的心理学1.4.2 软件测试的经济学1.5 软件质量保证1.5.1 软件质量保证概要1.5.2 软件质量保证活动的实施1.5.3 软件的验证与确认1.5.4 验证和确认任务分析 本章小结 第2章 软件生存周期中测试的实施2.1 软件开发阶段2.1.1 软件生存周期2.1.2 软件测试的生存周期模型2.1.3 软件测试过程模型2.1.4 测试信息流2.2 需求获取与分析阶段的测试2.2.1 需求评审的实施2.2.2 需求规格说明的评审2.2.3 Wiegers 用例与需求评审表2.2.4 基于原型的测试2.2.5 基于需求的测试覆盖率评估2.3 设计阶段的测试2.3.1 设计的测试因素2.3.2 设计评审的实施2.3.3 设计规格说明的评审2.3.4 设计元素的覆盖原则2.4 编程阶段的测试2.4.1 白盒测试与黑盒测试2.4.2 源代码的控制流覆盖原则2.4.3 源代码的数据流覆盖原则2.4.4 源代码的静态分析与动态测试2.5 运行和维护阶段的测试2.6 回归测试2.6.1 回归测试的概念2.6.2 回归测试的类型2.6.3 回归测试的时机2.6.4 回归测试的实施 本章小结 第3章 代码检查、走查与评审3.1 桌上检查3.1.1 桌上检查的实施3.1.2 桌上检查的检查表3.2 代码检查3.2.1 特定的角色和职责3.2.2 代码检查的实施3.2.3 用于代码检查的检查表3.3 走查3.3.1 特定的角色和职责3.3.2 走查的实施3.3.3 走查中的静态分析技术3.4 同行评审3.4.1 同行评审的角色和职责3.4.2 同行评审的内容3.4.3 评审的方法和技术3.4.4 评审工作 本章小结 第4章 白盒测试4.1 覆盖率的概念4.2 逻辑覆盖4.2.1 语句覆盖与块覆盖4.2.2 判定覆盖（分支覆盖）4.2.3 条件覆盖4.2.4 条件/判定覆盖4.2.5 条件组合覆盖4.2.6 路径覆盖4.2.7 ESTCA覆盖4.2.8 LCSAJ覆盖4.3 路径测试4.3.1 分支结构的路径测试4.3.2 循环结构的路径测试4.3.3 圈复杂度与基本路径测试4.4 数据流测试4.4.1 定义∕使用测试的几个定义4.4.2 定义∕使用测试举例4.4.3 定义∕使用路径测试覆盖指标4.5 基于覆盖的测试用例选择4.5.1 覆盖率的使用4.5.2 使用最少的测试用例来达到覆盖4.6 程序插桩技术4.6.1 程序插桩4.6.2 用于测试覆盖率的程序插桩4.6.3 用于断言检测的程序插桩4.6.4 用于数据流异常检测的程序插桩 本章小结 第5章 黑盒测试5.1 等价类测试5.1.1 等价类的概念5.1.2 等价类测试的原则5.1.3 等价类方法测试用例设计举例5.2 边界值分析5.2.1 边界值分析的概念5.2.2 选择测试用例的原则5.2.3 边界值方法测试用例设计举例5.3 基于判定表的测试5.3.1 判定表的概念5.3.2 基于判定表的测试用例设计举例5.4 基于因果图的测试5.4.1 因果图的适用范围5.4.2 用因果图生成测试用例5.4.3 因果图法测试用例设计举例5.5 基于状态图的测试5.5.1 状态图5.5.2 利用状态转换树生成测试用例5.5.3 利用状态转换表生成测试用例5.6 基于功能图的测试5.6.1 功能图5.6.2 功能图法设计测试用例举例5.7 基于用例和场景的测试5.7.1 基本流和备选流5.7.2 利用用例和场景设计测试用例的实例5.8 基于有向图的测试用例设计5.8.1 使用基于有向图的测试的场合5.8.2 基于事务流建模设计测试用例5.8.3 基于控制流建模设计测试用例5.8.4 基于有向图设计测试用例的过程5.9 基于正交实验设计法的测试5.9.1 提取功能说明，构造因子/ 状态表5.9.2 加权筛选，生成因素分析表5.9.3 利用正交表构造测试数据集5.10 其他黑盒测试用例设计技术 本章小结 第6章 单元测试和集成测试6.1 单元测试的基本概念6.1.1 单元测试的定义6.1.2 单元测试与集成测试、系统测试的区别6.1.3 单元测试环境6.2 单元测试策略6.2.1 自顶向下的单元测试策略6.2.2 自底向上的单元测试策略6.2.3 孤立测试6.2.4 综合测试6.3 单元测试分析6.3.1 模块接口6.3.2 局部数据结构6.3.3 独立路径6.3.4 出错处理6.3.5 边界条件6.4 单元测试的测试用例设计原则6.4.1 单元测试的测试用例设计步骤6.4.2 单元测试中的白盒测试与黑盒测试6.5 集成测试的基本概念6.6 集成测试策略6.6.1 基于分解的集成策略6.6.2 基于功能的集成6.6.3 基于路径的集成6.6.4 基于调用图的集成6.7 集成测试分析6.7.1 体系结构分析6.7.2 模块单元分析6.7.3 接口分析6.7.4 风险分析6.7.5 可测试性分析6.7.6 集成测试策略分析6.7.7 常见的集成测试故障6.8 集成测试的测试用例设计原则6.8.1 集成测试的测试用例设计步骤6.8.2 场景测试 本章小结 第7章 系统测试7.1 系统测试概念7.2 系。
