敏捷——测试先行方法介绍

　　是的，现在肯定有读者会这样说了：“我只在产品发品之前写测试。”有些人可能会窃笑，对质量保证部门说三道四。还有一些人作为项目经理可能会添油加醋地说：“我们可不会浪费时间写测试代码；我们还得写真正的代码呢。”那么，采用TDD到底是什么意思呢？

　　TDD产生于敏捷开发运动，特别是极限编程（extreme programming，XP），而且TDD正是XP的一个核心原则。推崇TDD的人认为，不应该完成开发之后再写测试，这通常只是“马后炮”，而应当在写代码之前先写测试。测试本质上相当于设计文档，而不是花大量时间去摆弄一个复杂的图形化工具，你要直接在代码中“拟画”一个类。开始时先为一些小功能块编写测试。在有些语言下，你写的测试甚至不能编译，因为所引用的类尚不存在。一旦建立了测试，就可以运行这个测试（当然，此时运行测试会失败）。然后再编写最少量的代码，以便测试通过。接下来再重构代码，并增加更多的测试。

　　通常可以使用测试框架来帮助编写自动化测试。最著名的框架是JUnit，不过现在已经有很多xUnit项目，可以简化在各种语言下测试的创建。一般地，这些框架都建立在断言（assert）基础上。开发人员编写测试方法，将调用方法的实际结果与期望结果进行比较。当然，可以人工地检查一个日志文件或用户界面来完成这些比较，但是，用计算机完成数据比较不仅速度快，也更准确。另外，就算是让计算机把同样的测试运行上1500次，它们也不会嫌烦，如果是人可做不到这一点。

　　有了JUnit和其他测试框架，编写和运行测试变得相当简单。这就能鼓励开发人员创建大量测试（往往能更完备地覆盖各种测试情况），而且会乐于经常运行这些测试（可以更快地帮助开发人员找到bug）。在许多情况下，如果项目中采用了TDD，测试代码往往与生产代码一样多！

　　使用TDD可以带来许多重要的好处：

　　提供明确的目标：你很清楚，一旦结束（也就是一旦测试通过），你的工作就完成了（假设你的测试写得很好）。测试会为代码建立一个自然的边界，使你把重点集中在当前任务上。一旦测试通过，就有确切的证据证明你的代码能工作。相对于人工地测试用户界面或者比较日志文件中的结果，在一个xUnit框架中运行自动化测试，速度要快几个数量级。大多数xUnit测试的运行只需几微秒，而且大多数采用TDD的人都会一天运行数次测试。在许多开发小组中，将代码签入源代码树之前，代码必须成功地通过测试。

　　提供文档：你是不是经常遇到看不懂的代码？这些代码可能没有任何文档说明，而且开发代码的人可能早就走了（或者度假去了）。当然，看到这种代码的时间往往也很不合时宜，可能是凌晨3点，也可能有位副总在你旁边大声催促着赶快解决昨天的问题，这样要想花些时间来明白原作者的意图就更困难了。我们见过一些好的单元测试文档，它们会指出系统要做什么。测试就像原开发人员留下的记号，可以展示他们的类具体是怎么工作的。

　　改善设计：编写测试能改善设计。测试有助于你从界面的角度思考，测试框架也是代码的客户。测试能让你考虑得更简单。如果你确实遵循了“尽量简单而且行之有效”的原则，就不会写出篇幅达几页的复杂算法。要测试的代码通常依赖性更低，而且相互之间没有紧密的联系，因为这样测试起来更容易。当然，还有一个额外的作用，修改起来也会更容易！

　　鼓励重构：利用一套健壮的测试集，你能根据需要进行重构。你是不是经常遇到一些不知是否该修改的代码？种种顾虑让你行动迟缓，过于保守，因为你不能保证所做的修改会不会破坏系统。如果有一套好的单元测试集，就能放心地进行重构，同时能保证你的代码依然简洁。

　　提高速度：编写这么多测试会不会使开发速度减慢呢？人们经常会以速度（或开发开销）作为反对进行TDD和使用xUnit框架的理由。所有新的工具都会有学习曲线，但是一旦开发人员适应了他们选择的框架（通常只需很短的时间），开发速度实际上会加快。一个完备的单元测试集提供了一种方法对系统完成回归测试，这说明，增加一个新特性之后，你不必因为怀疑它会不会破坏原系统而寝食难安。

　　提供反馈：单元测试还有一个经常被忽略的优点，即开发的节奏。尽管看上去好像无关紧要，但通过测试之后你会有一种完成任务的成就感！你不会成天地修改代码而没有任何反馈，这种测试—代码—测试的方法会鼓励你动作幅度小一些，通常修改一次代码的时间仅几分钟而已。这样你不会一下子看到冒出一大堆的新特性，而只是让代码基一次前进一小步。

　　从我们的经验看，测试是会传染的，你可能会慢慢上瘾。一开始，许多开发人员都心存疑虑，但最终几乎每个开发人员都迷上了运行测试后的绿条。测试第一次“抓住”bug或者增加一个新特性，只需几分钟而不是几个小时，往往就是在这样一些时候，开发人员会欣喜地认识到测试确实很有意义。

posted @ 2012-08-20 09:48 顺其自然EVO 阅读(1838) | 评论 (0) | 编辑收藏

数据库程序设计中的约束、触发器和存储过程

　　上篇博客中所说的对于表操作的几种限制少分析了触发器。这次从对表设计的角度来着重分析约束和触发器的关系，并进一步扩展比较触发器和存储过程。但在看该篇博客前强烈建议大家好好读下我的上一篇博客《约束与 数据库对象规则、默认值的探究》

　　首先，从图上来比较三者的关系：

　　触发器不仅能够保证数据的完整性，而且还可以封装复杂的T-SQL逻辑处理语句，在功能上类似于存储过程，所以触发器又是一种特殊的存储过程。但是存储过程的执行是我们使用Exec主观调用的，而触发器是经过一种事件操作后自动被调用的。

　　在拆开分析约束和触发器、触发器和存储过程之前我们穿插点外话。在数据库程序设计中包含有多种数据模型：

