软件测试流程

简介:

单元测试

  集成测试

  系统测试

  程序的常规步骤,但实际的软件生产过程中,这几步骤远远做不到,应视情况而定。

  为什么做不到?

  这与很多因素有关,如:公司的规模、性质,软件的规模、性质,软件的开发类型(有些只是demo版本),还有一个原因是由以上派生出来的原因,团队的管理制度(有没有强制去做一些友好的步骤,比如单元测试,大家都知道好,为什么都不去做呢?);

  单元测试:

  一般研发部门的领导都是要求开发人员编写单元测试代码,因为领导凭着自己的经验能够意识到单元测试的重要性,基本上每个小的功能都要编写单元测试。虽然是测试,也不一定非得在编写完代码之后编写,因为单元测试有其特殊性,在开发某个功能之前,毫无疑问,工程师已经对模块中每个小功能的实现做了详细的思考和规划,一个功能应该怎么实现,心中了如指掌,在这个前提下完全可以预先编写单元测试用例,而且编写单元测试,同时也是全面分析某个功能可能出现的任意bug的过程(这是一次很重要的分析过程,从而会在很大程度上避免一些错误,而在现实中,这种问题出现的太多了,给人的感觉是程序员只是一味地实现功能,而不去考虑功能实现的完整性、健壮性),如此,编写好的程序只要一运行,就能利马知道这段代码的好坏;另外一个好处是,单元测试能“监听”以后开发中的代码改动、模块衔接所出现的大多错误,从而最大程度的避免了新的bug,是这就是磨刀不误砍柴工吧;

  集成测试:

  以前总是以为书上说的大道理不如实际应用中的经验来的实在,走过一段路后发现,其实不然;我的总结是,当你的成长遇到瓶颈时,理论就开始起作用了,我想说的是“软件工程”里说的内聚与耦合得概念。初学时不理解他的真正含义,如今用到时才感到他的重要性。对于模块的开发者而言,就像要建造一架飞机,程序员的的工作就是生产一个飞机翅膀或者制作一个飞机轮子。假如说你制作的轮子的主要实现还是靠了机身本身的主干结构,而模块本身并没有太多的新东西,只是改改颜色,增加点花纹什么的,可以看出,这个轮不能从飞机身上摘下来,或者摘下来很费劲,并且不能使用,失去了本身的意义;它的核心再机身,而不是轮子本身,又假如你制作的轮子,整个功能的主题都在轮子上,飞机使用时,只需要挂在上去即可,如果飞机不想使用,摘下来换别的即可;这就正好类似程序模块见的内聚、耦合概念,让每个模块在不影响使用的前提下尽量的提高内聚性,降低模块之间的耦合性,这样的好处是,利于模块的重用,方便问题的定位,有利于程序整体结构的工整;(个人认为类的思想也有这样的好处,另外类的一个作用是重用,重用以减少代码量);在软件测试时,集成测试是耗时最长,重复最多的、最重要的环节;大部分bug再这个阶段被发现,我再测试过程中感受最多的就是,模块之间的耦合性处理的不好,造成了改动一个模块的功能,间接触发其他模块的功能发生错误(没有完整的程序需求和详细设计,是产生这类bug很重要的因素),而且修改时程序员总是很难意识到这类问题的发生,因此也造成了bug定位难的情况。

  这个阶段的回归测试,是个比较累人的重复流程,每次程序的改动后,为了避免造成关联模块的bug,改动完后都要进行相关的回归测试,回归的深度基本上设计所有相关模块,因此这种测试,使用自动化测试配合手动测试比较具有实际意义;

  系统测试:

  程序提交前的最后一轮测试,实际上这轮测试可以想想成工业上的“试车”,就是现场调试。涉及到了程序使用的各个方面,因为是在现场的环境中测试,因此这个阶段测试出来的bug更具有实际意义;一般来说这个环节就是在实际环境中做更复杂的集成测试的步骤,避免出现bug的因素主要是需求的准确性;这个阶段出现较多的bug一般为,网络方面的,一般都会涉及到网络后台、网络的稳定性,而这点在集成测试时往往会忽略。

  侃了会老生长谈的东西,大约每个测试人员都不怎么陌生这三个环节,也作了一些规避这些bug产生的研究,避免一些低级bug的产生。然而,现实让人泪奔;

  为什么要这样说?(网友)

  1、是公司重效益,轻测试

  2、程序规模小,不需要系统测试

  3、程序员基本没有养成做单元测试的习惯

  4、团队管理没有强硬的原则

  5、有些程序根本没有需求规格说明书,何谈,需求分析

  一般的外包程序,都是简单测试一下,连提交bug的必要都没有,一边测试一边改正(到底这样的程序是否需要做bug管理,我自己也不知道),没有需求规格说明书,没有需求分析;我在想对于开发周期比较小的程序如果做完整的开发测试流程,是否会在时间上得不偿失,因为小程序bug还是相对部较少的。任何流程规则的制定,看来要以现实为依据才是最好的,没必要可以的遵守固有的原则,好用万岁!大型程序,还是需要做完整流程的;

  以什么为标准来决定是否需要做bug管理呢?(待答)

  成本与质量之间的一个权衡








====================================分割线================================



最新内容请见作者的GitHub页:http://qaseven.github.io/

目录
相关文章
|
1月前
|
弹性计算 监控 测试技术
弹性计算的测试流程
弹性计算的测试流程
18 0
|
2月前
|
安全 测试技术 持续交付
接口自动化测试的基本流程
接口自动化测试的基本流程
|
3月前
|
存储 测试技术 持续交付
自动化测试与持续集成/持续交付(CI/CD):优化软件开发流程的利器
自动化测试与持续集成/持续交付(CI/CD)是现代软件开发中至关重要的环节,通过将自动化测试与持续集成/持续交付相结合,可以实现开发流程的高效优化,提高软件质量和交付速度。本文将探讨自动化测试与CI/CD的概念、原理及其在软件开发中的重要性,以及如何实施这些技术以提升团队的协作效率和软件交付质量。
55 1
|
4月前
|
Ubuntu 测试技术 Linux
dpdk测试环境搭建(vmware下ubuntu环境参考上文汇总流程)
dpdk测试环境搭建(vmware下ubuntu环境参考上文汇总流程)
97 0
|
4月前
|
关系型数据库 MySQL Java
SSM整合流程(整合配置、功能模块开发、接口测试)
SSM整合流程(整合配置、功能模块开发、接口测试)
67 0
|
6月前
|
iOS开发
完整版在xcode打测试专用ipa包流程​
完整版在xcode打测试专用ipa包流程​
|
12天前
|
监控 网络协议 安全
【软件测试】—软件测试的基本流程、 网络协议应该怎么测(一)
【软件测试】—软件测试的基本流程、 网络协议应该怎么测(一)
|
2月前
|
测试技术
有了测试标准流程后缺陷就不会遗漏到线上吗?
有了测试标准流程后缺陷就不会遗漏到线上吗?
|
2月前
|
测试技术 BI
性能基准测试基本流程
性能基准测试基本流程
|
2月前
|
敏捷开发 测试技术 持续交付
面试题1: 测试常见工作流程
面试题1: 测试常见工作流程