第13章系统实现与测试过程.ppt

六、如何提高团队编程的质量？ 在组建开发团队时，尽量多一些编程老手（至少有2年以上编程经验），少一些编程新手。由于开发工具越来越先进，现在的编程技术门槛也越来越低。有些公司为了省钱，往往低薪招聘编程新手来干活。这种做法无疑会大大降低团队的战斗力。公司支付低薪而省下来的钱，远不及开发团队修补软件质量带来的额外成本。笔者建议在实际开发时，编码人员中新手的比例不能超过50%，可以采用一对一的“传、帮、带”方式尽快提高新员工的编程能力，提高整个团队的编程质量。 如果每个开发人员的技能都是合格的，编程规范就显得比较重要。让开发人员都按照既定的规范进行编程，是提高代码质量、降低代码维护代价的简单有效的方法。 编写高质量的程序离不开责任心，这一点也是做任何工作所必须的。每个程序员都应对自己的代码进行仔细的跟踪调试，进行严格的自我测试，然后再提交给测试人员进行单元测试或集成测试。 编码中常见问题（续） 第十三章 系统实现与测试过程 CMMI中对应实践 系统实现与测试过程简述 编码流程 测试流程 缺陷管理与改错 建立产品支持文档 单元测试流程 项目经理根据开发人员开发进展情况，安排测试人员或系统分析人员（有些公司可能是开发人员）编写《单元测试管理列表》或直接使用相关测试工具来编写，具体采用什么方式，由各项目组根据实际情况在项目开发计划里确定。 项目经理审批《单元测试管理列表》，并指定测试人员进行单元测试，并记录在《单元测试管理列表》中；若使用专门的测试管理工具，则把结果记录进该工具中。 测试人员依据已审批的《单元测试管理列表》进行相应的单元测试，产生《单元测试报告》或登记进测试管理工具，然后由测试管理工具产生相关的单元测试报告。 集成测试 集成测试是单元测试的逻辑扩展，集成测试所持的主要标准是《概要设计规格说明》，执行步骤如下： 当开发进程达到《实现与测试计划》中预期集成点时，且《实现与测试计划》中“集成测试计划”中涉及的单元模块均通过单元测试，开始集成测试活动。 系统分析员及开发组长共同制定本次集成的《集成测试策略》，主要包括对本次集成范围、集成顺序、集成环境、集成方法等内容的描述，为产品集成做好准备工作。 开发组长组织开发人员及测试人员按照本项目的《集成测试策略》中集成环境的描述，建立产品集成环境，依据其中产品集成顺序和产品集成方法的描述，进行产品集成活动，同时搭建集成测试环境。 此项工作准备就绪后，开发组组长在《集成测试报告》1.基本信息表：“集成及测试环境”表项签字，说明项目已具备产品集成及可以进行集成环境确认的工作。 测试人员根据本项目的《集成测试策略》和《概要设计》编写《集成测试用例》或把集成测试用例放进测试管理工具，并进行同行评审。 开发组长组织测试人员根据《实现与测试计划》中“集成测试计划”和《集成测试用例》进行系统集成测试，将测试结果填写到《集成测试报告》或测试管理工具中。 第十三章 系统实现与测试过程 CMMI中对应实践 系统实现与测试过程简述 编码流程 测试流程 缺陷管理与改错 建立产品支持文档 缺陷管理与改错指导原则 在单元测试和集成测试过程中，测试人员发现系统中的缺陷时，必须将缺陷记录在《缺陷管理列表》或记录进BUG管理工具（一般的软件测试管理工具均带有BUG管理功能，也可采用专门的BUG管理工具）。 开发人员及时消除已经发现的缺陷，若使用BUG管理工具，则可以设置查询条件，查询由自己负责并且还未解决的缺陷。 开发人员消除缺陷之后，测试开发人员应当马上进行回归测试，确保不会引入新的缺陷。 集成测试人员在完成一次集成测试后，依据《缺陷管理列表》统计填写《缺陷管理统计报告》或由BUG管理工具对缺陷进行统计分析。 测试人员发现缺陷后，填写《缺陷管理列表》或Bug管理工具中缺陷信息项，并将其状态置为“Open”，提交项目经理。 项目经理确认缺陷内容后，将其转为相关人员解决或指派给相关人员解决。 当缺陷解决人员认为缺陷已经修复后，即可填写《缺陷管理列表》或Bug管理工具中相应款项，然后将此《缺陷管理列表》及修复后的程序提交给测试人员进行回测。 测试人员进行回测，填写《缺陷管理列表》或Bug管理工具中验证信息项 开发人员查询状态为Open和Reopen的缺陷，不是缺陷，由项目经理确认后，可置状态为Rejected。 对于不能解决和延期解决的缺陷，开发人员要提出申请，争求项目经理的同意后，才能将其状态置为“Rejected”。 缺陷管理与改错流程 找到错误的代码时，不要急于修改，先思考一下：修改此代码会不会引发其他问题？如果没有问题，可以放心修改；如果有问题，那么可能要改动程序结构，而不止于一行代码。 有些时候，软件中可能潜伏同一类型的许多错误（例如由不良的编程习惯引起的）。好不容易逮住一个，应当把同类的错误全部找到并且修改，