您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 其他 > 正文

看家本领之一:软件测试的系统性思维

发表于:2018-06-12 作者:朱 少民 来源:质量屋 点击数:
 

十天内,从北京到福州、再到深圳,完成了三场测试思维训练课程,从测试的基本思维到系统性思维、分析性思维(包括批判性思维)和发散性思维的训练,虽然期间还讨论了探索式测试和自动化测试。这也说明不少测试同仁渴望得到这方面训练,因为人类已经进入一个智能的时代,不会思维就可能很快被这个社会所淘汰  不仅仅是一般简单机械的劳动会被机器所代替,而且越来越复杂的工作也会被机器人所代替,未来留给人类的工作空间会越来越小,最终可能只剩下那些需要强大的思维能力才能完成的工作。

今天就和大家谈谈软件测试的系统性思维,为什么先讨论这个问题呢?因为有的同学眼睛、视力丝毫没有问题,但常常还是像“盲人摸象”一样,只看到软件测试的某个方面,甚至眼中只有测试用例和缺陷,连Test Oracle、质量模型都不了解,对用户、业务、技术和开发关系等也关注不够。要知道, test oracle是指“对测试执行结果是否通过测试的判断准则( The mechanism for determining whether a test has passed or failed ,可以参考: 软件测试的一个新公式引起的思考  )”,如果不知道test oracle,如何做测试?但有人会说,“没什么影响吧,我不是已经好好做了几年的测试?”。但又有谁知道,你的测试质量和效率怎样?缺陷命中率有多高(有多少缺陷误报)?有多少缺陷(非那种出错的功能缺陷,而是另一类缺陷,如易用性、合规性、合理性、一致性、潜在经济/健康的风险性等方面的问题)在你眼前被错过?交付的质量又如何?如果不知道产品质量模型和使用质量模型( 参考:完整诠释软件质量模型 ),如何评估一个软件产品的质量是否符合要求、是否能够上线?“幸运”的是,软件属于高科技产品,得到国家特别的“优待”,软件产品和服务可以不遵守国家标准也能上线(一般工业产品没有这种“待遇”),但如果这样下去,人类社会有一天可能会毁于自己开发的软件(希望这是杞人忧天)。

如果以系统性思维来分析和解决问题,就不会出现:

  • 只见树木不见森林
  • 片面地追求单个目标
  • 被表象所迷惑,看不到本质
  • 忽视某些产品质量风险
  • 千里之堤、溃于蚁穴
  • 用线性的思维方式来理解非线性的问题

而是会整体地、多角度地、多层次地分析问题。软件测试的系统性思维会帮助我们能够全盘掌控软件测试的目标、要素及其之间的关系。例如,当我们思考最基本的概念“什么是软件测试?” 时,就会从不同的角度去思考,正向的、反向的、狭义的、广义的……有不同的思考,就有不同的测试策略、测试方法,会决定我们是如何制定测试项的优先级、会影响我们的测试分析、设计与执行的某些活动。

  16

有了系统性的思维,对测试结构、黑盒测试方法等会重新审视,这样可以把握测试自身、测试方法的精髓。例如,对软件测试、黑盒方法,我们就会关注测试的输入、输出,还会关注被测系统( 延伸为“被测对象”)的所处环境、条件、接口等。针对输入,也不仅仅看到正常的输入数据,而且要考虑异常的数据输入、不同角色的用户操作等等。针对Test Oracle也不局限于Spec/标准等确定性的准则,还有不确定性的准则。

针对软件测试的目标、功能看,也不会仅局限于发现缺陷、验证功能特性的正确性等,会思考软件测试的其它价值,包括提供产品质量信息、完整地评估软件质量、不断地揭示软件产品的质量风险、测试能产生经济效益(投入产出分析,RoI)、增加管理者的信心等。

除了从不同维度测试软件产品,如进行不同的类型测试(功能测试、性能测试、安全性测试、兼容性测试……)和进行不同层次的测试(单元测试、集成测试、系统测试…)之外,借助系统性思维,会督促我们去全面了解做好测试的成功要素、影响我们做好测试的各种因素等,例如我之前在写《完美测试》时,构建了一个软件测试的金字塔,列举了软件测试五个要素:质量要求、人员、技术、资源、流程等。在去年绘制的软件测试思维全景图 ( 这才是世上最全的“软件测试”思维导图! ),软件测试的要素被概括为: 思想(流派)、方法、方式、技术、流程(过程)、管理等。当然,人、团队是做好测试的决定性的要素。除此之外,还要考虑项目中的范围、进度、业务领域、市场等因素的影响。

基于系统性思维,了解测试的成功要素、影响测试的各种因素等之后,还要确定它们之间的关系,能够将它们连接起来,而不是孤立地对待它们。只有了解它们之间的关系、相互影响,才能更准确地确定测试范围、采取更有效的测试方法(如组合测试),才能比较彻底地完成测试,即能从多个层次、多个维度来保证测试的充分性,这样的充分性才是客观、可靠的(这里省略了……几千字  )。

  • 业务需求决定了用户角色的需求,而这些会反映在系统功能上,或者说,功能需求是为了支撑业务需求(系统构成的依赖性);
  • 针对业务需求的验证就是传统意义上的验收测试,而系统测试是为了覆盖系统功能和非功能性需求,而集成测试、单元测试则是为了覆盖接口、代码层次等(系统构成的层次性);
  • 业务数据贯穿整个系统处理的过程,包括业务规则和流程,整个过程中如何保证数据的完整性、一致性、保密性等,确保数据和系统功能的和谐相处、有效协作(系统的交互性)。
  • 测试分析是测试设计的基础,测试设计是执行的基础。反过来,测试执行、设计分别为设计、分析提供反馈,以帮助我们优化测试的分析、设计(系统的反馈性);
  • 站在更高的层次上,能够综合运用与管理测试方式、测试方法、、测试数据等(系统的全局性、综合性);
  • ……

所以系统性的思维不仅从整体上把握被测试对象,如采用黑盒方法着重考察在不同的上下文驱动下系统的输入/输出,考察系统的不同的应用场景、不同的运行平台之下的测试;而且,经常需要对系统进行分解、分层,考虑它们的相互影响,各个击破,并考虑风险与效率的平衡,例如,如何分配UI、API、单元的测试投入,达到质量和效率的最佳收益(虽然许多团队没这么去考虑)。针对更具体的软件测试计划、分析、测试设计等工作,系统性思维显得更重要,由于时间所限,这部分具体的内容就不展开讨论,留到有偿的思维训练课程中去讨论  总之,系统性思维能力才是普适的、终身受益的一种能力,需要在日常工作中去训练。有了系统性思维能力,测试工作不仅做得又快又好,还能感受软件测试之美(系统之美)。