软件测试的2个高难度问题的思考

发表于:2012-3-31 10:49

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:高翔    来源:51Testing软件测试网采编

  首先在我们回顾下这2个问题:

  问题1:如何最大限度的降低需求的变更对测试质量的影响?

  问题2:有没有什么有效的方法来降低测试用例的不断修改率?

  记得好像测试用例PK里面也提出这2个问题,而且这些问题对于测试人员在工作过程中也是比较难以解决的,同样需要不断的尝试与探索新的方法与流程来增加问题解决的可能性。其实我觉得这2个问题是有一定的共性,第一个问题解决了,第二个问题也就解决了一大半了。那我就首先谈谈个人对第一个问题的理解:

  注意看题目的几个关键词:一个是“最大限度的降低”,另一个是“需求的变更”。最后一个是“测试质量”。我们要解决好这个问题,必须要很好的理解这个几个关键词的内在含义。我想并不是所有人都能很好的理解这些术语。

  那什么叫需求的变更呢?顾名思义就是项目需求发生了变化与修改(先不谈什么原因),对应测试这边测试需求也就相应的变化。这里可不要忘了一个重要的时间点,那就是一旦PRD评审通过后。其后任何一个时间点,不管是UC设计还是测试设计或是什么,只要需求发生了变化,这都属于需求的变更。

  那什么叫测试质量呢?这个概念比较大,一般我们讲软件质量,这个就与我们测试人员的工作职责相关的。而对于测试质量,个人认为包括2大块,一个是测试各个阶段的产出的高质量,一个是测试各个阶段的控制的高效性。解释一下第一个是各个阶段的产出的文档的高质量,这里面包括文档的规范性,完整性,正确性,统一性。第二个是各个阶段的进度控制和项目管理的高效率。包括测试目标以及发现缺陷,甚至是缺陷预防的持续改进等。

  想必大家都知道需求变更不是个好东西吧,那我们就要想办法减少需求变更。首先需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更,可最后需求变更总是会出现。在需求并更发生之前尽量减少需求变更,以将需求变更带来的风险降低到最低。因此,在需求人员(PD)同用户代表或用户部门主管人员接触时,就应该向他们挑明态度,和他们协商好,特别是应该让他们清楚软件的定价应该与软件的功能相关,以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。简单说让客户明白减少需求变更的重要性后,需求分析人员应该采取合适的方法同客户交流,帮助他们明确他们的需求。

  还有一个就是我们要规范需求文档,需求文档应该按照一定的格式和规范来写,而且应该具备完整性、一致性、基线控制、历史记录等特性。需求变更发生后,也应该生成相应的文档,并且这些文档的书写也应该采用规范的形式来写。

  前面说到得是减少需求变更的方法,这个不是一个人能做到的,是整个项目组成员共同努力的。正如前面所说,需求变更不可避免的会发生,那么当需求变更发生后我们测试人员应该如何应对呢?一般来讲,需求的变更通常意味着需求的增加,需求的减少相对很少,而且处理也比较容易。而且发现现在开发人员和PM对需求变更起主导作用,同时需求的变更并不能实时反馈到测试人员。这就需要流程的监控了,之前也

  说了一旦出现什么样的需求变更,就相应的走需求变更的流程(相信这里应该充分考虑测试人员的参与度)。充分的与开发人员沟通加上SQA的实时跟踪也许会减少需求的变更对测试质量的影响。

  我们说到了对测试质量的影响,那么有哪些呢?一个测试设计与测试用例的文档的修改;一个是与开发沟通需求变更的成本;再一个是测试人员重复测试执行的成本。另外最关键的是由于需求变更带来的测试覆盖率的风险,特别是在测试执行后期阶段,时间计划都已经安排的很合理,这时由于需求变更,其影响可想而知。

  那总结下解决第一个问题的思路:

  减少需求变更

  规范需求文档

  与开发及时沟通需求问题

  需求变更流程控制执行到位

  尽量避免需求变更在测试后期阶段(成本大,风险大)

  及时采取办法应对需求变更(时间延期,覆盖率,评估需求变更)

  至于第二个问题就要搞清楚为什么测试用例需要修改,个人理解大概有这些情况:一个是上面说的由于需求变更,之前根据之前的需求写的测试用例肯定要修改;一个是由于理解需求有误导致测试用例本来就写错了,但测试用例评审没有发现问题;另一个是比较小的修改,就是一些测试用例的细节与测试执行时得到的结果描述有偏差(最常见的就是报错信息内容);最后一个是自己在测试执行时,通过探索性测试发现了bug,而且没有测试用例,这时就需要增加测试用例。等等。

  搞清楚了原因,那么我们就可以有针对性的解决测试用例的修改率问题。比如第一个就需要把控需求变更的问题;或延长测试设计的时间,增加需求理解的正确性;还有就是加强测试用例的评审力度和监控力度;多关注测试用例的细节,用例设计时要求开发给出明确的输出信息。

  这里同样的是测试用例的修改也是不可避免的,这样做的目的就是要做好测试用例的基线,更好的管理和维护测试用例,更好的回归测试日常需求。更好的加强自己以后在测试设计时思维角度的多变性。

  以上是自己对这2个问题的理解,其实这2个问题也是在测试领域比较难以量化和解决的,这些解决思路都需要不断的探索和思考,去不断的总结,加上自己Team内部管理的一些规范,共同探索出适合自己的解决办法。

《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • steven_bian
    2012-4-13 14:36:28

    废话是多了点,没有提到测试在需求阶段的前期参与,者也是很重要的一点。

  • zhifei.xie
    2012-4-13 13:28:37

    讲了那么多废话,需求变更遇到很正常!搞明白需求改动牵扯到了哪些 功能模块;重点去测试相互关联到的模块 就可以了....哪来的那么多名堂!理论一套一套可行吗?
    让整个系统的问题减少到最少 才是王道!别搞什么流程啊 CMMI、文档啊都是扯淡.....
    整天没事干似的.....

  • XZTest
    2012-4-06 18:13:35

    问题1:做好需求跟踪,见CMMI二级的“需求管理”过程域,这里主要是做好需求和用例的“关联关系”,当需求变更的时候可以精确的确定对测试的影响范围

    问题2:利用工具,如QC,将用例中的公共步骤提取为模板用例,其他地方去调用(类似函数的功能)

  • heaven7253
    2012-4-05 14:57:33

    有些情况无法避免,这些是只有决策层才能做的事,而决策层一般不会听取执行层意见,所以有时候 在测试执行层来说 我们无法避免 也没能力推动。

    分享下怎么免责并保护自己的
    就测试方面来说  先做好准备
    第一个准备: 做个质量模型 特别highlight质量与测试时间的正比图,网上有现成的质量模型 把时间那块抽离出来,highlight如果因为变更导致测试时间缩水,我们可以顺理把质量下降N%。
    第二个准备: 这个楼主也提到了 新的变更需要走change request流程,同时也吧风险都写出来。还有增加的相应的 设计case 修改case执行case的时间也加进去。

  • javaweb2006
    2012-4-01 09:26:16

    这两个属于一个问题,如果需求基本不变更,那么用例基本上改动会很小,如果需求没变而用例大面积修改,说明测试人员的水平有限,需求变更是测试无法掌控的,只能看项目经理或管理者的管理方式。项目和产品的需求变更是不一样的,如果项目的话,让客户对需求变更流程化,那需求变更就会少很多,如果产品的话,就要看产品经理和需求人员的能力和调研力度如何了。

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号