Questions tagged «testing»

在一个非常小的团队中，黑盒子和白盒子的测试是由同一个人完成的，测试人员应该首先做什么？

14 testing 

您在多大程度上对类/模块/包/等的内部/私有组件进行单元测试？您是否对它们进行了测试，还是仅测试了与外界的接口？这些内部方法的一个示例是私有方法。 例如，想象一下递归下降解析器，它具有从一个中央过程调用的几个内部过程（函数/方法）。到外部世界的唯一接口是中央过程，该过程采用字符串并返回已解析的信息。其他过程解析字符串的不同部分，可以从中央过程或其他过程中调用它们。 当然，您应该通过使用示例字符串调用外部接口并将其与手动分析的输出进行比较来测试外部接口。但是其他程序呢？您是否会分别测试它们以检查它们是否正确解析了其子字符串？ 我可以想到一些论点： 优点： 测试越多越好，这可以帮助增加代码覆盖率 通过向外部接口提供输入，某些内部组件可能很难提供特定的输入（例如，边缘情况） 更清晰的测试。如果内部组件具有（已修复的）错误，则该组件的测试用例可以清楚地表明该错误位于该特定组件中 缺点： 重构变得非常痛苦和耗时。要更改任何内容，即使外部接口的用户不受影响，也需要重写单元测试。 某些语言和测试框架不允许这样做 您对此有何看法？

14 testing  unit-testing  test-coverage 

我喜欢RoR等的“红色/绿色/重构”等。 我的日常工作涉及使用python和其他自定义工具批量处理来自第三方的超大文件。 这些文件的属性的流失率很高，因此很多修正/增强功能都经常被应用。 不存在通过具有预期结果的已知测试数据进行回归测试。最近的事情是对最后一批进行手工编码的新测试用例运行，请确保它不会爆炸，然后应用抽查和统计测试来查看数据是否仍然正常。 问>>如何将TDD原理引入这种环境？

14 testing  tdd 

我了解异常如何工作以及如何在C＃中捕获和处理异常，但是我如何模拟可能导致异常的事件以确保正确捕获异常？例如，是否可以在一种可以模拟网络问题，数据库问题等的测试平台上运行应用程序？异常的性质似乎很难重现，因此很难确保您的代码可以应对它们。 尽管我主要使用C＃/。NET / Visual Studio开发，但是与其他语言有关的答案或资源可能会很有用。

14 c#  testing  exceptions 

我正在图像处理（主要是OCR）方面工作，我想知道如何在开发中集成单元测试。 我已经在使用单元测试来处理更多“常见”类型的代码，但是在处理图像处理代码时，我不确定该如何处理。这种代码总是需要一些图像数据输入/输出，而对其进行模拟并不明显。目前，我主要进行集成测试，但是它们需要一段时间才能运行，我想了解一些有关如何将这种代码分解为单元测试的想法，以便我可以更快地运行它们。 编辑：分析角色可以经历许多步骤，包括多次旋转，缩放和形态操作。随着算法的发展，这些步骤经常改变。因此，在测试期间，输入和预期输出会发生很大变化。每个字符可以为100x100像素，因此毫无疑问地在代码中对它们进行编码或处理生成的数据。

14 testing  unit-testing  tdd  integration-tests  mocking 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 我们的代码库已经增长了20年。我们大约有10位开发者+平方英尺与500kloc合作。不久前，我们的一个小团队（2个开发人员，一个来自sqa）开始着手进行自动化测试程序。目前，一次运行需要11小时，并且某种程度上是一项集成测试。我们正在努力解决这个问题，减少误报，并在此方面取得了良好的进展。但是细节并不重要。 一切正常，我们将继续对其进行改进。我们（小团队）非常喜欢。如果我们弄坏了东西，我们会在一天后而不是两个月后注意到sqa。此外，我们的经理（开发人员+平方英尺）也很喜欢这个想法。但是团队中的其他人只是忽略了测试结果。在他们看来，如果在签入后测试失败，这是测试的问题，而不是代码更改的问题，这只是我们的玩具项目。如果失败的测试是真正的错误，我们进行了几次讨论。大多数时候是这样。 我们不能也不想强制执行某些事情。我们如何证明自动化测试是一回事？

13 testing  integration-tests 

