Selenium自动化测试用例设计注意事项
●UI元素映射
●元素验证
●等待加载
●日志记录
●结果收集
Selenium自动化测试用例设计注意事项（一）
自动化测试设计简介
我们在本章提供的信息，对自动化测试领域的新人和经验丰富的老手都是有用的。本篇中描述最常见的自动化测试类型，还描述了可以增强您的自动化测试套件可维护性和扩展性的“设计模式”。还没有使用这些技术的、有经验的自动化测试工程师会对这些技术更加感兴趣。
测试类型
您应该测试应用程序中的哪些部分？这取决于您的项目的各种影响因素：用户的期望，时间期限，项目经理设置的优先事项等等。但是，一旦项目边界定义完成，作为测试工程师，你必须做出要测试什么的决定。
为了对Web应用的测试类型进行分类，我们在这里创建了一些术语。这些术语并不意味着标准，但是这些概念对web应用测试来说非常典型。
● 测试静态内容
静态内容测试是最简单的测试，用于验证静态的、不变化的UI元素的存在性。例如：
→ 每个页面都有其预期的页面标题？这可以用来验证链接指向一个预期的页面。
→ 应用程序的主页包含一个应该在页面顶部的图片吗？
→ 网站的每一个页面是否都包含一个页脚区域来显示公司的联系方式，隐私政策，以及商标信息？
→ 每一页的标题文本都使用的
您可能需要或也可能不需要对页面内容进行自动化测试。如果您的网页内容是不易受到影响手工对内容进行测试就足够了。如果，例如您的应用文件的位置被移动，内容测试就非常有价值。
● 测试链接
Web站点的一个常见错误为的失效的链接或链接指向无效页。链接测试涉及点各个链接和验证预期的页面是否存在。如果静态链接不经常更改，手动测试就足够。但是，如果你的网页设计师经常改变链接，或者文件不时被重定向，链接测试应该实现自动化。
●功能测试
在您的应用程序中，需要测试应用的特定功能，需要一些类型的用户输入，并返回某种类型的结果。通常一个功能测试将涉及多个页面，一个基于表单的输入页面，其中包含若干输入字段、提交“和”取消“操作，以及一个或多个响应页面。用户输入可以通过文本输入域，复选框，下拉列表，或任何其他的浏览器所支持的输入。
功能测试通常是需要自动化测试的最复杂的测试类型，但也通常是最重要的。典型的测试是登录，注册网站账户，用户帐户操作，帐户设置变化，复杂的数据检索操作等等。功能测试通常对应着您的应用程序的描述应用特性或设计的使用场景。
● 测试动态元素
通常一个网页元素都有一个唯一的标识符，用于唯一地定位该网页中的元素。通常情况下，唯一标识符用HTML标记的?id?属性或?name?属性来实现。这些标识符可以是一个静态的，即不变的、字符串常量。它们也可以是动态生产值，在每个页面实例上都是变化的。例如，有些Web服务器可能在一个页面实例上命名所显示的文件为doc3861，并在其他页面实力上显示为doc6148，这取决于用户在检索的…文档?。验
证文件是否存在的测试脚本，可能无法找到不变的识别码来定位该文件。通常情况下，具有变化的标识符的动态元素存在于基于用户操作的结果页面上，然而，显然这取决于Web应用程序。
下面是一个例子。
这是一个HTML标记的复选框，
其ID (addForm:_ID74:_ID75:0:_ID79:0:checkBox) 是一个动态生成的值。这个页面下次被打开时，复选框的ID将可能是一个不同的值。
● Ajax的测试
Ajax是一种支持动态改变用户界面元素的技术。页面元素可以动态更改，但不需要浏览器重新载入页面，如动画，RSS源，其他实时数据更新等等。Ajax有不计其数的更新网页上的元素的方法。但是了解AJAX的最简单的方式，可以这样想，在Ajax驱动的应用程序中，数据可以从应用服务器检索，然后显示在页面上，而不需重新加载整个页面。只有一小部分的页面，或者只有元素本身被重新加载。
验证结果
● 断言assert与验证verify
什么时候使用断言命令，什么时候使用验证命令？这取决于你。差别在于在检查失败时，你想让测试程序做什么。你想让测试终止，还是想继续而只简单地记录检查失败？
这需要权衡。如果您使用的断言，测试将在检查失败时停止，并不运行任何后续的检查。有时候，也许是经常的，这是你想要的。如果测试失败，你会立刻知道测试没有通过。TestNG和JUnit等测试引擎提供在开发测试脚本时常用的插件，可以方便地标记那些测试为失败的测试。优点：你可以直截了当地看到检查是否通过。缺点：当检查失败，后续的检查不会被执行，无法收集那些检查的结果状态。
相比之下，验证命令将不会终止测试。如果您的测试只使用验证，可以得到保证是—假设没有意外的异常—测试会被执行完毕，而不管是否发现缺陷。缺点：你必须做更多的工作，以检查您的测试结果。也就是说，你不会从TestNG和JUnit得到反馈。您将需要在打印输出控制台或日志文件中查看结果。每次运行测试，你都需要花时间去查看结果输出。如果您运行的是数以百计的测试，每个都有它自己的日志，这将耗费时间。及时得到反馈会更合适，因此断言通常比验证更常使用。
● 权衡：assertTextPresent，assertElementPresent和assertText
您现在应该熟悉这些命令及使用它们的机制。如果没有，请参阅相关章节。在构建你的测试时，你需要决定
→ 只检查在页面上的文本吗？（verify/ assertTextPresent）
→ 只检查是否在页面上存在HTML元素吗？即文本，图像，或其他没被检查的内容，只要和HTML标记相关。（verify/ assertElementPresent）
→ 需要同时检查元素和它的文本内容？（verify/ assertText）
没有正确的答案。这取决于您的测试要求。如有疑问，请使用assertText，因为这是最严格的类型检查点。您可以随后更改它，但至少你不会遗漏任何潜在的故障。
Verify/ assertText是最特殊的测试类型。HTML元素（标签）或文本的不符合都会导致测试失败。也许你的网页设计师经常改变页面面，而你不希望在他们改变页面时，你的测试失败，因为这是期望中的周期性变更。但是，假如你仍然需要检查的页面上的东西，如段落、标题文本或图像。在这种情况下，您可以使用verify/ assertElementPresent。这将确保一个特定类型的元素存在（如果使用XPath，可以确保它相对页面内其他对象的存在）。但你不关心的内容是什么，你只关心某个特定的元素，比方说，一个图片在一个特定的位置。
随着时间的推移和经验的积累，如何决定使用还是非常简单的。
定位元素的策略
● 选择一个定位策略
有多种方式选择页面上的对象。但面对这些定位类型，如何权衡呢？回想一下，我们定位一个对象的方式：
→ 元素的ID
→ 元素的name属性
→ XPath语句
→ 通过一个链接的文本
→ 文档对象模型（DOM）
使用元素的ID或name定位符，在测试执行方面来说，是最有效的方式。也让你的测试代码更具可读性，如果在页面源代码中的ID或name属性被友好命名的话。XPath语句需要更长的时间来处理，因为浏览器必须运行它的XPath处理器。在Internet Explorer 7，XPath出了名的慢。
使用链接的文本进行定位是很方便的，并运行起来也不错。这种技术只适用于链接。另外，如果链接文本很可能会经常改变，使用标签定位元素将是更好的选择。
不过，有时你必须使用XPath定位。如果一个页面元素没有一个ID或者name属性，除了XPath定位没得选择。（DOM定位器不再普遍使用，因为，XPath可以做得更好。DOM定位器只简单地为遗留测试而存在）。
相对使用ID或name属性定位，使用XPath进行定位有一个独特的优势。使用XPath（DOM）中，你可以找到页面上相对于其他对象的一个对象。例如，如果有一个链接必须存在
● 定位动态元素
正如前面测试类型部分所述，动态元素的页面标识在不同的页面实例上市不同的。例如，
View Archived Allocation Events
这个HTML锚标记定义了一个ID属性为“adminHomeForm”按钮。和大部分HTML标签相比，这是一个相当复杂的锚标记，但它仍然是一个静态标签。每次页面被浏览器加载时，HTML将保持不变。它的ID在所有的页面实例里保持不变，也就是说，页面被展示时，这个UI元素总是有同样的标识符。所以，点击此按钮的测试脚本（Selenium Server）如下所示：
selenium.click("adminHomeForm");
然而，你的应用程序，可能生成动态的HTML标识符。在不同的网页实例中，标识符发生改变。例如，一个动态的页面的HTML元素可能会是这个样子：
这是一个复选框，id和name属性都是addForm:_ID74:_ID75:0:_ID79:0:checkBox。在这种情况下，使用标准的定位，测试脚本应该是这样子的：
selenium.click("addForm:_ID74:_ID75:0:_ID79:0:checkBox");
对于动态生成的标识符，这种做法行不通。下一次页面加载时，标识符将是一个不同的值，执行上述脚本会遇到“element not found”错误。
要更正该问题，一个简单的解决办法是使用XPath定位替代ID定位器。因此，对于该复选框，可以简单地使用
selenium.click("//input");
或者，如果它不是在页面上的第一个文本输入域，尝试一个更详细的XPath语句。
selenium.click("//input[3]");
或
selenium.click("//div/p[2]/input[3]");
但是，如果你确实需要使用ID来定位元素，可以换一种不同的解决方案。您可以先捕捉到网站的这个ID，然后再使用它，例如：
String[] checkboxids = selenium.getAllFields(); // Collect all input IDs on page.
for(String checkboxid:checkboxids) {
if(checkboxid.contains("addForm")) {
selenium.click(expectedText);
}
}
如果页面上只有一个复选框的ID文本为“expectedText”时，这种方法工作。
● 定位Ajax元素
定位、验证AJAX元素的最好的方式是使用Selenium 2.0 webdriver的API，它专门解决Selenium 1.0测试AJAX元素的一些限制。
在Selenim 2.0中，可以使用waitfor（）方法来等待一个页面元素变得可用。该参数是一个WebDriver 用来实现定位的By对象。这是WebDriver的章节中详细解释。
在Selenium 1.0（Selenium-RC的）中，要做到这一点需要编写更多的编码，但它并不难。首先检查元素，如果它存在，等待预定义的时间段，然后再重新检查。这在循环内执行，如果超过一个预定的超时，元素不存在则终止循环。
让我们考虑页面上实现AJAX效果的一个链接（链接= ajaxLink），可以使用循环处理：
// Loop initialization.
for (int second = 0;; second++) {
// If loop is reached 60 seconds then break the loop.
if (second >= 60) break;
// Search for element "link=ajaxLink" and if available then break loop.
try { if (selenium.isElementPresent("link=ajaxLink")) break; } catch (Exception e) {}
// Pause for 1 second.
Thread.sleep(1000);
}
这当然不是唯一的解决办法。Ajax是一个共同的话题，在用户论坛上，查找一下之前的讨论，看看别人是如何做的。
封装Selenium调用
与任何编程一样，你需要使用工具函数来处理在测试代码中重复的函数。避免重复的方法之一是封装常用的Selenium方法的调用。例如，测试时经常点击页面上的元素，等待页面加载。
selenium.click(elementLocator);
selenium.waitForPageToLoad(waitPeriod);
为了不重复上述代码，你可以写一个包装方法实现这两个功能。
/**
* Clicks and Waits for page to load.
*
* param elementLocator
* param waitPeriod
*/
public void clickAndWait(String elementLocator, String waitPeriod) {
selenium.click(elementLocator);
selenium.waitForPageToLoad(waitPeriod);
}
● 判断元素存在的“安全操作”
另一种常见的封装Selenium的方法，在执行进一步操作前检查页面上的元素存在性。这有时被称为“安全操作”。例如，下面的方法可用于实现一个依赖期望的元素存在的安全操作。
/**
* Selenum-RC -- Clicks on element only if it is available on page.
*
* param elementLocator
*/
public void safeClick(String elementLocator) {
if(selenium.isElementPresent(elementLocator)) {
selenium.click(elementLocator);
} else {
// Using the TestNG API for logging
Reporter.log("Element: " +elementLocator+ ", is not available on page - "
+selenium.getLocation());
}
}
上述例子使用的是Selenium 1.0 API，Selenium 2.0同样支持安全操作。
/**
* Selenium-WebDriver -- Clicks on element only if it is available on page.
*
* param elementLocator
*/
public void safeClick(String elementLocator) {
WebElement webElement = getDriver().findElement(By.XXXX(elementLocator));
if(webElement != null) {
selenium.click(elementLocator);
} else {
// Using the TestNG API for logging
Reporter.log("Element: " +elementLocator+ ", is not available on page - "
+ getDriver().getUrl());
}
}
在第二个例子中，’XXXX’方法是一个占位符，可以用元素定位方法进行替换。
使用安全方法取决于测试开发人员的决定。因此，如果测试需要继续执行，即使知道页面上一些元素没有发现，这时可以使用安全方法，并发送一条缺少元素的消息到日志文件。这基本上等于实现了带报告机制的验证，而不是一个失败就终止执行的断言。但是，如果元素必须在页面上出现，以便能够执行进一步的操作（如一个门户网站主页上的登录按钮），这时安全方法技术不应该被使用。
Selenium自动化测试用例设计注意事项（二）
UI映射
一个UI映射是一种机制，它存储所有的定位器的测试套件在一个地方，方便修改UI元素的路径标识符或改变在AUT。测试脚本，然后使用UI地图定位以被测试的元件。基本上，UI地图是一个存储库的测试脚本对象，对应于被测试的应用程序的UI元素。
是什么让一个UI地图有帮助吗？其主要目的是测试脚本的管理更加容易。当定位需要编辑，有一个中央位置轻松地找到对象，而不是通过搜索测试脚本代码。此外，它允许改变的标识符在一个地方，而不是在多个地方，以使更改在测试脚本，或为此事，在多个测试脚本。
总之，一个UI地图有两个显着的优点。
● UI对象使用一个集中的位置，而不是让他们分散在整个脚本。这使得脚本维护更高效。
● 神秘的HTML标识符和名称可以被赋予了更多的人类可读的名字，提高测试脚本的可读性。
考虑下面很难理解的测试代码（Java语言）。
public void testNew() throws Exception {
selenium.open(https://www.doczj.com/doc/fd10310785.html,);
selenium.type("loginForm:tbUsername", "xxxxxxxx");
selenium.click("loginForm:btnLogin");
selenium.click("adminHomeForm:_activitynew");
selenium.waitForPageToLoad("30000");
selenium.click("addEditEventForm:_IDcancel");
selenium.waitForPageToLoad("30000");
selenium.click("adminHomeForm:_activityold");
selenium.waitForPageToLoad("30000");
}
该代码很难被那些不熟悉待测应用（AUT）页面源代码的人理解。即使是待测应用的固定用户可能也很难理解这段脚本代码的作用。一个更好的脚本可能是：
public void testNew() throws Exception {
selenium.open(https://www.doczj.com/doc/fd10310785.html,);
selenium.type(https://www.doczj.com/doc/fd10310785.html,ername, "xxxxxxxx");
selenium.click(admin.loginbutton);
selenium.click(admin.events.createnewevent);
selenium.waitForPageToLoad("30000");
selenium.click(admin.events.cancel);
selenium.waitForPageToLoad("30000");
selenium.click(admin.events.viewoldevents);
selenium.waitForPageToLoad("30000");
}
使用备注和空格换行、再加上UI映射标识，下面的代码更加易读：
public void testNew() throws Exception {
// Open app url.
selenium.open(https://www.doczj.com/doc/fd10310785.html,);
// Provide admin username.
selenium.type(https://www.doczj.com/doc/fd10310785.html,ername, "xxxxxxxx");
// Click on Login button.
selenium.click(admin.loginbutton);
// Click on Create New Event button.
selenium.click(admin.events.createnewevent);
selenium.waitForPageToLoad("30000");
// Click on Cancel button.
selenium.click(admin.events.cancel);
selenium.waitForPageToLoad("30000");
// Click on View Old Events button.
selenium.click(admin.events.viewoldevents);
selenium.waitForPageToLoad("30000");
}
有多种方法可以实现UI映射。可以创建一个类或结构体来存储字符串变量，每个变量存储一个定位信息。或者，使用一个文本文件来存储键值对。在Java中，一个包含键值对的属性property文件可能是最好的方法。
考虑如下属性文件prop.properties，为上述代码例子中的UI元素指定了“别名”：
https://www.doczj.com/doc/fd10310785.html,ername = loginForm:tbUsername
admin.loginbutton = loginForm:btnLogin
admin.events.createnewevent = adminHomeForm:_activitynew
admin.events.cancel = addEditEventForm:_IDcancel
admin.events.viewoldevents = adminHomeForm:_activityold
其中定位信息还是指向页面的HTML对象，但我们在测试脚本和UI元素之间引入一层抽象层。测试类从属性文件中读取定位信息，从而实现UI映射。
页面对象设计模式
页面对象设计模式，可以提高自动化测试脚本的维护性、减少代码重复，越发流行。页面对象是一个面向对象的类，作为待测应用对外提供的接口。测试代码在需要和UI页面交互时，使用此页面对象类的方法。这样做的好处是，如果UI页面发生变化，测试代码本身并不需要改变，只需要改变相应的页面对象的代码。为适应新UI页面的所有更改，都位于一个地方。
页面对象设计模式具有以下优点：
1、测试代码和页面相关的代码，比如页面元素定位信息（若使用UI映射，也包括定位信息的应用），
页面布局等，完全分离；
2、可以维护单一的储存库来存储页面提供的服务或操作，而不是把他们分散在测试代码中。
在这两种情况下，这使得任何由于UI界面变化导致的修改，都可以在一个地方进行修改。关于该技术的更多有用信息，可以在众多的博客上找到。我们也鼓励读者去阅读更多。许多人写这样的设计模式和超出本用户指南的范围，可以提供有用的提示。不过，为了让你开始，我们将举例说明页面对象的一个简单的例子。
首先，考虑一个例子，典型的自动化测试，不使用页面对象。
/***
* Tests login feature
*/
public class Login {
public void testLogin() {
selenium.type("inputBox", "testUser");
selenium.type("password", "my supersecret password");
selenium.click("sign-in");
selenium.waitForPageToLoad("PageWaitPeriod");
Assert.assertTrue(selenium.isElementPresent("compose button"),
"Login was unsuccessful");
}
}
这种方法有两个问题。
1、没有分离测试代码和待测应用的定位器（在这个例子中是ID）；两者都交织在一个单一方法中。如
果待测应用UI改变了它的标识，布局，或登录输入和处理的方式变化，测试代码本身必须改变。
2、ID定位信息分散在多个测试代码中，所有的测试不得不使用此登录页面。
使用页面对象技术，上述测试代码可以按如下方式重写，为登录页面的页面对象例子：
/**
* Page Object encapsulates the Sign-in page.
*/
public class SignInPage {
private Selenium selenium;
public SignInPage(Selenium selenium) {
this.selenium = selenium;
if(!selenium.getTitle().equals("Sign in page")) {
throw new IllegalStateException("This is not sign in page, current page is: "
+selenium.getLocation ());
}
}
/**
* Login as valid user
*
* @param userName
* @param password
* @return HomePage object
*/
public HomePage loginValidUser(String userName, String password) {
selenium.type("usernamefield", userName);
selenium.type("passwordfield", password);
selenium.click("sign-in");
selenium.waitForPageToLoad("waitPeriod");
return new HomePage(selenium);
}
}
主页的页面对象可能会是这个样子：
/**
* Page Object encapsulates the Home Page
*/
public class HomePage {
private Selenium selenium;
public HomePage(Selenium selenium) {
if (!selenium.getTitle().equals("Home Page of logged in user")) {
throw new IllegalStateException("This is not Home Pag e of logged in user, current page" +
"is: " +selenium.getL ocation());
}
}
public HomePage manageProfile() {
// Page encapsulation to manage profile functionality
return new HomePage(selenium);
}
/*More methods offering the services represented by Home Page
of Logged User. These methods in turn might return more Page Objects
for example click on Compose mail button could return ComposeMail class object*/
}
现在，使用上述两个页面对象的登录测试代码，如下所示。
/***
* Tests login feature
*/
public class TestLogin {
public void testLogin() {
SignInPage signInPage = new SignInPage(selenium);
HomePage homePage = signInPage.loginValidUser("userName", "password ");
Assert.assertTrue(selenium.isElementPresent("compose button"),
"Login was unsuccessful");
}
}
怎么样使用页面对象进行设计有很大的灵活性，但也有一些基本的规则以保证得到测试代码具有所需的可维护性。页面对象本身不应该被验证或断言。这应该是测试的一部分，并应始终在测试代码中去验证或断言，而不要放在页面对象内。页面对象将包含页面展现，方法的形式表示页面提供的服务，但不需要包含应该在测试代码中维护的代码。
唯一的应该存在页面对象中的验证方法是，验证页面、页面上的重要元素，被正确的加载。这这个验证应该在页面初始化时进行。在上面的例子中，SignInPage 和HomePage 的构造函数检查了期望的页面是否可用，是否准备好接受测试代码的请求。
页面对象并不一定要代表整个页面。页面对象设计模式可用于表示页面上组件。在待测应用上的一个页面若有多个组件，每个组件对应一个页面对象可以提高可维护性。
在测试时，还会遇到其他的测试设计模式。有些人用一个页面工厂模式来实例化页面对象。讨论所有的这些测试模式，超出了本文档的的范围。在这里，我们只为大家介绍概念，使读者知道这些东西可以些什么。正如前面提到的，很多人都在博客上讨论这个话题，我们鼓励读者搜索这些话题。
数据驱动测试
数据驱动测试是指相同的测试（或测试集）可以使用不同的数据多次执行。这些数据集往往来自外部文件，如csv文件，文本文件，或者是从数据库加载。数据驱动测试是一种常用的自动化测试技术，使用不同的输入对应用程序进行多次验证。当测试被针对不同的数据进行设计时，所输入的数据就可以扩展，基本上不需要修改测试代码就可以进行更多的测试。
# Collection of String values
source = open("input_file.txt", "r")
values = source.readlines()
source.close()
# Execute For loop for each String in the values array
for search in values:
sel.open("/")
sel.type("q", search)
sel.click("btnG")
sel.waitForPageToLoad("30000")
self.failUnless(sel.is_text_present("Results * for " + search))
上面的Python代码打开一个文本文件，这个文件每行包含不同的搜索字符串。然后代码保存字符串到一个字符串数组，对数值进行遍历，使用搜索字符串进行查询，并进行断言。
这是一个非常简单的例子，但其中的思路表明，可以很简单的使用编程、脚本语言进行数据驱动的测试。有关更多示例，请参阅Selenium RC wiki 来了解如何从电子表格读取数据或使用TestNG的提供数据。
此外，这是一个在自动化测试的专业人士圈内众所周知的话题之一，包括那些不使用Selenium的自动化圈子，因此搜索互联网上的“数据驱动测试”，会得到许多关于这一主题的博客。
数据库验证
另一种常见的测试类型是，比较用户界面上的数据和存储在后台数据库中的数据。因为你也可以使用一种编程语言进行数据库查询，假设你有数据库相关的函数，你可以用它们来检索数据，然后使用这些数据来验证页面上所显示的数据是正确的。
考虑如下例子，从数据库中进行检索注册电子邮件地址，然后再和界面上的数据进行比较。代码如下，先建立一个数据库连接，并从数据库中检索数据，使用的是Java语言：
// Load Microsoft SQL Server JDBC driver.
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
// Prepare connection url.
String url = "jdbc:sqlserver://192.168.1.180:1433;DatabaseName=TEST_DB";
// Get connection to DB.
public static Connection con =
DriverManager.getConnection(url, "username", "password");
// Create statement object which would be used in writing DDL and DML
// SQL statement.
public static Statement stmt = con.createStatement();
// Send SQL SELECT statements to the database via the Statement.executeQuery
// method which returns the requested information as rows of data in a
// ResultSet object.
ResultSet result = stmt.executeQuery
("select top 1 email_address from user_register_table");
// Fetch value of "email_address" from "result" object.
String emailaddress = result.getString("email_address");
// Use the emailAddress value to login to application.
selenium.type("userID", emailaddress);
selenium.type("password", secretPassword);
selenium.click("loginButton");
selenium.waitForPageToLoad(timeOut);
Assert.assertTrue(selenium.isTextPresent("Welcome back" +emailaddress), "Unable to log in for user" +emailaddress)
这是一个简单的Java例子从数据库中检索数据。
1白盒测试用例设计方法 1.1白盒测试简介 白盒测试又称结构测试、逻辑驱动测试或基于程序的测试，一般多发生在单元测试阶段。白盒测试方法主要包括逻辑覆盖法，基本路径法，程序插装等。 这里重点介绍一下常用的基本路径法，对于逻辑覆盖简单介绍一下覆盖准则。 1.2基本路径法 在程序控制流图的基础上,通过分析控制构造的环路复杂性，导出独立路径集合，从而设计测试用例，设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。 在介绍基本路径测试方法（又称独立路径测试）之前，先介绍流图符号： 图1 如图1所示，每一个圆，称为流图的节点，代表一个或多个语句，流程图中的处理方框序列和菱形决策框可映射为一个节点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个节点，即使该节点并不代表任何语句，例如，图2中两个处理方框交汇处是一个节点，边和节点限定的范围称为区域。 图2
任何过程设计表示法都可被翻译成流图，下面显示了一段流程图以及相应的流图。 注意，程序设计中遇到复合条件时（逻辑or, and, nor 等），生成的流图变得更为复杂，如(c)流图所示。此时必须为语句IF a OR b 中的每一个a 和b 创建一个独立的节点。
(c)流图 独立路径是指程序中至少引进一个新的处理语句集合，采用流图的术语，即独立路径必须至少包含一条在定义路径之前不曾用到的边。例如图(b)中所示流图的一个独立路径集合为： 路径1：1-11 路径2：1-2-3-4-5-10-1-11 路径3：1-2-3-6-8-9-10-1-11 路径4：1-2-3-6-7-9-10-1-11 上面定义的路径1，2，3 和4 包含了(b)流图的一个基本集，如果能将测试设计为强迫运行这些路径，那么程序中的每一条语句将至少被执行一次，每一个条件执行时都将分别取true 和false（分支覆盖）。应该注意到基本集并不唯一，实际上，给定的过程设计可派生出任意数量的不同基本集。如何才能知道需要寻找多少条路径呢？可以通过如下三种方法之一来计算独立路径的上界： 1. V=E-N+2，E 是流图中边的数量，N 是流图节点数量。 2. V=P+1，P 是流图中判定节点的数量 3. V=R，R 是流图中区域的数量 例如，(b)流图可以采用上述任意一种算法来计算独立路径的数量 1. V=11 条边-9 个节点+2=4 2. V=3 个判定节点+1=4 3. 流图有4 个区域，所以V=4 由此为了覆盖所有程序语句，必须设计至少4 个测试用例使程序运行于这4 条路径。 在采用基本路径测试方法中，获取测试用例可参考以下方式：
自动化测试基本流程 1. 制定测试计划 在展开自动化测试之前，最好做个测试计划，明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试计划后，下发给用例设计者。 2. 分析测试需求 用例设计者根据测试计划和需求说明书，分析测试需求，设计测试需求树，以便用例设计时能够覆盖所有的需求点。一般来讲，基于Web 功能测试需要覆盖一下几个方面： 1).页面链接测试，确保各个链接正常； 2).页面控件测试，确保各个控件可靠； 3).页面功能测试，确保各项操作正常； 4).数据处理测试，确保数据显示准确、处理精确可靠；
5).模块业务逻辑测试，确保各个业务流程畅通。 3. 设计测试用例 通过分析测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时，要将登陆系统的用户、密码、产品、客户等参数信息独立出来形成测试数据，便于脚本开发。 4. 搭建测试环境 自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件，添加对象。测试环境的搭建，包括被测系统的部署、测试硬件的调用、测试工具的安装盒设置、网络环境的布置等。 5. 编写测试脚本
根据自动化测试用例和问题的难易程度，采取适当的脚本开发方法编写测试较薄。一般先通过录制的方式获取测试所需要的页面控件，然后再用结构化语句控制脚本的执行，插入检查点和异常判定反馈语句，将公共普遍的功能独立成共享脚本，必要时对数据惊醒参数化。当然还可以用其他高级功能编辑脚本。脚本编写好了之后，需要反复执行，不断调试，知道运行正常为止。脚本的编写和命名要符合管理规范，以便统一管理和维护。 6. 分析测试结果、记录测试问题 应该及时分析自动化测试结果，建议测试人员每天抽出一定时间，对自动化测试结果进行分析，以便尽早地发现缺陷。如果采用开源自动化测试工具，建议对其进行二次开发，以便与测试部门选定的缺陷管理工具紧密结合。理想情况下，自动化测试案例运行失败后，自动化测试平台就会自动上报一个缺陷。测试人员只需每天抽出一地你该时间，确认这些自动上报的缺陷，是否是真实的系统缺陷。如果是系统缺陷就提交开发人员修复，如果不是系统缺陷，就检查自动化测试脚本或者测试环境。
一、白盒测试概念 1、定义 白盒测试又称结构测试、透明盒测试、逻辑驱动测试、基于代码的测试。盒子指被测试的软件，白盒指盒子是可视的。白盒测试是一种测试用例设计方法，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例。白盒测试主要针对被测程序的源代码，主要用于软件验证，不考虑软件的功能实现，只验证内部动作是否按照设计说明书的规定进行。 2、目的 我们一方面注重软件功能需求的实现，另一方面还要注重程序逻辑细节，主要是因为软件自身的缺陷，具体如下： 1）逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。 2）我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，只有路径测试才能发现这些错误。 3）代码中的笔误是随机且无法杜绝的。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。很多被语法检查机制发现，但是其他的会在测试开始时才会被发现。 4）功能测试本身的局限性。如果程序实现了没有被描述的行为，功能测试是无法发现的，例如病毒，而白盒测试很容易发现它。 3、目标 采用白盒测试必须遵循以下几条原则，才能达到测试的目标： 1）保证一个模块中的所有独立路径至少被测试一次。 2）所有逻辑值均需测试真(true) 和假(false)两种情况。 3）检查程序的内部数据结构，保证其结构的有效性。 4）在上下边界及可操作范围内运行所有循环。 4、黑白灰区别 黑盒测试技术：也称功能测试或数据驱动测试，只关注规格说明中的功能，测试者在程序接口对软件界面和软件功能进行测试，它只检查实现了的功能是否按照“用户需求说明书”的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。主要用于软件确认测试，结合兼容、性能测试等方面，但黑盒测试不能保证已经实现的各个部分都被测试到。黑盒测试适用于各阶段测试。 白盒测试技术：只关注软件产品的测试，深入到代码一级的测试，它是知道产品内部结构，通过测试来检测产品内部动作是否按照“设计规格说明书”的规定正常进行，按照程
Selenium安装以及简单的自动化测 试用例 中科软科技股份有限公司 2013年4月 V1.0.0
关于本文档 说明：类型－创建（C）、修改（U）、删除（D）、增加（A）；
目录 目录 (3) 1.Selenium介绍 (3) 2.相关组件 (3) 3.启动seleniumRC (4) 4.简单测试用例 (4) 4.1在火狐浏览器上下载并打开selenium IDE (5) 4.2录制测试用例 (6) 4.2.1 录制 (6) 4.2.2 检查 (6) 4.2.3 语言转换 (6) 4.2.4 准备Eclipse环境 (7) 4.2.5 运行 (9) 1.Selenium介绍 Selenium是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE、Mozilla Firefox、Mozilla Suite等。 功能： ●测试直接在浏览器中运行，就像真实用户所做的一样，从终端用户的角度测试应用程序。 ●使浏览器兼容性测试自动化成为可能。 ●使用简单，可生成多种语言的用例脚本。 2.相关组件 ●Selenium IDE：一个Firefox插件，可以录制用户的基本操作，生成测试用例。随后可以 运行这些测试用例在浏览器里回放，可将测试用例转换为其他语言的自动化脚本。
●Selenium Remote Control (RC) ：支持多种平台(Windows，Linux，Solaris)和多种浏览器(IE， Firefox，Opera，Safari)，可以用多种语言(Java，Ruby，Python，Perl，PHP，C#)编写测试用例。 ●Selenium Grid ：允许Selenium-RC 针对规模庞大的测试案例集或者需要在不同环境中 运行的测试案例集进行扩展。 3.启动seleniumRC 官网下载：https://www.doczj.com/doc/fd10310785.html,/download/。打开cmd，进入RC存放文件夹。在命令行输入：java –jar selenium-server.jar 。 启动成功。 注意在启动RC前，确认电脑上安装JDK版本高于1.5 4.简单测试用例 以OA系统登录为例：
自动化测试设计规范V1.0 (仅供内部使用） For internal use only Prepared by 拟制陈玉梅37906 Date 日期 2010-12-15 Reviewed by 评审人孟咏喜00137435 顾江00118951 张杰飞00101597 Date 日期 2010-12-16 Approved by 批准Date 日期 yyyy-mm-dd Authorized by 签发 Date 日期 yyyy-mm-dd Huawei Technologies Co., Ltd. 华为技术有限公司
All rights reserved 版权所有侵权必究
Revision record 修订记录 1前言 本规范适用于指导基于AutoSpace自动化测试平台的自动化测试设计活动，目的是通过规范性指导提升自动化测试设计质量。 自动化测试设计的活动流程如图所示：
自动化测试设计活动角色主要分为两种： ?自动化设计人员（如TSE、测试骨干） 负责自动化用例设计前的设计活动，包括自动化测试分析、AW设计、数据规划、 测试工程设计等 ?自动化测试工程师 负责自动化用例设计 本文将按照自动化测试设计流程，分别介绍各个活动的设计规范和指导原则。 2自动化测试分析 自动化测试分析过程，重点分析产品特性哪些适合自动化、哪些特性应优先实现自动化。 适合自动化的范围包括： 1.产品特性相对比较稳定，变化不是非常大 2.产品特性重要程度高，每轮版本测试、回归测试基本都是必测的 3.自动化投入成本在接受范围内，最好已有技术储备 通过如上三个维度分析自动化实现的优先级，应优先实现投入产出比收益明显的产品特性，即自动化较易于实现、且需要频繁测试的重要特性。 3AW设计 AW是自动化用例设计的基础，应易于理解、好用，便于测试人员快速掌握，降低学习成本，提高用例设计效率。 AW设计的基本原则是基于业务进行抽象、设计粒度合理，尽可能覆盖自动化用例。 对于底层AW（如协议AW），应封装为类似“开户”、“用户认证”、“拨号”等业务逻辑，降低用例设计难度和接口变更时对用例的影响，提升自动化用例的重用性。
自动化测试用例设计 序言：自动化测试中，自动化测试用例是一个重点中的重点，个人以为，到底如何去定位自动化测试用例设计的形式和发展是决定自动化测试成败的关键，根据一些研究和看法，我写了一个自动化测试用例设计的一个大概情况，当然一家之言而言，当然，大家在测试过程中，接触过自动化测试的，肯定就接触过自动化测试用例，其是自动化测试脚本本身也是一种自动化测试用例，看看以下的情况大家遇到过么，希望大家有什么想法，提出来吧。 一、自动化测试用例应用 手工测试用例是针对手工测试人员，自动化测试用例是针对自动化测试框架，前者是手工测试用例人员应用手工方式进行用例解析，后者是应用脚本技术进行用例解析，两者最大的各自特点在于，前者具有较好的异常处理能力，而且能够基于测试用例，制造各种不同的逻辑判断，而且人工测试步步跟踪，能够细致的定位问题。而后者是完全按照测试用例的方式测试，而且异常处理能力不强，往往一个自动化测试用例运行完毕后，报一堆错误，对于测试人员来定位错误是一个难点，这样往往发现的问题很少。所以，根据其各自的特点，需要将两者有很好的定位：手工测试是在软件版本前几轮测试的重点，目的是验证功能，发现问题；自动化测试是应用在后几轮版本，保证软件版本模块修改或者添加新功能后，没有影响开始的功能模块（因为软件中，各模块之间的接口以及类、函数方法等的互相引用，也是容易出问题的地方）。 二、自动化测试用例设计发展 1、自动化测试用例设计发展前期 记得，当时的自动化测试开展是针对测试设备设计一套测试环境系统，用于自动化例行测试，根据此，专门撰写了一套自动化测试用例，并转化成自动化测试脚本。之后整套系统都失败了，失败原因包括： a、系统太过于庞大，测试用例也过于繁琐，每次测试运行下来，测试结果都夹杂着一大堆各种错误，有可能是产品问题，有可能是脚本问题，也有可能是用例问题，这样下来，测试人员每次运行一遍都要面对大量的问题，维护的几次就放弃了，问题越来越多，根本没办法去定位，这样反而浪费了大量的成本和时间。 b、搭建的一套测试环境系统，各个产品功能模块都互相联系在一起，都互相有影响，容易造成问题。 c、更重要的是，由于是单独搭建的一套测试环境系统，其自动化测试用例与手工测试用例没有太大关系，这样就造成了其自动化测试很难对手工测试进行辅助。 2、自动化测试用例设计发展前中期 这时，自动化测试用例来源于手工测试用例，首先，自动化测试根据手工测试用例进行转换而来（举个例子：CLI测试时，自动化测试用例是根据手工测试用例的步骤，将其需要输入的CLI命令和回显进行填写），之后，自动化测试脚本人员根据其自动化测试翻译为脚本。这样做的好处就是手工测试用例与自动化测试用例的结合，保证了自动化测试的明确性，后期的改进还包括 a、将自动化测试用例根据手工测试用例进行了分层，把一些共性功能和全局变量抽象到了更上一层，保证复用性和降低维护性。 b、设计的自动化测试框架的管理。 经过一段时间之后，问题还是很大，主要问题在于
如何编写单元测试用例（白盒测试）。 一、单元测试的概念 单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。 测试的覆盖种类 1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。 2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。 3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。 4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。 5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。 6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。 用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。 二、开始测试前的准备
在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。穷举测试是不可能的。所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。 三、开始测试 基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。 函数说明：当i_flag=0；返回 i_count+100 当i_flag=1；返回 i_count *10 否则返回 i_count *20 输入参数：int i_count ， int i_flag 输出参数： int i_return; 代码： 1int Test(int i_count, int i_flag) 2 {
功能自动化测试流程解析 本流程是描述软件功能自动化测试过程中的步骤、内容与方法，明确各阶段的职责、活动与产出物。 1流程图 2流程说明 2.1 测试计划（可选） 与以前的测试计划过程一致，只是在原来的测试计划中，添加对项目实施自动化测试所需的资源、测试范围、测试进度的描述。该过程产出物为《测试计划》。 2.2 自动化测试用例设计 根据《测试计划》、《软件需求规格说明书》、《系统测试用例》设计出针对自动化测试的测试用例。测试用例的粒度精确到单个功能点或流程，对于各个功能点的业务规则，通过对脚本添加相应的检查点来进行测试。该过程的产出物是《自动化测试用例》。
2.3 自动化脚本设计（可选） 根据《软件需求规格说明书》、《自动化测试用例》、《系统原型》、《系统设计说明书》编写《自动化脚本设计说明书》，其主要内容包括：分析当前项目，设计出适合的脚本基本架构，针对特殊自动化测试用例设计可行的脚本编写方法，设计特殊检查点的实现方式，并对潜在的技术难点提出解决方案。该过程的产出物是《自动化脚本设计说明书》。 2.4 自动化脚本编写 根据《软件需求规格说明书》、《自动化测试用例》、《系统原型》、《自动化脚本设计说明书》，录制、调试、编写各个功能点的自动化测试脚本，并添加检查点，进行参数化。该过程还需要编写数据文件处理脚本、日志文件处理脚本、数据库处理脚本、公共检查点处理脚本等等。该过程的产出物是各个功能点的自动化测试脚本和其他公共处理脚本。 2.5 自动化测试数据设计 根据《软件需求规格说明书》、《自动化测试用例》设计出对各个功能点和相关业务规则进行测试的输入数据和预期输出，填写入对应的数据文件中。该过程的产出物是各个功能点的数据文件。 2.6 自动化测试执行 搭建好测试环境。根据《自动化测试用例》，执行自动化脚本，对系统进行自动化测试，并自动记录测试结果到日志文件中。 2.7 自动化测试结果分析 对测试结果文件中报告错误的记录进行分析，如果确实是由于被测系统的缺陷导致，则提交缺陷报告。对自动化测试的结果进行总结，分析系统存在的问题，提交《测试报告》。 2.8 自动化测试脚本维护（可选） 如果系统发生变更时，对自动化测试脚本和相关文档包括《自动化测试用例》、《自动化脚本设计说明书》进行维护，以适应变更后的系统。
20 14 —20 15 学年第 2 学期 软件测试技术课程 实验报告 学院：计算机科学技术 专业：软件工程 班级：软件12401 姓名：李晶宇 学号：041240134 任课教师：刘玉宝
实验日期：2015年 6 月16 日实验题目实验5、白盒测试：路径测试及测试用例设计 实验目的1、掌握独立路径，程序基本路径测试的概念。 2、掌握独立路径测试法。 实验内容 程序int binsearch(int array[],int key)实现折半查找的功能。数组array元素按升序排列，length为数组array的长度，key为要查找的值。 试用独立路径集测试法测试该程序，撰写实验报告。 关键代码如下（Java实现） public static int binsearch(int array[],int key) { int low = 0; int high = array.length - 1; int middle; while(low <= high) { middle = (low+high)/2; if(array.[middle] == key) { return middle; }else if(array.[middle] < key) { low = middle +1; }else { high = middle - 1; } } return -1; } 实验步骤： 1）画出程序的流图(控制流程图)。
程序入口（数组元素升序） low <= high (low+high)/2 array[middle] == key Y N array[middle] < key key=middle Y N low=middle+1 high=middle-1 程序出口 2）计算流图G 的圈复杂度V(G)。 封闭区域：○2→○3→○4→○6→○7→○2→○10 ○2→○3→○4→○6→○8→○9→○2→○10 还有一个区域是这两个区域以外的区域，共有三个区域，即独立路径数的上界 是3，V(G)=3。 3）确定只包含独立路径的基本路径集。 V(G)值正好等于该程序的独立路径的条数。 程序的独立路径是： Path1:○1→○2→○3→○4→○5→○10 Path2:○1→○2→○3→○4→○6→○7→○2→○10 Path3:○1→○2→○3→○4→○6→○8→○9→○2→○10 4）根据上面的独立路径，设计测试用例，得到测试用例表。 为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证每一条路径可以被测试到，满足上面例子基本路径集的测试用例表如下： 2 10 1 4 6 5 7 8 9 3
自动化测试学习计划 篇一：自动化测试设计规范V1 自动化测试设计规范 了解什么是自动化测试 2)自动化测试与手动测试的关系 3)自动化测试的优势 4)学习使用自动化测试软件中的功能测试工具：QuickTest Professional以及它的测试脚本语言VBScript 实习时间 2016年6月13日~2016年6月17日 实习地点 实习内容简述 星期一：学习使用Vbs语言 VBScript.BASIC本版). VBS是基于Visual Basic的脚本语言.。就是你写的程序不需要编译成.exe, 而是直接给用户发送.vbs的源程序, 用户就能执行了。
星期二：学习正则表达式 QuickTest Professional借助VBScript正则表达式形成不同的值来标示对象和文本字符串。QuickTest Professional读者可以在以下场景中使用正则表达式： 1）在描述性编程中定义对象的属性值； 2）参数化步骤值； 3）创建检查点中使用不同的值。 星期三至星期五：学习自动化测试实施的综合案例以及自动化测试报告QTP自带的飞机订票系统，在系统所有测试模块中，登录、预订机票是系统的重要功能模块，因此无论是哪个版本，均需要对这两个模块展开测试。所以，将登录、预定机票操作模块作为ＢＶＴ测试中的功能模块。考虑到ＢＶＴ测试的重复性于频繁性，对着两个功能模块执行自动化，通过自动化测试实现功能验证。 2 测试计划
引言 编写目的 编写本测试计划的目的是为了指导自动化测试，合理的分配资源与人力，使自动化测试能够顺利开展，并达到预期效果。 该计划阅读对象包括：自动化测试工程师、黑盒测试工程师及项目负责人。 背景 说明： 项目名称：Flight系统 项目代号：Flight系统 定义 SCM: Software Configuration Management（软件配置管理） SQA: Software Quality Assurance（软件质量保证） SaaS：SoftWare as a Service QoS：Quality of Service（服务质量管理） 错误级别 1级：不能完全满足系统需求，基本
开源自动化测试工具selenium的使用 (玉米猫) 一Selenium概述： Selenium是现在使用最为广泛的一款开源自动化测试工具，也是非商业支持的稳定性易用性最好的一款自动化测试工具。和由HP提供强大商业支持的QTP相比，selenium不仅在软件投资上有比较大的优势，在针对web测试的稳定性上也有绝对的优势。以下介绍的内容会通过和QTP在各方面的比较中进行，并针对简单的测试样例，对基本的使用进行简单说明。 二Selenium的组成： 和QTP等其他工具类似，selenium也有几个组件组成，同时在使用的时候还需要一些开发的IDE平台进行支持。 对于初步的简单使用，需要先掌握seleniumIDE，RC的基本使用，以及对象识别方式Xpathe的基本知识。 1)seleniumIDE： selenium和QTP类似，同样需要先进行一定的脚本录制工作，而它默认支持的录制浏览器是firefox，IDE就充当了一个脚本记录的工作，它的表现形式为firefox的一款插件。 它可以记录准备过程中，用户在firefox上的制定网址下所做的一切操作，并转化为自己需要的一种开发语言，包括：java、perl、PHP、C#、Ruby等等。 2)RC： RC是selenium的特色组件，它通过从底层向不同的浏览器发出动作指令，达到用脚本控制web的效果，和QTP的activeX驱动的模式有着本质的不同，只要浏览器的动作指令原理不发生本质性的变化，就可以利用selenium达到自动化测试的效果，不会由于出现新的浏览器，还要等待HP重新开发相应的activeX控件。
3)其他： 由于selenium的非商业支持，所以很多类似于QTP中的组件都使用了firefox插件的办法得到了补充。 Firebug：帮助用户对页面上的对象进行识别，它可以准确捕捉到任何一个可见元素和不可见元素，同时支持由对象找代码和由代码找对象的使用方法，非常类似于QTP的spy 和控件高亮显示功能。 Xpather：帮助用户利用xpath标记对象的位置信息，根据xpath的实现方式，可以将页面上的每一个控件元素做唯一性标识，非常类似于QTP的对象库，区别在于Xpath只记录元素的位置样式属性，不会记录截图。 三Selenium的简单使用： 1)测试的准备工作： 这里所说的准备工作，只一个自动化测试的准备，预计基本的测试用例等内容已经准备完成。 假如被测系统为ADCPX： 首先：用firefox打开被测系统的首页，启动IDE插件。 需要注意的是，IDE的baseUrl一定是当前要测试的web首页，默认生成的第一个testcase 的名称可以通过属性进行更改。一个IDE中可以录制或生成多个testcase。
目录 一、前言（课设目的及内容） (1) 1.1 课设目的 (1) 1.2 课设内容 (1) 二、测试计划及测试需求 (2) 2.1 测试原理分析 (2) 2.2 测试思想设计 (2) 2.3 测试计划设计 (3) 2.4 测试环境搭建 (4) 三、测试用例的设计 (5) 3.1 登陆测试用例设计 (5) 3.2 订票测试用例设计 (8) 四、测试过程 (9) 4.1 登陆测试过程 (9) 4.2 订票测试过程 (10) 五、测试结果分析 (16) 5.1 测试结果 (16) 5.2 测试结果分析 (20) 六、课设小结及心得体会 (23) 七、参考文献 (24)
一、前言（课设目的及内容） 1.1 课设目的 (1) 使学生能掌握网站功能测试的基本思路和方法，学会使用自动化测试工具QTP进行功能测试； (2) 培养学生分析、解决问题的能力； (3) 提高学生的科技论文写作能力。 1.2 课设内容 (1) 对默认环境和条件（要求详细记录环境条件）下，构造正确的输入进行正常功能需求的测试，使用常见的检查点测试，并将输入进行参数化； (2) 测试系统在异常环境下的功能需求变化，并对测试的结果进行分析和汇总； (3) 相应驱动的编写； (4) 在基本要求达到后，可对被测系统进行探索性测试。
二、测试计划及测试需求 2.1 测试原理分析 QTP主要采用的是使用GUI模拟人的操作。它在模拟人的操作时会记录操作的对象及所做的操作和顺序，然后在回放时按记录顺序操作这些对象。而在这个模拟的过程中，最重要的莫过于界面对象（控件）的识别。 首先，QTP会通过“用户名输入框”这个名字到对象库的对象名中查找； 然后通过找到的对象名，找到对象名映射的属性包； 接着QTP就会通过这个属性包来匹配页面上的控件的属性，如果在页面上找到一个唯一与此属性包匹配的控件，那QTP就会认为此控件为要找的控件； 最后QTP根据“WebEdit”来确定控件的类型，并调用QTP对于此类控件内置的操作方法“Set”把“**值”赋予了控件。 至于其他控件的识别和操作，基本原理和上面一样。 2.2 测试思想设计 根据测试原理的分析以及QTP测试的基本步骤可以设计如图2.2.1的测试思想流程图。该流程图使用Microsoft Visio 2003绘制。
白盒测试用例练习 1．为以下所示的程序段设计一组测试用例，要求分别满足语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖，并画出相应的程序流程图。 void DoWork (int x,int y,int z) { int k=0,j=0; if ( (x>3)&&(z<10) ) { k=x*y-1; j=sqrt(k); //语句块1 } if ( (x==4)||(y>5) ) { j=x*y+10; } //语句块2 j=j%3; //语句块3 } a Y c N b e Y N d x>3 and z<10 x=4 or y>5 j=j%3 j=x*y+10 k=x*y-1 j=sqrt(k) k=0 j=0
由这个流程图可以看出，该程序模块有4条不同的路径： P1:(a-c-e) P2:(a-c-d) P3:(a-b-e) P4:(a-b-d) 将里面的判定条件和过程记录如下： 判定条件M＝{x>3 and z<10} 判定条件N={x=4 or y>5} 1、语句覆盖 测试用例输入输出判定M的取值判定N的取值覆盖路径x=4,z=5,y=8 k=31,j=0 T T P1(a-c-e) 2、判定覆盖 p1和p4可以作为测试用例，其中p1作为取真的路径，p4作为取反的路径。 测试用例输入输出判定M的取值判定N的取值覆盖路径x=4,z=5,y=8 k=31,j=0 T T P1(a-c-e) x=2,z=11,y=5 k=0,j=0 F F P4(a-b-d) 也可以让测试用例测试路径P2和P3。相应的两组输入数据如下： 测试用例输入输出判定M的取值判定N的取值覆盖路径x=5,z=5,y=4 k=19,j=sqrt(19)%3 T F P2(a-c-d) x=4,z=11,y=6 k=0,j=1 F T P3(a-b-e) 3、条件覆盖 对于M：x>3取真时T1，取假时F1; z<10取真时T2，取假时F2； 对于N：x=4取真时T3，取假时F3; y>5取真时T4，取假时F4。 条件：x>3,z<10,x=4,y>5 条件：x<=3,z>=10,x!=4,y<=5 根据条件覆盖的基本思路，和这8个条件取值，组合测试用例如表所示: 测试用例输入输出取值条件具体取值条件覆盖路径x=4,z=5,y=8 k=31, j=0 T1，T2，T3，T4 x>3,z<10,x=4,y>5 P1(a-c-e) x=3,z=11,y=5 k=0, j=0 F1，F2，F3，F4 x<=3,z>=10,x!=4,y<=5 P4(a-b-d) 4、判定/条件覆盖 测试用例输入输出取值条件具体取值条件覆盖路径x=4,z=5,y=8 k=31, j=0 T1，T2，T3，T4 x>3,z<10,x=4,y>5 P1(a-c-e) x=3,z=11,y=5 k=0, j=0 F1，F2，F3，F4 x<=3,z>=10,x!=4,y<=5 P4(a-b-d)
白盒测试 白盒测试(White-box Testing，又称逻辑驱动测试,结构测试) 是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。白盒测试又称为结构测试和逻辑驱动测试。 白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。 六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。 白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。 "白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
功能自动化测试流程 1概述 本流程是描述软件功能自动化测试过程中的步骤、内容与方法，明确各阶段的职责、活动与产出物。 2流程活动图 3活动说明 3.1 测试计划（可选） 与以前的测试计划过程一致，只是在原来的测试计划中，添加对项目实施自动化测试所需的资源、测试范围、测试进度的描述。该过程产出物为《测试计划》。 3.2 自动化测试用例设计 根据《测试计划》、《软件需求规格说明书》、《系统测试用例》设计出针对自动化测试的测试用例。测试用例的粒度精确到单个功能点或流程，对于各个功能点的业务规则，通
过对脚本添加相应的检查点来进行测试。该过程的产出物是《自动化测试用例》。 3.3 自动化脚本设计（可选） 根据《软件需求规格说明书》、《自动化测试用例》、《系统原型》、《系统设计说明书》编写《自动化脚本设计说明书》，其主要内容包括：分析当前项目，设计出适合的脚本基本架构，针对特殊自动化测试用例设计可行的脚本编写方法，设计特殊检查点的实现方式，并对潜在的技术难点提出解决方案。该过程的产出物是《自动化脚本设计说明书》。 3.4 自动化脚本编写 根据《软件需求规格说明书》、《自动化测试用例》、《系统原型》、《自动化脚本设计说明书》，录制、调试、编写各个功能点的自动化测试脚本，并添加检查点，进行参数化。该过程还需要编写数据文件处理脚本、日志文件处理脚本、数据库处理脚本、公共检查点处理脚本等等。该过程的产出物是各个功能点的自动化测试脚本和其他公共处理脚本。 3.5 自动化测试数据设计 根据《软件需求规格说明书》、《自动化测试用例》设计出对各个功能点和相关业务规则进行测试的输入数据和预期输出，填写入对应的数据文件中。该过程的产出物是各个功能点的数据文件。 3.6 自动化测试执行 搭建好测试环境。根据《自动化测试用例》，执行自动化脚本，对系统进行自动化测试，并自动记录测试结果到日志文件中。 3.7 自动化测试结果分析 对测试结果文件中报告错误的记录进行分析，如果确实是由于被测系统的缺陷导致，则提交缺陷报告。对自动化测试的结果进行总结，分析系统存在的问题，提交《测试报告》。 3.8 自动化测试脚本维护（可选） 如果系统发生变更时，对自动化测试脚本和相关文档包括《自动化测试用例》、《自动化脚本设计说明书》进行维护，以适应变更后的系统。
selenium 自动化测试的框架 自动化测试的框架 软件自动化测试 style="font-family: 宋体 ;mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin;mso-fareast-font-family: 宋体 ;mso-fareast-theme-font: minor-fareast;mso-hansi-font-family:Calibri;mso-hansi-the me-font:minor-latin"> 个阶段。