　　20世纪60年代后期，在文件系统基础上发展起来的层次模型、网状模型和关系模型等传统数据模型；20世纪70年代后期产生的E－R数据模型；20世纪80年代以来又相继推出面向对象数据模型、基于逻辑的数据模型等新的模型。下图关系数据库中的关键术语和语义对象模型及ER图中使用的术语之间的映射关系：

　　上面的内容只存在了解而已，不用深究。

　　数据完整性和业务规则

　　在上篇博客我已经简单介绍了数据完整性，接下来我们详细说下数据完整性和业务规则。

　　一、数据完整性

　　数据完整性=可靠性+准确性，这里我们要清楚一下两点：

　　● 数据存放在表中

　　● 创建表的时候，就应当保证以后数据输入是正确的（错误的数据、不符合要求的数据不允许输入）

　　为了保证数据的完整性我们经常使用完整性约束来确保数据的完整性。数据完整性，主要包括下面四部分：

　　接下来我们从代码中认识下几种触发器。

       --#Update型触发器
If exits(select name from sysobjects where name=’tgr_update’)
Drop trigger tgr_update
Go
Create trigger tgr_update on student
  for update
As
  If (Update(student_ID))
   Print ‘更改成功！’
  Else
   Begin
    Raiserror(‘系统提示：更新发生错误’,16,1)
    Rollback tran
   End
Go
--测试
Update student set student_ID=10002 where student_ID=10001

　　注意：在创建触发器时，创建触发器必须是批处理的第一行，存储过程也是如此。

     --# instead of 触发器
          if (object_id('tgr_classes_inteadOf', 'TR') is not null)
           drop trigger tgr_classes_inteadOf
         go
         create trigger tgr_classes_intead Of
               on classes
         instead of delete/*, update, insert*/
         as
            declare @id int, @name varchar(20);
            --查询被删除的信息，病赋值
              select @id = id, @name = name from deleted;
            print 'id: ' + convert(varchar, @id) + ', name: ' + @name;
            --先删除student的信息
              delete student where cid = @id;
            --再删除classes的信息
              delete classes where id = @id;
            print '删除[ id: ' + convert(varchar, @id) + ', name: ' + @name + ' ] 的信息成功！';
         go
         --test
         select * from student order by id;
         select * from classes;
         delete classes where id = 7;
 

　　# 启用、禁用触发器

--禁用触发器
 disable trigger tgr_message on student;
 --启用触发器
 enable trigger tgr_message on student;
 # 显示自定义消息raiserror

if (object_id('tgr_message', 'TR') is not null)
 drop trigger tgr_message
 go
 create trigger tgr_message
 on student
 after insert, update
 as raisError('tgr_message触发器被触发', 16, 10);
 go
 --test
 insert into student values('lily', 22, 1, 7);
 update student set sex = 0 where name = 'lucy';
 select * from student order by id;

　　二、业务规则

　　业务规则听起来很难理解，当然它也是值得我们深究东西，通俗的讲它其实是符合实际条件。如：某商店规定一个售货员在一个月内售出10个以上的热浴盆，那么奖励2000元；某公司的订单上必须含有客户的姓名和联系方式等等，这些都是简单的业务规则。从数据库的角度看，业务规则就是约束。

　　约束和触发器

　　MS SQL Server提供了两种主要的机制进行强制业务规则和数据的完整性：约束和触发器。在作用上约束支持的触发器都可以实现，它们两者是相容的关系，如下图。虽然两者在作用关系上有重合的地方，但是相较两者的执行效率和维护难易来说，触发器是远远不如约束的。所以约束能实现的情况下编程人员是不会选择触发器的。

　　一、约束，上篇博客我已经着重讲解了约束的概念，这里不再深究。

　　SQL Server中存在五种约束：

　　● 约束的目的：确保表中数据的完整型

　　● 常用的约束类型：

　　– 主键约束（Primary Key Constraint）：要求主键列数据唯一，并且不允许为空

　　– 唯一约束（Unique Constraint）：要求该列唯一，允许为空，但只能出现一个空值。

　　– 检查约束（Check Constraint）：某列取值范围限制、格式限制等，如有关年龄的约束

　　– 默认约束（Default Constraint）：某列的默认值，如我们的男性学员较多，性别默认为“男”

　　– 外键约束（Foreign Key Constraint）：用于两表间建立关系，需要指定引用主表的那列

　　二、触发器，首先在下表中来看触发器的基本结构。

　　触发器是一种对表进行插入、删除、更改的时候自动运行的特殊的存储过程。它一般用在比核查约束更为复杂的约束中。但能用约束实现的功能，一般不用触发器。

　　触发器的应用种类繁多上面的几个示例都是比较常用的，当然最好的熟练方法就是多用，多练。

　　触发器和存储过程

　　触发器是一种特殊的存储过程，不是由用户直接调用。而存储过程是一组T-SQL语句，经过编译后可以被多次调用。类似于其它编程语言中的过程。它可以接收输入参数、输出参数、返回单个或多个结果集以及返回值。

　　存储过程分为三类：

　　1、系统存储过程：以sp_开头，用来进行系统的各项设定、取得信息。相关管理工作，如 sp_help就是取得指定对象的相关信息

　　2、扩展存储过程以XP_开头，用来调用操作系统提供的功能

　　exec master..xp_cmdshell 'ping 10.8.16.1'

　　3、用户自定义的存储过程，这是我们所指的存储过程

　　常用格式

Create PRocedure procedue_name
   [@parameter data_type][output]
   [with]{recompile|encryption}
   as
        sql_statement
--解释:
--output：表示此参数是可传回的
--with {recompile|encryption}
--recompile:表示每次执行此存储过程时都重新编译一次
--encryption:所创建的存储过程的内容会被加密

　　举例：

　　有如下表量表

　　result_Info：

　　Student_Info

　　#创建返回参数的存储过程

If exists(select name from sysobjects where name=’proc_return’ and type=’P’)
Drop proc proc_return
Go
Create proc proc_return
@param1 int,
   @param2 char(10),
   @param3 char(10)
   @param4 int output
With encryption    --加密
As
  Insert into student_Info(student_ID,name,result) values(@param1,@param2,@param3)
  Select @param4=sum(result) from student_Info
  Print ‘总分为：’ & convert(char,@param)
