测试驱动开发的感悟

1、微软自动化测试是否适合于淘宝? 微软的自动化测试有三种形式。

  1)根据设计文档,进行代码级别的测试。开发人员根据测试脚本进行开发。

  现状,很难进行这种测试。

  2)针对于界面的自动化测试。

  淘宝属于web服务提供商,而且界面变更频繁,且缺乏这方面的专业人才。

  3)测试主要业务逻辑。

  目前我们的自动化测试,主要集中于业务逻辑方面。业务逻辑的正确性对于淘宝来说是必须保证的。

  它是保证系统稳定的基础。淘宝的接口有很多,如果逐个进行自动化回归,以现在的人力是几乎不可能完成的。

  若只是大体上进行测试而没有达到一定的测试粒度,那么意义并不大。所以我们做自动化测试的基础就是做好业务逻辑的测试,做细做强。

  2、淘宝的自动化测试要细化到何种程度,细化过程中容易遇到的问题?陆老师在课堂上举过一个例子。一个方法,其返回值长达两屏。老师问:测么? 有人说测,有人说不测。 而最终的答案是:全要测,交给自动化测试。

  而我们的测试怎样能细化到这种程度呢? 首先,测试所有的返回值。 其次,测试执行方法后所有数据库表中的相关数据。

  但是,实现这两点有可能会遇到很多问题。

  其一,在编码结束前,没有一个确定的文档明确的准确的告诉你这个方法会返回些什么,对哪些表中的哪些数据会有改动。

  其二,淘宝是一个web服务提供商。时间,意味着更多的pv,更多的成交额,更快的击败对手。所以项目的周期要短且严格要求保证质量。在一个年轻的团队中,若经验丰富的开发人员所占

  比重较小且缺乏经验和时间准备详细而又准确的文档的情况下,周期短质量严就意味着,在项目结项之前要写出如此细化,高覆盖率测试脚本的难度会大大增加。

  其三,每一个开发项目的架构和运行环境都各有不同。 自动化测试人员搭建测试环境,调试的时间会根据该项目架构,环境的难易度而有所增减。当项目结构复杂且有缺乏说明文档的情况下,测试人员就需要花费大量时间以及精力用于构建和调试环境,这样会直接的影响测试进度和效果,进而延长项目的周期。

  3、淘宝自动化测试的发展方向。

  微软和淘宝的流程体制不尽相同。微软要的是“聪明人”。更多的是依靠个人能力去完成某个项目的自动化测试脚本的编写。而淘宝则主张“平凡人做非凡事”。更趋向群策群力,共同协作,所以要分工合作。有特定的小组来做测试环境配置,CC集成。 特定的小组来进行

  测试计划,测试用例的编写。特定的小组来进行测试脚本的编写。。。只有“专”,才可以杜绝样样通,样样松的情况。

  4、UE测试的重要性。

  陆老师也提到:“微软的界面很人性化。从视觉上可以很容易的区分出,这个产品是否出自微软手中。微软的UE测试已经做到了极其苛刻的程度了。”

  我们的UE测试做的怎么样了呢? 每次界面改动后,测试人员是否以新,老用户的角度上思考过?是否做到的了全面细致的了解? 有微软那样专门研究人类行为学的UE测试人员么?

  我记得有一次的首页改版后,就为了找首页上我的淘宝链接,都花费了我好长时间,这让我感觉很困惑。在淘宝成千上万的用户中,有这种类似经历的恐怕不会只有我一个人吧?。长此以往,就会影响用户对我们服务的好感度。

  是否要增加一种针对新老用户好感度的,有权威性的测试呢?例如,当我们页面或者服务准备变动时,应事先考虑到用户的感受和接受度。

  5、意识问题--时间,质量,协作。

  微软的测试还有很好的一点就是意识。时间和质量的意识都是非常强。在控制时间成本的基础上,对bug的查找近乎于苛刻。而且测试和开发团队协作力很强。“有问题不会推脱责任。能做就给做掉了。” 这一点值得我们学习

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-11-05 17:26:39

测试驱动开发的感悟的相关文章

用NUnit2.1简单实现.net的测试驱动开发(TDD)

