Questions tagged «testing»

我们有一个人（我们叫他Ted）负责测试新功能和错误修复。 我们正在使用Git和GitHub。master应该/始终可以部署，并且development是我们提交/合并新功能或错误修复的地方，但前提是经过Ted测试之后。 该项目使用PHP。 我希望测试过程如下： 开发人员想要开发新功能（例如，问题跟踪程序中Ted记录的功能/错误＃123），因此他origin/development进入development了自己的本地存储库，并issue-123从那里创建了一个新分支（比如）。 对工作感到满意后，他承诺并将其新分支推至origin。 Ted连接到test.ourproject.com/choose-branch并看到分支上的列表，origin然后选择打开issue-123（应该可以通过网页进行操作）。然后test.ourproject.com，他继续进行测试，在Web应用程序之外进行测试（他真的很无情），在与开发人员反复交流之后，他对该功能感到满意。 特德告诉他可以合并开发issue-123到development上origin。 冲洗并重复。 第三步，我可以破解一些可以完成工作的东西（显示和切换特定页面上的分支），但是我觉得我所描述的是非常普遍的模式。 所以我的问题是： 这是分支的良好/可持续/可维护的工作流程吗？您是否可以通过引用此工作流程中其他项目的一些示例来备份您的答案？

11 testing  git  integration 

与测试的持续集成对于确保始终检查“可运输”代码很有用。 但是，要保持一套全面的测试确实很困难，而且常常感觉该版本无论如何都会出错。 您必须对CI管道测试充满信心的进行多少次测试？您是否使用某种指标来确定何时有足够的测试？

10 unit-testing  testing  continuous-integration 

在工作中，我们有一个非常复杂的系统。我们将此系统称为System_A。我们的质量检查小组创建了另一个系统，称为系统_B，以测试系统_A。 System_B的使用方式如下。我们生成输入（使用System_B本身）IN，再通过System_B处理此类输入，并生成输出O_B。因此过程如下： System_B(IN) -> O_B。 然后，我们对System_A进行相同的操作以生成自己的输出O_A： System_A(IN) -> O_A。 在任何时候，都假定O_B是预期输出，而O_A是观测/实际输出。暗示O_B是“金”源（事实）。但是，我们遇到了一系列问题。 O_A是错误的，O_B是正确的 O_A是正确的，O_B是正确的 O_A错误，O_B错误 O_A是正确的，O_B是错误的 如果假定O_B永远是对的（或期望的是什么），谁来决定对的呢？好吧，事实证明，在人工检查和分析中，O_B有时（或经常）是错误的。使用此过程，一切都会通过质量检查，真正的用户会抱怨，我们回到发现O_B毕竟是错误的。 问题是这样的：创建“测试系统”以测试实际系统是否是错误的做法？ 湿滑的斜坡呢？然后，我们不能说我们需要另一个系统来测试“测试系统”吗？ 成本绝对是高得让人望而却步，因为开发人员现在需要学习至少2个代码库，而System_B的复杂性可能大于System_A。我们如何量化拥有System_B对组织有多好？ 创建System_B的最初“诱人”原因之一是“自动化”测试。现在，我们为完全自动化而感到自豪（因为System_B生成输入以引导使用其自身也生成输出的过程）。但是我认为我们以一种无法量化的方式造成了更大的伤害并引入了更多的复杂性。质量检查的工作是否完全自动化？这个理由足以证明创建并行系统吗？ 我真正担心的是，即使我们都知道System_B是错误的（经常）。如果System_B擅长处理输入并且其输出是黄金来源，为什么不用System_B替换System_A？为此，没有人能够提供满意的答复。 对此问题的任何指导表示赞赏。

10 unit-testing  testing  qa  acceptance-testing  integration-testing 

为了清楚起见，我编写的压力测试稳步增加了系统的负载，直到达到断裂点为止。从理论上讲，它是无限期运行的，但是由于系统资源是有限的，因此预计它将在某个时间点后失败。我对系统有预期的负载，但是在负载测试中对此进行了单独测试。此压力测试的目的是找出在需要实施扩展之前可以给系统施加多少负载。 我正在为系统编写压力测试，并且想知道具有通过/失败标准是否有意义。根据测试的性质，负载会稳定增加，直到达到断裂点（即失败）。我显然不知道这个突破点是什么，因此我对系统可以处理的负载没有任何期望（理论上无论如何）。 现在，我确实还有其他性能测试，可以在预期的负载等条件下测试系统，我可以轻松为其设置通过/失败标准，并且可以将这些标准用作压力测试的基础。换句话说，我可以为压力测试设置一个最低基准，但是我不确定这是否是正确的做法（这是“重复”我的其他测试吗？）。 我希望在性能测试方面有更多经验的人可以在这里为我提供帮助。压力测试时是否使用其他通过/失败标准（如果有）？