Go
--调用测试
Declare @sumresult int
Exec proc_return 12,’王刚’,80,@sumresult
Go

　　output和return都可在批次程式中用变量接收，而recordset则传回到执行批次的客户端中

　　#创建一个存储过程，实现将表一和表二合并，该表只含Student_ID、Name、sex、result，将临时表存放在存储过程中。

If exists(select name from sysobjects where name=’proc_save’ and type=’P’)
Drop proc proc_return
Go
Create proc proc_save
As
  Select r.student_ID,r.Name,r.result,s.sex into #temptable from result r inner join student s on                 r.student_ID=s.student_ID
If @@error=0
  Print ‘Successed’
Else
  Print ‘Failed’
Go

　　存储过程的应用类型还有很多，这里我只介绍了在编程时常用的两种。

　　总结

　　在进行数据库程序设计时，数据的完整性是编程人员必须要考虑的，但是有时候这些知识的细节却让我们纠结的很，搞不清改用哪个。总之吧：能用存储过程实现的不用触发器；能用约束实现的不用触发器，约束和存储过程用哪个都可以。

　　有些不懂得地方在SQL Server中按F1，在SQL Server联机丛书的索引中查找可以解决我们的一切矛盾。

posted @ 2012-08-20 09:43 顺其自然EVO 阅读(798) | 评论 (0) | 编辑收藏

游标、事务并发和锁三者之间的那点事

http://www.51testing.com/html/73/n-821673.html

　　对数据库学习的不断深入，对游标的认识也在逐渐加深，游标与事务、锁有着密不可分的关系。无论是事务、锁还是游标相对于数据库来说最主要目的是保证数据的完整性。对事务并发、锁定的深入学习才能更加完善对游标的理解。少说废话，下面进入本篇文章的正题。

　　首先，我们讲解游标与事务并发的那点事

　　事务是为完成特定任务，将一条或多条的SQL语句组合在一起。有效的使用事务不但可以提高数据的安全性，而且还可以增强数据的处理效率。如果没有锁定且多个用户同时访一个数据库，多个事务使用相同的数据时就会出现事务并发的问题。

　　我们一张图讲解事务并发的四个方面：

　　从上图我们可以看出来，事务并发的四个方面，归根结底都有相似的地方：多个事务修改同一行数据，发生错误。

　　对比着学习游标的并发问题，游标的并发与事务的并发基本相同：多个游标修改同一行数据，发生错误。

　　同样，我们还是一张图分析游标的四个并发选项：

　　其次，我们讲解锁和事务并发的那点事

　　所谓锁即是保证数据安全、数据库的完整性和一致性，例如：每家的门锁，因此，锁可以防止事务的并发问题。我们看一下锁的类型：

　　为了防止数据的并发性，可以使用锁的粒度即锁的级别，锁定不同类型的资源。

　　死锁又是怎么产生的呢？

　　书上的概念：当两个或多个线程之间有循环相关性时，将会产生死锁。其实简单的说就是：当两个或多个事务需要同时使用一组有冲突的锁，而不能将事务继续下去，就会出现死锁。

　　例如：有两个事务：事务1、事务2。事务1具有Supplier表的排它锁，事务2具有Part表上的排它锁。事务1需要Part表上的锁，无法获得。事务2需要Supplier表上的锁，也无法获得，这样就会出现死锁。只要一方首先释放持有的锁，就不会出现死锁。

　　如图：

　　最后，我们讲解游标和锁的那点事

　　游标适用于任何其他SELECT语句的相同事务锁定规则。通过任何SELECT语句获得的事物锁由下述两项控制：

　　● 连接的事物隔离级别设置

　　● FROM子句中指定的任何锁提示

　　对于游标和独立的SELECT语句，这些锁都会保持到当前事务结束。

　　注：SQL Server以显性或隐性事务运行，则这些锁将保持到事务提交或回滚

　　举两个例子，其所作的锁定基本相同。如下：

/* Example 1 */
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ —设置隔离级别为可重复读
GO
BEGIN TRANSACTION
GO
SELECT * FROM AdventureWorks2008R2.Sales.Store;
GO

/* Example 2 */
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ —设置隔离级别为可重复读

GO
BEGIN TRANSACTION
GO
DECLARE abc CURSOR STATIC FOR
SELECT * FROM AdventureWorks2008R2.Sales.Store;
GO
OPEN abc
GO

　　游标、事务并发和锁三者之间的关系，就分析这么多，希望对大家有所帮助。同样，希望大家对菜鸟提出宝贵的意见。

posted @ 2012-08-17 10:19 顺其自然EVO 阅读(261) | 评论 (0) | 编辑收藏

零基础学习SVN之（一）：SCM与SVN的使用（基础篇）

　　今天用了一点时间看了看SVN的视频，发现很多东西还是要学习基础的，之前虽说在用SVN，但今天看完视频之后还是收获很大。

　　要学习SVN，首先得知道SCM（Software Configuration Mangement）软件版本控制管理。我们大家都知道，一款软件从开始着手到完成发布，中间一定有很多不同的版本，那么如何管理好这些版本呢？作为SCM的一个工具，SVN给我们提供了很好的解决办法。

　　SCM要解决的问题：

　　1、如何把大家的代码合并的一起。

　　2、多平台的支持。

　　3、版本之间的不同

　　SCM的核心功能：

　　版本控制（version control）

　　SCM常用工具：

　　CVS
　　SVN
　　VSS
　　Clearcase
　　Teamware

　　学习SCM重点在学习SVN，下面我们来说说SVN的使用方法

　　SVN分客户端和服务器端。

　　服务器：

　　服务器的建立：分三步

　　第一步：建立核心仓库，respository

　　Cmd控制台：Svnadmin+create +名称

　　第二步：设置权限：svnserver，password中的名字和密码

　　第三步：启动服务器：svnserve -d-r+目录名称/相对路径。

　　注意：这种方法控制台窗口不能关，否则服务器就会关闭。

　　服务器的两种运行方式：1、svnserve 2、apache http

　　客户端常用功能：