因此，我在系统中使用了以下代码。目前，我们正在回顾性地编写单元测试（比我的观点迟来的要好得多），但是我不知道这将是可测试的吗？ public function validate($value, Constraint $constraint) { $searchEntity = EmailAlertToSearchAdapter::adapt($value); $queryBuilder = SearcherFactory::getSearchDirector($searchEntity->getKeywords()); $adapter = new SearchEntityToQueryAdapter($queryBuilder, $searchEntity); $query = $adapter->setupBuilder()->build(); $totalCount = $this->advertType->count($query); if ($totalCount >= self::MAXIMUM_MATCHING_ADS) { $this->context->addViolation( $constraint->message ); } } 从概念上讲，这应该适用于任何语言，但是我正在使用PHP。该代码只是基于一个对象构建了一个ElasticSearch查询对象，而该Search对象又是从一个EmailAlert对象构建的。这些Search和EmailAlert只是POPO。 我的问题是，我不知道怎样才能模拟出的SearcherFactory（使用静态方法），也不是SearchEntityToQueryAdapter，它需要从结果SearcherFactory::getSearchDirector 和的Search实例。如何在方法中注入从结果中构建的内容？也许有一些我不知道的设计模式？ 谢谢你的帮助！

13 design-patterns  php  unit-testing  testing 

我正在努力测试一种将文档上传到Amazon S3的方法，但是我认为这个问题适用于任何非平凡的API /外部依赖。我只提出了三种潜在的解决方案，但似乎没有一个令人满意的： 请运行代码，实际上传文档，使用AWS的API检查文档是否已上传，然后在测试结束时将其删除。这将使测试非常缓慢，每次运行测试都将花费金钱，并且永远不会返回相同的结果。 模拟S3。这是超级毛茸茸的，因为我不知道该对象的内部，并且感觉太错了，因为它太复杂了。 只要确保使用正确的参数调用MyObject.upload（），并相信我正确使用了S3对象。这使我感到困扰，因为无法确定仅从测试中就正确使用了S3 API。 我检查了亚马逊如何测试他们自己的SDK，以及它们是否在模拟一切。他们有一个200行的助手来进行模拟。我觉得这样做不可行。 我该如何解决？

13 testing  mocking 

我继承了一个基于网络的教育游戏。在过去的一年中，我一直致力于稳定代码和添加新功能。大多数逻辑都在前端，因此后端单元测试虽然很有用，但只覆盖了一小部分代码。 游戏已经到了开始变得复杂的地步。每个游戏有两种不同的模式，并且游戏的行为取决于模式。还有各种影响游戏玩法的标志。 我担任应用程序开发人员已有10多年了，这使我感到困惑。在企业界，算法始终以相同的方式起作用。我将为算法编写一个单元测试，我期望值42，如果我没有得到该值，它将出错。 说到游戏，我迷路了。我该如何测试？我有可用的测试仪。我可以花时间编写单元测试。 测试人员...不可靠。他们不是最能根除问题的人，我也没有给他们最好的方向。在每个发行周期花大量时间测试游戏的每个排列和组合时，我应该如何将它们用作资源？ 单元测试似乎很有限。由于大多数逻辑是javascript（并且我继承了意大利面条代码），因此我可以使用诸如Cucumber或selenium之类的前端套件来确保某些功能正常工作。 那是最好的策略吗？游戏公司如何测试游戏？ 我已经读过“ 复杂游戏的测试驱动开发 ”（以及网站上的其他问题）的问题，但是它没有解决我所寻找的问题。我要的是策略，而不是具体的测试示例。

13 unit-testing  testing  tdd  games 

我是一个有点防御性的程序员，并且是Microsoft代码合同的忠实拥护者。 现在我不能总是使用C＃，在大多数语言中，我唯一拥有的工具就是断言。所以我通常会得到这样的代码： class { function() { checkInvariants(); assert(/* requirement */); try { /* implementation */ } catch(...) { assert(/* exceptional ensures */); } finally { assert(/* ensures */); checkInvariants(); } } void checkInvariants() { assert(/* invariant */); } } 但是，这种范式（或您所说的任何范式）会导致很多代码混乱。 我开始怀疑这是否值得付出努力，是否已经进行了适当的单元测试？

13 testing  code-contracts 

