问题列表
-
编码阶段的参考文档主要有哪些? 如何确保编码的准确? 公司是否定义了编码标准?是否被遵循?
答:1.需求设计编码标准等 2. 走查,单元测试 3. Java、C#等编码标准
-
是否编写用户手册,安装手册?
由谁编写?
答: 编写了,由开发人员编写 -
你的项目是否识别了可替代的集成顺序?
是如何选择最合适的集成顺序的?
答: 1. 根据系统架构关系、业务关系 2. 先根据架构关系、再根据模块业务关系 -
你的项目需要哪些软、硬件集成环境?
答:1. 硬件环境(服务器、客户端等配置) 2. 软件环境(数据库、服务等)
-
你建立了哪些集成标准?
答:1. 准入条件(单元测试通过)2. 集成测试用例 3. 集成退出准则
-
如何确保接口的参数与模块定义的接口一致? 如何确保接口的正确性和完整性?
答:1. 接口一致性审查 2. 通过集成测试用例进行测试
-
设计评审是否发现了问题?如何改正的? 有没有通过模拟/原型模型得到改进的内容? 如何管理这些改进内容?
答:
1. 有,通过记录评审问题,跟踪评审的改进结果(可举例说明)
2. 有,如识别到原来没有意识到的需求等
3. 通过评审缺陷记录进行跟踪、维护 -
如何确保集成前所有模块是无缺陷的? Bug是不是在集成前都已解决?
- 单元测试、代码走查
- 须全部解决才能开始测试/没有严重的Bug存在
-
谁负责系统集成? 有没有集成计划? 集成的模块在哪存档?
- 项目经理/技术经理
- 有
- 在配置库中
-
谁执行集成测试? 测试缺陷记录在哪并且是如何跟踪的?
- 测试人员/开发人员
- 记录在缺陷管理工具中,通过缺陷分配、每周跟踪
-
如何向客户发布系统?
- 测试通过,打包,验证,发布(验证软硬件环境,配置系统安装环境,安装系统)
-
代码评审是怎么做的?
非正式的,开发人员互查,项目经理检查
-
谁来检查编码规范?
通常项目经理会检查开发人员的编码规范遵循情况;在做代码评审时也会检查规范执行 情况
-
单元测试是怎么做的,有没记录?
核心代码代码走查,页面黑盒测试
-
模块测试怎么做的?
开发人员自测和测试人员做全面的专业测试
-
项目组对单元测试、代码评审、模块测试是如何要求的?
代码走查至少选取核心代码来做,单元测试要求语句覆盖
-
是否建立了集成策略? 如何进行的产品集成工作?
集成策略:自底向上或自顶向下或混合方式,持续集成。
产品集成步骤包括:
1)制定产品集成计划,计划的内容包括:确定集成顺序、集成的环境、以及制定集成标准。
2)审查接口的兼容性:按照设计阶段定义好的接口类型,确定接口与产品组件、产品集成环境、外部环境之间(包括软件运行的环境、客户已有的其他应用等)的关系。
3)组装产品组件:检查待集成产品组件,确认集成准备就绪;一次性组装产品组件。
4)进行产品测试:组装产品组件完成后,要通过集成测试的方式来检查这些已组装的产品组件是否能正确运行。集成测试通过,产品集成结束。 -
按照集成的顺序进行集成,当发现集成顺序不合理时调整集成顺序
根据业务逻辑关系分批次进行集成。
-
集成的时候都需要哪些环境,是怎么准备的?
集成的环境包括:
1.开发、编译的工具
2.集成测试的工具
3.集成时的软硬件要求,如:配置服务器,配置网络环境 -
项目/组织级的集成步骤是怎样的? 集成的入口、出口准则是怎样的?
产品集成步骤包括:
1)制定产品集成计划,计划的内容包括:确定集成顺序、集成的环境、以及制定集成标准。
2)审查接口的兼容性:按照设计阶段定义好的接口类型,确定接口与产品组件、产品集成环境、外部环境之间(包括软件运行的环境、客户已有的其他应用等)的关系。
3)组装产品组件:检查待集成产品组件,确认集成准备就绪;一次性组装产品组件。
4)进行产品集成测试:组装产品组件完成后,要通过集成测试的方式来检查这些已组装的产品组件是否能正确运行。集成测试通过,产品集成结束。
入口准则:产品的集成环境已经建立并通过验证;待集成的组件编译及测试通过。评审通过
出口准则:集成后的产品通过编译。完成产品的打包,并通过了集成测试。 -
如何保证内外部接口是兼容的? 是否评审了接口描述?
内外部接口定义需要经过相关人员的评审,确保一致,一般来说在需求文档和概要设计 中描述内外部接口,如果接口很复杂,也可以单独写接口文档
-
如何管理接口? 接口有没发生过变化?
接口作为需求和设计文档的一部分纳入基线管理;当发生变更时要走变更流程;
-
集成前是否确认过各个构件是否可用? 如何进行确认的?
集成前要确认各个模块代码调试通过并通过代码走查;
-
如何做集成的?
按集成计划中定义的集成顺序、集成步骤进行一次性集成
-
集成测试是怎么做的?
待所有组件集成后,一次性集成并测试
-
什么时候集成测试就算完成了,可以交付给测试组了?
集成编译没有错误,集成测试缺陷修改完成
-
交付给最终客户: 交付前要准备什么? 交付的方式是怎样的? 交给客户哪些东西?
1.交付前的准备
1.交付、安装、操作环境要部署好
2.评审需求、设计、产品、测试结果,确保打包交付的顺利进行
2.交付的方式
直接部署软件/产品到用户的使用环境中,由用户试运行或验收
3交付的内容
打包的可执行程序、用户手册等支持文档 -
交付给测试组: 交付前要准备什么? 交付的方式是怎样的? 交给测试组哪些东西?
1.交付前的准备
1.测试环境要部署好
2.通过代码审查并修订完成所有错误,保证整个系统能够顺畅运行
2.交付的方式
1.直接部署软件/产品到测试环境中,由测试人员试进行测试
3交付的内容
打包的可执行程序、用户需求文档、用户手册等支持文档;有时候用户手册还没产出,需要测试人员在测试的时候或测试后撰写. -
有哪些接口标准? 在哪里可以看到接口需求?
- 接口设计准则
- 在产品需求说明书、详细设计说明书
-
使用了什么标准来评估是否开发,购买或者重用产品组件?
有重用分析列表
-
编码阶段的参考文档主要有哪些? 如何确保编码的准确? 公司是否定义了编码标准?是否被遵循?
编码规范(每个项目的编码规范)
走查 ,核心代码测试
是,是 -
编码和设计是如何进行配置管理的?
svn
-
如何对技术解决方案活动进行跟踪和管理的?谁负责跟踪?有发现问题吗?怎么解决 的?
周会,状态报告,里程碑报告
-
技术解决方案实施过程出现的问题如何和高层汇报?(高层如何帮助工作)
沟通
-
你参与项目中哪些评审或测试,是怎么进行的?
项目计划、需求文档、设计文档等技术文档的评审,测试有测试过程(测试用例–用例 评审–测试–BUG修复)
测试的话就是单元测试。 -
在你的项目中,你是如何计划和执行评审或测试的?
项目计划有评审计划,还有测试计划,编码人员主要的测试就是单元测试,需要进行白 盒测试,进行源码测试。
-
测试的准入标准和推出准则是什么? 评审有相关的标准吗?
测试的准入=单元测试、(模版完成,进行测试)
-
(1)请解释4种评审类型的不同(管理评审,正式同行评审,非正式同行评审,走查) (2)有没有标准来选择评审类型? (3)每个工作产品使用什么样的评审检查单? (4)哪些工作产品是必须要开展正式同行评审?
管理评审 管理评审是对工作产品系统的评估,向上层管理者提供信息,以帮助决策判 定是否能够进入下一个阶段。
同行评审 由作者的同行(一个或几个同事)对工作产品进行系统性检查,主要是技术的完整性和适宜性。在本过程中,同行评审分为正式同行评审、走查。
正式同行评审 最系统化、最严密的评审技术,被认为是最实用、最有效的评审方法,严格定义评审流程。
走查 评审的方式比较随意,一个或几个同事对工作产品进行相互交流,尽早的解决问题。
-
在你同行评审活动中有发现的缺陷吗,针对这些发现,你做了些什么?
评审中发现的问题,记录在评审记录表中
-
如何分析评审发现的问题? 根据分析的结果采取什么措施? 有相关文件吗?在哪里能看到? 多长时间来分析同行评审准备,执行和结果数据?
当问题提交后,由于没有经过确认,称为“待定问题”。
当待定问题被确认为是非缺陷问题或缺陷后,其状态为“待修复”。
当为同行评审时,项目经理可以改变状态为 “遗留”。当为技术评审或管理评审时,项目经理可以将状态改为“遗留”。
责任人修改工作产品后,需要将状态由“待修复”改为“待验证”。
项目经理验证非缺陷问题和缺陷是否已经修改,若已经修改,则改为“已解决”,否则可以改为“待修复”。 -
bug是如何处理的?如果暂时无法关闭的,怎么处理?你是根据什么原则处理的?
BUG通过工具进行跟踪,处理原则BUG严重等级
-
对缺陷数据进行哪些分析? 根据分析的结果采取什么措施?
会对数据进行采集,进行度量分析。
-
对于验证和确认这个活动是如何计划的?这个计划存放在哪里?
项目计划和测试计划中
-
如何对验证活动进行跟踪和管理的?谁负责跟踪?
项目经理对活动进行评审,测试人员通过测试工具进行跟踪
-
集成成功的标准是什么?
1)成功地执行了集成计划中规定的所有集成活动和测试;
2)修正了所发现的错误;
3)测试结果通过了专门小组的评审。 -
出现了哪些问题与接口覆盖率和完整性有关?请描述?
接口遗漏等。
-
如何保证要集成的构件达到集成的标准?
产品的集成环境已经建立并通过验证;
待集成的组件编译及测试通过。
评审通过 -
怎样验证集成后的产品?
集成测试
-
怎样递交集成的产品?
检查各次同行评审、评审的问题和测试中的BUG追踪结果,确保发布的版本已经满足需求。
对确认的版本进行打包或者制作安装程序。
制作用于分发的软件光盘母盘,进行封样测试。或者在网络为用户提供获取安装程序或者部署组件的途径。 -
公司对于产品集成有什么样的组织方针?
集成方针:
1.重大项目必须开发多个技术方案,并进行决策
2.框架设计时首先考虑复用组织已有的模块组件
3.设计必须文档化,并进行技术评审
4.编码必须遵循编码规范
5.研发人员必须进行模块功能测试 -
对于产品集成这个活动是如何计划的?这个计划存放在哪里?
设置由集成计划,在开发域的集成测试的集成计划中
-
如何对产品集成活动进行跟踪和管理的?谁负责跟踪?
周会 状态报告 里程碑报告
-
在项目中,计划了哪些不同种类的评审和测试?
评审: ?(管理评审,正式同行评审,非正式同行评审,走查),测试:单元测试,接口测试,系统测试,验收测试
-
是否识别了评审&测试所需要的环境? 在哪里有记录?
是,位置:开发域,集成测试,测试计划
-
对于代码评审和单元测试,定义了什么准则?(有检查单吗?或者测试用例)
都有,在开发域的编码实现目下中。
-
在哪里记录了测试结果?针对缺陷,如何采取纠正措施?
在测试报告中记录了测试结果,针对缺陷首先判断是否是业务逻辑上的认知错误,其次定位出现问题的接口,最后以debug的形式针对性的对代码模块进行问题排查
-
你准备了什么支持类文档材料?
用户手册和开发手册 ,由开发人员xhf编写
-
你的项目是否记录了集成顺序在哪里?
是,记录在开发域的集成测试中的产品集成计划
-
评价集成的准则是什么?
集成的准入准则,集成测试用例,集成退出准则
-
如何确保模块已经准备好,可以集成?
产品的集成环境已经建立并通过验证;
待集成的组件编译及测试通过。
评审通过 -
谁来做集成测试? 集成中发现的问题记录在哪里?如何确保这些问题解决了?
由测试人员进行集成测试 ,问题解决后由确认人员进行二次检查
-
如何把产品提交给客户?
测试通过,打包,验证,发布(验证软硬件环境,配置系统安装环境,安装系统)
-
是否有PI的方针?在哪里定义的?
有,在组织资产库的组织方针中
-
在哪里计划了编码和集成活动?
-
在哪里识别了PI所需要的资源?
在组织资产库的产品集成过程中表述了产品集成所需要的硬件信息以及软件信息
-
作为开发,你的职责是什么?
- 负责软件项目的详细设计、编码和内部测试的组织实施
- 参与需求调研、项目可行性分析、技术可行性分析和需求分析
- 熟悉并熟练掌握交付软件部开发的软件项目的相关软件技术
-
与PI有关的输出存放在哪里?在哪个目录下,这个目录的名字是什么?
输出文件在组织资产库中的产品集成过程进行了说明,具体目录为开发域的04,05,06
-
谁是PI的相关干系人?
项目经理,设计人员,测试人员,配置管理员都负责了相关工作内容
-
如何监控PI的活动?
周会 状态报告 里程碑报告
-
PI活动接受审计了吗?你收到不符合项了吗?有几个?
接收了审计,收到了不符合项,三个
-
如何确保所定义的与产品集成有关的活动是合适的?
-
和PI有关的输出,哪些纳入组织级资产库?
Which artifacts you keep in PAL for PI activities?
英文的真正含义是 :您在组织级资产库中保存哪些工件用于PI活动?
这个回答应该是在 组织资产库\02组织标准过程\产品集成[PI]中的指南、过程、模板这 些可以用于PI过程的部分文件。
例如产品过程中的《产品集成过程》文档 产品模板中的打包清单,交接验收单什么的