　　下载/更新：Update / CheckOut 即从仓库中取出内容。

　　上传/提交：Commit / CheckIn 即把内容放入仓库。

　　SVN主要是团队合作以及多人异地开发时使用，这样就有一个同时进行的问题存在，就会产生某些冲突。SVN是如何处理冲突的？

　　通常采用三种方法：

　　1、把远程的文件更新到最新到本地，再重新添加你的修改。

　　2、放弃你的修改，把远程的更新到你这，用最新的。

　　3、人为沟通。

　　下面是我视频学习的笔记总结，以备快速复习

posted @ 2012-08-17 10:16 顺其自然EVO 阅读(465) | 评论 (0) | 编辑收藏

软件产品的需求管理浅析

　李先生在一家上市软件企业担任需求分析师，该公司在电信信息化已经有多年积累，为了缩短软件的交付周期，降低研发和维护成本，公司从一年前开始逐步从定制化开发向产品化方向转型。李先生负责的产品参加软件产品化运营的第一批试点，经过1年的努力，产品已经在5个现场上线并开始正式运营，年底成本核算，比同类定制化项目效益提升了近40%，李先生还被评为优秀员工。

　　随着产品的深入使用，现场反馈的新需求越来越多，而且需求之间的冲突越来越多。以前做定制化开发遇到需求冲突的情况，一般都是和用户协商，由用户方安排一接口人，负责沟通和解决有冲突或者不合理的需求。但现在不同的现场需求之间有冲突，这种办法就行不通了。另外，软件中为了实现不同需求，配置项和逻辑分支越来越多，程序的维护越来越困难，常常一周过去了现场报的问题解决还没有眉目，用户啧有烦言。开发工程师的不满也越积越多，认为需求分析工作不到位，需求频繁变更，导致软件质量下滑。如果再这样下去，软件的问题会越来越多，工作会越来越难做，点上一支烟，李先生陷入沉思。

　　一、软件产品需求管理面临的问题分析

　　软件产品化运作的企业越来越多，大多企业的需求分析师或项目经理都遇到过和李先生类似的情景。总结一下大概有下面三个问题：

　　1、需求来源多样，差异过大难以兼容

　　产品化和定制化开发的主要区别之一就是产品化面向的是用户群，而定制化开发面向的是一个或几个同质化的用户。所以产品化比定制化接收需求的多样性要丰富的多。针对同一功能点的需求，需求之间或重叠，或交叉，或互斥。按照用户甲想法实现，可能用户乙会强烈不满。

　　2、配置项过多，软件使用过于复杂，用户不满增加

　　解决不同需求的一个最简单的办法，就是增加配置项。通过配置项交付有差异的功能给不同的用户。随着产品的维护时间，软件中的配置项越来越多，产品的使用复杂度越来越大。每次产品升级时，一不小心覆盖了本地化配置，就会造成原有功能丢失，软件无法使用等异常情况，严重时还可能被用户投诉。

　　3、程序中充斥大量的分支逻辑，越来越难以维护，产品质量越来越差

　　研发工程师的人员流动率在诸多行业中，公认比较高。一茬一茬的新陈代谢，再加上很多企业的过程管理不严谨，文档不全，原来为解决不同需求引入的配置和逻辑分支成了新的世纪之谜。为了快速完成任务，避免影响现有功能，工程师们采取另外增加一个分支的方式解决问题和实现需求。

　　日积月累，程序中像谜一样的分支越来越多，程序质量开始变的很糟糕。往往解决了一个问题，引发了一系列的bug。开发工程师们越来越没有成就感，对软件的前景越来越没有信心。

　　二、多层次需求管理的对策

　　在上述的问题仔细分析，可以发现一个产品的需求其实是分层次的，有些需求是某个用户群特有的需求，比如电信领域中中移动和中联通的规范在方向上有非常大的差异；有些需求是某些用户的通用需求，比如网管中心监控人员对于网元的呈现方式；有些需求是用户的个性化或者临时性需求，比如重大活动保障时期的特定需求。如果要解决产品化引致的这一系列需求问题，就不能把视角局限在需求-开发的层面上，而是要在站在业务领域分析，产品定位的高度，合理地把需求落实到不同层次上解决。

图1：需求和需求交付的对照关系

　　1、用户群的需求处理策略

　　一个规模推广的产品可能会横跨多个用户群，比如在电信BOSS领域的计费软件，移动，联通，电信都有自己的技术规范，中间的规范方向，计费的模式以及算法各不相同。

　　如果把这些都放到相同的产品上实现，会造成产品非常臃肿和复杂。

　　我们的经验是首先创建产品平台，平台的设计采用微内核的方案，内核包括系统的技术框架，组件的集成引擎和一些公共的工具组件，平台外围功能采用组件化的方案，包括不同的批价算法组件，适配组件，配置组件等。按照用户群的需求以及商务策略把内核和相关组件打包成不同的业务产品，如移动版，电信版和联通版等。

　　运营商的规范升级以后，同时也要对产品平台上的相关组件进行升级，并发布新版本的业务产品。所有的业务产品就组成了一个计费的产品族。

　　这种策略在一些大型的软件企业里应用非常广泛，比如微软的window产品系列：window Server，window profession，window home，分别覆盖企业用户，商务用户和家庭用户这三个有着明显需求差别的用户群。国内腾讯公司的QQ和TM也是一个成功的案例，用两个不同风格的软件覆盖娱乐人群和商务人群的社交需求。

　　2、用户的典型性需求

　　所谓典型性需求是此类需求具有普遍性的特征，比如在报表要提供10秒钟自动刷新数据功能。这类需求往往可以引导产品规划方向，因为使用最深入的用户提出的需求最多，而且需求的价值越大。

　　对待这一类的需求，一般对应有两种配置方式，一种是粗粒度，一种是细粒度。跟据用户的偏好和使用的环境，在系统安装阶段配置，配置影响的粒度一般是组件级，最小到对象级，比如office安装过程中，引导用户选择需要在本地安装的程序模块，比如word，excel，dbaccess等。另一种是系统中的各种配置项，影响的主要是对象级以及程序的逻辑，比如firefox中的系统配置项，以及window的注册表。