用NUnit2.1简单实现.net的测试驱动开发(TDD)下面的例子很简单,就是实现两个整数的四则运算,TDD提倡测试优先,即先写测试用例,再写运行代码,刚下了个NUnit2.1,迫不及待的试了试--1最初的测试用例using System;using NUnit.Framework;namespace netshop{ /// <summary> /// 四则运算TestCls测试用例 /// Edit by spgoal /// </summary> [TestFixture]

网络相册开发(3)——测试驱动开发(TDD)

测试驱动开发的理论已经提出好多年了,在这里关于他的原理和优势我就不多说了,我将大略的写一下我在实际中运用TDD的过程. 补一个jar: commons-pool-1.4.jar 过程 1.搭建测试用例运行环境 2.编写接口类 3.针对接口类编写测试用例 4.实现接口类,编写对应的功能代码 5.运行测试 6.如不通过,修改直至通过 7.循环完成其他功能 搭建测试用例运行环境 spring采用的依赖注射技术带来的一个主要好处就是你的代码对容器的依赖性比传统的J2EE开发小得多.配合spring提供的

测试驱动开发实践之重构篇

前一篇文章 测试驱动开发实践-入门篇 我们我们讲了一些基本的测试驱动开发流程: 1.写单元测试使他亮红灯 2.写代码使测试变成绿灯 3.重构代码 接下来我们需要开始重构了,大家有可能会问,为什么需要重构,什么时候开始重构. 对与为什么需要重构,其实就是为了使代码结构清晰,去除一些重复的代码,比如我们执行sql语句操作,我们起初这样写 Code 1private connStr="server=.;database=TestDB;uid=sa;pwd=123" 2public int A

在C和C++开发过程中应用测试驱动开发的理念

测试驱动开发和现在流行敏捷开发的是分不开的,测试驱动开发是敏捷开发的一个强有力工具,可以帮助我们从简单的设计开始,逐步地有保护重构设计直至完善设计过程.测试驱动开发是 Kent 提出的一种新的软件开发流程,现在已广为人知,这种开发方法依赖于极短重复的开发周期,面对开发需求,http://www.aliyun.com/zixun/aggregation/7155.html">开发人员要先开发代码测试用例,这些代码实现的测试用例定义了工程要实现的需求, 然后去开发代码快速测试通过这这些用例,这

Android测试驱动开发实践1

在正式进行Android测试驱动开发之前,不得不先提一下Android应用架构问题.在传统软件开发中,MVC架构得到了广泛的应用,然而在Android开发中,很少见应用采用了MVC架构(不要说Android及Widget全部采用的是MVC架构,那是系统的事,我们讲的是应用程序开发),究其原因可能是初期Android应用大多较为简单,没有采用的必要,而后期一直在沿用初期的习惯.但是遇到一些复杂的应用,例如同样的数据在多个Activity中显示,如果数据分散在多个Activity中,那么数据发生更新

《重构与模式(修订版)》—第1章1.4节测试驱动开发和持续重构

1.4 测试驱动开发和持续重构 重构与模式(修订版) 测试驱动开发[Beck, TDD]和持续重构,是极限编程诸多优秀实践中的两个,它们彻底改进了我开发软件的方式.我发现,这两个实践能够帮助我和公司降低过度设计和设计不足的几率,将时间用在按时地构造出高质量.功能丰富的代码上. 通过测试驱动开发(TDD)和持续重构,我们将编程变成一种对话1,从而高效地使可以工作的代码不断演变. 问:编写一个测试,向系统提问. 答:编写代码通过这个测试,回答这一提问. 提炼:通过合并概念.去芜存菁.消除歧义,提炼你

Android测试驱动开发实践2

在实际项目开发过程中,一般先实现核心功能,最后再做辅助性功能,这样可以尽快验证Idea的正确性,同时有助于让老板.投资人或客户看到可运行的产品,从而对产品充满信心,加大对项目的支持. 但是对于我们这个项目而言,我们首先需要得到一个Android应用MVC的架构体系,因此我们首先来实现一些典型功能,但是可以完整体现MVC架构的功能.在此我们选择任何应用程序在启动时都会显示的Splash页面,通常这个页面会显示一个应用图片,过30秒左右再显示程序的主界面,应用在这段时间完成数据加载等准备工作. 在这

Android测试驱动开发实践

在Android应用开发中,相信很少有人在坚持先由设计人员做完整的概要设计 .详细设计,然后交给程序员进行编码实现了.通常是在有一个大体框架的情况下,就开始进行具体编码开发了.在这种情形下,开发速度可以有很大的提高,但是最终代码质量却不可避免的降低了.如何能既保持开发速度,同时又能保证开发质量呢?相信测试驱动开发是一种比较可行的开发方法学. 测试驱动开发首先通过设计测试用例,对从用户需求到方法接口进行细化,在构想这些测试用例的过程,就是站在使用者角度上来思考系统的过程,而传统方法中设计人员通常是

python测试驱动开发实例_python

本文实例讲述了python测试驱动开发的方法,分享给大家供大家参考.具体方法如下: import unittest from main import Sample class SampleTest(unittest.TestCase): def setUp(self): print "create a new Sample" self._sample = Sample("b64e5843ca7db8199c405be565fa7f57") def tearDown(