因此，我有一段时间前编写的身份验证模块。现在，我看到了自己的错误并为此编写了单元测试。在编写单元测试时，我很难想出好名字和好地方进行测试。例如，我有类似的东西 需要Login_should_redirect_when_not_logged_in 需要登录时登录_通过_登录_登录 Login_should_work_when_given_proper_credentials 就个人而言，即使看起来“适当”，我还是觉得它有点丑陋。我也难以通过仅扫描测试来区分测试（我必须至少读取两次方法名称才能知道失败了）。 因此，我认为也许不编写纯粹测试功能的测试，而是编写一组涵盖场景的测试。 例如，这是我想出的一个测试存根： public class Authentication_Bill { public void Bill_has_no_account() { //assert username "bill" not in UserStore } public void Bill_attempts_to_post_comment_but_is_redirected_to_login() { //Calls RequiredLogin and should redirect to login page } public void Bill_creates_account() { //pretend the login page doubled as registration and he made an …

13 design-patterns  .net  testing  unit-testing  user-story 

有些错误很难重现，很少发生，而且似乎是随机的。可能会发生，我找到了可能的原因，进行了修复，测试了程序，并且无法重现该错误。但是，由于不可能可靠地重现该错误并且它很少发生，因此如何在Bugtracker中指出呢？常见的做法是什么？ 如果我将设置status为固定，并将设置solution为固定，则意味着完全固定了，不是吗？ 是否通常将“ status固定”和“ solution打开” 设置为向测试人员表明“它可能是固定的，但需要更多注意以确保”？ 编辑：大多数（如果不是全部）错误跟踪程序都具有两个用于错误状态的属性，也许名称不相同。通过status我的意思是新的，分配，固定，封闭等，并通过solution我的意思是开放的（新），固定的，无法解决的，不可重复的，重复的，而不是一个错误，等等。

13 testing  issue-tracking 

最近，我一直在努力了解什么是正确的检查量以及什么是正确的方法。 我对此有一些疑问： 检查错误（错误的输入，错误的状态等）的正确方法是什么？显式检查错误，还是使用可以从最终代码中优化的断言之类的函数，更好？我感觉像是用很多额外的代码来明确地检查程序是否杂乱，无论如何在大多数情况下都不应该执行这些代码，更不用说大多数错误都以中止/退出失败而告终。为什么将具有显式检查的功能弄乱只是为了中止？我一直在寻找断言而不是显式检查错误，却很少能真正解释什么时候做。 大多数人说“使用断言检查逻辑错误，并使用显式检查检查其他故障”。但这似乎并没有使我们走的太远。我们可以说这是可行的： Malloc returning null, check explictly API user inserting odd input for functions, use asserts 这会使我在错误检查方面变得更好吗？我还可以做些什么？我真的很想改进和编写更好的“专业”代码。

13 c  testing  assertions 

如果使用BDD进行项目并通过自动验收测试覆盖100％的用户案例，那么测试人员/质量保证人员的角色是什么？ 我想我正在想象开发人员将与产品负责人一起编写验收测试，让我知道这似乎是一个愚蠢的假设。

13 testing  team  qa  bdd  acceptance-testing 

有时我遇到这些消息中心式的API，例如Cocoa NSNotificationCenter：http : //developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter_Class/Reference/Reference.html 通常，这些API提供您在其上订阅或广播消息/事件的全局访问点。我认为这是一个问题，因为它鼓励使用扁平且非结构化的程序体系结构，其中的依赖关系在API中不是显式的，而在源代码中则是隐藏的。您不必考虑对象的所有权和层次结构，而可以使程序中的任何对象导致在任何地方调用任何代码。但这也许是一件好事吗？ 这种模式通常会鼓励程序设计的好坏，为什么呢？它会使代码更难或更容易测试吗？ 如果这个问题太模糊或太宽泛，请原谅我。我正在努力避免像这样大量使用API​​的潜在后果以及使用它的不同方式。 编辑：我猜想我最大的问题是这种API依赖于依赖关系和对象耦合，并且可以通过以下示例进行说明： myObj = new Foo(); myOtherObj = new Bar(); print myOtherObj.someValue; // prints 0 myObj.doSomething(); print myOtherObj.someValue; // prints 1, unexpectedly, because I never indicated that these objects had anything to do with each other

13 design  testing  architecture  singleton