1.对教材与参考资料阅读后关于软件质量保障你的体会是什么?(40分)
我觉得对于质量保障而言,它不光是程序本身质量的问题,他还包括软件工程的质量,一个质量好的软件才能算是一个成功的软件,对于一个项目团队来说,怎么分配好个人分工,明确自己的责任,怎么努力去承担起自己的责任这些问题都是开发一个软件所必需的,而整个软件质量保障体系是由解决若干个这样那样的问题作为软件开发前提的。下面是我搜集的资料:
关于软件质量保障,有下面这个公式:
软件(质量)=程序(质量)+软件工程(质量);
软件质量保障是建立一套有计划,有系统的方法,来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。而具体的软件质量保证是怎样的呢?
1.2流程图
能体现软件详细运行的流程图能够帮助我们预测在何处可能发生何种质量问题,并且可以由此帮助开发处理它们的办法,所以预制良好的软件运行流程图,是软件质量的前提。
1.3因果分析
对于复杂的软件,控制软件质量时可以采用因果分析图。简述相关的各种原因所产生的潜在问题或影响,将影响质量问题分解分析,并在软件质量计划中制定相应的预防措施。
1.4技术控制
软件质量控制的关键点体现于在软件开发实施全过程中依据质量保证体系建设,按照软件质量的工程标准和国家标准规范规定的方法进行开发、实施及验收;在软件开发的全过程中,监理有重点、有选择地评估、度量承建单位的技术成果,跟踪承建单位的质量整改情况等。
1.5遵循代码规范
遵循编程的代码规范是程序编码所要遵循的规则,所以在软件的开发过程中需要注意代码的正确性、稳定性和可读性。
1.6软件可靠性测试
发现一些可以通过测试避免的开发风险。
实施测试来降低所发现的风险。
确定测试何时可以结束。
在开发项目的过程中将测试看作是一个标准项目。
2.如果你是一个项目的QA,那么你认为你的工作职责范围是什么?(30分)
QA:Quality Assurance,直译为质量保证。
具体工作包括以下内容:
- 测试程序是否存在BUG并写出测试报告
- 研发流程规范执行辅导(口头、电话、邮件、会议)
- 检查研发流程规范执行规范,并识别出不符合项
- 记录并跟踪不符合项问题的解决
如果小公司的话,可以考虑质量保证人员身兼多职,比如:兼过程改进人员,或配置管理或测试等。
如果我是一个项目的QA,我觉得我的工作不光包括对程序的测试、写测试文档,他还需要思考一些存在的问题,比如:
- 需求没和客户沟通好,我们的设计不能满足用户的需求;
- 需求分析不能覆盖用户需求,和用户需求不能一一对应;
- 软件模块设计不能覆盖需求,无法从模块追溯到需求;
- 软件开发技术选型、架构设计响了扩展性和可维护性,导致升级困难,修改一处代码影响全局;
- 数据库设计不能满足用户的性能需要;
- 编码质量不高,存在错误;
- 软件开发的过程中没做好配置管理,代码被反复覆盖,没有LOG,不能追溯;
- 软件界面和易用性差;
- 上游设计文档质量差,导致下游设计人员无法根据设计导出代码;
- 其他
3.项目中需要专职的QA么?还是只需有Test即可?如果一旦出现问题,你如何界定由谁担责?(30分)
我个人觉得项目中不太需要专职的QA,或者说如果有QA,那么那么所有的开发时间比上所有的测试时间应该 >20:1。更不需要只知道测试的Test,因为不懂开发的人必然做不好测试。引用一个观点,
就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得Dev应该应该是做测试最合适的人选,这必然是未来的趋势 (因为我已经看到了中国程序员的进步,相比起10年前,今天的程序员已经是非常全面了,再来十年,必然证明我的观点是对的)。证据呢?
不论是当今的Facebook,还是30年前最初的NT团队,很多伟大 的产品都是出自没有或很少测试人员的团队。开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试,全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”,那你需要更好的程序员。
开发人员最应该关注的是软件质量,需要证明自己的开发成果的质量。如果出现问题,直接追究到Dev个人代码部分的责任,因为这样在以后出现BUG的可能性最小,就算没有专职QA,那我的程序BUG可能会更少,因为QA可能不懂开发,有些问题必然会出错,相比Dev做测试更专业,更能直击程序BUG痛点,只有了解了测试的难度,才明白怎么写出可测试的软件,怎么去做测试的自动化和测试系统。
4.软件质量怎么保证?或者说一个软件保证质量最优该怎么走?
在软件开发团队中,由于质量被视为软件产品的生命,而始终被人们所高度关注;然而在现实生活中,许多软件产品却时常陷入质量低下的旋涡,总是不尽人意。究其根源,在于这些软件产品对其质量内涵的把握,仅仅停留在减少软件运行错误、加强软件测试、避免软件缺陷的一般性层面,而对整个软件开发生命周期的全过程质量管理,缺乏总体架构。因此,在大型软件产品的开发与设计中,始终体现全过程质量管理思想的Rational Unified Process™(简称RUP)和提供全生命周期支持的软件开发平台,则展现出强大的生命力和独特魅力。
4.1注重过程质量
软件开发过程质量就是指为了生成工件而对可接受流程(包括质量评测和质量标准)的实施和遵守程度。软件生产的过程质量与汽车类似,体现在三个层次:一是产品本身和用来生产、组装软件产品的零部件质量,包括用来进行软件开发或在软件开发过程中产生的代码、文档、模型和可执行系统等工件;二是软件开发活动本身对标准化软件开发过程的遵守程度,主要体现在软件开发过程的标准化、流程化、自动化程度和团队基本协作平台的效率;三是用来对整个软件产品进行验收的评测手段,它应该是被业界广泛认可和接受的方法。
4.2 RUP的质量保证思想
Rational Unified Process? (简称RUP)是一个可以通过Web来使用的软件工程过程。作为软件工业事实上的标准,它回答了我们以下问题:在整个软件开发过程中,应该由谁(角色)在什么时候(详细工作流程)做什么(活动)和产生什么样的开发结果(工件),以完成整个项目的开发目标。建立有效的工作过程,可以提高团队的生产效率,控制开发过程中的风险,保证软件开发进度并且提高软件产品质量。同时通过为所有重要的开发活动提供全面的指南、模板和示例,使整个软件开发团队能够有效共享成功经验,提高团队效率,最终保证软件开发质量。
(1)RUP的质量保证思想之一:全过程质量保证思想
- 每个角色承担相应的质量任务
- 每个活动产生合格的工件
- 为每个工件建立指南、模板和检查点
- 每个工作流程设定相应的工作指南和检查点
(2) RUP的质量保证思想之二:软件工程成功经验共同铸就软件质量的思想
- 迭代式软件开发:能够有效控制项目风险、增加对项目控制能力、减少需求变更对项目的影响,实现持续的质量验证;
- 有效管理需求:能够做到质量保证从头作起,在软件开发一开始,就把好需求质量关,实现需求的可追踪性和需求变更的有效管理;
- 基于构件和面向服务的软件架构:采用可视化建模技术来构建以构件为基础、面向服务的系统框架,可以有效地管理系统的复杂度,增强系统的灵活性和可扩展性;