禅道博客

分享专业技术知识,文章内容干货满满

《软件测试的艺术》(一)

2022-11-28 11:17:00
李洁
原创 146
摘要:本文详细分享了《软件测试的艺术》一书中关于软件测试的学习心得。
软件测试是一个过程或一系列过程,用来确认软件完成了其应该完成的功能,不执行其不该有的操作,完全的测试一个复杂的、实际运行的的程序是不可能的。 总的来说,软件测试正在变得容易,但同时也变得更难,容易之处在于:各种图形化界面的产生,工具也更多。困难之处在于,编码方式变得更多。 现阶段的软件测试中,完全测试是比较困难的,但是我们可以通过一系列方法,完成一个软件的部分测试工作。 

一、软件测试的心理学和经济学 

心理学 

测试是为发现错误而执行程序的过程 这个定义,在软件测试过程中可能是破坏性的,但是就是在破坏中找到问题,修复问题,提高软件的信心,建立用户的信任度。

经济学 

黑盒测试 

数据驱动的测试或输入/输出驱动的测试跟程序结构无关,不按照程序规范正确运行程序穷举测试较难,不能完全举出测试用例无法通过测试确保一个程序是没有错误的只能通过有限的测试投入,提高发现问题的数量。我们要想要获得高效的测试结果,最好能窥见程序的内部,对程序做些合理但非无懈可击的假设。


白盒测试 
逻辑驱动的测试对程序的逻辑结构进行检查,从中获取测试结果数据确保完全测试的方法,程序的每条语句都能至少执行一次。
缺点在于,穷举路径测试不能保证程序符合设计规范,程序可能会缺少某些路径而存在问题,穷举测试可能不会暴露数据敏感的错误。因此,要想得到更完美的测试,应该黑盒测试与白盒测试心理学和经济学相结合。

原则 
  • 测试用例中一个必需部分是对预期输出或结果的定义;
  • 程序员应当避免测试自己编写的程序;
  • 编写软件的组织不应当测试自己编写的软件;
  • 应当彻底检查每个测试的执行结果;
  • 测试用例的编写不仅应当根据有效和预料到的输入情况,而且也应当根据无效和未预料到的输入情况;
  • 检查程序是否“未做其应该做的”仅是测试的一半,测试的另一半是检查程序是否“做了其不应该的做的” ;
  • 应避免测试用例用后即弃,除非软件本身就是一个一次性的软件;
  • 计划测试工作是不应默许假定不会发现错误;
  • 程序某部分存在更多错误的可能性,与该部分已发现错误的数量成正比;
  • 软件测试是一项极富创造性,极具智力挑战的工作。

总结
测试是为了发现错误而进行的,穷举测试是不可能的,功能的输入输出应该与代码逻辑相结合测试,测试时应该仔细研究输入输出,测试完成时,仔细总结测试结果。


二、代码检查、走查与评审 

代码检查与走查 

代码检查、走查、可用性测试时三种主要的人工测试方法,代码检查和走查,都是组织3-4个人进行阅读特定的程序并找出错误,但是不用进行现场纠正。代码检查和走查通常能发现30%-70%的错误。审查完成后,需要进行检查修改后的程序。

代码检查 

组建4人代码检查小组,以每小时150行代码进行组织,时间一般在1小时左右,需要有组织协调人、作者、程序设计人员、测试专家(熟悉大部分常见的编码错误)。

 

检查过程为:作者逐条解读程序,其他人员进行提问、判断是否存在问题;参考错误列表进行检查代码是否有相应的问题;对事不对人,树立正确的态度,不可进行人身攻击;代码检查可以促使程序员可以提高自己的代码技能,其他参与者也可根据出现的错误反思自己,提升自己的代码水平。


用代码检查的错误列表 

  • 数据引用错误 
  • 数据声明错误 
  • 运算错误 
  • 比较错误 
  • 控制流错误 
  • 接口错误 
  • 输入/输出错误 
  • 代码格式检查等 

三、代码走查 

以小组为形式,进行1-2小时不间断会议,1人秘书、作者、经验丰富的程序员、专家等,会前了解相应测试用例,会中按照测试用例进行推算结果。


桌面检查:由一个人进行阅读代码,对照错误列表进行检查代码。


同行评审:依据程序整体质量、可维护性、可扩展性、易用性、清晰性,对程序进行匿名评价技术。


总结 