10 testing  stress-testing 

我正在测试REST API。假设它返回JSON结构。什么是测试服务器的最佳方法？如果所有先前的步骤都成功，则每个测试步骤都只能成功。 结构A：一次测试所有内容 - Test method 1: - make server request - assert http response code was 200 - assert returned file is not empty - assert returned file has valid JSON syntax - assert returned JSON contains key X 这似乎是最好的解决方案。 优点： 仅一个服务器请求 我正在整体测试行为“服务器是否使用键X返回JSON？” 结构B：向每个测试逐渐添加断言 - Test method 1: - …

10 testing  acceptance-testing 

我们有对象 public class MyObject{ protected MyObject(){} public string Property1 {get;private set;} public string Property2 {get;private set;} public string Property3 {get;private set;} public string Property4 {get;private set;} public string Property5 {get;private set;} public string Property6 {get;private set;} public string Property7 {get;private set;} public string Property8 {get;private set;} public string Property9 {get;private …

10 c#  testing  constructors  setters 

游戏的某些部分易于以自动化方式进行测试（逻辑，数学，输入处理）；但是还有很多是纯视觉的，并且不容易测试。 如果游戏行业将所有这些都留给人工测试，我会感到惊讶。里面有足够的钱，我想应该已经投入了至少对游戏的某些视觉方面进行回归测试的能力。 这是真的？如果是这样，可以测试游戏渲染的可能方式有哪些？捕获输出并比较图像（这可以可靠吗？）？从低级别拦截图形卡中的数据？正在捕获通往图形卡的顶点信息（等）？似乎有很多可能性；但我找不到关于此的任何信息:( 注意：这个问题被标记为对此的重复，但是我并不是要问具体的技术/框架/工具如何做到这一点，而是要更广泛地了解这种做法的想法以及实际的游戏行业（如果他们做的）。

10 unit-testing  testing  game-development 

我有一个很大的PHP应用程序。通常有2-3个开发人员全职从事这项工作，而现在我们正在进行更改并创建错误（咳嗽功能！）。每个人说的软件并不复杂，只是发生了很多事情（35个控制器，大约相同的型号，等等）。 即使小心，更改此视图（更改元素上的id）也很容易破坏在某些特殊条件下（单脚站立时注销）发生的ajax查询。 首先想到的是单元测试，但是我们在另一个应用程序上进行了尝试，很容易忘记它们/或花更多的时间编写测试然后进行测试。我们确实有一个临时环境，可以在上线之前检查代码。 也许我们需要兼职Q / A人员？ 任何人都有任何建议/想法。

10 testing  code-quality  tdd 

有时，我的质量检查小组会报告错误，但是我或他们都不知道如何重现错误。这导致非常长且令人沮丧的调试会话，有时甚至无法产生结果。 我的软件与专有硬件紧密相关，因此错误可能一次来自多个方向。 我应该对他们期望比“按下按钮时您的软件崩溃”还要多，还是应该自己弄清楚发生了什么？ 编辑： 我的一位同事指出，我们可能是这里的所有开发人员，因此结果可能会出现一些偏差

10 testing  bug  qa  reporting 

我看过很多研究文章和技术博客，它们夸耀了软件测试的好处。我对此深信不疑。但是，由于所有软件测试研究都是由大型软件公司进行的，因此我认为它们并不真正适用于初创公司。与大型软件公司相比，初创公司具有不同的需求和约束。 因此，这就提出了问题。科技创业公司应该编写自动化测试吗？如果是这样，它们是否以与大型软件公司相同的方式进行？（烟度测试，回归测试等）。最好是可以参考一些与此主题相关的研究文章。因为我自己找不到任何文章。 （我必须承认，即使我仍处于职业生涯的初期，但我还没有看到一家认真致力于编写自动化测试的初创公司）

10 testing  startup 

如果将新的配置选项添加到程序，则在将选项带到需要对其执行操作的位置时，它通常会产生大量涟漪效应。我知道有三种基本的处理方法： 将所有配置设置传递给程序中明确需要它们作为原语的部分。这是最明确的方式，也是最能使事物解耦的方式。缺点是这既冗长又脆弱。 将最常用的配置设置设为全局/静态。这是最简单的方法，但是会引入一定距离的操作，阻碍了可测试性，并假定该配置确实是全局的（您在任何给定时间只需要一个配置）。 创建一个包含整个程序或程序中每个主要问题的所有配置选项的配置类/结构，然后将其显式传递。它不如（1）明确，但比（2）更明确。如果只想更改一个函数调用的设置，则可以克隆config对象并更改该值。这在测试和实践中都是有用的。但是，您仍然可能最终将大量信息传递给它不需要的功能，并且更改config类/结构中的值仍会导致一定距离的操作。 您会考虑（3）模式还是反模式？如果是反模式，您该怎么办？

10 design  testing  configuration  object 

我们目前正在开发一个中型/大型PHP / MySQL项目。我们正在使用PHPUnit＆QUnit进行单元测试，并且有两个全职测试人员正在手动测试应用程序。我们的测试（模拟）数据当前是使用SQL脚本创建的。 我们在维护测试数据脚本方面遇到问题。业务逻辑非常复杂，测试数据中的一个“简单”更改通常会在应用程序中产生多个错误（不是真正的错误，只是无效数据的产物）。由于我们不断创建和更改表，因此这已成为整个团队的一大负担。 我真的看不到在脚本中维护测试数据的意义，因为可以使用UI在大约5分钟内将所有内容手动添加到应用程序中。我们的PM不同意，并说拥有无法使用测试数据进行部署的项目是一种不良做法。 我们是否应该放弃使用测试数据来维护脚本，而只是让测试人员在没有数据的情况下测试应用程序？最佳做法是什么？

10 testing  unit-testing  quality  manual-testing 

我们有一个大型的（1200多个小时）网站，其中包含很多技术债务。这主要是由以下（通常）原因引起的。 在开发过程中来来往往的多个程序员。 在开发过程中更改规格。 （在短时间内）添加了许多附加功能。 客户需要大量新功能，这基本上归结为每周进行10多个小时的项目开发。 由于技术债务，我们花费了大量时间来修复或调查问题，这些问题通常是由以下原因之一引起的： 一个无耻，愚蠢的虫子，让人哭泣。 以上是产生新功能的原因，因为我们并未预见到新功能会在所有地方产生影响。 我们面临的其他一些问题（服务器迁移，升级） 我们每天都有问题，我们试图采取以下措施来阻止这种情况： 创建有关网站导入，付款和一般工作的技术文档。 一周开始时开会-讨论当前的问题或改进以及应如何解决。 有一个测试计划。程序员A测试B，B测试C和C测试A。然后我们的项目经理将进行一些测试。关于此功能的影响，我们将其投入到临时环境中，并让客户自行检查。 问题在于问题一直在发生……而我们却无法控制它。新功能仍然会导致错误，而旧错误会一直打招呼。不知何故-也许由于项目的规模-我们似乎无法控制这个项目。 我假设有很多程序员正在从事更大的项目。这就是为什么我要问我的问题： 在大型项目中，我们应该怎么做，或者您如何避免这些问题？ 较小的修改，更多信息： 我们使用版本控制（SVN）。 我们有DTAP开发过程。

10 testing  programming-practices 

我在公司内部开发团队中，我们根据营销团队的要求开发公司的网站。在将网站发布给他们进行验收测试之前，我们被要求给他们提供一个遵循的测试计划。 但是，开发团队认为，由于需求来自请求者，因此他们将最了解测试内容，查找内容，行为方式等，因此不需要测试计划。我们一直对此争论不休，开发人员发现浪费时间来写下以下内容： 点击按钮一个。 重点在XYZ表单字段，然后单击按钮乙。 你应该看到的行为Ç。 对于每项要求/功能，我们都必须重复进行。基本上，这是对需求文档中已有内容的重新表述。 我们正朝着使用敏捷方法来管理我们的项目迈进，并且在每次迭代结束时都要求这样做。 除了单元和集成测试之外，谁应该是提出最终用户验收测试计划的人？应该是请求者还是开发者？ 提前谢谢了。 关于 CK

10 web-development  testing  websites  acceptance-testing 

我们正在使用经典的V形开发过程。然后，我们进行需求，体系结构，设计，实现，集成测试，系统测试和验收。 测试人员正在项目的第一阶段准备测试用例。问题在于，由于资源问题（*），测试阶段太长，并且通常由于时间限制而缩短（您知道项目经理...;）。开发人员正在按需进行单元测试。 所以我的问题很简单：开发人员应该参与测试阶段吗，是否不是太“危险”？恐怕这会给项目经理带来错误的质量感觉，因为工作已经完成了，但是增加的man.days是否有价值？我对开发人员进行测试并不十分有信心（这里没有冒犯之处，但我们都知道，数天之内很难完成几次点击就很难打破）。 感谢您分享您的想法。 （*）由于晦涩难懂的原因，到目前为止，增加测试人员的数量已不再是一种选择。 （只是在先，这不是重复的，程序员应该帮助测试人员设计测试吗？它讨论测试准备而不是测试执行，我们避免了开发人员的牵连）

10 testing  development-process