我已经制定了一些测试计划,使用该方法可以节省多达50%的工作。但是现在我的老板和其他同事要求我提供证明,证明这些成对的测试用例足以确保我们的软件运行良好。我已经告诉过他们,从详尽的测试到成对组合时,总有机会找不到一些错误,因为您没有测试所有3(或n)方式的组合。因此,我无法证明我的测试用例会发现所有错误(或至少与穷举测试一样多)。充其量我可以说是出于软件编程方面的考虑,成对方法比穷举测试更容易发现“大多数”错误。测试请随时回答。
#1 楼
很抱歉,冗长的答案。在过去的八年左右的时间里,我已经对这个确切的问题进行了深入的研究,对这个主题充满热情,并对此进行了深入思考,并希望您能从中找到与自己的情况相关的一些经验。 >要进行全面披露,我应该指出,我已经创建了一个名为Hexawise的测试设计工具,因此存在利益冲突。话虽如此,这是我的经验。我。背景
大约8年前,我在一家大型系统集成公司工作,被要求帮助该公司将其测试产品与其他公司提供的测试服务区分开。当时是软件测试,但碰巧的是,我父亲是实验设计领域的领先专家。实验设计是一个在许多领域都具有适用性的领域(包括农业,广告,制造业等)。实验设计的目的是为人们提供工具和方法,以帮助他们在尽可能少的时间内学习尽可能多的可操作信息
我用Google搜索了“实验软件测试设计”。搜寻使我找到了Madhav Phadke博士(碰巧是我父亲的前学生)。距今已有20多年的历史了,ATT Bell实验室的Phadke博士及其同事问了您现在要问的问题。他们使用成对测试设计/正交阵列测试设计进行了实验,以识别ATT的StarMail系统的测试子集。该测试工作的结果非常成功,并且有据可查。
在那之后不久,在该系统集成公司工作时,我开始提倡任何人和每个人都应该听到,设计测试方法的设计方法承诺既(a)更彻底,又(b)要求(在大多数但不是全部)案例)的测试次数明显减少。来自17个直接项目的结果证实了这两个说法都是正确的。
II。可重复的步骤来确定此方法是否会提高效率和彻底的改进(和/或证明业务案例/投资回报率计算)
我们如何证明这种测试设计方法可以带来更彻底的测试和更高效的测试?我们遵循以下步骤:
采用一组现有的30-100个已经创建,检查并批准用于测试(但尚未执行)的现有测试。
现有测试中包含的测试思路,设计一套成对测试(通常是原始测试数量的一半左右)。将测试放在一起时,如果利益相关者认为有特定的,已知的,高优先级场景对于测试很重要,则重要的是要确保您“强制”成对测试生成器包括这样的高优先级场景。 br />让两个不同的测试人员同时执行两组测试(例如,在开发人员开始修复由执行任一组测试的测试人员发现的任何缺陷之前)
记录以下内容:
执行每组测试需要多长时间?
每组测试识别出多少个唯一缺陷?
创建和记录每组测试需要多长时间?*
*这第三次测量通常是估计值,因为大量团队没有跟踪创建原始测试集所花费的时间。
在我的旧公司中进行的17个成对测试“烘烤”项目的结果包括:
在测试执行过程中,每个测试者小时发现的缺陷:使用成对测试时,每个测试者小时发现的缺陷多于两倍。尽管事实上在几乎每种情况下,每组原始测试中都有明显更多的测试)
成对测试发现的缺陷却被传统测试遗漏了:很多(我忘记了确切的数字)
传统测试发现的缺陷,而成对测试则遗漏了这些缺陷:零
选择和记录测试的时间量:使用成对测试生成器时所需的时间要少得多(如前所述以上,很难在这里收集精确的测量值)
更多的最新项目收益包括:
500家公司开始尝试采用更智能的测试设计方法来实现这些目标的好处,但一直在努力寻找易于使用且可以集成到其他工具中的测试设计工具,这促使我决定创建Hexawise。
III。根据我的经验学到的其他建议和经验>我从“成对测试在理论上是一个不错的方法,但不适用于我们的情况”变为“成对在理论上是好的,并且可能适用于我们的情况”,最后变成“成对在我们的情况下适用!”。
我已经制定了一些测试计划,使用该方法可以节省多达50%的工作。但是现在我的老板和其他同事要求我提供证明,证明这些成对的测试用例足以确保我们的软件运行良好。
我的建议有三点:
首先,请欣赏您自己的思维方式是如何演变的,并了解其他人将需要遵循类似的旅程(并且其他人将没有那么多的时间投入到您必须亲身经历的学习中)。当我创建Hexawise时,实验设计专家George Box拥有数十年的经验,向持怀疑态度的高管解释了实验设计如何为组织的效率和有效性带来变革性改进,他告诉我:“贾斯汀,您将经历三个阶段接受和接受的发生将比您期望的发生的过程更为缓慢:首先,人们会告诉您“这是行不通的”。接下来,他们会说“这在这里行不通。”最终,他笑着说,他们会告诉您“当然可以,我首先想到了!”您自己的出发点是假设“理论上不错,但不适用于我所做的事情。”当人们听到您可以使用新方法将测试执行效率提高一倍时,他们最初不会相信您。他们会对此表示怀疑。您正在向大多数人解释这种方法的人会从您所做的事情开始。人们需要一些时间和经验来理解和欣赏其巨大的好处。
其次,在逐个案例研究之后,人们会本能地拒绝成对测试案例研究,这些案例研究表明,这种方法对几乎所有类型的行业以及所有类型和阶段的测试人员的有效性。乔治·博克斯(George Box)预测人们将经常以“在这里行不通”的方式回应时是对的。有时候当人们担任这个职位时,很难不笑。恰当的例子:我将很快与一家大型资本市场公司的高级管理人员讨论我们的工具如何帮助他们改变测试团队的效率和效力。我可以将它们介绍给我们的客户,该客户在他们最重要的IT项目中的每个项目中都广泛使用我们的测试设计工具。那位高管会接受我的提议吗?我希望是这样,但是根据过去的经验,我怀疑他会反驳说“是的,是的,是的,可以肯定的是,如果公司是人,那家公司将是我们公司的同卵双胞胎,但... “不能在这里工作。”
最后,我发现要解决可理解的怀疑论并确保组织级的支持和承诺,最有效的方法是通过收集有关多个方面的无可争辩的证据预测该方法通过烘焙方法对公司本身有效(例如,遵循上面概述的四个步骤。尽管如此,但还是要提几句建议。
我建议的方法不是为了淡淡的如果您在一家采用既定方法的大公司工作,您将需要耐心和坚持。
即使在收集到证据表明这种方法在业务部门A,业务部门B和业务部门C中都有效之后, D将不会对您收集到的令人信服且无可辩驳的证据感到信服,告诉你'在这里行不通。业务部门D是唯一的。 “测试类型” A,B和C的结果可能会引起相同的异议。
尽管此测试设计方法功能强大且广泛应用,但请始终记住(并与利益相关者保持清楚),这不是神奇的灵丹妙药。 James Bach使用这种方法提出了一些有效的限制。尤其是,除非您的测试人员具有较强的分析能力来驱动测试设计过程,否则这种方法将行不通。由于成对的测试用例生成工具依赖于周到的测试设计人员来确定适当的测试输入以进行变化,因此这种方法(像所有测试设计方法一样)要承受“垃圾进/垃圾出”的风险。
项目负责人会抗拒“重复努力。”但是,除非您进行实际的审核,否则利益相关者将不会欣赏他们现有流程的破裂。在标准测试中不可避免地隐藏着比人们意识到的浪费更多的重复。当您开始报告多个项目的测试人员生产率提高一倍时,精明的经理会注意到并希望参与其中。到那时-希望-您的毅力应该得到回报。
我的经验是,为了使怀疑论者真正相信其收益,通常需要他们使用一种能够产生明确证据的评估方法,在他们熟悉的应用程序中亲眼目睹所评估的收益。这就是为什么我强烈建议采用烘焙方法。如果利益相关者拒绝采取行动,我将继续鼓励他们采取行动,因为这样做的好处很可能是(a)巨大而(b)明确的。如果您的敦促最终失败了,您可以问一个很简单的问题,它成为问题的核心:在遗漏的最后20个缺陷中,通过成对测试可以找到多少个缺陷?具体来说,如果一个缺陷只能由3个或更多特定的输入共同触发,则出于过于保守的目的,您可以假定,即使再次保守,也不会被成对测试所捕获假设是由于这里说明的原因。如果一个缺陷可能是由两个经过测试的特定输入共同触发的,则有一个强有力的论点是,该缺陷将在您的成对测试中被发现。提供者认为测试人员会认为这两个测试输入都包含在您的测试计划中。 (这是与user246建议的方法类似的分析,但略有不同;该方法侧重于成对测试集创建的彻底性的提高。我反复看到的证据表明,成对测试不仅是AS透彻的,而且是更长的测试集。
一些有益的数据和案例研究可能对您有用:
成对测试确实有效吗?证据,数据和案例研究
组合软件测试
利用实验设计降低IT系统测试成本
IV。如果您无法更改公司,请考虑更改公司
最后,请记住,无论您当前的公司是否重视您的新技能。并且要知道,尽管您尽了最大的努力和最大的意图,您的努力可能不会说服怀疑者。有些人不可避免地不愿意花时间去理解。如果您发现自己想使用这种测试设计方法(因为您知道这些方法功能强大,实用且广泛应用),但是您没有管理层的支持,那么请考虑是否最好让您当前的雇主加入一家公司,让您使用新技能。
例如,我们的大多数客户都在积极寻找具有完善的成对和组合测试设计的软件测试设计师。技能。而且,他们甚至愿意为能够设计出功能强大的测试集的高度分析性测试设计师支付高薪。 (我们在LinkedIn Hexawise Guru小组中公开了此类职位空缺,供在该工具的自定进度的基于计算机的培训模块中达到“ Guru”级别状态的测试人员使用。)
在相关说明中,您可能会发现有关“选择测试数据的系统方法”的sqa.stackexchange问题。
评论
难以置信的,无价的建议和实践经验!为此会给+100。
– Peter L.
13年11月23日在10:21
#2 楼
当组合问题如此之大以至于无法进行详尽的测试时,例如,对详尽的测试要比成对的测试贵几个数量级。听起来好像不是您的情况。或者,您可以同时兼顾以下两点:
寻找使测试速度甚至快50%的方法是值得的仍然会找到大多数(或全部)错误。
第一点不是普遍的真理,但我相信通常是真的。
如果第二点需要帮助,则可以尝试以下实验。创建成对的测试计划,将其写下来,然后放在抽屉中。现在运行您详尽的测试计划,或者您的老板和同事可以同意的任何测试策略。每次发现错误时,记录所有相关变量的值,即成对测试计划中出现的所有变量的值。测试结束后,将成对的计划从抽屉中拉出,并检查您会发现哪些错误。
您可能需要在多个测试工作中重复进行该实验,因为您会感到信服结果。
您似乎对结对很感兴趣(就像我第一次学习它时一样)。这是关于实验过程要记住的一件事。每个成对的测试计划也包括一些三向组合-并非每个三向组合都包括在内。如果发现错误需要成对的测试计划无法涵盖的三向组合,则您可能会尝试生成一个涵盖它的其他成对的测试计划。抵制这种冲动;这是作弊,会损害您的结果。
评论
感谢您的答复。我喜欢您建议的专家,所以我要求开发人员操纵一些软件代码,以获取有关成对检测到的错误的一些信息。这可能需要一些时间,所以请稍等,以免发布结果。
– Robert.Sie
13年11月25日在6:52
评论
他们否决了您建议的测试方法,因为还没有发现所有可能的错误? bewilderedLook>他们要求“证明这些成对的测试用例足以确保我们的软件运行良好”。您为什么担心“发现所有错误”和“比进行详尽的测试省力”?这些都不能回答所要提出的问题。