品质管理 如何保证软件质量

一江春水zcc · 2020年06月08日 · 最后由 ys-xmgg 回复于 2022年10月26日 · 7695 次阅读

用体温计量体温不能治病,它只能证明一个人生了病;同样地,对软件的测试,并不能提高软件质量,它只能证明代码中存在缺陷。

1. 软件测试危机

1.1 国内软件测试的困境

目前的软件开发环境中,最在乎软件质量的是用户、项目经理,最应该在乎软件质量的软件测试人员并不关心软件本身的质量,他们只想找 bug。

早期的软件开发过程中,软件的质量仅仅只是靠编码后的测试来验证,谁能真正提高软件的质量呢,其实是开发人员,因此那时候软件开发人员的薪水要比测试人员高很多。

后来,大多数软件开发团队意识到,只有提高整体的软件开发效率,才能激烈的竞争中占有优势。这一时期有两个明显的特征:软件测试的周期越来越短,因为在交付的压力下,不再有以前那样充足的测试时间;软件测试人员的工作贯穿整个软件开发的周期。软件开发的 W 模型很好地诠释了这一时期的软件测试工作特征,软件测试有了专门的团队,测试人员的地位相比于过去有了明显的提高。

再后来软件开发的流程演变成螺旋模型,摒弃了 W 模型的长周期,追求增量开发,随着一轮又一轮的编码和测试,软件开发处于一种不断迭代的过程中。现在流行的敏捷开发模型,本质上还是螺旋模型。

即使是螺旋模型,测试人员始终还是从事着质量控制(Quality Control)的工作,不断手段多么花哨,接口测试,自动化测试,性能测试,安全测试,各种先进的测试工具,本质上和手工点点点找 bug 并没有什么不同。在软件的开发过程中,测试人员依然是很被动,被动体现在不能主动提高软件的质量。

1.2 软件测试人员的危机

软件测试人员将会分层,有管理能力熟悉测试流程的顺利成章地成为测试过程的管理者,代码能力强的演变为测试工具的开发者(为项目定制的自动化黑盒测试工具,为项目定制的性能测试工具等等),代码能力差的就只能从事点点点的黑盒测试。

黑盒测试岗位门槛较低,可替代性强。在不远的将来,黑盒测试人员不是被测试开发人员取代,就是被测试工具开发人员开发的测试工具取代。值得一提的是:当黑盒测试被取代之后,测试过程管理者也会有失业的风险,他们必须要转型为测试架构师才能适应潮流,才不会被后浪拍死在沙滩上。

2. 解决危机

2.1 引入软件质量保证

绝大多数公司招聘测试人员,更多地是:想通过他们的测试工作,去发现软件中存在的问题,修复缺陷,从而提高软件的质量。很明显,这是一种头痛医脚的行为,提高软件的质量难道不是更应该去直接提高代码质量吗?

对于测试人员来讲,解决软件测试危机的办法就是专注于提高整个开发过程的质量,也就是说,成为软件开发项目的质量保证人员(Quality Assurance)。测试人员更多的是需要在整个软件开发的过程中,通过制定标准,监督执行,保证每一个环节的质量,从而提高整个软件开发过程的质量。这其实是一整套解决方案,当你的过程有了标准化的、成熟的解决方案之后,软件的质量一定是过硬的。

2.2 质量保证的思路

对于螺旋模型而言,最基本的单元就是:

需求分析->详细设计->编码->集成->测试->验收

那么每一个过程都应该有对应的工作过程及体现工作过程的文档,质量保障人员就可以根据以往成功的经验,制定合理的质量标准体系来指导和优化工作过程,同时也在实践中优化质量体系。

3. 如何保证软件质量

如何保证软件质量这个问题很宽泛,应该保证以下几个方面的质量,那么软件的质量将得到保证。

3.1 需求文档质量

  • 需求描述详尽:无缺漏,无歧义,无重复,没有无法实现的,没有巨大风险
  • 需求指标明确:前提条件明确,数据指标精确。

3.2 设计文档质量

  • 字段定义明确:字段没有混淆,数据来源和走向清晰
  • 逻辑清晰通畅:软件操作不会进入死胡同,用户使用场景考虑全面
  • 交互简单易懂 :每个按钮点击前是怎样,点击后会有什么变化
  • 提供丰富的辅助文档:Visio 流程图,Xmind 思维导图,Axure 交互原型设计文档等

