软件测试自动化.ppt

测试的价值主要在于支撑代码改变以后仍能捕获bug的能力。如果我们一点也不了解支撑代码，无法知道测试是否能捕获bug?如何估计测试是否有助于我们捕获bug?可以认为与被测试的代码进行交互的其他代码大多数是支撑代码，支撑代码的变化也会产生自动测试所能捕获的bug。注意：高价值的测试不可能是特征驱动测试而是任务驱动测试。分析被测试代码的结构。例子：被测试的是一段处理从银行账户里提款的代码。（例子详见教材）把被测试的代码分成两部分：①功能代码（featurecode），它直接实现被测试代码所完成的功能。测试会专门对其进行调用。功能代码（supportcode）可以完成用户所进行的操作（通过使用用户界面的关联代码）。②支撑代码(supportcode)，它起到支持功能代码（supportcode）的作用。测试代码会对其进行调用，但并没有针对这些代码的特殊测试。图7-2功能代码和支撑代码示意图在这里，支撑代码位于水平线以下。功能代码位于水平线以上，共有五种不同的功能，我们只针对其中的两个功能进行测试。二、被测试代码的变化所带来的影响。主要考虑这样一些问题：1．就给定的结构而言，代码的变化将会产生什么样的影响？2．什么样的变化具有测试价值？假设一些功能代码发生了变化，如图7-3中灰色图形所示：这种变化极有可能会导致调用功能代码的测试中止。因此，如果希望使用自动化测试的方法在发生变化的功能代码（featurecode）中找到bug，就必须终止原有测试。如果测试的成本很高，这样做是很不经济的。为了使原有的测试行为仍然能够保留，通常采用的做法是更改支撑代码（supportcode）以便能够支持其他功能代码的变动。请看图7-4：图7-3图7-4010203040506支撑代码的变化对测试的影响主要从以下两方面来考虑这个问题：代码的变化有多少？这些变化会引入多少bug?7.1.5例子假设我正在测试一个产品，测试已经完成一半。产品已经实现了主要的功能，但是还需要增加一些辅助功能。现在我要对这些主要的功能进行测试。测试过程中，在同如下人员进行交流的过程中提出的问题如下：程序员：这些辅助的功能是否有可能需要改变产品的支撑代码？程序员有可能精心设计了支撑代码，并且考虑坚持使用可视化的用户界面来完善各种功能。如果是这样的话，那么自动化测试的价值就不大。但是因为要急于完成测试，程序员也可能知道程序的支撑代码的结构不会一成不变的。由于大部分工作将会重复进行，所以可能会特别需要进行自动化测试。或者程序员也不知道支撑代码是否要改变。项目经理：在新版本中，新增的功能是一个十分重要的部分吗？如果是这样的话，由于市场竞争激烈，图形用户界面有可能改变吗？以前，用户界面改动有多大？为什么会希望今后的改动越少越好？这些变化是为了增加功能，还是用来代替现有的功能？我们需要切实的估计一下变动的可能性，因为任何变化都可能会提高自动化测试的成本，缩短测试的生命周期。了解并熟悉测试工具的人员：如何应对产品的变化？什么样的变化会使测试中止？对于新增加功能的测试，遇到这些情况的几率会有多大？一次自动化测试所花费的成本相当于几次手工测试，并且要特别重视测试价值的大小和生命周期的长短，这样做可能不对。但这都是为了避免犯下灾难性的错误，如果自动化测试的成本很高而生命周期很短，我们最好使用手工测试。01020304但是这并不意味着不能使用自动化测试，而是要判断与衡量。?什么样的因素与产生的bug无关？05?代码行为的稳定性如何？在测试中，要不断跟踪bug报告并加以修改，保留所有和测试相关的文档。从这些资料当中，我们常常能够发现更为重要的信息。如：?哪里存在bug？经过一段时间，要进行自动化测试还是手工测试的想法就会逐渐成熟，可能会形成一个更大的测试套。0617.1.6另外一些需要考虑的问题2手工测试有时候会发现一些自动化测试所不能发现的问题。3尽管人善于发现问题，但很容易疲劳。并且不能对结果做出精确的分析。4由于我们不能保证每次手工输入的数据完全相同。因此，重复的手工测试多少会有些不同，那么就有可能捕获支撑代码中的bug。5要求对配置测试进行更多的自动化测试。6如果在进行第一次测试的时候就捕获了bug。表明这部分程序代码将来有可能发生变化，要进行更多的自动化测试。6.如果自动化测试的技术支持足够强大，开发人员很容易就能做回归测试，自动化测试也需要比手工测试快得多，但是并不是所有的公司都具有这样的自动化测试技术支持水平。7.使用手工测试的时