　　利用这两级的配置管理，基本上能解决用户需求的差异化，但采用这种办法的前提是已知用户的可能需求并预先做了定义和开发。对于不可预知的需求，就需要通过二次开发接口来解决了。

　　3、用户的本地化需求

　　用户本地化需求的满足程度，响应时间和用户的满意度关系非常密切，要提升用户满意度就必须关注本地化需求的实现。而软件产品的大规模推广带来的本地化需求的工作量非常大，不仅会影响企业的利润率，而且提高了产品自身维护的风险。所以大型的软件产品都会提供一些本地化需求开发，比较典型的是sap，sibel，把产品实施和本地化开发的工作全部外包出去。

　　在产品定义阶段，需要重新评估产品的范围，以及在产品范围内可能的用户本地化需求，对其中非核心的，可以通过外挂接口实现的功能规划出二次开发接口。比如运维平台短信派单模块，安排短信派发的二次接口，产品实施的时候，通过开发相应的短信接口类，适配不同的短信网关，短信协议，然后把该实现类挂接到系统上实现短信工单排饭的功能。

　　二次开发接口的优点是增强了系统功能的扩展性以及缩短了需求的响应时长，缺点也是比较明显的，当二次开发接口过多，过于复杂超出了产品管理的能力时，会在产品升级的时候带来很多问题，比如开发程序被覆盖，接口变更导致功能无法使用等。

　　三、总结

　　相比定制化开发，产品化的模式提高了复用水平，降低了研发和维护成本，但是提高了管理水平的要求，特别是规划，需求以及交付管理。笔者见过很多中小公司，产品化运营以后不经没有提高经营效益，反而因为产品前期投入过大，后期维护成本过高而陷入泥潭。所以产品化运营是否成功的关键在于业务积累和管理水平。前者是规划产品方向，能否取得市场竞争优势的核心；后者是产品化目标的保证，是能否切实降低研发维护成本的关键。采用定制化还是产品化，取决于企业的发展水平以及企业的竞争优势，没有最好，只有最适合。

　　对于产品的需求管理，不应该套用定制化的那套解决办法，应该把需求分析放在合适的产品层次上考虑需求的实现方案，如果原有的解决方法需要平面思维，那么在产品化的需求分析需要的是多层次的立体思维模式。

posted @ 2012-08-17 10:07 顺其自然EVO 阅读(405) | 评论 (0) | 编辑收藏

Java 处理 XML 的三种主流技术及介绍

摘要: XML （eXtensible Markup Language）意为可扩展标记语言，它已经是软件开发行业中大多数程序员和厂商用以选择作为数据传输的载体。本文作者对于 Java 处理 XML 的几种主流技术进行一些总结和介绍，希望帮助那些有不同需求的开发人员对于 XML 处理技术的作出最优的选择。　　最初，XML 语言仅仅是意图用来作为 HTML 语言的替代品而出现的，但是随着该语言的不断发展和完... 阅读全文

posted @ 2012-08-16 10:35 顺其自然EVO 阅读(177) | 评论 (0) | 编辑收藏

过程改进 “三七”法则

　　过程改进工作开展应该从三个方面做准备，分七步走。

　　三方面做准备：

　　1、在组织方面的准备上，除了要求高层领导出资支持改善软件过程，委托具有管理职责的人员负责实施之外，须成立：

　　软件工程过程组（SEPG），研讨、编写、组织评审及修订体系文档并推广文档；

　　软件质量保证组（SQAG），研究软件质量保证技术及过程，编写、组织评审及修订必要的SQA文档并推广已编写的文档，度量和分析项目进展情况，反馈项目过程状态，准备和评审过程、计划和标准，审计指定的软件工作产品以检验其遵从性，审计软件工作过程的符合性；

　　成立软件配置管理组（SCMG），研究软件配置管理技术及过程，编写、组织评审及修订必要的SCM文档并推广已编写的文档，建立必要的工具支持。

　　2、在知识准备方面，要加强培训工作，建立和扩大内部的过程改进队伍。对各角色人员进行专项培训，普遍开展软件工程基础及CMM的培训，使每个岗位的人员都具备过程改进的意识，并掌握所必需的过程改进知识和技能。此外，要重视对软件工程的研究，包括方法、工具和过程，加速培养过程改进的骨干队伍。

　　3、在能力准备方面，建立有效的软件项目管理，文档化且遵循软件项目管理过程，在建立管理过程中，使用组织的方针来指导项目，建立基本软件工作产品完成准则和检查单，并迅速实施，并收集改进意见，然后根据改进意见及时修改。坚持适当的监控机制，例如对过程改进项目进度进行跟踪而建立的例会制度，制度化的日报和周报活动。做好实际数据收集、度量与分析工作等。

　　七步实施：

　　确定目标：与公司领导一起确定在一段时间内预计达到的改进状态。

　　调研与差距分析：把过程改进要达到的状态与目前的状态作比较，找出存在的差距。

　　制定改进方案与计划：制定过程改进方案，并对过程改进工作进行WBS分解，沟通协调资源，制定实施计划。

　　规程制定：过程改进的一个重要的地方就是“事事有规程，时时有记录”，这样，即使关键人走了，原来的事也能继续而不致产生过多的停顿。

　　过程试点：制定了规程后，要对行动计划按执行过程的情况进行适当调整。其中，尤其要注重评审和验证，实现定期监控，注意采集度量数据。

　　过程推广：扩大应用范围。

　　持续改进：总结过程试点的经验，修订规程。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

posted @ 2012-08-16 10:32 顺其自然EVO 阅读(236) | 评论 (0) | 编辑收藏

测试用例设计——如何提高测试覆盖率

　　说到测试用例的设计，我想每个有过测试经历的测试工程师都会认为很简单，不就是：按需求或概要设计，得到软件功能划分图，然后据此按每个功能，采用等价类划分、临界值、因果图等方法来设计用例就行了。

　　但事实上撇开测试数据的设计不谈，仅就测试项来说，我们发现，对同一个项目，有经验的测试人员，在写用例或测试时总会有更多的测试考虑点，从而发现更多的问题；而有些测试人员测试用例的撰写却只有那么三板斧，表面看好象已经把页面所有信息的测试都考虑到了，实际上却还是遗漏了大量测试覆盖点，导致其测试出来的程序总是比较脆弱。

