欢迎光临
梦想从学习开始!

关于验收测试的几个困惑| 小熊测试

本文主要介绍 关于验收测试的几个困惑| 小熊测试,小熊希望对大家的学习或者工作具有一定的参考学习价值,在测试领域有所提升和发展。

  相关概念

  单元测试:单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此,单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

  集成测试:集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

  系统测试:系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的 “ 先知者问题 ” 。因此,系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多,主要有功能测试、性能测试、随机测试等等。

  验收测试:验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

  回归测试:回归测试是在软件维护阶段,对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里,修改的正确性有两重含义:一是所作的修改达到了预定目的,如错误得到改正,能够适应新的运行环境等等;二是不影响软件的其他功能的正确性。

  困惑一:自动化验收测试 vs 手工验收测试

  通过合理地创建和维护自动验收测试套件,其成本就会远低于频繁执行手工验收和回归测试的成本:

  手工测试通常都是在项目的最后、软件即将发布、整个团队都面临压力的情况下进行的;

  原计划中预留的时间并不足以修复手工验收测试中发现的缺陷;

  当需要比较复杂的修改才能修复刚发现的缺陷时,很可能引入新的回归问题。

  结论:自动化验收测试是很有必要的。

  困惑二:创建和维护自动化验收测试的成本太高

  将自动化验收测试的成本降到投入产出比可接受程度是可能的。实现自动化验收测试的两种方法:

  直接基于业务层执行测试。前提是表现层只负责展现,不要涉足业务领域或应用逻辑。如:基于MVC的Controller进行测试。

  基于应用程序的GUI运行。需要使用分层将验收测试和UI解耦。

  结论:自动化验收测试如果成本高是因为设计得不够好。

  困惑三:基于GUI进行验收测试时,如何让测试与GUI解耦

  验收测试的层次:

  验收条件。“假如……当……那么……”。

  测试实现层。代码使用领域语言,不引用UI元素。

  应用程序驱动层。理解如何与应用程序进行交互,来执行一系列动作,并返回结果。

  【案例】验收条件

  功能: 下订单

  场景: 用户订单应该正确地记入账户

  假如 存在一种叫做"债券"的金融契据

  而且 存在一个叫"Dave"的用户,他的账户中有50美元

  当   我用"Dave"登录

  当   我选择了"债券"契据

  当   我下订单以10美元的单价购买了4份"债券"

  当   订单已完成

  那么 我的账户中还剩10美元

  【案例】测试实现层

1 using System;

2 using TechTalk.SpecFlow;

3

4 namespace AcceptanceTestExample

5 {

6     [Binding]

7     public class 下订单Steps

8     {

9         private AdminApi adminApi;

10         private TradingUi tradingUi;

11

12         [BeforeScenario]

13         public void 准备工作()

14         {

15             adminApi = new AdminApi();

16             tradingUi = new TradingUi();

17         }

18

19         [Given(@"存在一种叫做""(.*)""的金融契据")]

20         public void 假如存在一种叫做的金融契据(string instrument)

21         {

22             adminApi.CreateInstrument(instrument);

23         }

24

25         [Given(@"存在一个叫""(.*)""的用户,他的账户中有(.*)美元")]

26         public void 假如存在一个叫的用户他的账户中有美元(string user, decimal amount)

27         {

28             adminApi.CreateUser(user, amount);

29         }

30

31         [When(@"我用""(.*)""登录")]

32         public void 当我用登录(string user)

33         {

34             tradingUi.Login(user);

35         }

36

37         [When(@"我选择了""(.*)""契据")]

38         public void 当我选择了契据(string instrument)

39         {

40             tradingUi.SelectInstrument(instrument);

41         }

42

43         [When(@"我下订单以(.*)美元的单价购买了(.*)份""(.*)""")]

44         public void 当我下订单以美元的单价购买了份(decimal amount, int quantity, string instrument)

45         {

46             tradingUi.PlaceOrder(instrument, quantity, amount);

47         }

48

49         [When(@"订单已完成")]

50         public void 当订单已完成()

51         {

52             tradingUi.ConfirmOrderSuccess();

53         }

54

55         [Then(@"我的账户中还剩(.*)美元")]

56         public void 那么我的账户中还剩美元(decimal balance)

57         {

58             tradingUi.ConfirmAccountBalance(balance);

59         }

60     }

61 }

  【案例】应用程序驱动层

1 namespace AcceptanceTestExample

2 {

3     public class AdminApi

4     {

5         //调用业务逻辑

6     }

7 }

8

9 namespace AcceptanceTestExample

10 {

11     public class TradingUi

12     {

13         //使用Selenium.WebDriver操作Web UI

14     }

15 }

  结论:验收测试分为三层。只有应用程序驱动器层知道如何与应用程序打交道,而其他两层只用业务的领域语言。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小熊分享邦(www.xxfxb.com),希望大家能坚持软件测试之路,谢谢。

赞(0) 打赏
未经允许不得转载:小熊分享邦 » 关于验收测试的几个困惑| 小熊测试

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