-
selenium2.0关于python的常用函数
2015-02-12 14:24:20
selenium2.0关于python的常用函数（二）
(2013-05-15 14:05:19)新建实例driver = webdriver.Chrome()
1.获取当前页面的Url函数
方法：current_url实例：
driver.current_url
2.获取元素坐标
方法：location
解释：首先查找到你要获取元素的，然后调用location方法
实例：
driver.find_element_by_xpath("//*[@id='tablechart']/tbody/tr[14]/td[9]").location
3.表单的提交
方法：submit
解释:查找到表单（from）直接调用submit即可
实例：
driver.find_element_by_id("form1").submit()
4.获取CSS的属性值
- 方法：value_of_css_property(css_name)
- 实例：
- driver.find_element_by_css_selector("input.btn").value_of_css_property("input.btn")
- 5.获取元素的属性值
- 方法：get_attribute(element_name)
- 实例：
- driver.find_element_by_id("sellaiyuan").get_attribute("sellaiyuan")
- 6.判断元素是否被选中
- 方法：is_selected()
- 实例：
- driver.find_element_by_id("form1").is_selected()
- 7.返回元素的大小
- 方法：size
- 实例：
- driver.find_element_by_id("iptPassword").size
- 返回值：{'width': 250, 'height': 30}
- 8.判断元素是否显示
- 方法：is_displayed()
- 实例：
- driver.find_element_by_id("iptPassword").is_displayed()
9.判断元素是否被使用 - 方法：is_enabled()
- 实例：
- driver.find_element_by_id("iptPassword").is_enabled()
- 10.获取元素的文本值
- 方法：text
- 实例：driver.find_element_by_id("iptUsername").text
- 11.元素赋值
- 方法：send_keys(*values)
- 实例：
- driver.find_element_by_id("iptUsername").send_keys('admin')
- 注意如果是函数需要增加转义符u,eg.
- driver.find_element_by_id("iptUsername").send_keys(u'青春')
- 12.返回元素的tagName
- 方法：tag_name
- 实例：
- driver.find_element_by_id("iptUsername").tag_name
- 13.删除浏览器所以的cookies
- 方法：delete_all_cookies()
- 实例：
- driver.delete_all_cookies()
- 14.删除指定的cookie
- 方法：delete_cookie(name)
- 实例：deriver.delete_cookie("my_cookie_name")
- 15.关闭浏览器
- 方法：close()
- 实例：driver.close()
- 16.关闭浏览器并且推出驱动程序
- 方法：quit()
- 实例：driver.quit()
- 17.返回上一页
- 方法：back()
- 实例：driver.back()
- 18.设置等待超时
- 方法：implicitly_wait(wait_time)
- 实例：driver.implicitly_wait(30)
- 19.浏览器窗口最大化
- 方法：maximize_window()
- 实例：driver.maximize_window()
- 20.查看浏览器的名字
- 方法：name
- 实例：drvier.name
-
selenium2.0关于python的常用函数
2015-02-12 14:24:20
selenium2.0关于python的常用函数（二）
(2013-05-15 14:05:19)新建实例driver = webdriver.Chrome()
1.获取当前页面的Url函数
方法：current_url实例：
driver.current_url
2.获取元素坐标
方法：location
解释：首先查找到你要获取元素的，然后调用location方法
实例：
driver.find_element_by_xpath("//*[@id='tablechart']/tbody/tr[14]/td[9]").location
3.表单的提交
方法：submit
解释:查找到表单（from）直接调用submit即可
实例：
driver.find_element_by_id("form1").submit()
4.获取CSS的属性值
- 方法：value_of_css_property(css_name)
- 实例：
- driver.find_element_by_css_selector("input.btn").value_of_css_property("input.btn")
- 5.获取元素的属性值
- 方法：get_attribute(element_name)
- 实例：
- driver.find_element_by_id("sellaiyuan").get_attribute("sellaiyuan")
- 6.判断元素是否被选中
- 方法：is_selected()
- 实例：
- driver.find_element_by_id("form1").is_selected()
- 7.返回元素的大小
- 方法：size
- 实例：
- driver.find_element_by_id("iptPassword").size
- 返回值：{'width': 250, 'height': 30}
- 8.判断元素是否显示
- 方法：is_displayed()
- 实例：
- driver.find_element_by_id("iptPassword").is_displayed()
9.判断元素是否被使用 - 方法：is_enabled()
- 实例：
- driver.find_element_by_id("iptPassword").is_enabled()
- 10.获取元素的文本值
- 方法：text
- 实例：driver.find_element_by_id("iptUsername").text
- 11.元素赋值
- 方法：send_keys(*values)
- 实例：
- driver.find_element_by_id("iptUsername").send_keys('admin')
- 注意如果是函数需要增加转义符u,eg.
- driver.find_element_by_id("iptUsername").send_keys(u'青春')
- 12.返回元素的tagName
- 方法：tag_name
- 实例：
- driver.find_element_by_id("iptUsername").tag_name
- 13.删除浏览器所以的cookies
- 方法：delete_all_cookies()
- 实例：
- driver.delete_all_cookies()
- 14.删除指定的cookie
- 方法：delete_cookie(name)
- 实例：deriver.delete_cookie("my_cookie_name")
- 15.关闭浏览器
- 方法：close()
- 实例：driver.close()
- 16.关闭浏览器并且推出驱动程序
- 方法：quit()
- 实例：driver.quit()
- 17.返回上一页
- 方法：back()
- 实例：driver.back()
- 18.设置等待超时
- 方法：implicitly_wait(wait_time)
- 实例：driver.implicitly_wait(30)
- 19.浏览器窗口最大化
- 方法：maximize_window()
- 实例：driver.maximize_window()
- 20.查看浏览器的名字
- 方法：name
- 实例：drvier.name
-
【转载】软件测试全景图
2013-10-17 11:46:23
-
测试课程设置
2011-08-11 11:29:05
-
测试设计中需要考虑的22种测试类型
2011-08-10 17:58:35
-
LoadRunner监控Linux与Windows方法
2011-08-10 17:45:40
-
s1
2011-08-04 11:57:24
-
四级软件测试工程师考试大纲
2011-02-16 13:00:07
-
2011年度软考软件测评师测试技术辅导汇总
2011-02-16 12:35:00
-
2011软件水平考试软件测评师测试技术辅导
2011-02-16 12:22:42
软件功能测试用例的书写方式 软件测试功能性测试用例
1. 测试的来源，即测试的需求
测试用例的主要来源有：
1) 需求说明”及相关文档
2)相关的设计说明(概要设计，详细设计等)
3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)
4)已经基本成型的UI(可以有针对性地补充一些用例)
简而言之，所有你能得到的项目文档，都尽量拿到。 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。
2. 用例的组织方式
不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。
用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组 织在一起。
在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未 执行”的用例的状态，共3种状态。
即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。
至于用例文件格式，可以是.DOC或.XLS(如果有专门的测试用例管理工具另当别论)。
3. 用例与其他材料的关联方式，即如何解决用例跟踪的问题 测试用例面临的比较大的风险有：
需求的变更、设计的修改、需求的错误和遗漏等等。
由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的 变更势必引起测试用例的变更。
如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个(编号的)功 能点和测试用例间的关联关系。
这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增 加了新的功能点。
重要和困难的是，不手头的资料和信息一定要是最新的。
软件测试用例的设计-提高测试覆盖率 软件测试
说到测试用例的设计，我想每个有过测试经历的测试工程师都会认为很简单，不就是：按需求或概要设计，得到软件功能划分图，然后据此按每个功能，采用等价类划分、临界值、因果图等方法来设计用例就行了。
但事实上撇开测试数据的设计不谈，仅就测试项来说，我们发现，对同一个项目，有经验的测试人员，在写用例或测试时总会有更多的测试考虑点，从而发现更多的问题;而有些测试人员测试用例的撰写却只有那么三板斧，表面看好象已经把页面所有信息的测试都考虑到了，实际上却还是遗漏了大量测试覆盖点，导致其测试出来的程序总是比较脆弱。
究其原因，我觉得还是测试用例的撰写水平不到位，更确切地说是测试用例的覆盖度太低。说实话我认为系统测试用例真正做到100%覆盖是很难的。难道说按设计中的功能划分，每个功能都写到了这个用例就覆盖完整了?错，这还远远不够。因为我们知道还有大量的内部处理、转换、业务逻辑、相互影响的关系等都是需求或设计中所不会点明的。而这些一方面需要靠测试人员对项目本身的了解，另一方面要靠测试人员的经验，来一一找到这些隐藏点并予以测试，才能真正地保证我们的测试覆盖度。
所以本文抛开具体的测试数据设计方法，主要从测试覆盖度的角度来介绍用例设计时，如何才能考虑地更周全，如何才能将隐藏的测试项一一找出，从而使我们的测试更全面更完整。
想法虽然美好，可是毕竟每个测试的项目都是各不相同，针对不同项目我们的经验也会告诉给我们不同的想法，这些想法通常很感性，很难用严密的逻辑理论来把它升华。因此本文的内容仍是很简陋且不成熟，只是希望能以本文为砖，引起大家的思考，一起来补充完善，以使我们的测试用例设计水平不断提高。
测试用例的切面设计
所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。
1、功能点切面
这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能;或一个功能点分多页;或多个功能点合成一页来进行用例的撰写。
2、特定切面
除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面，可以使我们的用例阅读性、理解性、操作性更强。
3、隐含切面
这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。
(1)、后台功能
常见的如一些定时自动启动的服务;以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的，但许多在需求设计中还是会提到，也有一些比较细小的功能可能会被忽略，就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员，写出来的用例就完全是两个层次的。
(2)、完整业务流程的测试
我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。
事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再完全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。
(3)、某种特定情况下的系统运行
这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾一天、月头一天、年尾一天、年头一天，对所有相关功能中的日期处理进行测试;又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如;再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。
(4)、其它相关系统
即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数;以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时就不需要单独划分测试项;若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。
(5)、除功能测试外的其它测试类型
包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。
所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。
做好测试计划和测试用例的工作的关键是什么? 软件测试
软件测试每周一问：测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法?
会员godn_1981的精彩回答：
这个问题问的非常好，也确实是很多人有过切肤之痛的问题，对我来说，我也一直在苦苦追寻这个问题的答案，现在我不能说完全找到了，只能说把自己的心得分享一下，希望大家的测试计划和测试用例不再是一个摆设。
(一) 先说测试计划吧
诚如magic_zhu所言，现在很多测试人员没意识到测试计划的重要性，很多时候测试计划成为一纸空文，其根本原因在于测试计划缺乏可执行性，也正是因为测试计划缺乏可执行性，导致下一次写计划的时候非常草率，甚至不写，就算写了也是一个花架子应付领导，这样形成了一个恶性循环，久而久之，测试计划纯属一个摆设，我们很多从业者不写测试计划，其理由是反正写了也不能按照计划执行，这种理由真的很荒唐可笑，这是典型的因噎废食，因为你的计划执行性差就不写?这样只能使测试更加失去控制，使你的测试过程彻底无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。
我觉得这个问题的解决方案不是不写，而是想办法写得更好，更有实效性，执行性。这个是问题的关键。
一个好的测试计划是用来计划测试的，指导整个测试过程。所以一个好的测试计划一定是可以指导测试的，就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。
作为一个测试计划来讲，核心的三个要素是时间，资源，范围。(这句话摘自微软的软件测试培训材料)，时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。
除以上提到的3项之外，还有比较重要的项目有策略(具体就是怎么测)、风险控制(一旦有问题采取什么应急措施)等项目
要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面：
a. 上面提到的三要素不能少
b. 测试策略一定要交待清楚，就是大概怎么测试
c. 需要其他人员(部门)协调的，要交待清楚
d. 在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数
e. 测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚
f. 测试计划中的时间段不宜太长(最好以day为单位)，太长就比较模糊，不好度量，不好check
g. 一定要有风险控制，要不然计划缺乏可执行性
h. 计划写完之后不是装在兜里，要组织PM和Dev进行评审
i. 要不断更新计划，记住：每个计划都是动态的，不是一成不变的
(二) 再说测试用例
和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试?这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上，至于如何选择回归测试用例，我曾经写过另一篇文章，欢迎查阅。
下面我就个人体会谈谈做好测试用例的关键。
首先，在做用例之前，要做两件事情。
第一， 透彻了解程序(需求和架构)。
第二， 做一个正式的测试设计(最好文档化)。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设计，具体的设计方法就是那几种(郑老的书上写的很清楚)
一般来说，设计一个比较实用的测试用例，注意如下几个方面：
a. 选用好的用例管理工具(这个很重要，千万不要用word，excel)
b. 用例一定要及时更新(补充新的想法，删除过时的需求)
c. 做好用例分级
d. 做好用例评审，写用例之前可以征询相关人员的意见
e. 可以考虑结对编写，这个是不错的主意
f. 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等
g. 注意把握适当的颗粒度
软件测试流程之测试用例的设计与测试执行流程 软件测试
高效设计测试用例培训结束了，在上机练习的过程中，给他们穿插了sougo输入法的项目测试。之所以选择 sougo输入法，是因为大家对它比较熟悉，不用再熟悉其业务了。而且sougo输入法从1.0.14到现在的4.0有多个版本。每个版本更新前都会有当前版本更新的bug列表，和新增功能点列表。特别适合我们模拟实际的测试过程。这次我们测试使用TD从需求管理到缺陷管理的整个测试过程的管理。经过大家的努力和配合，我们采取边做测试边总结的方法，最后总结出测试工作中的工作流程，下面就是总结出的测试流程，大家看到后多多交流。
一、需求分析：
1、列出测试需求(根据需求规格说明书、帮助文档、软件的demo版，利用测试大纲法，以每个窗体为对象，每个窗体里面的控件为单位列出测试功能点。)
2、需求等级划分，依据需求内容的重要程度划分为：高、中、低等。
3、划分需求类型，(功能性、易用性、兼容性等)。
4、评审需求(软件不熟悉的情况下采取以集体的形式整体讨论的方法评审需求或设立专人负责评审)。
5、需求列入TestDirector(评审后的结果在TestDirector要有体现)。
二、用例设计：
1、根据功能点确定人员分工，具体的功能点分配给具体的组员。
2、测试用例的编写，借助功能演示demo、前一阶段所编写的测试功能点等编写测试用例。
3、要求组员对自己负责的功能点选择具体的设计测试用例的方法。
一般选择方法顺序：在考虑好被测试软件本身的特性后，一般首先边界值挑选最具有代表性的数据;然后使用等价类进一步补充;如果要考虑各功能的输入输出关系可以使用因果图、判定表法;但如果输入太多，可以使用正交排列法选择减少测试用例，并且是测试数据均匀分布。这些理性方法都使用完后，在测试执行阶段，可以使用随机测试法或者错误猜测方法进一步丰富你的测试用例。
4、针对所设计的用例对软件的功能点(以及其他类型的需求)进行需求覆盖。
我们列测试需求的最主要目的，就是为了完成对需求的覆盖，所以这个是对每一个设计测试用例的人员的基本要求。
5、用例评审，优化用例的数量确保用例的质量(设定专人评审)。
6、评审后写入TestDirector中。
7、挑选冒烟测试用例(抽取用例总数的10%~20%左右进行冒烟测试来反映基本功能)。
三、测试执行：
测试执行工作应尽量做到详细，依据测试计划里面的测试的整体安排，但是因为根据实际工作进度要做适当调整。一般情况是当天晚上前安排好明天的具体工作，具体任务可以以测试用例的数量来衡量。测试组长的几个重要工作步骤：
1、确认人力以及硬件资源是否到位，测试开启时间是否和测试整体计划相一致。
2、按照测试计划着手准备具体的测试工作。
3、在TD中，Test Lab里面设置以天为单位安排组员当天的应完成的用例，以及利用TD分析功能总结当天执行用例的情况。
4、指导组员工作，解决组员工作遇到的疑难问题
5、做好审查工作，监督组员工作
6、做好全组当天执行情况的总结
用例执行通过情况、发现bug数量、以及在各个模块中的分布情况等
7、将当天任务的执行情况书面化呈报上级领导
阶段任务完成后书写整个阶段的测试总结报告衡量当前版本软件的质量以及相关的发布问题。
四、下一版本的工作安排：
根据软件更新功能的多少分为两种情况：
1、一种是软件更新功能较少(新增加功能点是前一版本总功能的%5以内)，执行回归测试，根据新的功能点增加相关的需求和测试用例，确定新的功能点安排相关人员执行新加的测试用例;
2、另外一种情况是软件的新增更能点较多，则按照新的系统测试执行，首先进行冒烟测试，通过后进行详细的系统测试，测试过程中重点测试上一版本出现的缺陷(返测)、新增功能以及修改缺陷新增功能所影响到的模块。
新本版出现，总体按照测试执行阶段的测试工作流程进行测试同时注意特殊问题特殊处理。
五、提交缺陷(bug)
提交的缺陷需要测试部门专门人审查，通过审查后的缺陷，提交的TD中。主要审查下面几个方面：
1、发现的问题是否是缺陷(bug)
2、是否是重复的缺陷(bug)
3、缺陷(bug)程度的优先级是否合理
4、缺陷(bug)修复情况
看到很多有关测试流程以及测试用例设计的书籍，只是零散的测试知识，但是没有可操作性。希望上面列出的测试用例设计以及测试执行每个阶段的工作的步骤，有利于你更快更有效的进行软件测试工作。
从软件测试用例看测试的问题及变化 软件测试
对于一个测试人员来说测试用例的设计与编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是功能上都有一个明晰的把握。如何系统、结构的对用例加以规范将直接影响到其后的测试效率和效果，同时测试用例也将用来控制软件的整体执行覆盖，对最后的测试结果给出一种量化的评估标准。
一、问题：
许多测试类的书籍都有大幅篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图，判定表等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法真正有效的提高测试效率，并且我们也没有足够的时间和资源编写完备的用例。通常我们只能依靠以前项目的用例编写经验(或习惯)，希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。
当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：
* 从此几乎很少被执行
* 已经与程序的实现发生了冲突(界面变动，功能变动)
* 执行用例发现的bug很少
* 根本没有时间为新的功能需求增补用例
* 有时间补充，但用例结构越来越乱
* 特性的用例与通性用例之间联系不明确(以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化)
知道怎样执行这个用例，但它要说明什么呢?(多数用例给我们的感觉是只见树木，不见森林，只说明某一功能的实现，无法串起)
通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。
但没有用例或简略用例的编写我们又会舒服很多么?不言自明，谁也不想倒退发展。
二、原因：
事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：
1、没有适合的规范
“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、指导步骤和书本上的定义，但它适合我们当前的项目么?
每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好?
在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。我们有太多经验，但却没有形成适合的规范。
2、功能与业务的分离
我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。
边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。
复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)，只能自己添加note向开发人员指出可能出错的源头。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。
用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。
3、测试未能跟上变化
变化!想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢?当地区特性，软件版本越来越多的时候，测试是否在积极响应呢?变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。
对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。
疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法及时发现。
永远是变化决定我们的下一步工作，这也是混乱的开始
三、可能的解决办法：
上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。分析错误并不能给我们带来成功，而成功的特质也不会尽为相同。所以在这里我希望以探讨的方式提出一些可能的解决办法，不拘泥形式，以结果来确定，最适合的就是最好的。
1、测试驱动开发，用例指导结果，数据记录变化
“测试驱动开发”(TDD)是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效(Work)更洁净(Clean)，“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。
首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80%以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。
如何在黑盒测试中做到测试驱动开发?我认为可以从用例级别做起，以业务用例指导实现的结果。
开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很全面的指出应该实现怎样的结果，这就使得从业务到功能出现一个“阅读上的障碍”，如果最后发现程序错了还需返工，这样耗费的人力物力就非常大了。测试人员和最终用户不用过分关心软件实现的细节，所以以业务用例驱动开发，就是一个比较好的方法。给出一个明确的预期结果，指导开发人员如何界定是否达成目标，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。
业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会出错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。
我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段(业务段与程序中以窗体或页面的划分是不一样的)，使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。
再进一步的话“数据库”就开始涉及到程序内部的接口，属于单元和集成测试，这需要开发人员的配合。
2、为用例标明时间(版本)和优先级
为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。
为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。
3、功能用例与业务用例分开组织
为业务用例单独开辟出一种分类，将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作(例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理?)。
4、审核用例，结对编写
测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例(前提是你有两个以上的测试人员)，内部审核。
测试用例不是自己编写自己执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理负担，提高组员的参与积极性。
四、发展
上面的这些解决方法只是一种建议，具体如何实施到项目中还需根据情况而定。同时即使我们正在积极的寻求改变，我们还是会碰到无数的新问题和新苦恼，也许会比以前更为众多，这是我们必须付出的。
可以看到测试的发展方向很多很广，即使传统的黑盒测试并不是毫无新意，高级的测人员必须同时在测试技巧和专业领域方面都有很高的“修为”。测试工作怎样更适合我们而发展，将给予我们更多的思考。
使用NModel自动生成测试用例 软件测试
在前面的网站自动化系统里面，大概聊了下如何结合Selenium生成的代码和VSTT创建一个简单的自动化系统。虽然在文章网站测试自动化系统—基于Selenium和VSTT、数据驱动测试、在测试代码中硬编码测试数据里，我讲了一些封装代码以及测试数据的技巧，规避后续开发过程中，程序员修改代码时，对测试程序带来的影响。但是每次程序员做出大的改动的时候，测试人员还是要修改大量的测试代码，更糟糕的是，每次大的改动，又涉及到测试覆盖是否足够的问题。为了规避类似的风险，以及帮助测试人员创建尽量多的测试用例，有些人提出了模型驱动测试的概念。
模型驱动测试的想法和飞机的风洞测试差不多，即根据功能需求说明书，对要测试的程序先建立一个模型，然后有另外一个程序分析这个模型，产生测试用例。就好比为了验证新飞机的气动布局，不可能建一个全比例的飞机，去测试它的布局是否合理;而是建立一个小的飞机模型，模型的气动布局和整机的布局是一致的。飞机模型建好以后，才放到风洞里面测试一下。
市面上已经有几个做模型驱动测试的工具了，这里我用的是NModel，本来想拿SpecExplorer尝一下鲜的，但最后发现这个想法太贵了—需要安装了Visual Studio 2010才能使用“免费”的SpecExplorer。你可以在这个网页里下载 NModel：
http://nmodel.codeplex.com/
在NModel中，测试人员使用C#创建程序的模型，模型创建的原理是：
1.程序是用来处理数据的，数据也可以称作状态(State);
2.用户通过程序提供的操作界面来处理数据，操作界面也可以称作动作(Action);
3.数据的更动 又反过来影响一些动作是否可以执行。
比如说，使用Word的时候，刚启动程序时是没有任何数据的，这个时候有些动作，例如“保存”是禁用的。当用户通过“新建”这个动作创建了一个新文件(数据)，这个新文件反过来激活“保存”动作。
因此当测试人员建模时，他要做的工作就是将程序的动作和状态抽象出来，并且描述动作和状态相互影响的过程。
来看一个例子，假如现在要测试一个用户登录程序，登录界面就是一个输入用户名和密码的文本框，而程序支持的用户有两种：管理员和授权用户。
先来做第一步，将动作和状态抽象出来，程序的状态应该包括：
1.程序状态：运行状态和未运行状态。
2.用户类型：管理员和授权用户。
3.密码：正确的密码和错误的密码。
4.登录状态：成功登录和登录失败。
动作应该包括：
1.登录：即用户在界面上输入用户名和密码。
2.注销。
第二步，编写C#?程序建模。
状态已经抽象出来了，在NModel里面，抽象出来的状态一般是用枚举值表示的。
MILY: 'Courier New'">public enum ModeState { Initializing, Running }
public enum User { Authenticated, Administrator }
public enum Password { Correct, Incorrect }
public enum LoginStatus { Success, Failure }
接下来模拟动作：
[Feature("Login")]
public static class Login
{
public static Map
[Requirement("Send username and password to the server to log in.")]
[Action]
public static void Login_Start(User user, Password password)
{
if (password == Password.Correct)
ActiveLoginRequests = ActiveLoginRequests.Add(user, LoginStatus.Success);
else
ActiveLoginRequests = ActiveLoginRequests.Add(user, LoginStatus.Failure);
}
public static bool Login_StartEnabled()
{
return WebSiteModel.State == ModeState.Running;
}
public static bool Login_StartEnabled(User user)
{
return !ActiveLoginRequests.ContainsKey(user) &&
!WebSiteModel.UsersLoggedIn.Contains(user);
}
[Requirement("It should be possible to log out from any page")]
[Action]
public static void Logout(User user)
{
WebSiteModel.UsersLoggedIn = WebSiteModel.UsersLoggedIn.Remove(user);
}
public static bool LogoutEnabled()
{
return WebSiteModel.State == ModeState.Running;
}
public static bool LogoutEnabled(User user)
{
return WebSiteModel.UsersLoggedIn.Contains(user);
}
}
上面的代码稍微解释一下，标注了[Action]的函数，就是抽象出来的程序所支持的动作，例如Logout;而在动作函数名后面加上Enabled的函数，是NModel用来判定指定的动作是否可以执行，例如LogoutEnabled函数。
Feature属性，我们现在不讲，NModel用这个属性来标识一个大的功能。
另外要注意的是，在NModel里面，集合Set、Map是不可变的，即创建好了以后，就不能从里面删除和添加新元素了。每一次修改都会创建一个新的Set、Map实例。所以你会看到类似下面的用法：
ActiveLoginRequests = ActiveLoginRequests.Add(user, LoginStatus.Success);
最后，你需要采用一个工厂模式的方式，告诉NModel分析哪一个Feature，创建测试用例
public class WebSiteModel
{
public static ModeState State = ModeState.Initializing;
public static ModelProgram CreateLoginModel()
{
return new LibraryModelProgram(typeof(WebSiteModel).Assembly,
"TrainMode", new Set
("Login")); }
[Action]
public static void Initialize()
{
State = ModeState.Running;
}
public static bool InitializeEnabled() { return State == ModeState.Initializing; }
public static Set
UsersLoggedIn = Set .EmptySet; }
编译通过以后，先用NModel提供的图形化模型验证工具查看一下生成的模型是否正确。NModel自带的mpv.exe是用来验证模型的，但是 mpv.exe使用到一个图形布局程序GLEE需要单独下载，下载后，将Microsoft.GLEE.*.dll拷贝到NModel的bin文件夹里，就可以执行mpv.exe了。
使用下面的命令查看生成的模型：
"d:\Program Files\NModel\bin\mpv.exe" /r:TrainMode.dll TrainMode.WebSiteModel.CreateLoginModel
生成的模型应该如下图所示：
下图是放大后的结果：
如果查看模型以后，觉得没有问题，就可以生成测试用例了，这里先生成手工的测试用例，下一篇再介绍如何生成自动化的测试用例。
"d:\Program Files\NModel\bin\otg.exe" /r:TrainMode.dll /f:scenario.txt TrainMode.WebSiteModel.CreateLoginModel
下面是生成的测试用例:
TestSuite(
TestCase(
Initialize(),
Login_Start(User("Authenticated"), Password("Correct")),
Login_Start(User("Administrator"), Password("Incorrect")),
Logout(User("Authenticated"))
),
TestCase(
Initialize(),
Login_Start(User("Administrator"), Password("Correct")),
Login_Start(User("Authenticated"), Password("Correct")),
Logout(User("Administrator")),
Logout(User("Authenticated"))
),
TestCase(
Initialize(),
Login_Start(User("Administrator"), Password("Incorrect")),
Login_Start(User("Authenticated"), Password("Incorrect"))
),
TestCase(
Initialize(),
Login_Start(User("Authenticated"), Password("Incorrect")),
Login_Start(User("Administrator"), Password("Correct")),
Logout(User("Administrator"))
),
TestCase(
Initialize(),
Login_Start(User("Administrator"), Password("Incorrect")),
Login_Start(User("Authenticated"), Password("Correct"))
),
TestCase(
Initialize(),
Login_Start(User("Administrator"), Password("Correct")),
Login_Start(User("Authenticated"), Password("Incorrect"))
),
TestCase(
Initialize(),
Login_Start(User("Administrator"), Password("Correct")),
Logout(User("Administrator")),
Login_Start(User("Authenticated"), Password("Correct"))
),
TestCase(
Initialize(),
Login_Start(User("Authenticated"), Password("Correct")),
Logout(User("Authenticated")),
Login_Start(User("Administrator"), Password("Correct"))
),
TestCase(
Initialize(),
Login_Start(User("Administrator"), Password("Correct")),
Logout(User("Administrator")),
Login_Start(User("Authenticated"), Password("Incorrect"))
),
TestCase(
Initialize(),
Login_Start(User("Authenticated"), Password("Correct")),
Login_Start(User("Administrator"), Password("Correct")),
Logout(User("Authenticated")),
Logout(User("Administrator"))
),
TestCase(
Initialize(),
Login_Start(User("Authenticated"), Password("Incorrect")),
Login_Start(User("Administrator"), Password("Incorrect"))
),
TestCase(
Initialize(),
Login_Start(User("Authenticated"), Password("Correct")),
Logout(User("Authenticated")),
Login_Start(User("Administrator"), Password("Incorrect"))
)
)
LoadRunner中参数化中参数迭代规则详解
Each Occurrence
每次遇到参数就进行更新。
多次使用同一参数，而且没有什么关联，例如随机数。
Each Iteration
每次迭代时发生更新。 如果参数出现几次，虚拟用户用同一个数值。
适用同一个关联的参数。
Once
所有的地方都用同一个数值，包括所以的迭代。
文件类型参数分派方法
Sequential
按照顺序访问。
MILY: StoneSerif; FONT-SIZE: 12pt" lang=EN-US>
更新方式
Sequential
例子
1.
Each Iteration
所有用户每次迭代同时取下一个数值。
All the Vusers use Kim in the first iteration, David in the second iteration, Michael inthe third iteration, etc.
2.
Each Occurrence
所有用户每次遇到同时取下一个数值，即使在同一个迭代。
All the Vusers use Kim in the first occurrence, David in the second occurrence,Michael in the third occurrence, etc.
3.
Once
所有用户第一次迭代时同时取第一个值，该用户所有的子迭代值不变。
If you specified Once, all Vusers take Kim for all iterations.
First Name
Kim
David
Michael
Jane
Ron
Alice
Ken
Julie
没有足够的值，从第一行开始重新取值。
Random：每个虚拟用户开始运行时安排随机的数值。
更新方式
Random
1.
Each Iteration
每次迭代时，随机从数据表中取数。
2.
Each Occurrence
每次遇到随机取一个数值，即使在同一个迭代。
3.
Once
第一次迭代时随机取值，改用户所有的子迭代值不变。
Unique
The Unique method assigns a unique sequential value to the parameter for
each Vuser.
更新方式
Unique
例子
1.
Each Iteration
每个用户每次迭代时，虚拟用户取下一个不同的数值。
If you specified Each Iteration, for a test run of 3 iterations, the first Vuser takes Kim in the first iteration,David in the second, and Michael in the third. The second Vuser takes Jane, Ron, and Alice. The third Vuser,Ken, Julie, and Fred.
2.
Each Occurrence
每个虚拟用户每次遇到取一个新的不同的数值，即使在同一个迭代。
lr自己决定。
3.
Once
每个第一次迭代时取不同值，该用户所有的子迭代值不变。
If you specified Once, the first Vuser takes Kim for all iterations
the second Vuser takes David for all iterations, etc.
数据必须足够，例如20个虚拟用户，5次迭代，至少要有100个数据。
性能测试工具Loadrunner中日志参数的设置与使用
一、Run-Time Setting日志参数的设置
在loadrunner 的vuser菜单下的Run-Time Setting的General的LOG选项中可以对在执行脚本时Loadrunner对日志 的操作行为进行定义，下面我们在逐一介绍：
1、 Enable logging启用日志记录
如果选中该选项Loadrunner在执行脚本时，进行日志的记录，否则不记录日志
2、 Send messages only when an error occurs 仅在出错时发送消息
也称为 JIT (实时)消息传递，仅当错误发生时才写入日志，选择该选项后则可以设置高级选项，指明日志缓存的大小，loadrunner默认的日志到小为1k
3、 Always send messages
始终发送消息
4、 Standard log
标准日志：创建在脚本执行期间发送的函数和消息的标准日志，供调试时使用。
对于大型负载测试 场景、优化会话或配置文件禁用此选项。
如果日志记录级别设置为“标准”，当把脚本添加到场景、会话步骤或配置文件
中时，日志记录模式将被自动设置为“Send messages only when an error occurs”。但是，如果日志记录模式被禁用或者设置为“扩展”，则将脚本添加到场景、会话步骤或配置文件中将不会影响其日志记录设置。
5、 Extended log-----Parameter substitution
参数替换：选择此选项可以记录指定给脚本的所有参数及其相应的值
当脚本进行参数化、插入事务、关联等优化后，在执行脚本过程中，参数化的值、事务所耗时间、关联函数取出的变量值均会在日志中输出，这个选项对调试脚本查看参数化取值、关联取值是否正确有着重要的作用
6、 Extended log-----Data returned by server
选择此选项可以记录服务器返回的所有数据。
Loadrunner会将所有对服务器发出请求后的response情况记录在日志中，从这个日志中可以查看到服务器对请求的回应是否正确，在使用关联取值时往往需要到该日志中查看需要关联的值，从而确认所取数据左右边界。
7、 Extended log-----Advanced trace 高级跟踪
选择此选项可以记录 Vuser 在会话期间发送的所有函数和消息。
调试 Vuser 脚本时，该选项非常有用。
二、日志函数的使用
Loadrunner提供了一下几个message函数：
1、lr_message
int lr_message (const char * format, exp1, exp2,...expn.);
中文解释：lr_message函数将信息发送到日志文件和输入窗口。在VuGen中运行时，输入文件为output.txt。
例如：
char* abort="aborting";
lr_message ("login failed: %s", abort);
在日志中将会看到:login failed: aborting
2、lr_log_message
int lr_log_message (const char * format, exp1, exp2,...expn.);
中文解释：lr_log_message函数将消息发送到Vuser或代理日志文件(取决于应用程序)，而不是发送到输出窗口。通过向日志文件发送错误消息或其他 信息性消息，可以将该函数用于调试。
3、lr_error_message
int lr_error_message (const char *format, exp1, exp2,...expn. );
中文解释：lr_error_message函数将错误消息发送到输出窗口和Vuser日志文件。
如果Run-time settings > General > Miscellaneous >Continue on error未被选中，当脚本执行到此处时将终止执行，这个函数所输出的错误级别较高的信息，所以一般情况下如果使用该函数时选中Continue on error
4、lr_output_message
Loadrunner中若干message函数的使用方法详解
Loadrunner提供了若干message函数，以在脚本回放中和脚本运行中，对外输入信息，主要的函数有：
【lr_message】
int lr_message (const char *format, exp1, exp2,...expn.);
中文解释：lr_message函数将信息发送到日志文件和输入窗口。在VuGen中运行时，输入文件为output.txt。
【lr_log_message】
int lr_log_message (const char *format, exp1, exp2,...expn.);
中文解释：lr_log_message函数将消息发送到Vuser或代理日志文件(取决于应用程序)，而不是发送到输出窗口。通过向日志文件
发送错误消息或其他信息性消息，可以将该函数用于调试。
【lr_error_message】
int lr_error_message (const char *format, exp1, exp2,...expn. );
中文解释：lr_error_message函数将错误消息发送到输出窗口和Vuser日志文件。要发送不是特定错误消息的特殊通知，请使用lr_output_message。
【lr_output_message】
int lr_output_message (const char *format, exp1, exp2,...expn.);
中文解释：lr_output_message函数将带有脚本部分的行号的消息发送到输出窗口和日志文件。
【lr_vuser_status_message】
int lr_vuser_status_message (const char *format);
中文解释：lr_vuser_status_message函数向控制器或优化模块控制台的vuser窗口的“状态”区域发送字符串。它还将该字符串发送
到vuser日志。从VuGen运行时，消息被发送到output.txt。
如何在LoadRunner中监控oracle数据库
环境相关信息概述：
LoadRunner 9.0
Sitescope 9.0
Windows 2003
Oracle database 10g
1. 使用LR自带的监控引擎
1.1.在LR的controller上安装oracle客户端
这一步就不用说了，安装直接Setup，安装就OK了。
1，安装完后，先配置一下Net Configuration Assistant。记住配置的服务名。
配置成功会显示：正在连接...测试成功。
2，用sqlplus连接一下，看是否可以连接成功，打开sqlplus输入oracle用户名密码和主机字符串。
查看是否登录成功
1.2.添加oracle计数器
3，登录成功后，打开LR的controller.，在可用图中选择oracle，点击add measurements,再点击Advanced，如下所示：
这里我们用LR native monitors。
4，在Monitored Server Machines区域，添加oracle服务器所在的IP。
5，再在Resource Measurements on:IP区域点击添加，弹出对话框如下：
6，输入相应的信息，这里的orcl就是前面在Net Configuration Assistant配置的服务名。
7，点击OK，这里我们应该可以看到可以添加oracle的计数器了，如下所示：
2. 使用Sitescope引擎
不需要配置Net Configuration Assistant。
1，在第一个图choose monitor engine中选择sitescope，然后在在Monitored Server Machines区域点击Add如下所示：
在这里可以选择本地或者其他机器的sitescope，如果sitescope启用了account的验证，也要写上相应的用户名密码。
2，在Resource Measurements on:IP区域点击添加，弹出对话框如下：
3，输入信息如图。点击OK，如下：
至此就可以监控oracle了。
软件测试工作量估算之功能点估算法
从上个世纪70年代开始，一些软件企业就开始引入“功能点分析算法”，来评估软件功能的规模，然后便可以对软件开发的成本和工期，进行精确的度量，也可以对开发团队的生产率进行考核评估。半个世纪以来，很多种不同的功能点算法模型被建立起来，Mk II功能点算法是其中一种比较常用的模型。
随着淘宝网站的高速发展，淘宝开发团队规模也不断增大，于是必然要面对管理问题。人数的增多必然带来管理层级的增多，这样很容易出现管理结构的臃肿，管理成本增高。如果我们引入一种简单而且科学的工作度量模型，让每个人每个团队的工作质量和效率用数字来说话，便可以促进管理结构的扁平，简化管理过程，每个管理者可以管理更多的人，并且对下属的工作了如指掌。
功能点算法就是为了解决如何度量工作效率的问题，而工作质量主要是依靠分析各种Bug数据，我们在别的文章里讨论。
首先我们讲一下MVC模型，这是目前WEB开发的一种非常流行的软件架构模式。它把WEB应用程序定义为3个部分，每个部分负责完成特定的任务：
Model 模型
View 视图
Controller 控制器
Model主要与数据库交互，把数据表转换成对象，并且实现基本的数据读写逻辑，比如在淘宝网，商品就是一个Model。View负责实现界面的设计，我们浏览网页看到的WEB界面控件，比如按钮、文本框、GRID都是在View中定义的，设计View主要是用Html和JS。用户在View层进行的各种操作(比如点击按钮)，就会启动Controller里的函数，主要的业务逻辑代码，都写在Controller里了，其实也就是对各种Model进行增删改查，比如购买一个商品。
关于MVC的更多详细说明请参考维基百科。
接下来我们介绍MkII功能点算法，淘宝测试选择MkII的主要原因是，它的算法和MVC模式非常的吻合，可以说是黄金搭档。
MkII功能点算法是这样：先要给各个功能模块划分逻辑事务，然后针对每个逻辑事务，分析输入DET(Data Element Type)和输出DET的数量，以及关联的实体类型数量，再根据一个算法公式，计算出功能点指数：
功能点=输入DET×0.58+实体类型×1.66+输出DET×0.26
逻辑事务指用户在WEB应用程序中的原子操作。很多开发团队都会设计UseCase，一般来说一个UC对应一个逻辑事务。注意：逻辑事务一定是记录用户行为的，而不是程序内部的处理逻辑。不过在实际的分析中，我们发现逻辑事务的个数，往往要大于UC的个数，这是正常的，主要因为很多UC包含的信息很多。
我们用淘宝的“购买商品”来举例说明怎么划分逻辑事务，先来看购买商品的页面：
在这个页面中，左边一块是显示商品的简要信息，这是一个逻辑事务：“查看商品信息”，右边最上面一个收货地址的radio button，也是一个：“展示我所有的收货地址”，右边下面一组文本输入框加一个按钮，是一个：“为当前商品创建一个订单”。
在MVC中，逻辑事务对应Controller，每个逻辑事务都可以在Controller里面找到一个public函数。
再讲一下输入DET和输出DET。比如刚才的“为当前商品创建一个订单”这个事务，页面上输入信息的控件，都是输入DET，比如文本框、按钮，都是输入DET。这个事务大约有10个输入DET：“收货地址”、“购买数量”、“运送方式”等等。输出DET指应用程序给用户提供的所有的提示信息，以文字提示的方式知会用户。比如“购买成功”、“您没有绑定支付宝，不能购买”、“商品库存不足，无法购买”、“购买数量必须输入整数”等等。这个事务的输出DET数量大约是20个。
在MVC中，输入DET和输出DET对应View。每个输入DET和输出DET都能在View中找到对应控件。
最后讲引用实体，在创建订单事务里，引用的实体有很多。订单成功后要扣减商品库存，因此商品算1个;订单本身是1个;订单需要同步生成支付宝交易，支付宝算1个;还有物流记录算1个，等等，大约是5个实体以上。
在MVC中，引用实体对应Model。
到此为止这个逻辑事务的数据收集完整，代入公式计算得出结果：
10×0.58+5×1.66+20×0.26=19.3
当然这只是一个DEMO，数字都是估算的，实际情况肯定比这个要复杂，算出的功能点指数就会多一些。需要注意的是，使用MkII算法计算出的功能点指数，只是一个数值，代表应用程序的功能规模，和我们平时听到开发说的“我修改了一个功能点”，概念上是不同的。所以我们用“功能点指数”这个概念，不过为了沟通起来方便，还是简化成“功能点”了。
MkII功能点算法是非常适合于淘宝这样的互联网公司的。不过由于WEB应用程序的交互日趋复杂，JS被大量使用，因此在实践中，如何划分逻辑事务，如何统计输入输出，还需要进一步的研究。
-
功能测试用例的书写方式
2011-02-16 12:20:50
-
用例设计与测试执行流程
2011-02-16 11:57:12
-
软件评测师考前冲刺复习资料
2011-02-16 11:56:20
-
2011年软件水平考试软件测评师基础知识辅导(2)
2011-02-16 11:50:14
-
2011年软件水平考试软件测评师基础知识辅导(1)
2011-02-16 11:45:00
-
43个日常测试功能点
2011-02-15 17:53:45
-
大学生必须脱口而出80个英语句子
2010-12-09 13:46:55
-
测试成长
2010-10-08 14:11:22
-
功能测试注意事项
2010-09-01 15:49:12
-
软件需求
2009-12-03 12:03:46
转载
标题搜索
我的存档
数据统计
- 访问量: 61263
- 日志数: 62
- 建立时间: 2007-10-11
- 更新时间: 2015-02-12