　　究其原因，我觉得还是测试用例的撰写水平不到位，更确切地说是测试用例的覆盖度太低。说实话我认为系统测试用例真正做到100％覆盖是很难的。难道说按设计中的功能划分，每个功能都写到了这个用例就覆盖完整了？错，这还远远不够。因为我们知道还有大量的内部处理、转换、业务逻辑、相互影响的关系等都是需求或设计中所不会点明的。而这些一方面需要靠测试人员对项目本身的了解，另一方面要靠测试人员的经验，来一一找到这些隐藏点并予以测试，才能真正地保证我们的测试覆盖度。

　　所以本文抛开具体的测试数据设计方法，主要从测试覆盖度的角度来介绍用例设计时，如何才能考虑地更周全，如何才能将隐藏的测试项一一找出，从而使我们的测试更全面更完整。

　　想法虽然美好，可是毕竟每个测试的项目都是各不相同，针对不同项目我们的经验也会告诉给我们不同的想法，这些想法通常很感性，很难用严密的逻辑理论来把它升华。因此本文的内容仍是很简陋且不成熟，只是希望能以本文为砖，引起大家的思考，一起来补充完善，以使我们的测试用例设计水平不断提高。

　　正文

　　一、测试用例的切面设计

　　所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。

　　1、功能点切面

　　这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。

　　2、特定切面

　　除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面，可以使我们的用例阅读性、理解性、操作性更强。

　　3、隐含切面

　　这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。

　　（1）、后台功能

　　常见的如一些定时自动启动的服务；以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的，但许多在需求设计中还是会提到，也有一些比较细小的功能可能会被忽略，就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员，写出来的用例就完全是两个层次的。

　　（2）、完整业务流程的测试

　　我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。

　　事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再完全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。

　　（3）、某种特定情况下的系统运行

　　这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾一天、月头一天、年尾一天、年头一天，对所有相关功能中的日期处理进行测试；又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如；再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。

　　（4）、其它相关系统

　　即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数；以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时就不需要单独划分测试项；若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。

　　（5）、除功能测试外的其它测试类型

　　包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。

　　所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。
二、详细用例的设计

　　划分好了测试项，接着就是针对各个测试项，考虑具体的测试用例了。根据测试项的特点，测试用例的设计角度也有所不同。下面我们就来看看通常的功能点测试用例，该从哪些角度出发来进行设计：

　　1、功能切面表面用例设计

　　（1）、具体功能测试

　　根据需求分析设计，按页面提供的各个功能项，采用黑盒测试的各种方法，设计用例。比如页面提供了增、删、改、查功能，那么这四个功能是否正确实现就是我要验证的。这是最简单、最基本，同时也是必须的测试用例，通常我们的编码人员自测也就是做到这个程度。^_^

　　（2）、组合操作的测试

　　这是从上一角度扩展出来的，相对而言也是编码人员不会去测试的，所以需要测试人员多作考虑。

　　所谓组合操作测试，也就是选择某几个操作项，按一定的顺序进行操作，验证系统不会出现意外错误。当然要将所有功能项排列组合一遍来测试不仅不必要，也是不可能的。所以具体要将哪些功能项进行结合，要按怎样的步骤来操作，还是需要测试人员根据实际情况来作设计（所以说在IT业人才就是一切呀，呵呵：）。

　　一般来说我们会考虑功能项之间的数据是否会存在关联，若有就需要考虑这种组合了。常见的如查询功能，需要将各条件逐一累加进行测试；增完的数据能否改，改完能否删，删完能否再增，这之间能否查询到正确结果；按钮的连续多次点击会否出现异常；有严格前后顺序要求的几个操作，尝试颠倒顺序去操作，系统能否控制等等。

　　不仅在某功能内部，扩展到有关联的多个功能项之间，同样有组合操作测试的存在。如申报完了能才反馈；如申报成功或失败后再尝试申报等。当然对于这类用例既可以写到某个功能切面中，也可以单独写到完整业务流程的切面中，这就取决于可能涉及用例的数量了，若关系比较复杂，当然是单独写比较好；若也就是三五个用例数，那就直接在某个功能的用例中补充好了。

　　（3）、GUI界面的测试

　　这类测试是测试人员的强项，具体测试项目如限长、非法输入等等，就不必赘述了。要提醒的是在测试时，一定要从实际使用者的操作习惯出发。要知道界面原型所能确定的也只是页面的摆放显示，而实际操作时的控制实现仍是编码人员自行实现的，即使有编码指南，其所及范围也是十分有限。而许多编码人员在用户操作方便性上的考虑往往差强人意。所以测试人员就必须要把好这一关。

　　（4）、数据初始化情况测试

　　不该为空的数据是否有校验；该有默认值的数据默认值是否正确；引用其它功能生成的数据，是否会实时刷新；页面关闭或系统重启后，数据的初始化设置等都是这类用例。

　　（5）、业务需求实现是否正确

　　这类问题往往是由于我们的需求说明欠详细，而编码人员的需求了解程度又较低造成。作为测试人员自然要对需求进行深刻研究，来对软件实现进行把关。这里常见的一些关注点有：

　　●数据的长度、类型控制是否合理（比如控制纳税人识别号只能为数字，但实际业务中是会有字母出现的）；

　　●业务逻辑控制是否合理（比如某数据项不提供修改，但实际业务中该数据项经常会需要改动）；

　　●提供的实现方式是否合理（比如只在某一页面提供某数据的获取功能，但根据业务划分有些人员不能操作此页面，却必须要能看到该数据）；

　　●所做的数据控制是否合理（比如必须在A功能中新增数据，然后才能在B功能中操作，但实际业务中有可能会出现相反操作）；

　　●所做的数据控制是否完整（如授权的方式有普通按月、有买断、有按数量控制，那么当同一企业尝试同时存在以上几种授权方式时，系统是否能有必要的控制）；

