验收测试的自动化
作者:管理员 发布时间:[ 2010/2/9 15:46:31 ] 推荐标签:
测试包括很多种,单元测试、集成测试、功能测试、验收测试、数据库测试等等。撇开大家都熟悉的单元测试、功能测试不谈,为什么这里要单独拿验收测试来说自动化呢?
首先谈谈准备一次发布要做哪些事情。首先得验收这个迭代里面的所有Story,功能符合验收条件,没有bug。然后呢,需要对以往的所有迭代的Story 都要进行回归测试,来验证这个迭代里面的修改没有破坏以前的功能。如果全部通过,或者核心功能工作完好,那么系统能进行发布了。
由此看来,测试人员的工作量相当大,验收Story+回归所有功能。如果在一个发布很频繁的互联网项目上,两周甚至一周一个发布,要是这些活全部手工做的话,测试人员得累得吐血了。即使这样,血吐光了都不一定能测得完。测不完?所有人都来做测试,所有人都得吐血了。“人肉测试”不仅仅是很难完成任务,而且还有以下几个问题:
1. 重复劳动。这样一件事情,每次都得做一遍,烦不烦?
2. 人工测试精确度不高,容易出错。人不是机器,没有百分百的准确性,某个时候肚子饿了,或者听说股市大跌,精神一紧张,手一抖,测不准了。
3. 浪费人力,物力和时间。一大堆人花大量时间来测试,测试完还得花时间写书面报告,成本增长的那个快。
结论是人肉测试不行!能自动化的必须得自动化。因为有了自动化以后:
1. 系统质量得到保证。任何时候,只要测试通过,你能勇敢的说:看!测试全过,功能肯定没问题。
2. 消除浪费。上面所提到的人力、物力和时间的浪费都能消除掉。
3. 加快了测试速度。人工测试需要两天的,自动化通常2个小时可以测完。累得吐血这种情况已经看不见了。而且自动化测试可以通过一系列的方法,比如使用更好的机器,将测试分布式运行等来加速。
4. 提高测试的效率和准确性。自动化测试是高效的,它一刻也不停的在运行。同时它也是准确的,程序代码帮你做验证,不会有任何偏差。
5. 勇气和反馈。开发人员有勇气去修改、维护或重构代码,有的时候即使单元测试通过,功能不一定正确。有双重保证的话,开发人员有足够的勇气。项目所有人都有勇气说发布,不会像以前那样战战兢兢。
6. 可阅读的文档。验收测试的代码是测试用例。看代码是看用例,一步一步,清晰明确。不需要投入精力去维护一份测试用例文档,而且很有可能是过期不管用的。
自动化测试,不管是XP、精益还是DSDM都把它放在重要的地位。如果还处在人工测试阶段上的朋友,请自动化它们吧。
如果写好测试,也是一门很高深的学问。不要认为写测试是测试人员的专利,不管白盒黑盒,写出漂亮的测试是开发人员的基本素质。先看看下面这个测试,以Watir+RSpec为例:
it “Scenario: create story with full information” do
@browser.open(…)
@browser.text_field(:id, ‘..’).set story_name
@browser.text_field(:id, ‘..’).set story_description
……
@browser.button(:id, ‘..’).click
@browser.div(:id, ‘..’).text.should contains(‘…’)
……
end
这里描述了一个场景,用户填写一些字段,然后保存提交来创建一个用户故事。细看每一行代码,会发现看不懂!不知道每一行代码是在做什么。无法领会写测试人员的意图。
这段代码大的问题是其脆弱性。测试代码跟页面元素、结构紧紧耦合在一起,而UI元素是会经常被重构被改变的,一旦改变,很多测试用例会失败,需要做出相应的修改。
要想同时解决这两个问题,可以引入Page Model模式(相信ThoughtWorks的人都会用)。上面的代码便可以写成这样:
it “Scenario: create story with full information” do
create_story_page = @navigator.goto_add_story_page
create_story_page.add_story :name=>’…’, :description=>’…’
……
view_story_page = page.save_and_view
view_story_page.information.text.should contains(‘…’)
……
end
下面再来一个复杂点的测试用例
it “Scenario: import all the stories from excel file”
import_stories_page = @navigator.goto_import_stories_page
import_stories_page.import_from excel_path
preview_page = import_stories_page.preview_import
preview_page.choose_import_stories :all
preview_page.to_next_page
preview_page.choose_import_stories :first
story_list_page = preview_page.confirm_import
story_list_page.stories.should contains(‘imported story1’)
……
end
看!代码是不是可读性很好,业务意图是不是很清晰。每一行代码都是一个业务操作,代表着测试用例的一个步骤,后是一些断言,进行验收。断言也避免了 assertEquals这种写法,采用RSpec的should来达到可读性佳,贴近人类语言的效果。如果你仔细看看这段代码,会发现它没有一点 UI元素的操作在里面。UI再怎么重构,页面结构再怎么变化,测试用例代码都是稳定的。
因为Page Object封装了UI元素和结构,使得测试代码稳定,达到要修改只修改一处的效果。同时,Page Object也封装了业务行为及操作,使得测试代码更可读。Page Model还有几个重要的概念,Driver, Navigator, DataFixture,其实都是封装了不同的变化点,这里也不多做介绍。
验收测试的理想目标是全部自动化,测试代码即测试用例文档,易读易写。
首先谈谈准备一次发布要做哪些事情。首先得验收这个迭代里面的所有Story,功能符合验收条件,没有bug。然后呢,需要对以往的所有迭代的Story 都要进行回归测试,来验证这个迭代里面的修改没有破坏以前的功能。如果全部通过,或者核心功能工作完好,那么系统能进行发布了。
由此看来,测试人员的工作量相当大,验收Story+回归所有功能。如果在一个发布很频繁的互联网项目上,两周甚至一周一个发布,要是这些活全部手工做的话,测试人员得累得吐血了。即使这样,血吐光了都不一定能测得完。测不完?所有人都来做测试,所有人都得吐血了。“人肉测试”不仅仅是很难完成任务,而且还有以下几个问题:
1. 重复劳动。这样一件事情,每次都得做一遍,烦不烦?
2. 人工测试精确度不高,容易出错。人不是机器,没有百分百的准确性,某个时候肚子饿了,或者听说股市大跌,精神一紧张,手一抖,测不准了。
3. 浪费人力,物力和时间。一大堆人花大量时间来测试,测试完还得花时间写书面报告,成本增长的那个快。
结论是人肉测试不行!能自动化的必须得自动化。因为有了自动化以后:
1. 系统质量得到保证。任何时候,只要测试通过,你能勇敢的说:看!测试全过,功能肯定没问题。
2. 消除浪费。上面所提到的人力、物力和时间的浪费都能消除掉。
3. 加快了测试速度。人工测试需要两天的,自动化通常2个小时可以测完。累得吐血这种情况已经看不见了。而且自动化测试可以通过一系列的方法,比如使用更好的机器,将测试分布式运行等来加速。
4. 提高测试的效率和准确性。自动化测试是高效的,它一刻也不停的在运行。同时它也是准确的,程序代码帮你做验证,不会有任何偏差。
5. 勇气和反馈。开发人员有勇气去修改、维护或重构代码,有的时候即使单元测试通过,功能不一定正确。有双重保证的话,开发人员有足够的勇气。项目所有人都有勇气说发布,不会像以前那样战战兢兢。
6. 可阅读的文档。验收测试的代码是测试用例。看代码是看用例,一步一步,清晰明确。不需要投入精力去维护一份测试用例文档,而且很有可能是过期不管用的。
自动化测试,不管是XP、精益还是DSDM都把它放在重要的地位。如果还处在人工测试阶段上的朋友,请自动化它们吧。
如果写好测试,也是一门很高深的学问。不要认为写测试是测试人员的专利,不管白盒黑盒,写出漂亮的测试是开发人员的基本素质。先看看下面这个测试,以Watir+RSpec为例:
it “Scenario: create story with full information” do
@browser.open(…)
@browser.text_field(:id, ‘..’).set story_name
@browser.text_field(:id, ‘..’).set story_description
……
@browser.button(:id, ‘..’).click
@browser.div(:id, ‘..’).text.should contains(‘…’)
……
end
这里描述了一个场景,用户填写一些字段,然后保存提交来创建一个用户故事。细看每一行代码,会发现看不懂!不知道每一行代码是在做什么。无法领会写测试人员的意图。
这段代码大的问题是其脆弱性。测试代码跟页面元素、结构紧紧耦合在一起,而UI元素是会经常被重构被改变的,一旦改变,很多测试用例会失败,需要做出相应的修改。
要想同时解决这两个问题,可以引入Page Model模式(相信ThoughtWorks的人都会用)。上面的代码便可以写成这样:
it “Scenario: create story with full information” do
create_story_page = @navigator.goto_add_story_page
create_story_page.add_story :name=>’…’, :description=>’…’
……
view_story_page = page.save_and_view
view_story_page.information.text.should contains(‘…’)
……
end
下面再来一个复杂点的测试用例
it “Scenario: import all the stories from excel file”
import_stories_page = @navigator.goto_import_stories_page
import_stories_page.import_from excel_path
preview_page = import_stories_page.preview_import
preview_page.choose_import_stories :all
preview_page.to_next_page
preview_page.choose_import_stories :first
story_list_page = preview_page.confirm_import
story_list_page.stories.should contains(‘imported story1’)
……
end
看!代码是不是可读性很好,业务意图是不是很清晰。每一行代码都是一个业务操作,代表着测试用例的一个步骤,后是一些断言,进行验收。断言也避免了 assertEquals这种写法,采用RSpec的should来达到可读性佳,贴近人类语言的效果。如果你仔细看看这段代码,会发现它没有一点 UI元素的操作在里面。UI再怎么重构,页面结构再怎么变化,测试用例代码都是稳定的。
因为Page Object封装了UI元素和结构,使得测试代码稳定,达到要修改只修改一处的效果。同时,Page Object也封装了业务行为及操作,使得测试代码更可读。Page Model还有几个重要的概念,Driver, Navigator, DataFixture,其实都是封装了不同的变化点,这里也不多做介绍。
验收测试的理想目标是全部自动化,测试代码即测试用例文档,易读易写。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-61079698-8054),我们将立即处理,马上删除。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11热门文章
常见的移动App Bug??崩溃的测试用例设计如何用Jmeter做压力测试QC使用说明APP压力测试入门教程移动app测试中的主要问题jenkins+testng+ant+webdriver持续集成测试使用JMeter进行HTTP负载测试Selenium 2.0 WebDriver 使用指南