开发人员查看自己的代码往往发现不了太多问题,需要在代码评审或代码走查中在别人的问题中总结技巧,提高自己的能力。在代码评审过程中应当秉持公正、对事不对人、平和陈述事实的原则,不可以进行人身攻击。


四、测试用例的设计 

软件测试的一个最重要的因素是设计和生成有效的测试用例。

白盒测试 

1、逻辑覆盖测试 

  • 路径覆盖/语句覆盖:程序中的每条路径都会覆盖到,缺点是条件中的值可能是任意的,这就导致仅覆盖路径是不够的。
  • 判定覆盖/分支覆盖:每个判断都必须有一个真和假的情况,判定比语句覆盖,验证性更强。
缺点:
  • 程序中不存在判断时,有些语句可能覆盖不到;
  • 程序或子程序有多个入口时,可能会遗漏;
  • 在ON-unit单元中,遍历每个条件分支,不一定所有的,ON单元都能被执行。

2、条件覆盖 

一个判断中的每个条件的所有可能的结果至少执行一次,条件覆盖比判定覆盖的验证性更强。

缺点:每个条件的真假跟整体的真假并不会相关联,比如A&B,A真B假和A假B真看似满足了条件,实际AB都为真时,整个条件是真的没有覆盖到。


3、判定条件覆盖 

一个判断中的每个条件的所有可能结果至少执行一次,每个判断的所有可能的结果至少执行一次。
缺点:多重条件可能会成为阻碍与、或中的某些条件可能会被忽略。

4、多重条件覆盖 

该准则要求编写足够多的用例,覆盖所有的判定以及判定中的所有条件组合,所有入口都至少执行一次。
缺点:覆盖方式很多,但需要写足够的测试用例,进行完全覆盖是有困难的,所以需要测试用例评审,集合组内成员的想法,编写完善的测试用例。

黑盒测试 

1、等价类划分

每个等价类,程序需要测试每个输入,设计测试用例的方法:划分等价类->生成测试用例。

确定等价类 
有效等价类:对程序有效的输入 ;
无效等价类:对程序其它的输入(不确定的值)。
生成测试用例 
每个测试用例尽可能的包含更多的有效等价类和无效等价类,测试用例写完的标准是所有的等价类全部被用例覆盖。

2、边界值

是指输入的等价类正好处于边界、超过边界、边界以内。

3、因果图

对输入条件进行组合分析方法,因果图是使用布尔逻辑展示的表达形式。

错误猜测

利用直觉和经验猜测出错的可能类型。

测试策略 

规格说明中包含输入条件组合情况,首先使用因果图,任何情况下都应该使用边界值分析方法,可使用猜错法增加测试用例,可根据白盒测试方法中判定/条件覆盖使测试用例对需求的覆盖达到满足。可根据自己的方式方法结合书中提供的方法,进行编写合适的测试用例,不必墨守成规。


五、单元测试 

单元测试是对程序中的单个子程序、子程序或过程片进行测试的过程,测试注意力集中在构成程序的较小模块的测试上面。其中,单元测试用例设计所需信息包括,模块规格说明书、源代码,使用一种或多种白盒测试方法分析模块的逻辑结果,然后使用黑盒测试方法对照模块的规格说明书进行补充测试用例,在写测试用例过程中需要建立输入与判定输出的对应关系列表。

单元测试及集成的顺序 

增量测试 

将要测试的模块组装到测试完成的模块集合中。

自顶而下:从程序的顶部或初始模块开始,选择测试的模块,调用改模块的程序已经经过了测试。

自底而上 :开始于程序中的终端模块,测试模块后如果没有修改的最佳方案则进行拼接,直到程序所有模块拼接完成。这样能够帮助我们尽可能早的发现模块之间数据传输问题。 


非增量测试 

独立测试每个模块,测试完成后全部组装需要驱动模块或桩模块。这样做的好处在于,占用机器时间少,可以多个模块进行并行操作。但缺点在于,需要的驱动模块或桩模块较多,不能尽快发现模块之间的接口连接问题。
总结 
  • 无论选择自顶向下还是选择自底向上,都要设计合适的驱动模块和桩模块。
  • 对于执行结果与预期结果不一致的测试用例,需要进行分析测试用例问题还是程序语言问题。
  • 单元测试不局限于白盒测试,要适量使用黑盒测试来进行补充。

发表评论
评论通过审核后显示。