　　●还有其它一些操作细节上的满足（如业务上需要批量操作的数据有否提供批量操作功能、导入失败的结果文件是否能修改后直接再导入等）。

　　对于不满足的需求，经开发组长、需求经理等确认不作修改的，就要作为软件的缺限或限制在测试报告中进行说明民。
2、功能切面隐含测试项用例设计：

　　（1）、数据完整性的测试

　　当某数据被其它功能引用；或当前功能要引用其它来源的数据，就会涉及到数据完整性的测试。最常见的如被引用的数据删除了，或关键字被修改了，引用的数据会否出错；两个途径进入的数据会否冲突或重复；此外还有因为相关的几个功能由不同人员编码，从而导致彼此的控制不一致，如A功能进入的数据在可允许的极端情况下，到B功能中引用会否异常（最常见如用户名录入时允许长度10，但引用到某个单子填写时允许长度是8，此时就会异常了）。

　　（2）、后台的特殊处理

　　是指某功能除了表面所见以外的程序处理。比如订单录入，表面所见的就是订单的保存，但后台还会有重复数据的判断、非法数据的处理、业务逻辑上冲突情况的处理以及其它种种根据需求设计所特有的处理。又比如备份功能，在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等。类似这些在分析设计中就未必会写全了，还是要测试人员多花心思去思考挖掘。

　　（3）、功能业务之间的关联与转换

　　相关联的几个功能之间数据的传递，会否产生影响。比如新增录入的某种特殊字符，要查询时会引起查询SQL语句异常；又如某下载文件名中存在中文等字符，下载时由于编码问题导致乱码的出现；再有报表填写时到小数点后四位，生成报文时会不会被忽略成两位了等等。象这种问题，通常只能是在每个功能设计用例时，尽量保证用例中的数据能涉及到允许范围的各种情况，即充分运用等价类划分+边界值的方法设计出各种“稀奇古怪”的数据，并需验证这些数据从头流到尾，都还是能保持其正确性，而不仅仅是在当前功能中正确。

　　（4）、从设计实现发掘测试点

　　这个就是我们测试中最难捉的BUG了，它往往是由编码人员自己在编码时创造出来的，连设计人员都不会知道。

　　比如内部管理系统中，正常的产品，其类别通常是2位数字；如果是模块，其类别就以产品代码来取代。这时如何来判断该产品是模块呢？最保险的当然是校验其产品类别字段的值能否在产品表中找到；也有比较简单的方法就是直接判断类别代码大于2位还是小于等于2位。此时若能确切知道采用的是哪种实现方法，就可以直接找到其漏洞所在。比如采用后一种方法，当产品类别长度变化时，明显系统会出错。那么即使确认该实现方式不改，测试人员也应将其作为限制写入测试报告，。让大家知道这个产品类别长度是不能随意变化的。

　　而让人郁闷的是，类似这样的实现，有太多的编码人员都是随性处理的，它们细而隐蔽，在系统数据正常情况下根本不会被发现；而在漫漫的软件使用道路中，由于需求变更等原因对原有一些设计做维护变化，这种问题就会突然暴发出来让人措不及防。所以要杜绝这类漏洞，除了测试人员要做土拨鼠，不停地对软件各功能的实现细节进行挖掘外，也要多给编码人员灌输完美实现的理念，多用复杂但抗压性高的代码，来替代简单但依赖性强的代码。

　　（5）、并发操作时的测试

　　即两个或多个用户同时操作同一功能时，会否引起数据的混乱。通常在C/S结构下，如果有同时操作的可能，是需要作此测试的；而在B/S结构下由于其特殊性，此问题通常难以解决。除非就是某用户一旦使用过某功能后，在一定时间内锁定不允许再用，但这也会带来实际应用中的不便，所以除非是特别核心的数据，一般我们也不会去做此控制，当然对于可能出现的并发冲突也就作为系统的限制进行遗留了。

　　3、特定切面用例设计

　　所谓特定切面，其实就是从另一个角度切割出来的用例面，所以具体的用例撰写方式其实与功能切面是一致的。

　　4、隐含切面用例设计

　　隐含切面分以下几种情况：

　　（1）、无界面的后台功能

　　对这类测试项，需要通过参数设置、代码调用等方式来实现测试，但具体的测试设计其实与普通功能测试并无二致。这里要注意，因为测试时往往前台、后台是分开来分别进行的，而实际运行时两者很可能是交集的，所以测试时要多注意后台功能的执行与前台的一些功能执行会否产生冲突？比如后台有个文件搬运的服务，那有没有可能在前台文件生成过程中，后台执行文件搬运了？若有可能就要注意会否出现问题了。

　　（2）、与业务流相关的测试

　　这类测试用例的设计，就要从完整业务角度来设计数据了。从理论上来讲，应该要将各个功能可能出现的各种数据排列组合到一起，按业务流程逐一进行测试。但实际上我们不可能去做全覆盖。所以设计这类用例时，最好有一张草稿，将所有相关功能按业务流程逐一列示，然后再将每个功能可能出现的特定数据一一标上，最后将图中最可能出现的、最可能出错的、最核心的数据取出来，分别组合成一个个完整的业务数据用例，来进行测试。这样就可以按清晰的思路，找出最实用、最有效的测试数据。

　　（3）、其它测试类型

　　这一类的测试通常都有其特定的方法。如要测可靠性就准备大量数据不停地执行；要测安全性就考虑数据的加密、数据的传输、数据的破坏；恢复性一般从网络、电源方面着手；配置安装则根据系统可支持的配置，搭建相应环境进行功能验证，此处的验证也要掌握技巧，即要多测试那些涉及到：数据库读写、磁盘文件读写、文件上传下载、文件加解密、数据统计、图表展现、打印等方面的功能。
三、测试数据的设计

　　每一个测试思路最终都要转化成具体的数据才能来执行。关于测试数据设计的方法也不外乎那几种，就不再赘述了。此处单就一些经常易犯的错误，提出一些注意点，作为用例数据设计时的参考：

　　1、尽量避免可能出现歧义测试结果的数据：即你设计的数据必须能唯一正确地反映出你所希望测试的结果。比如一组测试数据，有可能得到结果A或结果B，此时单用此数据来测试预期结果为A的用例，那明显就产生了歧义。

