您正在针对 Chrome 进行测试吗?

发布于 2024-09-03 04:39:39 字数 94 浏览 7 评论 0原文

我很好奇谁在针对 Chrome 进行测试。

我主要是因为它已经成为我的主要浏览器,所以所有的开发都在Chrome上进行,然后我用IE和Firefox进行测试。

I'm curious to know who is testing against Chrome.

I am mainly because it has become my primary browser, so all development is taking place on Chrome, then i test with IE and Firefox.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

多像笑话 2024-09-10 04:39:39

您的浏览器使用统计数据是什么?你必须从那里开始。每个应用程序的用户群都不同。根据这些统计数据对浏览器进行排名,并按顺序进行测试/错误修复。在大多数情况下,这将为您带来最好的时间/金钱回报。

如何跟踪浏览器使用统计数据?分析您的网络服务器日志或使用 Google Analytics。

例如,我知道一个拥有 5000 个用户的 B2B Web 应用程序,其比例如下:

  • 90% IE(6,7 或 8)
  • 8% Firefox
  • 2% Chrome
  • Safari 等可以忽略不计

所以他们应该:

  • 完成全功能测试IE
  • 仅测试核心功能和一般 CSS 与 Firefox 的兼容性,
  • 忽略其他浏览器

如果它们具有自动化测试(即 Selenium)怎么办?那么测试所有浏览器就很简单了。但您仍然可以将我的逻辑应用于特定于浏览器的错误修复。这无法自动化。企业必须对修复的错误进行分类。

当然,这个答案是主观的。也许 2% 的 chrome 用户是付费最高的用户。我不知道。考虑您的浏览器使用统计数据、最重要的用户以及可用的开发/质量检查资源。

What are your browser-usage stats? You must start there. Every app's userbase is different. Rank the browsers based on those stats, and test/bug-fix in that order. That will, in most cases, give you the best bang for your time/money.

How can you track browser usage stats? Analyze your web server's logs or use Google Analytics.

For example, I know a B2B web app with 5000 users that have these ratios:

  • 90% IE (6,7,or 8)
  • 8% Firefox
  • 2% Chrome
  • Safari, etc are negligible

So they should:

  • do complete full-featured tests with IE
  • test only core features and general CSS compatibility with Firefox
  • disregard other browsers

What if they have automated testing (i.e. Selenium)? Then testing all browsers is trivial. But you could still apply my logic to browser-specific bug-fixing. That cannot be automated. And the business will have to triage what bugs get fixed.

Certainly, this answer is subjective. Perhaps the 2%-chrome users are the highest paying users. I don't know. Consider your browser usage stats, your most important users, and the dev/QA resources available.

音盲 2024-09-10 04:39:39

我首先在 chrome 上测试,其次是 FF,最后是 IE...

调试 JS 时我使用 Firefox Firebug...

Chrome 使用类似于 Safari 的 Webkit 渲染引擎。因此,如果您的网站在 Chrome 上看起来很糟糕,那么它在 Safari 上也可能看起来很糟糕......

I test on chrome first, FF second and IE last...

When debugging JS I use Firefox Firebug...

Chrome is using the Webkit rendering engine similar to Safari. So, if your site looks bad on Chrome, it'll probably look bad on Safari...

浅浅 2024-09-10 04:39:39

我在 IE、FF、Chrome 和 Opera(偶尔还有 Safari)上进行测试。这些天你真的必须这样做。为了调试 Javascript,我倾向于使用 Chrome 作为其控制台,有时使用 FF 中的 Firebug - 它们都非常有帮助。

I test on IE, FF, Chrome and Opera (and occasionally Safari). You really have to these days. For debugging Javascript I tend to use Chrome for its console, and sometimes Firebug in FF - they're both very helpful.

半﹌身腐败 2024-09-10 04:39:39

对于公共网站:是的。

企业内部网站:依然“不支持”(IE被逼,FF被偷偷进来)

Chrome的市场份额每天都在增加。如果您希望大约 10% 的用户错过,请不要进行测试。这是一个成本,也许为 Chrome 用户代理添加“不支持”消息是可以接受的。

最好的办法是查看您网站的网络统计数据,看看 Chrome 用户的百分比是多少。监控您的用户群并查看他们是否已适应 Chrome。请记住,您正在为您的用户构建网站。

http://www.w3schools.com/browsers/browsers_stats.asp

For public websites: yes.

Internal Corporate sites: it's still "un-supported" (IE is forced, FF is sneaked in)

Chrome's market share is increasing every day. If you want about 10% of your users to miss out, feel free not to test. It's a cost and maybe it's acceptable to put "unsupported" message for chrome user agents.

You best bet would be to look at your web stats for your site and see what the percentage of chrome users is. Monitor your user base and see if they have adapted chrome. Remeber you are building your site for your users.

http://www.w3schools.com/browsers/browsers_stats.asp

五里雾 2024-09-10 04:39:39

由于我正在开发 Google Maps API 网站,因此我测试了它们支持的内容:Chrome、IE 和 Firefox。我倾向于首先检查 Chrome,因为它是我的默认浏览器。

Since I'm working on a Google Maps API site I test for what they support: Chrome, IE, and Firefox. I tend to check Chrome first as it's my default browser.

软糖 2024-09-10 04:39:39

答案应该是肯定的。

谷歌足够大,不容错过,和苹果一样,几乎和微软一样重要。

