咸鱼的翻身技术

[翻译]Test Design ConsIDerations

又蛋疼了 仅仅看英文很容易注意力分散 就开始翻译手册了

原文地址
http://seleniumhq.org/docs/06_test_design_considerations.html

Introducing Test Design

In this subsection we describe a few types of different tests you can do with Selenium. This may not be new to you, but we provide this as a framework for relating Selenium test automation to the decisions a quality assurance professional will make when deciding what tests to perform, the priority for each of those tests, and whether to automate those tests or not.

设计测试引言

在这个子章节,我们会描述一些不同类型的selenium的测试供你使用。对你来说,可能不是什么新内容,但是我们提供了一个selenium自动化测试框架,以便质量控制专家能做出应该测试什么,每个测试的优先级,每个测试是否需要自动化的决定

What to Test

What parts of your application should you test? That depends on aspects of your project: user expectations, time allowed for the project, priorities set by the project manager and so on. Once the project boundaries are defined though, you, the tester, will certainly make many decisions on what to test.

We will define some terms here to help us categorize the types of testing typical for a web-application. These terms are by no means standard, although the concepts we present here are typical for web-application testing. We’ve created a few terms here of our own for the purposes of categorizing the types of test you may perform on your web application.

测试什么
应该测试你应用的哪部分?这个依赖于你项目如何部署:用户期待功能点,项目可用时间,项目经理设置的优先功能点等等.一但项目周期确定,作为测试者的你,就自然而然制定大量什么该测试的计划

为了帮助我们做好web应用各种典型的测试分类,我们会定义一些术语。尽管我们描述的概念是为了典型的web应用,但这些术语没有标准的手段。我们创造了一些独有术语,用于分类可能在你的web应用执行的测试

Testing for Expected Content

The simplest type of test, a content test, is a simple test for the existence of a static, non-changing, UI element. For instance


You may or may not need content tests. If your page content is not likely to be affected then it may be more efficient to test page content manually. If, however, your application will be undergoing platform changes, or files will likely be moved to different locations, content tests may prove valuable.

测试期待的内容

内容测试是一项最简单的测试,它仅仅为了测试那些静态不会改变的UI元素是否存存在,例如

每个页面是否有期望的标题?这个常用来测试点击一个超链接后是否得到一个期望的页面
应用的主页面顶部是否有一个期望的图片
每个页面的底部是否含有公司联系页面,隐私政策和商标信息的链接
每个页面的是否以H1标签作为第一个文本 ?自然,每个页面的头部是否有正确的文本?

你可以选择是否采用内容测试。如果你的页面内容不太容易受到影响,那手动测试页面内容更有效率。一旦你的应用受到底层平台变化或者文件经常移动位置的影响,内容测试就证明很有价值

Testing Links

A frequent source of errors for web-sites is broken links and missing pages behind those broken links. Testing for these involves clicking each link and verifying the expected page behind that link loads correctly.

Need to include a description of how to design this test and a simple example. Should that go in this section or in a separate section?

测试超链接

常见的大量网页错误是错误的超链接或者超链接所指向的丢失页面。测试内容主要是点击每个超链接然后测试每个超链接指向的页面是否存在

如何设计测试需要大量的描述和一个简单的例子。这个应该写在这章节还是另起一章节。[备注:翻译时该文不是最终稿]

Function Tests

These would be tests of a specific function within your application, requiring some type of user input, and returning some type of results. Often a function test will involve multiple pages with a form-based input page containing a collection of input fields, Submit and Cancel operations, and one or more response pages. User input can be via text-input fields, checkboxes, drop-down lists, or any other browser-supported input.

功能测试

在你的应用了,应该有特定功能测试,主要是要求用户不同的输入,然后返回不同的结果。通常功能测试会涉及到多个页面,如基于表单, 有大量输入框,提交和取消操作的输入页面或者不止一个的结果页面。
用户输入方式一般指通过文本输入,多选输入,下拉菜单或者其他浏览器支持的输入方式


Testing Dynamic Elements

Every web page element has an Identifier, a name that can be use to locate the element. These names can be static - for example, when you enter a search term into Google, the text field in which you type your query is always named ‘q’. These names can also be dynamic - generated fresh, new, and unique for every instance of a web page. For example, some web servers might name a text entry field ‘q1’ on the first instance of a page, and ‘q2’ on the next instance of the same page, etc. This means your test script could be looking at a different field name every time you run the script. Dynamic names are usually on a result page of some given function.

An example would be a result set of data returned to the user. Suppose each data result, in, say for example a list of documents, had a unique Identifier for each specific document. So, for a particular search, the search results page returns a data set with one set of documents and their correponding Identifiers. Then, in a different search, the search results page returns a different data set where each document in the result set uses different Identifiers.

An example will help. Dynamic content involve UI elements who Identifying properties change each time you open the page displaying them. For example,

Dynamic HTML of an object might look as:


This is HTML snippet for a check box. Its ID and name (addForm:_ID74:_ID75:0:_ID79:0:checkBox) are same and both are dynamic (they will change the next time you open the application). In this case

测试动态内容

每个网页元素都有一个可以用来定位的标识.这些标识可以是静态的,例如当你使用google搜索一个术语的时候,那个你输入查询文字的输入框的name一直是q;这些标识也可以是动态的,时刻更新,新且唯一标识网页的每个实例,例如,一些网页服务器可能以q1命名某个网页的第一个输入框,以q2命名该网页的下一个输入框等等.这个意味当每次你执行脚本时,你的脚本应该定位到不同的元素.动态的标识通常通过特定函数在一个结果页面显示.

那返回结果数据给用户做例子,假设每个数据结果都是一个文档集合,每个特定的文档都有唯一标识.因此,为了一个特定的搜索,搜索结果页应该以文档集以及相应的标识返回结果页面,那么,在另外一个搜索里,也返回了含有不同的标识的文档集合的结果页面

这有一个有用的例子,当你每次打开页面的时候,用UI元素构建的动态内容有标识的属都会更改。例如：

一个动态HTML的对象一般都这样写

这个一个checkbox的HTML片段,它的ID和NAME（addForm:_ID74:_ID75:0:_ID79:0:checkBox）都是一样的,而且也是动态的（在这个例子里,他们会你下次打开应用的时候更改）

Ajax Tests

Ajax is a technology which supports dynamic real-time UI elements such as animation and RSS feeds. In Ajax-driven web applications, data is retrieved from the application server without refreshing the page.

Ajax是一个支持像动画或者RSS订阅这样动态实时UI元素的技术。在一个以Ajax驱动的网页应用里,不需要通过刷新页面来获得应用服务器数据

Verifying Results?
校验结果


Assert vs. Verify?

断定和校验

When should you use an assert command and when should you use a verify command? This is up to you. The difference is in what you want to happen when the check fails. Do you want your test to terminate or continue and record that the check failed?

什么时候使用断定命令或者校验命令取决于你。这两个命令的不同点是当检查失败的时候你该如何处理:是终结测试还是继续并记录什么失败了

Here’s the tradeoff. If you use an assert, the test will stop at that point and not run any subsequent checks. Sometimes, perhaps often, that is what you want. If the test fails you will immediately know the test did not pass. Test engines such as TestNG and JUnit have plugins for commonly used development environments (Chap 5) which conveniently flag these tests as failed tests. The advantage: you have an immediate visual of whether the checks (those using asserts anyway) passed. The disadvantage: when a check does fail, there are other checks which were never performed, so you have no information on their status.

In contrast, verify commands will not terminate the test. If your test uses only verify commands you are guaranteed (assuming no unexpected exceptions) the test will run to completion whether the checks find defects in the AUT or not. The disavantage: you have to do more work to examine your test results. That is, you won’t get feedback from TestNG or JUnit. Rather, you will need to look at the results of a console printout or a log output by your test application. And you will need to take the time to look through this output everytime you run your test. For Java, Logging Selenium (Chap 5) is a convenient logging utility for recording the results of verify commands, however you still need to open the logs and examine the results. If you are running hundreds of tests, each with it’s own log, this will be time-consuming.



Trade-offs: assertTextPresent, assertElementPresent, assertText?

You should now be familiar with these commands, and the mechanics of using them. If not, please refer to Chapter 4 first. When constructing your tests, you will need to decide



There is no right answer. It depends on the requirements for your test. Which, of course, depend on the requirements for the application you’re testing. If in doubt, and if the requirements are not clear, you can go with your best guess and can always change the test later. Most of these are easily changed in either Sel-IDE or Sel-RC.

Realize that verify/assertText is the most specific test. This can fail if either the HTML element (tag) OR the text is not what your test is expecting. Sometimes, for instance if HTML changes frequently by your programmers, verifyTextPresent makes more sense. It can check for the content, but will pass the test when the programmers change the HTML used to present that text. Alternatively, perhaps your web-designers are frequently changing the page and you don’t want your test to fail everytime they do this because the changes themeselves are expected periodically. However, assume you still need to check that something is on the page, say a paragraph, or heading text, or an image. In this case you can use verify/assertElementPresent. It will ensure that a particular type of element exists (and if using Xpath can ensure it exists relative to other objects within the page). But you don’t care what the content is, that is, a specific image file, or specific text. You only care that some type of image exists.

Getting a feel for these types of decisions will come with time and a little experience. They are easy concepts, and easy to change in your test, but they do depend do depend on the requirements of your AUT. For some projects the requirements are clear and therefore your tests will be clear. For others, not so much, and you will have to give it your best guess. The purpose of this subsection is to help you anticipate your needs so you can make these decisions more efficiently.

posted on 2010-12-30 22:16 hopesfish 阅读(271) 评论(0)  编辑 收藏 引用 所属分类: selenium