　　2、对于不便具体列示的数据，则必须详细描述其各项特性：有时我们在设计用例时为节约时间，不一定要到具体的一个数值，这也是允许的，但前提是你必须要详细描述清楚你要测试的数据特性。比如数据库字段限长20，要测试超长数据时，可以描述为：尝试输入长度为21位的半角英文字符；尝试输入长度为 19位的半角英文字符，然后切换到中文全角再输入一位全角字符等。千万不能写成：尝试输入超长字符，因为这只能是测试方案，作为方案是可以这样写，但到用例阶段，必须要是具体的、明确的、可操作的。

　　3、测试数据的设计必须有明确目的性：即测试数据是从测试方案衍生而来的。如上例测试方案是测超长字符输入控制，所以测试数据就要根据具体字段长度来录入超长数据，如果一味录入长15位、长16位的数据那就没意义了。好的测试数据是可以同时针对多个测试方案的，此时可以在用例边注明一下该数据的测试目的，因为随着时间推移，对着具体的数据你也许会忘了它到底是测什么的，而这对你最后总结测试，查验测试覆盖率是非常不利的，所以随时记下你的思路想法吧，好记性不如烂笔头。

　　4、测试数据可省略描述：测试数据描述以能让人看懂为准则。所以写用例时当碰到连续几个用例，仅某几个关键数据值改动，其余均是一样的情况下，不必每个用例都要重复描述所有数据，可以在第一个用例描述完整之后，其余用例中仅列示不同的数据，并标明其余数据同上第X个用例，即可。这样测试时仍能复原测试数据，且该用例的测试目的一眼就明，增加了用例的清晰性。

　　至些，我根据测试用例设计的顺序，从测试数据的切面设计（即测试项划分），到详细测试用例设计，再到测试数据设计三个层面，逐一介绍了如何来提高测试用例的覆盖度。因为具体项目中的具体情况太多，以上叙述的内容也只能是管窥蠡测。至于其中的疏漏错误之处应也难免，只希望各位阅后能打开思路，从自己多年的测试经验中多总结、提炼出一些想法思路，进一步补充完善这个文档，使大家的测试用例设计能力都能进一步提升。

posted @ 2012-08-13 09:59 顺其自然EVO 阅读(1239) | 评论 (0) | 编辑收藏

如何利用测试类型提高测试覆盖率？

缺陷分类的获取

posted @ 2012-08-13 09:47 顺其自然EVO 阅读(645) | 评论 (0) | 编辑收藏

测试用例能带来的（软件测试人生系列之六）

　　通过测试用例，我们都能获得些什么呢？

　　1、测试团队的质量判断。例如，测试用例的覆盖率。我们只需要去把所有的valid的功能bug去做一个分析，用所有在测试用例覆盖范围之外的bug数/总bug数，就可以作为测试用例覆盖率使用。一个良好的测试团队，这个覆盖率应该在80%以上。

　　2、测试人员的质量判断。一个测试人员，最重要的是测试用例的质量，而不是发现的bug的多少。

　　3、提高开发代码的质量。选择高severity和priority的测试用例，给开发人员进行smoke testing。从而使得进入测试阶段的代码已经避免了大部分P1和P2的bug存在。提高了测试的效率，减少了测试的资源消耗。

　　4、合理的制定测试计划。在制定功能测试阶段的计划，需要的人力资源，可以通过测试用例的执行平均效率来估算。从而得出大致的测试跨度。

　　5、通过对测试文档的共同review，可以让BA能够确认他们设计和需求分析转换的效率。开发人员能够更详细细致的了解所要开发的模块。

　　6、通过测试用例的complete rate，failed rate等，管理层可以很好的跟踪项目的质量状况和进度。

　　7、通过测试用例的分析，可以避免overlap区域测试用例的缺失。

　　8、最终用户可以使用测试用例熟悉产品。

　　9、Tech writer使用测试用例来书写用户手册是产品说明。

　　10、开发人员通过bug相关的测试用例能够更快的发现问题和更好的修复问题，减少带来的间接影响导致的新bug。

　　11、配置管理人员根据测试用例来更有效率的管理测试资源和环境。

　　12、support人员可以根据测试用例来对客户进行更加有效的支持。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

qileilove

敏捷——测试先行方法介绍

数据库程序设计中的约束、触发器和存储过程

游标、事务并发和锁三者之间的那点事

零基础学习SVN之（一）：SCM与SVN的使用（基础篇）

软件产品的需求管理浅析

Java 处理 XML 的三种主流技术及介绍

过程改进 “三七”法则

测试用例设计——如何提高测试覆盖率

如何利用测试类型提高测试覆盖率？

测试用例能带来的（软件测试人生系列之六）

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜

测试类型	测试条件：手机的基本呼叫功能
功能性	- 手机作为主叫，呼叫其他手机号码 - 手机作为主叫，呼叫特殊号码 - 手机作为被叫，接听电话 - 手机作为被叫，拒绝接听电话 - 手机作为主叫，主动挂机/被动挂机 - 手机作为被叫，主动挂机/被动挂机
易用性	- 手机号码输入是否简单方便？ - 手机接听是否方便？ - 手机拒绝接听是否方便？ - 通话状态显示是否简单易懂？ - 其他操作是否方便？
配置	- 呼叫转移配置 - 呼叫限制配置 - 呼叫等待配置 - IP电话配置 - 自动回拨配置
性能	- 最长待机时间测试 - 最长通话时间测试 - 每个小时通话12次，每次5分钟，检查待机时间
可靠性	- 呼叫异常号码 - 作为主叫，通话时间保持24小时 - 作为被叫，通话时间保持24小时 - 在充电状态下，作为主机呼叫72小时 - 在充电状态下，作为被叫保持72小时 - 通话过程中关机重启 - 通话过程中拔掉电板 - 通话过程中电池没有电了
可移植性	- 手机软件版本从1.0升级到2.0 - 在2.0版本中恢复1.0版本的内部数据库
容量	- 同时可以接听的电话数目 - 同时可以呼叫的电话数目
一致性	- 与电话呼叫相关的标准与规范一致性检查