我在这里唯一想说的是记住它的渲染引擎是一种 webkit(不太确定细微的差异),所以不要让 mozilla(-moz-) 不处理:)

而且,我觉得最喜欢 Firebug 控制台。您可以向其中添加一些非常有用的面板,例如:

就个人而言,我测试我的 Web 应用程序(从最重要到最不重要):

  1. Firefox 3 +(其实版本并不重要,Firefox 总是好的);
  2. Safari 4(适用于 iMac 用户、我的 iPhone、我的 iPad,以确保我的网络应用程序正常运行);
  3. IE8(我讨厌MS,但我不能忽视它的浏览器);
  4. Chrome(它通常像 Safari 一样工作,但为了确保这一点很好);
  5. Opera
  6. IE7(如果我真的有时间的话...)

    ......

Max.Integer IE6 (原因大家都知道......)

The answer should be a definitely yes.

Google is big enough not to be missed, same as Apple, almost as important as Microsoft.

Only thing I'd like to say here is bear in mind its rendering engine is sort of webkit(not too sure about the subtle differences), so just don't leave mozilla(-moz-) unhandled :)

And also, I feel like the Firebug console the most. You can add some quite useful panels to it, such like:

Personally, I test my web application against (from most important to least):

  1. Firefox 3+ (version is not that important actually, Firefox is always good);
  2. Safari 4 (For the iMac people, my iPhone, my-iPad, to make sure my web app works);
  3. IE8 (I hate MS, but I cannot ignore its Browser);
  4. Chrome (It usually works like Safari, but it's good just to make sure);
  5. Opera
  6. IE7 (If I really really have the time...)

    ......

Max.Integer IE6 (For the reasons everybody knows already...)

反话 2024-09-10 04:39:39

我首先在 Google Chrome 上进行测试,然后是 IE,最后是 Firefox...
因为有时我们会遇到一些主要来自 IE 和 Chrome 的问题。所以有必要在这些浏览器中测试完整的应用程序流程和 UI。

Google Chrome 还提供了一些很好的扩展,例如 IE 选项卡、iMacros、Firebug、Flashbug 等。

I test on Google Chrome first, then IE and in last Firefox...
Because sometime we are getting some issues mainly from IE and Chrome.. So it's necessary to test complete application flow and UI in these Browsers.

and Google chrome also provides some good Extensions like, IE tab, iMacros, Firebug, Flashbug etc etc..

鹿! 2024-09-10 04:39:39

我们的测试是针对 IE 和 Firefox 进行的。我们的产品被大型银行和电信公司使用,因此我们不必担心在其他浏览器中的使用。

我发现使用 Firefox 测试运行速度快了 50% 以上,主要原因是 IE 不能很好地处理 Xpath。为了解决这个问题,我使用了大量的 Jquery 和 selenium 命令 WaitForCondition。我建议这样做,因为它确实提供了更多的灵活性。例如,为了模拟 waitForElementPresent (这在带有 Thread.sleep 的循环中使用 isElementPresent ),我只使用单个 selenium 语句 WaitForCondition(My Jquery Statement, waituration),所以如果我正在等待控件加载 btn_login 我会使用以下

WaitForCondition("selenium.browserbot.getCurrentWindow().$('#btn_login'),"10000") !=null),这会等待 10 秒。

我正在考虑写一篇 selenium 博客,因为我的工作量很大大家觉得做的好像挺高级的。

Our testing is carried out against IE and Firefox. Our product is used by large banks and telecoms companies so we dont have to worry about usage in other browsers.

I have found using firefox the test run 50% + quicker and the main reason for this is IE does not process Xpath's very well. To work around this I use alot of Jquery and the selenium command WaitForCondition. I would recommend doing this as it does provides alot more flexability. For example to emulate the waitForElementPresent (this uses isElementPresent in a loop with a Thread.sleep) i just use a single selenium statement WaitForCondition(My Jquery Statement, wait duration), so if i was waiting for a control to load of btn_login i would use the following

WaitForCondition("selenium.browserbot.getCurrentWindow().$('#btn_login'),"10000") !=null), this waits 10 seconds.

Im thinking of writting a selenium blog as alot of the work i am doing seems to be quite advanced. What does everyone think.

一城柳絮吹成雪 2024-09-10 04:39:39

Firebug 在编写测试的 Jquery 元素方面非常出色。你需要小心,因为一些 selenium 命令在 IE 和 Firefox 中的行为有所不同(keyUp、KeyDown),我确信还有更多的命令:)。

我发现实际上使用 Jquery 来处理大多数事情要好得多。我可以输入文本并触发事件。按 Enter 键真的很痛苦。我必须检查我正在运行的环境,然后运行 ​​2 个命令中的 1 个。我可以只使用 $( 控件的 id).trigger( 你想要运行的事件 ) 即 (onblur、click、keyup 等)。

另外,使用 Jquery 意味着它也兼容跨浏览器(yippieee),甚至在 IE6 中也是如此。

Firebug is brillant when it comes to writting the Jquery elements of the test. You need to be careful mind you as some of the selenium commands act differently in IE and Firefox (keyUp, KeyDown) Im sure there are alot more than this :).

I have found actually using Jquery for most things is a lot better. I can input the text and fire off an event. Pressing the Enter key was a real pain in the b**. I had to check which environment i was running and then run 1 of the 2 commands. I can just use $(the id of the control).trigger(event you want to run) ie (onblur,click,keyup etc).

Also using Jquery means it is cross browser compliant as well (yippieee) and even in IE6.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文