3.3 代码质量

  • 优质的框架设计:根据项目的实际情况选择合适的技术栈,底层设计容错性高、健壮性好、可扩展性好,前端兼容性好、性能好
  • 编码规范:参考阿里巴巴的 java 编码规范制定
  • 代码走查:开发人员自己或者结对进行代码走查,考虑逻辑是否完备,数据处理是否到位,场景是否缺漏,算法性能是否最优
  • 代码评审:评价代码是否还有改进的空间等
  • 单元测试:开发人员自行编写单元测试,测试函数方法是否满足要求,随着代码版本的迭代,能否保持原来的功能

3.4 测试质量

3.4.1 测试策略

后端测试:接口测试,压力测试,部署测试,安全测试

前端测试:UI 测试,性能测试,兼容性测试,安全测试

3.4.2 测试方法的质量

  • 设计合理的测试方法
  • 测试方法的评审
  • 改进优化测试方法

3.4.3 测试用例质量

  • 良好的用例设计方法:等价类划分、因果图法、场景分析法、正交分析法、路径覆盖、逻辑覆盖、语句覆盖
  • 用例评审:保证测试的广度(界面、接口、数据库、日志)和深度(测试要点的精细程度)
  • 测试用例维护:测试过程中补全缺漏的和思路有问题的用例,记录线上故障并添加到测试用例中

3.4.4 缺陷质量

  • 缺陷分级:一般四级分类法,
  • 缺陷记录:bug 管理系统,bug 的生命周期理论
  • 缺陷反思:bug 评审,开发避免类似错误,测试在设计测试用例的时候考虑类似情景

3.5 部署质量

不是说保证了设计、开发、测试质量之后,产品上线后质量一定好。因为部署上线还有一整套流程,部署流程的质量,直接决定了产品的上线质量。
部署环境:硬件环境和软件环境,是否满足功能和性能要求
部署时机:选择对用户影响最小的时机,一般游戏更新选在午夜。
部署参数:测试环境的参数和正式环境的参数往往是不同的,往往涉及到参数的调整。
自动化部署:流程化,自动化的部署将大大减少人为失误。

3.6 风险控制

  • 项目风险:需求变动,开发环境不能满足,人员缺失,技术自身风险,安全风险
  • 风险预测:根据项目实际情况和自身的软件开发经验,找到薄弱环节和不确定的环节,这些往往都是风险高发处
  • 降低风险: 在可能发生风险的地方做好两手,甚至多手打算

3.7 组织技术学习

从长远来看,提升团队的技术水平,也能够提升软件产品的质量

4.结论

保证软件质量需要一整套的质量保证体系,搭建这样的体系是 QA 的核心竞争力。QA 人员在从业的道路上需要不断地打磨自己的业务能力、技术能力、团队合作能力,才能在激烈的市场竞争中立于不败之地。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 12 条回复 时间 点赞

写的挺好。
感觉就是测试左移的思想。但是 QA 除了对自己的交付物测试用例和测试报告可以把控外,对于需求文档、设计文档、代码质量有多大的影响力呢? QA 提出的 bug 有全生命周期的记录和管理,但是对于需求文档和设计文档的改进意见是没有这样的途径和权力

这些只能开大会讲话用的文,还是少发比较好。耽误时间

sonar 你值得拥有

写得挺全的,但感觉都做好不容易。特别是需求、设计、代码,这三块要产生影响力不容易。

期望楼主后续可以继续分享下,自己实际工作中的实践经验。

陈恒捷 回复

哈哈哈,会的😁

hai 回复

现在的测试,绝大多数是 QC,QC 是质量控制,主要工作内容是检测,QC 是没有权力对需求、设计和代码做干预的。但是 QA 可以,QA 是质量保证,QA 人员有质量控制的技术,也有质量管理的能力。要保证产品的质量,就必须要对全流程进行质量的审视,这是岗位所赋予的权利,也是 QA 人员的职责。

管昭 回复

看了一下官网,感觉不错

如果想了解如何从数据维度衡量代码质量,建议您看看https://testerhome.com/articles/24210

确实是一个代码质量管理的好东西

一江春水zcc 詹聪聪:游戏接口测试自动化实践 中提及了此贴 06月17日 14:19

进行一次测试只是做了一次代码度量,并不能影响质量;
要影响产出代码的开发人员,通过提升他们来提升代码质量;
持续进行有效的度量和反馈才能培养和监督开发人员的质量意识,最终作用在产品质量上;
记住羊毛出在羊身上。

hai 回复

我们还好,对需求文档,流程管控上的权利还是比较高的,核心思想就一个,谁能帮助团队提效率提质量就听谁的。所以执行程度还可以,效果也好很多

陈恒捷 回复

所以建立代码门禁很重要,得让开发认同这个代码门禁是有效果,可检出潜在问题的

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册