他想要一个完整的回归包。很好...没问题。
但是，他想要100％的覆盖率。那是我的问题。
我将使用灰盒测试。但是，我确实认为某些原则是通用的，无论... >我将使用模拟器（即iPhone X）实现自动化。我想到了这个想法。我可以在灰盒测试中使用真实的设备自动化吗？正如我希望的那样，我将获得更强大的烟熏和健康测试。创建不必要的测试来创建障碍。
当我从头开始构建这个框架时，我想知道以前是否有人在这个职位上？用它吗？
#1 楼
您的老板不希望单调“否”，或者听到他们的要求是不切实际的。他们希望减少将更改发布到应用程序的风险。
让老板选择自己的优先级，这是经理的职责之一。
根据团队知识添加方案并与老板合作进行排名
实施最高优先级方案
回到第1步
最终，您将获得递减的收益，并且可以进行下一个任务。
#2 楼
约翰·鲁伯托（John Ruberto）几年前在Stickyminds上写了一篇文章，题为“ 100％单元测试覆盖率足够吗？”。可以在这里找到该文章：https://www.stickyminds.com/article/100-percent-unit-test-coverage-not-enough
在其中他提出了一种论点，即存在不同类型的承保范围。一个可以满足100％的需求，但其中不包括测试人员在探索性测试期间可能寻找的极端情况。它不包括安全测试或UI测试。它不包括单元测试。现在，我们最多可以通过5次，即500％通过测试。我们甚至还没有涵盖配置测试将带来的大量测试。
您的老板丢了一个号码。他真正想要的是确保所建造的东西能够按照预期的方式运行。与其挂在电话上作为最低通过要求，不如告诉他根据您的经验，您以尽可能多的方式涵盖了该应用程序的全部内容，并找到了可能不应该使用的内容清单不会发生根据这些信息，您的老板或他的老板将不得不做出通过/不通过的决定。
李·科普兰（Lee Copeland）对这个问题提出了不同的看法，包括对以下问题的回答：“我何时停止测试？”在他的演讲“测试者的香蕉原理”中，可以在以下位置找到：按数字进行管理的要求是数字管理，它使上任与否决定从您的老板手中掌握。他试图通过向您提出要求来免除失败的责任。在人们犯错并从错误中学习而不是自责的商店中，这种要求不会出现。
评论
我可以说这是如何链接和汇总的一个光辉的例子吗？太棒了！
–corsiKa♦
18/12/5在23:19
#3 楼
用数字表达自己的观点总是很好的。iPhone有N种型号和子型号（对于某些应用程序，您还应该算出手机的网络子类型），每种型号都有有M个可用的iOS版本和子版本（这并不完全准确，某些型号和iOS版本无法一起使用，但现在不必担心）。
较旧的iOS版本需要不同的自动化工具。通过WiFi，3G或4G，也许还有蓝牙和USB，
您将需要在较新的iOS和iPhone版本上测试P版本
将以上内容乘以并呈现给老板
#4 楼
我花了很多时间来研究与安全相关的软件。如果软件发生故障，人们会死于某种安全。首先要注意的是，我们对要求的测试覆盖率为100％。但是，不必自动化，有时是因为它不实用，有时是因为它在物理上是不可能的。没有安全相关的标准即使对于最关键的系统也不需要100％自动化测试，因此在iPhone应用程序中进行测试的想法非常荒唐。您可能需要进行单元测试的各种覆盖范围。声明覆盖率是一个不错的开始，因为它保证至少所有代码都是可访问的，但是它并没有说明是否已对其进行正确性测试。分支机构的覆盖范围更好，但是您仍然不确定分支机构为何如此。条件覆盖范围更为全面，可以检查是否为比较指定的条件小于，等于和大于条件，但是现在您的测试正在扩展。添加组合逻辑测试以检查每个条件为真，所有条件为真和无条件为真。添加边界覆盖范围以检查最大/最小值输入和输出。依此类推。
在一个平均项目中，我们估计大约有5-10％的时间用于编码，10％的需求和20％的设计。其余正在测试。那是为了降低安全等级。对于必须进行此类单元测试的严重安全性工作，我们认为应将测试时间加倍。
我们实际上对此进行了分析，并决定在大多数情况下放弃功能级单元测试。我们发现缺陷/成本比是不合理的，并且由于较高的限制，许多错误实际上无法在系统中显示。相反，我们增加了模块级和系统级测试的数量，因为有证据表明，这是发现了大多数客户可见的错误的地方。
因此，您的老板需要决定为什么他认为这是一个好主意。他需要定义您应该瞄准的“ 100％”测量。而且他需要证明完成您的项目所需的时间增加10倍，因为这就是您现在预计的交货日期。
评论
@Wildcard我知道您来自哪里，但是我们在需求捕获方面投入了更多精力，因此它涵盖了很多东西，这些东西通常可以留给设计。当需求可以明确实现时，设计就会自然而然地消失。如果有的话，我虽然高估了编码时间。
–格雷厄姆
18/12/6在8:56
@Wildcard我刚刚阅读了您的第一个链接。这就是我们的目标。就像那里的家伙说的那样，这一切都是为了使其符合规范。
–格雷厄姆
18/12/6在9:03
格雷厄姆（Graham），我了解您想要传达的要点以及您为什么希望这样做，但是不允许使用某些语言。如果您想改写它，那很好，但是让我们保持措辞自由无礼。谢谢！
–corsiKa♦
18/12/27在20:57
#5 楼
这取决于他们认为100％，但是我的基本答案是“否”，特别是如果这些是UI级别的测试。在这个级别上的测试很慢，编写和维护起来又很昂贵。#6 楼
欢迎管理您的经理。我同意您的老板不想听到“否”的观点。这还不够详细。但是，答案几乎可以肯定地是“否”。您需要的是一种传达如何以及为什么限制测试范围的方法。即使您测试了每个制造模型，屏幕尺寸和操作系统的所有排列，您也会很快看到哦，有不同版本的OS，然后是不同的浏览器，还有那些浏览器版本。哦，哇，现在，明年，您已经找到新工作了，因为您错过了其他产品中的错误。
所以，确实，您需要基于风险的方法。了解测试变量及其对发现错误的可能性的意义至关重要。
找出客户群正在使用什么。有人应该对此进行监视或收集。而且，如果您尚未实施此功能，请从Perfect之类的公司那里获得一些咨询。 。如果您必须为测试平台中的每个移动设备配置文件编写不同的自动化工具，那么就不用管它了。使用可视上下文或确保您正在测试的站点或应用程序是可测试的，以便您实际上可以挂接到DOM。正在适当地限制您的测试范围，以便您可以查找错误，而不用购买具有无限测试范围的魔术豆。
#7 楼
我只想写一个原始问题的更新，因为它已经过去了大约7个月，而且自笔者提出问题以来，很多事情已经发生了变化。我决定采用基于风险评估的方法。当时我的经理真的不喜欢“不”一词，这似乎是最好的选择。如果我可以明确地证明某些功能不适合自动化，那么他更乐于听取该功能，而不是自动化过程中的优先事项。
这就像帮派克星一样对我有用。
帮助我影响他决定的因素是使用来自Angie Jones（Twitter的前高级自动化测试人员，现在为appitools工作）研讨会上的矩阵。使用此矩阵与同行（手动测试人员，BA和开发人员）进行讨论，它给出了整体视图并减少了猜测工作-每个人都在同一页上。
然后我可以向经理介绍结果...导致他没有用100％覆盖的耳朵疼痛来压我！
评论
除非该应用程序极其琐碎，否则它是不可能的。软件测试的七个原则之一是不可能进行详尽的测试。如果您的老板要求100％的承保范围，请提醒他们执行时间和所有相关费用都在增加。基于风险和优先级的测试将比“测试一切”的方法更有利于负载。当您说100％覆盖率时，您是在谈论项目中的所有代码路径，还是在谈论不同电话设备的100％覆盖率？
@ Alex KeySmith。我认为这是一个很好的问题。这是我最近10天注意到的。我将在模拟器而非真实设备上实现自动化。
除非您已在程序中的每条可能的CPU指令上测试了所有可能的中断，否则您没有100％的测试覆盖率。并且这假设程序没有输入。对于真实程序来说更糟。
覆盖范围就像光速一样。您可以任意接近100％（随着您与投资的距离越来越近，您的投资呈指数增长），但实际上却永远无法达到。