回复 61# ryugun
目前是这么设计的，因此为了达到这个目的，才会增加一个java的用例文件，主要是依赖testNG的功能，以及产出报告。
当然这个java用例其实很简单，不能复杂了，不然开发成本就太高了。
下面贴出用例java 文件：
package com.XXXX.testcase.login;
import org.testng.annotations.Test;
import com.CCCC.testcase.BaseTestCase;
/**
* （只检查了是否有完整用户名）
* 用例名称：用户登录（成功）
* <p />
*/
public class Test_Login_001 extends BaseTestCase {
@Override
public void prepare() {
selenium = resolver.readFile("case-login.xls","Test-Login-001","prepare");
}
@Test(description="Test_Login_001 用户登录（成功）", groups={"用户登录"})
@Override
public void test() {
selenium = resolver.readFile("case-login.xls","Test-Login-001","test");
}
@Override
public void renew() { //用例文件 用例名称 状态位
selenium = resolver.readFile("case-login.xls","Test-Login-001","renew");
if(null != selenium) {
selenium.stop();//关闭浏览器
}
}
}
本帖最后由 ryugun 于 2012-3-2 17:55 编辑
上面的红字提及到了 测试用例有父类BaseTestCase
里面主要是初始化关键字等准备工作，以及preparetestrenew 标志位函数的定义
package com.XXXX.testcase;
import java.io.File;
import java.io.UnsupportedEncodingException;
import java.net.URLDecoder;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import org.dom4j.Document;
import org.dom4j.DocumentException;
import org.dom4j.Element;
import org.dom4j.io.SAXReader;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.testng.Assert;
import org.testng.annotations.AfterClass;
import org.testng.annotations.BeforeClass;
import com.XXXX.resolver.KeyWordsResolver;
import com.thoughtworks.selenium.Selenium;
/**
* 测试用例基类
*
* <p />初始化各种数据
*
*/
public abstract class BaseTestCase {
/**
* Log
*/
public static Logger logger = LoggerFactory.getLogger(BaseTestCase.class);
/**
* 状态标识位:初始化 状态
*/
public static final String FLAG_PREPARE = "prepare";
/**
* 状态标识位:测试点 状态
*/
public static final String FLAG_TEST = "test";
/**
* 状态标识位:恢复环境 状态
*/
public static final String FLAG_RENEW = "renew";
/**
* 状态标识位:全部 状态
*/
public static final String FLAG_ALL = "all";
/**
* 数据地图(控件路径、浏览器参数)
*/
protected Map<String, String> dataMap = new HashMap<String, String>();
/**
* 关键字地图
*/
protected Map<String, String> keyWordsMap = new HashMap<String, String>();
/**
* selenium对象
*/
protected Selenium selenium = null;
/**
* 关键字解析器
*/
protected KeyWordsResolver resolver = null;
继续BaseTestCase
/**
* 准备数据
* <p/>当用selenium来构造环境时，对于浏览器，准备环境与验证点之间存在2种关系（若非selenium来构造环境，忽略此项）
* <p/> 1、在准备环境的基础上不关闭浏览器直接进行验证点(验证点直接续用准备环境的浏览器)
* <p/> 此时，prepare()中无需关闭浏览器，在test()中获取selenium,关闭浏览器
* <p/> 2、准备环境与验证点相互独立，不存在续用关系,需要在prepare()与test()中分别关闭浏览器
* <p/>关闭浏览器：selenium = resolver.readFile("","","");selenium.stop();
*/
public abstract void prepare();
/**
* 测试验证点
* <p />注意：在子类中，必须为此方法加上TestNG的测试标签:@Test
* <p />建议：为避免运行测试套时启动过多的浏览器而占用系统资源，请务必在此方法的最后关闭浏览器
* <p />关闭浏览器：selenium = resolver.readFile("","","");selenium.stop();
*/
public abstract void test();
/**
* 恢复环境
* <p />恢复环境的步骤应该与准备环境、测试验证点没有耦合，它是单独的完整的:登陆-恢复环境
* <p />建议：当用selenium来清理环境时，为避免运行测试套时启动过多的浏览器而占用系统资源，请务必在此方法的最后关
闭浏览器
* <p />关闭浏览器：selenium = resolver.readFile("","","");selenium.stop();
*/
public abstract void renew();
本帖最后由 ryugun 于 2012-9-21 21:23 编辑
接着BaseTestCase
/**
* 初始化地图
* <p/>从xml里读取出对应的关键字，放入map里
*/
@SuppressWarnings("unchecked")
private void initMap(String xmlPath, Map<String, String> map) {
try {
SAXReader reader = new SAXReader();
Document confXml = reader.read(BaseTestCase.class.getClassLoader().getResourceAsStream(
xmlPath));
// 获得根节点
Element rootElement = confXml.getRootElement();
Element paret;
// 遍历一级节点
for (Iterator<Element> parets = rootElement.elementIterator(); parets.hasNext();) {
paret = parets.next();
for (Iterator<Element> childrens = paret.elementIterator(); childrens.hasNext();) {
Element children = childrens.next();
map.put(children.attributeValue("name"), children.attributeValue("code"));
}
}
} catch (DocumentException e) {
logger.error("初始化【" + xmlPath + "】出错：", e);
Assert.assertFalse(true); //强制断言
}
}
/**
* 类前方法(初始化数据以及准备测试环境)
*/
@BeforeClass
public void beforeClass(){
initMap(); //初始化地图
resolver = new KeyWordsResolver(dataMap, keyWordsMap); //初始化关键字解析器
prepare(); //准备数据
}
/**
* 类后方法(清除环境)
*/
@AfterClass(alwaysRun=true)
public void afterClass() {
renew(); //恢复环境
}
/**
* 读取xml文件,初始化地图
*/
private void initMap() {
File file = new File(formatPath(BaseTestCase.class.getResource("").getPath()));
if (!file.exists()) {
logger.error("找不到xml初始化文件，请检查文件路径！");
return;
}
String[] names = file.list(); //获取当前文件夹内所有的文件名称
for (int i = 0; i < names.length; i++) {
if (names.startsWith("locator") || names.startsWith("init")) {
initMap("data/" + names, dataMap);
continue;
}
if (names.startsWith("keywords")) {
initMap("data/" + names, keyWordsMap);
}
}
}
/**
* 格式化参数文件的路径
* @param path 当前java文件的路径
* @return path 格式后的字符串
*/
private String formatPath(String path) {
path = path.replaceAll("com/huaweisymantec/iget/omm/testcase/", "");
path = path.replaceAll("\\/", "\\\\");
path = path.replaceFirst("\\\\", "").trim();
path = path + "data\\";
try {
path = URLDecoder.decode(path, "UTF-8");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
return path;
}
}
------------------------------------------
下面贴上一个简单的工程。。里面jar包都不在，需要自己去下
工程里就是利用这个思想做的一个例子。
可以通过ant 运行build.xml来看效果，当然得需要把对应的jar包下载下来放进工程的lib里（selenium一系列的包，testng的包，读取excel的包jxl.jar,读取xml的dom4j.jar）
这个工程还存在一些问题，代码的设计还有些BUG，没详细解决，但具体思路大致就是这样。
ET测试
指南测试法(适合资料测试)通过阅读用户手册并严格按手册建议执行操作。
卖点测试法针对卖钱的特性（特别吸引客户的）进行测试。
地标测试法把重要特性作为地标，确定他们可能的先后顺序，然后执行应用程序从一个地标跳跃到另一个地标，探索应用程序。
极限测试法了解软件能承受的极限场景和不能承受的极限场景。考虑如何让软件发挥到最大程度？哪个特性会使得软件运行到其设计极限？哪些输入和数据会耗费软件最多的运算能力？等等。
遍历测试法以最快的速度遍历被测目标包含的每个对象，不追求细节，只求遍历，只检查那些明显的东西。
深夜测试法测试软件的使用高峰期,也要测试软件的空闲期.如:日志备份等任务。发现软件被业务使用空闲时的问题。
清晨测试法测试软件的启动过程及其脚本。
恶邻测试法在产品缺陷多的地方以及邻近区域进行测试。缺陷通常扎堆出现，因此这里强调对历史上缺陷密度高的特性进行反复测试。从“触发条件”、“问题根因”、“检查点”、“外部
环境”、“所做的操作”、“有限的资源”等探索视角进行探索测试。
博物馆测试法把很久没有更新的老功能与被测对象进行交互。
配角测试法只要场景提供了选择，就不选择所建议的而是选择和它相邻的或语义接近的；把不主要的功能与主要功能进行交互。
深巷测试法测试产品特性使用情况列表中排在最下面的几项特性，也就是最不可能被用到或最不吸引用户的特性。
通宵测试法连续不断的使用某种特性或将文件一致保持在打开状态，真正让运行时间足够长。
收藏家测试法创建一个可以产生最多输出数量的新场景。
长路径测试法选择离程序开始点尽可能远的特性开始,在尽可能多的程序中穿行,选择长路径而不是短的。
ET测试（继续）
超模测试法（适合GUI测试）只关心哪些表面的东西，关注界面可用性。
测一送一测试法考虑多个应用程序操作同一个数据或对象的场景测试,或者是测试并发情况下有没有冲突或错误。
取消测试法执行耗时的操作,然后过程中取消操作,检查取消后系统还能否继续工作;
或取消操作后再做相同的操作能否操作成果。
懒汉测试法测试默认值和默认配置。
强迫测试法反复执行同样的操作或不按特定顺序做事。
反叛测试法输入最不可能的数据或已知恶意输入或错误的顺序。
破坏测试法
输入恶意数据或状态破坏软件。在运行场景测试时，在资源调用处进行破坏活动。如业务执行过程中拔插网线、掉电、复位设备、禁用必需资源等去掉本次操作所依赖的的条件。
基于场景的ET-插入操作在执行规定场景测试操作过程中插入操作：增加比规定更多的数据；使用附加输入；访问新的界面。
基于场景的ET-删除操作每次只删除一个步骤来找到最短的可执行步骤。
基于场景的ET-替换操作用可以替换的步骤代替原有场景的步骤，先删除步骤再插入步骤。例如：用键盘快捷键代替鼠标操作。
基于场景的ET-重复操作重复单独的步骤或重复一组步骤来改变顺序，创建额外的变化。
基于场景的ET-数据替换用更大的数据和更小的数据来代替先前测试所使用的数据。
基于场景的ET-环境替换硬件替换；容器替换（如：浏览器和.net平台）；版本替换（更换老版本的浏览器）；修改本地设置。
混票测试法在测试某个过程时，中途插入其他场景，或跳转到另一场景进行操作，达到混合目的。
ET测试（继续）
出租车测试法通过不同路径(测试操作步骤路径/测试输入构造方式)达到同一个功能目的。
出租车禁区测试法通过不同路径(测试操作步骤路径/测试输入构造方式)达到同一个限制目的。
快递测试法分析并跟踪数据在被测系统内的处理过程，参与数据生命周期的每个阶段，测试和输入数据有接触的那些特性可能对数据做出的操作；如同一参数在不同的地方被引用重新计算得到另一个参数，在该参数达到边界值时，引用它的其他参数的计算是否正确；同一个变量在不同的地方显示，变量变化后，不同的显示地方有没有都同步刷新。
停车场测试法地标测试法和超模测试法结合体，第一轮测试不用看太深，重点在被测代码如何显示；第二轮再显示有错的地方运用其他ET方法，挖掘更深的bug。
上一版本测试法相对于上一版本，是否有配置丢失，是否有规格数变更导致的用户数据丢失，是否有特性丢失。
肥皂剧测试法其要点与电视中的肥皂剧如出一辙:源于真实生活、浓缩、夸张,类似于我们的故障注入测试，但是将所有的故障一次性注入进去，看看会发生什么。
软件生命周期中的测试阶段（不同测试阶段中的测试方法）
从coding--->交付产品
测试类型：单元测试（UT）---集成测试（IT）----系统测试（ST）---验收测试
本帖最后由 ryugun 于 2012-3-24 16:29 编辑
单元测试
u单元测试，又称模块测试，是针对软件设计的最小单元——程序模块，进行正确性检验的测试工作。
u单元测试主要关注每个具体单元模块内部的逻辑结构和功能是否正确，侧重于发现程序设计或实现的逻辑错误，基本属于白盒测试范畴。
u单元具有一些基本属性，如明确的功能、明确与其他部分的接口定义等，可清晰地与同一程序的其他单元划分开来。如：函数、模块、类或组件为基本测试单元。
由于单元本身不能独立运行，所以必须为每个单元测试开发驱动模块（Driver）和桩模块（Stub）以构成一个可运行的软件系统进行测试。
驱动模块：
l
接收测试数据
l
把数据传给（被测试）模块
l
显示或比较相关测试结果
桩模块：替代隶属于本模块（被调用）的模块，使被测对象得以运行
单元测试过程分为计划，设计和实现，执行，评估等几个步骤。
单元测试的测试用例主要是针对功能来设计的，有时也考虑非功能属性方面的要求（如资源泄漏，性能要求，
结构测试等）。
单元测试的用例的分析和设计依据是详细设计说明书，根据详细设计说明书中的描述进行测试用例的设计，主要使用白盒测试方法。
本帖最后由 ryugun 于 2012-3-24 16:33 编辑
集成测试
集成测试：把若干个经过单元测试的组件/模块/单元组装到一起的测试，主要目的是测试模块之间的接口
，以及被对象与系统其他部分的相互作用。
u集成测试依据软件概要设计说明书，通过对模块功能、接口设计进行分析，覆盖所有的功能项目，重点测试接口和边界。
根据被测对象的规模，集成测试分为：
l
模块内集成测试
l
子系统内集成测试
l
子系统间集成测试
根据测试过程中组合模块的方式，集成测试可分为：
l
非增式集成：又称一次性集成，对完成单元测试的所有模块在一起进行测试
l
增式集成：又称递增式集成，即逐次将未测试的模块与已测试的模块组合成较大的系统，边连接边测试
根据集成的过程还可分为：
自顶向下集成——沿控制层次自顶向下进行集成测试
自底向上集成——从程序模块结构的最底层模块开始集成测试
l
衍变式集成：增式和非增式两者结合
集成测试主要依据是软件概要设计说明书，一般不过多的考虑集成测试对象（子模块）内部的实现，通过对模块功能、接口设计进行分析，覆盖所有的功能项目，重点的接口、重点的边界进行重点测试。
为什么进行集成测试？
一个模块可能对另一个模块产生不利的影响
将子功能合成时不一定产生所期望的主功能
独立可接受的误差在组装后可能会超过可接受的误差限度
可能会发现单元测试中未发现的接口方面的错误
在单元测试中无法发现时序问题（实时系统）
在单元测试中无法发现资源竞争问题
目的：在模块组装后查找模块间接口的错误
自顶向下的集成方法是将模块按系统的程序结构，沿控制层次自顶向下集成。首先以主模块为所测模块兼驱动模块，所有直属于该模块的下属模块全部用桩模块对主模块进行测试；然后采用深度优先或宽度优先的策略，用实际模块替换相应的桩模块，再用桩代替它们的直接下属模块，与已测模块集成为新的子系统进行测试；直到所有的模块都被集成到系统并完成所有测试用例。
自底向上的集成方法是从程序模块结构的最底层模块开始集成测试；然后用实际模块替代驱动模块，与它已测试的直属子模块集成为子系统。为新的子系统配置驱动模块，进行新的测试。直到集成到主模块完成所有测试用例。
系统测试
系统测试：针对软件系统进行的整体测试，将软件系统在实际环境下运行，以验证系统是否正确实现了客户的需求
系统测试依据软件需求分析说明书，检验软件系统与需求规格说明符合的程度。通常采用黑盒测试方法。
系统测试包括功能性测试和非功能性测试，需要考虑不同的测试类型：
功能性
可靠性
效率性
可服务性
系统测试主要依据是软件需求分析说明书，检验软件系统与需求规格说明符合的程度，一般不考虑程序实现的内部逻辑，以检验输入输出信息为主，通常采用黑盒测试方法
验收测试
验收测试：通常由使用系统的用户来进行，同时系统的其他利益相关者也可能参与其中。
验收测试的目的是通过对系统功能、系统的某部分或特定的系统非功能特征进行测试，来确定系统是否满足客户需求并能够进行商用。发现缺陷不是验收测试的主要目标。
验收测试有下面几种典型的类型：
用户验收测试
运营测试
合同验收测试
现场（Field)测试（alpha and beta 测试）
本帖最后由 ryugun 于 2012-3-24 16:48 编辑
HLT和LLT的区别（）
LLT与HLT主要区别
测试依据不同
LLT测试依据是实现层面的需求
HLT测试依据是客户可见的需求
测试手段不同
LLT通常通过测试代码触发测试运行，运行环境通常为仿真环境
HLT通常通过外界命令或是事件触发测试运行，运行环境通常为真实设备
主导人员
LLT多为开发人员主导开展
HLT多为测试人员主导开展
其他说明
网络现状中，部分项目开展的ST活动，虽然是开发人员执行，但是测试依据和测试手段都和SDV一样，不能称之为LLT
参考：业界对不同测试阶段的定义
本帖最后由 ryugun 于 2012-3-24 16:58 编辑
HW IPD流程中LLT和HLT：测试活动
------------------------------|<--------LLT-------------->| |<------------HLT-------------|
| (low level test) | TR4| (high level test) |
测试活动：coding/review--->UT---->IT---->ST--->BBIT--->|--->SDV----->SIT(Beta)---->SVT
活动阶段
UT
IT
ST
BBIT
活动定义
Unit Test 单元测试
Integration Test集成测试
System Test系统测试
Building Block Integration and Test构建模块集成和测试
测试对象
通常是函数和语句，由开发个人行动，投入产出低
模块间接口，项目组级别，基本被裁剪
基本上是模块测试
项目组级别测试活动
系统的功能块（多个模块组合）
实际上BBIT基本等同SDV活动
本帖最后由 ryugun 于 2012-3-24 17:02 编辑
Wiki流行观点：LLT
------------------------------|<-LLT---->| |<------------HLT-------------|
| | |
测试活动：coding/review--->UT---->IT---->ST--->apha(Beta)---->UAT
UT
IT
ST
UAT
活动名称
Unit Test 单元测试
Integration Test 集成测试
System Test 系统测试
User Acceptance Test
用户验收测试
活动说明
UT是软件应用程序的一个最小可测试的部分。一个unit可以是一个程序(program)，一个函数(function)，一个过程(procedure)。
在面向对象的编程中，最小的unit是一个类的方法（method）。
IT测试目的是验证被测对象（组件，一群units）的功能、性能和可靠性方面的需求。
IT是一个“building block”方法，将一个验证过组件添加到一个已经验证过基础组件上，以便进行下一步的组件集成活动。
ST定义：对一个完整软件/硬件系统进行的测试，来确认是否满足特定需求。
测试方法：采用黑盒测试方法，ST不需要了解系统内部设计和逻辑关系。
区别：IT为了测试构成一个系统的组件之间不一致，或者软件和硬件之间不一致。ST是为了一方面为了发现组件间的缺陷，同时将多个组件作为一个整体来发现缺陷。ST包括负荷测试和压力测试，ST之后就是Alpha测试和Beta测试。
客户接收系统之前的测试活动，模仿正式使用情况，由客户或者最终用户进行测试，其目的是给客户信心。
本帖最后由 ryugun 于 2012-3-24 17:06 编辑
TPI模型：LLT定义
------------------------------|<-LLT---->| |<----HLT----|
| | | |
测试活动：coding/review--->UT---->IT---->ST------->AT
UT
IT
ST
AT
活动名称
Unit Test 单元测试
Integration Test 集成测试
System Test 系统测试
Acceptance Test
验收测试
活动定义
demonstrate that the program meets the requirements set in the design specification.
demonstrate that a logical series of programs meets the requirements set in the design specification.
demonstrate that the developed system or subsystems meet the requirements set in the functional and quality specifications.
demonstrate that the developed system meets the functional and quality requirements.
实施
开发者，实验室
开发者，实验室
开发者，（专门）实验室
用户/经理，仿真/模型环境
测试技术
主要是白盒技术
主要是白盒技术
通常使用黑盒技术
通常使用黑盒技术
测试对象
program
a logical series of programs
the developed system or subsystems
the developed system
测试退出评估/准则
1、过程目标达成情况
2、累计用例覆盖度
累计用例覆盖度实际上是一种测试进度的体现（我们缺省的认为用例的覆盖就是对规格的覆盖），用例覆盖度应该作为测试项目完成退出的一个重要指标（90％以上？）。
3、遗留缺陷分析
测试退出准则还有一个重要因素就是应该满足DI值。开发问题解决的力度不够，实际上会增加测试的成本，降低测试效率。
测试计划：回答我们如何安排测试，达到什么测试目标的问题；
测试需求分析：回答我们要测试什么的问题；
测试设计：回答我们如何实现测试的问题；
测试策略：回答我们如何组织测试的问题；
测试执行：回答产品质量如何的问题。
