blocks|key|674459|text|Concordion的目标不是将测试脚本实现为HTML，而是让HTML描述您正在测试的行为(您想要达到的目标)。实现细节(如何测试)是作为Java代码实现的。然后，可以用适当的抽象级别来构造该代码，这样，对被测试系统的每一次更改都只需要对代码的一部分进行更改。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|674460|您的HTML规范只需要在业务规则更改的罕见情况下进行更改。|674461|这些概念将在Concordion主页的提示和提示选项卡上进一步描述。|offset|length|674462|entityMap|0|LINK|mutability|MUTABLE|url|http://concordion.org/Technique.html^0|0|0|J|5|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

The goal of Concordion is not to implement test scripts as HTML, but rather for the HTML to describe the behaviour that you are testing (what you are trying to achieve). The implementation details (how it is being tested) are implemented as Java code. This code can then be structured with an appropriate level of abstraction so that each change to the system under test only requires a change to one part of the code.

Your HTML specifications should only need to change on the rare occasions that the business rules change.

These concepts are described further on the <a href="http://concordion.org/Technique.html" rel="nofollow">Hints and Tips</a> tab of the Concordion home page.

blocks|key|434709|text|感谢您与我们分享您的经验。通过实例了解/阅读行为驱动开发/规范的大规模应用是很好的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|434710|一种可以帮助您的方法是专注于关键示例(http://gojko.net/2014/05/05/focus-on-key-examples)。在规范研讨会期间，整个团队致力于对新用户的需求和需求有一个共同的理解。然后继续编写包含关键示例的规范文档。在这里，你不应该试图涵盖一切，而只写尽可能多的例子，以表达共同的理解。此外，您应该尝试识别这些示例所基于的概念。是否有一些与类似主题相关的例子--这可能是一个潜在的概念。如果示例只关注一个概念(例如，验证卡号)，则通常更容易理解这些示例。每个概念通常只能用几个例子来描述。|offset|length|434711|您有其他类型的自动化测试(例如单元测试)吗？您是否遇到了与这些其他测试相同的可维护性挑战？您能使用这些其他测试类型的良好实践来改进Concordion方法吗？|434712|你能告诉我们更多关于你的设置吗？您已经在您的公司内创建了多少活动规范？|434713|entityMap|0|LINK|mutability|MUTABLE|url|http://gojko.net/2014/05/05/focus-on-key-examples^0|0|J|1D|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Thank you for sharing your experience with us. It’s great to hear / read about large scale application of behavior driven development / specification by example.

One approach that could help you is to focus on key examples (<a href="http://gojko.net/2014/05/05/focus-on-key-examples" rel="nofollow">http://gojko.net/2014/05/05/focus-on-key-examples</a>). During specification workshops the entire team is working to get a common understanding of the new user needs and requirements. Then you go on and write specification documents containing key examples. There you should not try to cover everything, but to write only as many examples as necessary to express the common understanding.
Additionally, you should try to identify concepts, on which the examples are based. Are there some examples related to a similar topic – this is probably an underlying concept. It is often easier to understand the examples, if they focus just on one concept (e.g. the validation of a card number). Each concept can be usually described with only a few examples.

Do you have any other types of automated tests (e.g. unit tests)? Are you experiencing the same maintainability challenges with these other tests? Could you use good practices from these other test types to improve your Concordion approach?

Could you tell us more about your setup? How many active specifications have you already created within your company?

I am currently working for a large organisation with about 2k developers working in our IT department. We maintain many things including our e-commerce platform and there are currently about 30 projects currently impacting that. 

Recently all of our teams have been instructed to deliver a series of automated tests using Concordion and Selenium Webdriver. For a while this has been going fairly well and many tests have been created but lately maintaining the existing tests while our e-commerce platform constantly changes has been somewhat of a nightmare. We have thousands of test scripts covering many parts of our website but there does not seem to be any facility in Concordion to split scripts into reusable compartments which could then be maintained once, rather than having to make changes to hundreds of HTML files for one change.

How are other people approaching this?

Maintaining large numbers of Concordion scripts

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我目前在一个大型机构工作，在我们的IT部门工作，大约有2k名开发人员。我们维护了许多东西，包括我们的电子商务平台，目前大约有30个项目正在影响这一点。最近，我们所有的团队都被指示使用Concordion和Selenium交付一系列自动化测试。有一段时间，这个过程进行得相当顺利，并且已经创建了许多测试，但是最近维护了现有...

问维护大量的协和脚本
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问维护大量的协和脚本EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问维护大量的协和脚本
EN