Questions tagged «acceptance-testing»

根据Wikipedia的说法，验收测试是为了确定是否满足规范或合同要求而进行的测试。

7
自动化的单元测试，集成测试或验收测试
目前，TDD和单元测试似乎很受欢迎。但是，与其他形式的自动化测试相比，它真的有用吗？ 凭直觉，我猜想自动化集成测试比单元测试有用。以我的经验，大多数错误似乎都在于模块之间的交互，而不是每个单元的实际（通常是有限的）逻辑。此外，由于模块之间的接口发生更改（以及更改的前后条件），经常发生回归。 我是在误解什么，还是与集成测试相比，单元测试为什么会引起更多关注？仅仅是因为假设您已经拥有集成测试，而单元测试又是我们需要学习以开发人员身份应用的下一件事？ 还是与自动化的复杂性相比，单元测试仅能带来最高的收益？ 您在自动化的单元测试，自动化的集成测试和自动化的验收测试中有什么经验，而在您的经验中，哪些产生了最高的投资回报率？为什么？ 如果您只需要选择一种测试形式就可以在下一个项目中实现自动化，那会是什么？ 提前致谢。
5
端到端测试与单元测试之间，应该将测试解耦吗？
在我们公司，我们通常会确保为我们的网站/ Web应用程序编写一个端到端测试。这意味着我们访问一个URL，填写一个表单，将该表单提交到另一个URL并检查页面结果。我们这样做是为了测试表单验证，测试HTML模板是否具有正确的上下文变量等。 我们还使用它间接测试基础逻辑。 一位同事告诉我，这样做的原因是，只要端到端测试通过，我们就可以随时淘汰和更改基础实现。 我想知道这种解耦是否有意义，或者这仅仅是避免编写针对较小代码单元的测试的方法？
7
在将团队转换为TDD以实现全面覆盖之后，编写所有可能的测试用例是一个好主意吗？
假设我们有一个大型企业级应用程序，而没有任何单元/功能测试。由于非常紧迫的期限，因此在开发过程中没有测试驱动的开发过程（我知道我们永远不能在不确定的情况下承诺任何紧迫的期限，但是已经完成了！） 既然所有的截止日期都过去了，事情变得平静了，每个人都同意将我们转变成一个富有成效的基于TDD / BDD的团队...是的！ 现在的问题是关于我们已经拥有的代码：（1）停止大多数开发并从头开始编写所有可能的测试用例还是可以的，尽管一切都可以很好地进行（尽管！）。 ？或（2）最好等待一些不好的事情发生，然后在修复过程中编写新的单元测试，或者（3）甚至忘记以前的代码，而只为新代码编写单元测试，并将所有内容推迟到下一个主要重构中。 有几个好的，如相关的文章这一个。考虑到我们的时间非常有限，还有许多其他项目/作品正在等待我们，我仍然不确定是否值得为此进行投资。 注意：这个问题正在解释/想象开发团队中一个完全尴尬的情况。这与我或我的任何同事无关；这只是一个假想的情况。您可能会认为这种情况永远都不会发生，否则开发经理会造成这种混乱！但是无论如何，已经完成了。如果可能的话，请不要仅仅因为您认为这永远不会发生而投票。
2
软件测试技术或类别
很难说出这里的要求。这个问题是模棱两可，含糊，不完整，过于宽泛或夸张的，不能以目前的形式合理地回答。如需帮助澄清此问题以便可以重新打开， 请访问帮助中心。 8年前关闭。 您知道哪种软件测试？我听说过测试驱动开发，单元测试等，但是不了解它们的重要性和差异。例如，为什么我们要使用回归测试或验收测试。他们提供什么优势？
4
如何进行测试驱动开发
我在应用程序开发方面只有2年以上的经验。在那两年中，我对发展的态度如下 分析需求 身份核心组件/对象，必需功能，行为，过程及其约束 创建类，它们之间的关系，对象行为和状态的约束 根据要求创建功能，处理行为约束 手动测试应用 如果需求更改修改组件/功能，则手动测试应用程序 最近，我对TDD进行了介绍，并认为这是进行开发的好方法，因为已开发的代码有充分的理由存在，并且可以缓解许多后期部署问题。 但是我的问题是我不能先创建测试，而是要标识组件，并在实际编写组件之前为它们编写测试。我的问题是 我做对了吗？如果不是，我到底要改变什么 有什么方法可以确定您编写的测试是否足够？ 是针对非常简单的功能（相当于1 + 1 = 2）编写测试的好习惯吗？ 更改功能并相应地测试需求是否有所变化是否很好？
4
编写验收测试用例
我们正在将测试过程集成到SCRUM过程中。我的新角色是编写我们的Web应用程序的验收测试，以便稍后使它们自动化。我已经阅读了很多有关如何编写测试用例的文章，但是没有一个给我实用的建议来编写用于复杂Web应用程序的测试用例，相反，它们引发了我发现难以应用的矛盾原则： 测试用例应该简短：以CMS为例。简短的测试用例易于维护，并且易于识别输入和输出。但是，如果我想测试一系列的操作（例如，添加文档，向另一个用户发送通知，其他用户答复，文档更改状态，用户收到通知），该怎么办？在我看来，测试用例应该代表完整的场景。但是我可以看到这将如何产生明显复杂的测试文档。 测试应该标识输入和输出：如果我的表单很长，包含许多相互作用的字段，并且行为不同，该怎么办。我要为所有内容编写一份测试，还是为每项编写一份？ 测试用例应该是独立的：但是如果测试上传操作要求连接操作成功，我该如何应用呢？它如何适用于编写测试用例？我应该为每个操作编写一个测试，但每个测试都声明其依赖关系，还是应该为每个测试重写整个场景？ 测试用例应轻松记录在案：此原则特定于敏捷项目。那么，您对如何实施这一原则有何建议？ 尽管我认为编写验收测试用例会很简单，但我发现自己对要做的每一个决定都不知所措（仅供参考：我是开发人员，而不是专业的测试人员）。所以我的主要问题是：为了编写适用于复杂应用程序的可维护验收测试用例，您有什么步骤或建议。谢谢。 编辑：澄清我的问题：我知道验收测试应该从需求开始，并将整个应用程序视为一个黑匣子。我的问题与编写测试文档，确定测试用例，处理测试之间的依赖关系的实际步骤有关...对于复杂的Web应用程序
3
您将如何测试Google Maps的“获取路线”功能？
（我想这将是一个很好的面试问题，但就我而言，这比这更为实际。） 我们有一个庞大而复杂的应用程序，可以对数十种化学成分之间极其漫长而复杂的化学反应过程进行建模。我们正处于为应用程序设计验收测试的阶段，但是对于可能的测试路径数量之多，我们有些畏缩。在我看来，我们的情况非常类似于Google Maps开发团队在其“获取路线”功能中测试路线规划算法时必须面对的情况。显然，他们无法测试（验证和验证）所有可能的路线。那么，他们如何使自己的应用程序在任何情况下都能运行的信心？ 而且由于我不希望知道他们是如何做到的，所以让我问您：您将如何设计一个具有足够代码覆盖率的测试套件，以使自己确信给定的应用程序是健壮的，而这在实际上是不可能的探索整个系统的每条潜在路径？ 我正在寻找的原则是您可以用来将棘手的问题分解成较小的，易处理的部分，这些部分的总和提供了令人满意的整体估计：“我无法测试所有内容，但我可以对此进行测试，这个和这个-就足够了。” 考虑到实际的预算/时间限制，我并不是在寻找一种“证明是正确的”方法，而是一种审慎的方法。 （我将Google Maps示例用作箔纸，以寻求尽可能具体的答案。）
3
是否有软件工程原理将生产系统上的重用和回归测试成本联系起来？
我曾为一家负责退休金和投资银行的大型金融交易系统工作。经过15年的功能更改，手动回归测试成本已攀升至每个版本20万美元。（1000万本金，每天交易1000万美元）。该系统还与公司周围的其他19个系统对接，可移动大量数据。该系统是用Java实现的。 但是，我们观察到的是，我们做的“重用”越多，回归测试的成本就越高。（原因是您需要“测试您触摸过的代码”-并且重用/共享的代码在触摸时会影响多个地方。因此尽管“干-不要重复自己”-即不要复制和粘贴代码-我们注意到复制和粘贴代码的经济动机。这是为了降低回归测试的成本，因为我们不想修改可以共享的代码，因为这会带来很大的回归测试影响。 我的问题是，是否存在描述重复使用和回归测试成本之间关系的软件工程原理？ 我问这个问题的原因是，将系统分解成要测试的较小部分可以说具有成本优势。 假设： “回归测试”指的是“验收测试”，即另一个小组花时间代表企业针对系统编写新的测试和重用旧的测试，包括环境和数据设置。 我知道对大型回归测试成本的下意识反应是“更多自动化测试”。这是一个好原则。在这种环境下，存在两个挑战。 （a）自动化测试在系统边界上的用处不大，除非该系统也具有很高的自动化测试覆盖率。（势力范围挑战）。 （b）从文化上讲，当您的系统已经很大且很复杂时，很难在程序员的时间上获得动力，或者在高度自动化的测试覆盖率上进行资本投资。 （c）维护自动化测试的成本隐藏在项目中，因此很容易在项目级别将其丢弃。 （d）这只是在银行工作的文化现实。 （e）我正在以不同的方式（分解）解决此问题。
2
在进行游戏开发时，软件测试是否有所不同？
我在阅读本文对一般和游戏开发软件开发之间的差异，作者提出了一些好点的关于软件测试，并指出，例如，该 ...游戏开发人员不愿使用自动化测试，因为面对游戏设计师不断变化的创意需求，这些测试迅速过时。 因此，这种阅读使我想到，当我们处理/测试游戏时，在软件测试中还有哪些其他方面应该与众不同或特别？有人对此有经验吗，或有人听到过有关此事的其他信息？
3
为另一个质量保证（QA）创建完全重复的系统是否是不良做法？
在工作中，我们有一个非常复杂的系统。我们将此系统称为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？为此，没有人能够提供满意的答复。 对此问题的任何指导表示赞赏。
4
每个步骤都有单独的测试方法是一个好主意吗？
我正在测试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: - …
6
改变了客户的世界-我们该如何处理？
不久前，我们的任务是进入一个项目，并使用SQL Server作为后端，用新的Intranet ASP.NET解决方案替换客户的旧Mainframe系统。部分原因还在于业务的重新设计-本质上，随着我们更换系统，我们正在考虑如何更好地开展业务。 因此，第一个任务是进入并执行逻辑和物理数据模型。客户参与了这些讨论，并已完成签收。下一阶段是实际进行每个模块的设计和构建。好了，总而言之，编程已经完成，我们现在正在对该系统进行并行测试。到目前为止，对于大多数模块来说，一切都进行得很顺利-除了一个。 我们拥有一个系统-如果您仅让业务用户查看应用程序和报告，一切都会很好。它与新的集成工作流程一起使用，可以自动执行以前的手动流程，并且可以按规格执行。并行测试发现了与迁移的旧数据有关的一些问题。遗留系统的构建者很难理解新的架构和业务流程，因此，他们很难理解如何获取遗留数据并将其放入新的架构。因此，他们召集业务用户和利益相关者开会，并告诉他们新系统没有提供旧系统所做的数据（实际上确实如此），这确实使新系统看起来很糟。 至少可以这样说，这令人沮丧。新系统运行良好，可提供他们需要和想要的一切，如果不是由于IT员工无法用旧数据填写新表，则业务用户将对新特性感到满意。 我正在寻求有关如何处理此问题的建议。由于采取了一些政治措施，新的“架构师”对系统的工作原理一无所知，并且无法完全理解IT员工要求的变更的后果。IT员工希望对系统进行一些根本性的更改，这些根本上不必要的更改实际上是一个糟糕的设计-但他们是客户。 有什么想法吗？
7
谁应该编写测试计划？
我在公司内部开发团队中，我们根据营销团队的要求开发公司的网站。在将网站发布给他们进行验收测试之前，我们被要求给他们提供一个遵循的测试计划。 但是，开发团队认为，由于需求来自请求者，因此他们将最了解测试内容，查找内容，行为方式等，因此不需要测试计划。我们一直对此争论不休，开发人员发现浪费时间来写下以下内容： 点击按钮一个。 重点在XYZ表单字段，然后单击按钮乙。 你应该看到的行为Ç。 对于每项要求/功能，我们都必须重复进行。基本上，这是对需求文档中已有内容的重新表述。 我们正朝着使用敏捷方法来管理我们的项目迈进，并且在每次迭代结束时都要求这样做。 除了单元和集成测试之外，谁应该是提出最终用户验收测试计划的人？应该是请求者还是开发者？ 提前谢谢了。 关于 CK
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.