Smile to yourself,both on your face and in your heart! MSN:lmjsmiling@hotmail

发布新日志

  • 随着敏捷的发展，测试人员会被淘汰吗？

    2011-06-21 16:52:36

    我们常常听到这样的描述：“在敏捷中，不区分任何角色，只有开发团队，团队中的任何人都可以做任何事，当然，这也包括开发人员做测试。”也经常听到这样的说法：“随着敏捷的发展，在不久将来的某一天，项目中将不再有测试人员。”而我们实际的敏捷项目中，也有些项目的确是没有专业的测试人员，开发人员在承担开发工作的同时，也承担测试工作。在敏捷时代，开发人员也可以编写测试代码，似乎测试人员真的可有可无。但，这是不是我们对敏捷的一种误解呢？

    在敏捷开发团队中，的确是鼓励团队中的成员参与多个开发活动、承担多种类型的开发任务（包括需求分析、设计、编码和测试等）。一些敏捷先驱不鼓励在开发团队中指定角色，比如明确划分需求分析人员、开发人员、测试人员、DBA等角色，但是，这个团队中必须有具备这些能力的专业人才。也正是因为这样，很多人都觉得敏捷中就是应该不分角色，也有很多敏捷开发团队中，都没有专业的测试人员，而是由开发人员承担测试任务。我们的项目也曾是这样的运作模式。

    然而，随着敏捷的发展日趋成熟和这种开发模式的问题的暴露，一些敏捷团队在敏捷实践的过程中也引进专业的测试人员，而这些团队的敏捷的经验和经历也证明，测试技能和经验对项目的成功至关重要，测试人员也增加了敏捷团队的价值。

    但这并不意味着敏捷团队的所有测试活动都是由测试人员来承担，敏捷测试和传统测试其中一个重要区别是“Whole Team Approach”，在敏捷中不单单是测试人员对团队的质量做保证，而是由这个团队的所有人员一起承担。这意味着所有人都必须对测试负责，由团队的所有成员一起完成这个团队的测试任务，而不仅仅是测试人员单纯地做测试。同时，也意味着，团队在开发设计的时候，必须考虑到测试，设计具有可测试性的框架和代码。这是我非常喜欢的敏捷思想。

    我们对比一下传统的测试，开发团队在完成编码工作后就直接Deliver到测试团队测试，由测试团队对软件的质量把关。在传统的开发模式中，开发团队在设计和实现的时候，很少会考虑到软件的可测试性，这给自动化测试带来一定的困难。而测试团队写好的自动化测试用例，也很可能会因为开发改了代码而导致测试用例运行失败，测试团队需要花很多的时间和精力才可以找到什么改动对测试用例带来的影响。但是，如果由敏捷团队的所有人员一起对软件的质量负责，团队中的测试人员和开发人员紧密合作，这些问题也将迎刃而解。

    敏捷测试和传统测试的另一个重要区别是持续地增量测试，测试人员和开发人员紧密地工作在一起，当某个user story完成编码后马上投入测试，只有编码和测试工作都完成，这个user story才算”Done”。在敏捷中，并不鼓励开发了一大堆User Story然后再集中式地测试。相应地，敏捷中的测试人员，也并不是一直在等到有测试工作了才有事情做，而主动地承担了测试相关的或测试以外的其它工作，协助团队顺利交互最大价值的产品。

    事实上，在敏捷中，测试人员的确起着非常重要的作用。很多敏捷团队的测试人员参与客户团队的需求分析工作，不但帮助激发更完善的客户需求，并且帮助客户用测试的形式来描述需求，这将作为开发的输入和客户验收的依据。同时，作为开发团队的一分子，测试人员会协助开发团队更完善更准确地实现需求，使开发团队交互最大价值化的产品。测试人员是需求和实现的桥梁。

    在敏捷开发团队，传统的角色需要转型，测试也不例外，纯粹的手工测试、任务式地完成测试工作的时代不再。敏捷不是不需要测试人员，而是需要具有更全面技能的测试人员，测试人员必须提高自己的能力，需求分析的能力、探索性测试的能力、测试编码的能力、全局把握的能力和沟通协调的能力，这些能力对测试人员在贯穿整个开发周期的过程中帮助开发团队交付更有价值的产品。

    查看(1214) 评论(3) 收藏 分享 管理

  • 机会的选择

    2010-12-26 22:44:59

    和同事聊天，普遍感觉外企的优势正在一点点地失去。十多年前的二十世纪九十年代，我们公司提供给应届研究生的工资是7、8K左右，而十多年后的今天，工资并没有太大的变化。左看公务员，虽然账面上的工资也没有太大的调整，但是灰色收入一路飙升，再加上其诱人的福利，并且又以稳定、清闲著称，成了就业选择的香饽饽。右看国内同行华为中兴新浪网易腾讯，开价一点也不比我们低，而且，随着时间的推移，他们的弹性收入更大。

     

    为了保持自己的竞争力，公司今年给应届毕业生的工资终于大方地涨了1K，这是近几年来涨幅最大的一次。而两年前进入公司的毕业生，按每年平均5％的工资涨幅，计算下来实际收入比这些2011年毕业的应届生还要低。同事抱怨：“为什么只有应届生才可涨工资？凭什么他们一进来就比我们的工资高？”我打趣：“嗨，你不知道吗？明年开始，我们普涨2K啊。”另一同事马上反驳：“Smilings，再散播谣言，把你抓起来关上三个月。”我只好老实地闭嘴。

     

    我很能理解同事的心情，因为在很长的一段时间里，我也是拿着比别人低的工资做比别人多的事情，不同的是自己假清高不好意思把钱挂在嘴边。但是，不得不承认，外企不再是十多年前那样成为大多数高校优秀毕业生的首选，它在中国的优势正在一点点地减弱。三年前，在我进入公司的时候，我的同学研究生毕业，面对着我们公司的offer和中国人民银行的offer，他毫不犹豫地选择了后者。而两年前，我的一个实习生，在我们公司和移动之间，虽然是有点犹豫但最终还是选择了后者。就在六个月前，我的另一个让我非常满意的实习生，拒绝了我们这个在IT领域颇为出名的外企，回到他的故乡的电力局。

     

    随着就业形势的好转和生活压力的增大，流动量不大的公司，今年出现了一轮人才流失热，而且，走的都是能力态度都不错的同事。S同学，离开公司，以非常人的思维到一家非常山寨的小公司的工作，而吸引他离开的，除了工作内容外，还有诱人的翻了三倍的工资。用他的话说，拿着高的工资花着更少的力气做自己喜欢的事情，何乐而不为？当然，他也曾拷问过自己的选择是否对，但不断怎样，他最终还是放弃了外企的工作走进了山寨工厂。而现在，他每个月剩下的存起来的钱，比我一个月的税前工资还高不少，并且，他的创业收入也正在一点点地增长。

     

    前段时间见到老同事，他问我：“想要到我们公司来吗？我可以推荐你。”我一时间反应不过来，也觉得很好笑，因为在过去的几年，都是别人问我：“你们公司还招人吗？”而同事之所以这样说，是因为他们公司是内地做某移动业务非常成功的一个公司，并且即将上市，而在上市前进入公司的员工，都会获得一部分原始股，因此，他们公司吸引了大批的优秀人才，这当中，包括诸多我的旧同事。腾讯上市给公司员工带来的利益，就是一个很好的例子。

     

    虽然这样，外企还是吸引了众多人才。相比公务员，外企的确是少了很多灰色收入和待遇，但是，不用对领导点头哈腰、享受具有创造力的工作状态、享有尊重和被尊重的工作文化，而这些是国企或公务员所不能比的。而国内的IT公司，虽然某些公司某些时候提供给个人的收入比较具有诱惑力，但是这是以牺牲自己的私人时间和身体为代价的。很多时候，我会觉得，中国人对自己同胞的剥削，比欧美的资本家要厉害得多。有时候，我也会觉得，国企对自己的同胞的人性的摧残，也远远高于欧美的资本家。一些在国企或事业单位工作的同学和朋友，几年后再见他们，已经认不得了，那些怀有梦想的、正义凛然的、朝气蓬勃的年轻的影子荡然无存。

     

    现在面试，每每遇到欣赏的同学，总会这样诱惑他们：“在这里，你有多大的能力，就有多大的舞台。”这是实话，因为在外企，它提供了更多更公平公正的机会，更多人是看人的能力，而不是关系。

     

     

     

     

     

    查看(484) 评论(1) 收藏 分享 管理

  • 自动化测试设计实战 － 移动广告系统自动化测试设计

    2010-12-26 22:22:35

    1                                      自动化测试框架

    1.1                                 测试流程

    1.1.1                            测试流程图

    自动化测试包括系统的安装和配置、模拟器的安装和配置、公用测试数据的准备、测试数据和配置的更新以及自动化测试脚本。如下图：

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     


    1.1.2                            测试流程说明

    系统测试准备：系统的安装和配置、模拟器的安装和配置、公用测试数据的准备这些动作，是自动化测试开始的前提，在自动化测试过程中的一次性行为。在系统测试中，公共的测试数据可以供整个系统使用，这些数据在系统安装配置完成后使用自动化测试脚本创建，创建好后存放在XML文件中。使用XML存放的好处是数据的复用。

    功能测试类：同属某功能的测试用例放在同一个JAVA测试类中，该测试类从XML文件中读取公共测试数据并验证测试数据的合法性，如果测试数据合法则使用这些测试数据，否则创建一套新的公用测试数据并将这套公共测试数据存放到XML文件中供其它测试类使用。同时，创建适合这个功能测试类使用的测试数据，并配置适合该功能测试类的配置参数。

    测试用例：如果某个测试用例需要某些特殊的测试配置和数据，在具体的某个测试用例开始的时候进行，在准备好数据后，获取当前测试数据的状态和设置预期结果，然后执行测试步骤，当所有的测试步骤都测试完成后检查测试结果。最后，一定要恢复测试环境，如果公共测试数据或配置被修改，一定要在测试用例结束的时候恢复。

    1.2                                 测试结构

    自动化测试框架由Data, Action, Verification, Cases和Util组成。如下图：

    1.2.1                            Data

    主要用于存放公共测试数据的定义，比如要创建的公用测试数据的定义，创建测试数据的Action在创建数据的时候从Data定义文件中读取输入，然后创建符合测试要求的测试数据。

    也用于存放数据结构的定义，比如，短消息的结构体定义或某测试对象的属性定义。

    Data中还会有常量定义，常量在整个系统中全局使用。

    1.2.2                            Action

    在测试过程中需要进行的任何操作，比如：配置、创建数据、测试步骤等。

    1.2.3                            Verification

    在测试完成后，对测试结果进行验证的类和方法。比如：检查接收到的广告内容是否正确。

    1.2.4                            Cases

    测试用例存放目录，相关功能的测试用例放在同一测试子目录中，同一功能的测试用例放在同一个测试类中。

    1.2.5                            Util

    主要是用于存放工具类。

    1.3                                 命名规则

    1.3.1                            包（Package）

    ·         All other letters are lowercase

    ·         E.g. pushcampaign

    1.3.2                            类（Class）

    ·         The first letter of every word is capital, all other letters lowercase

    ·         The class including test cases should end with XXXTest.java, or else should be XXX.java

    ·         For example: PushCampaignTest.java  

    1.3.3                            变量（Variable）

    ·         The first letter of the first word is lowercase.

    ·         The first letter of the every word except the first word is capital.

    ·         All other letters are lowercase.

    ·         For example: dailyBudget.

    1.3.4                            常量（Constant）

    ·         All letters are capital

    ·         The name should be meaningful

    ·         The name of different words should be joined by “_”

    ·         The name should start with “DEFAULT”

    ·         For example: DEFAULT_COUNTRY

    1.4                                 基本原则

    自动化测试的基本原则：

    ·         Reliable

    ·         Readable

    ·         Extensible

    ·         Maintainable

    ·         Practicable

    ·         Repeatable

    2                                      Data

    2.1                                 测试数据

    测试数据可分为三种：公用测试数据、功能类测试数据和用例测试数据三种。

    2.1.1                            公用测试数据(Common Test Data)

    公用测试数据是测试系统中所有测试用例都能使用的数据，在自动化测试用例开始运行前首先创建一套供所有测试用例使用的公用测试数据，这些数据可以包括：

    ·         Service Provider

    ·         Publisher

    ·         Publisher Pricing Agreement

    ·         Site

    ·         Inventories (One inventory for one channel)

    ·         Ad Sales

    ·         Ad Sales Pricing Agreement

    ·         Media Agency

    ·         Media Agency Pricing Agreement

    ·         Campaign (One campaign for one campaign type)

    ·         Consumer

    公用数据应存放在XML文件中供所有测试类使用，测试类在测试开始前先从XML文件中读取测试数据，并验证测试数据的合法性，如果测试数据非法则需要重新创建并保存到XML文件中。

    公用测试数据的创建流程：

    ·         根据数据定义文件创建公用测试数据(createCommonTestData)

    ·         保存公用数据到XML文件中(storeCommonTestDataToFile)

    在测试类中使用公用数据的流程：

    ·         从XML文件中读取公用测试数据(readCommonTestDataFromFile)

    ·         校验公用测试数据的合法性：存在于系统并且状态正常(verifyCommonTestData)，如果数据非法则重新创建。

    使用公用数据的好处是避免重复创建测试数据，节省自动化测试的时间。而存放测试数据到XML的好处是一方面可以重复使用这些测试，另一方面是遇到问题的时候可以方便地使用保存在XML的测试数据进行问题跟踪。

    公用测试数据不建议修改，如果非要修改，一定要记得恢复。

    2.1.2                            功能类测试数据(Functionality Test Data)

    同一功能的测试用例放在同一测试类中，当公用测试数据满足不了这个测试类并且某些测试数据又可以供这个测试类的大部分测试用例使用时，在测试用例开始运行前创建功能类测试数据。

    2.1.3                            用例测试数据(Case Test Data)

    某些测试用例需要特殊的测试数据，而且这些测试数据只适合于某个测试用例，则在这个测试用例测试前准备该测试用例的测试数据。

    每个与广告投递相关的测试用例，都创建一个唯一的用户，这样做的好处是方便计费日志的检查，并且，当用例运行失败的时候，唯一的用户ID也方便定位出错的原因。

    2.2                                 测试数据常量化

    公用测试数据应该用常量定义，这些常量在创建数据、使用数据、校验测试结果的时候可以使用。这样可以避免测试数据写死在测试用例中，当某个值被改变或参数被删除的时候，所带来的维护工作量。

    比如，每个广告投递一次需要1元，定义常量CAMPAIGN_DELIVERY_COST=1，那么在数据创建的时候可以使用CAMPAIGN_DELIVERY_COST这个常量，并且在检查这个广告投递成功后是否扣除1元也可以使用这个常量。

    2.3                                 测试数据结构体

    测试数据或测试对象定义测试结构体，供Action/Verification/Cases使用，比如：Publisher或Campaign这些测试数据根据它们的属性构成测试数据结构体；又如：短信广告内容这些被测试检查对象也根据他们的属性组成测试对象数据结构体。

    3                                      Action

    Action，顾名思义，就是在测试的过程中所作的任何操作。Action在自动化测试中可分为所有或某些测试类都可以使用的公用Action和某类或某个测试用例使用功能类Action两种，而这两种Action又可以分为原子Action和组合Action。

    Primitive Action就是一个不可被分割的简单操作，而Composite action则是由若干个Primitive Action组成的操作，如果某几个Primitive Action会被两个以上的地方使用，那么这几个动作应该封装成一个Composite Action。

    3.1                                 公用测试操作(Common Action)

    以下这些测试动作是全局使用的：

    ·         getCampaignBudgetImpressionClicks

    ·         getInventory

    ·         getChannel

    ·         optinConsumersByWebservice

    以下这些测试动作，适合于所有PUSH广告相关的测试，包括push campaign, survey campaign, incentive reward campaign和direct market campaign等与PUSH相关的测试场景：

    ·         configurePushEnvironment

    查看(477) 评论(0) 收藏 分享 管理

  • 年薪翻倍的跳槽

    2008-07-13 21:38:01

    我的同事C，也是我的好朋友，跳槽去了一个正在迅速发展的IT公司，年薪翻了一倍。而他，从准备找工作到工作敲定，仅仅一周。二十万的年薪，在IT行业，对于不到五年工作经验的人来说，是一个很不错的收入了，我的同事自然也很开心很满足。我的其他同事，还有我的朋友，听说后，都非常羡慕，觉得他的运气很好。我也觉得他的运气不错，但除了运气外，我更多地觉得，他具备了这样的实力，所以当机会来了，自然就是他的了。我也会觉得，他的实力，源于他的态度，源于他一点一滴的积累与提升。

    在与C合作的两年多的时间，我们的合作非常愉快，虽然存在异议，但是所有的争议都是为了把工作做得更好。我们的第一次合作，是一个短信过滤模块，产品出来后，是一个初步的原型，根据我对SMS的理解、业务的需求和维护方便，给他提了很多不错的建议，对于我所提的建议，他没像其他开发那样讨价还价，几天之后又交给我一个比较完美的产品。对产品的测试，我非常挑剔，不满足于简单的需求，在产品满足了功能需求后，继续进行了深入的测试、改进和性能调优；产品试行后，继续跟进产品在实际环境的运行情况，对产品进行二次完善，所有的这个过程，C都非常配合，力求完美，毫无怨言。最终，他开发的这个产品，是我们SMS系统中，功能最完善、故障最少的产品。如果当初，没有他积极的配合，也许，这个产品也像其他的产品一样，只是一个普通的模块，我再努力也是徒劳。

    在05年春节，我们的P2P系统出现了很大的故障，故障的原因无法定位也无法重现，当时整个团队都承受了很大的压力，我自己也在想方设法定位问题解决问题。那段时间，C给了我非常大的帮助，我们在一起讨论问题可能产生的原因，在交换各自的见解，每有一个新的想法就测试问题是否重现，同时配合代码白盒检查，将问题一个个地解决。我们都很清楚，这些隐藏的问题，仅仅靠一个开发或测试是很难定位的，需要的是一个配合良好的团队的努力。在后来的性能调优中，我提了很多建议，别的开发都没时间去做优化，是C主动接过了别人负责的模块，积极地配合我对P2P进行了长达两个月的性能调优与隐患挖掘，P2P最终成了一个从05年底到现在都无任何来自于软件的故障。现在再翻开我们合作完成的P2P性能调优报告，整整50页，每个改进都密密麻麻地写满了我们各自的原因追踪、改进建议和结果分析，现在再看，我自己还会感动。我想，这样的工作态度，是成就了他年薪翻倍的主要原因。

    在他刚进入公司的时候，回复bug也跟其他同事那样只是简单地写上“fixed”或“ok”，我对他说：“回复bug的时候，最好能够写上产生bug的原因、解决的方法、升级的步骤以及这个改动引起哪些变动，方便测试进行模块升级和问题跟踪，也方便以后维护管理。”从此以后，他所有的bug回复都非常详细、专业。但，我其他的同事，同样的话我重复了N次，部门经理也发邮件要求大家去遵循，但是没几个同事能够像C那样自觉、认真的地回复，也没几个同事可以坚持两年多来一直都是那样认真地回复每个bug。我想，这就是人与人之间的差距，从这么一件简单的事情上，可以看到不同的人的工作态度。我们在羡慕别人得到了好机会的青睐，以为这只是运气，但事实上，运气的背后，是他的付出。现在，当我们再回头查看两年前C所负责的bug，对于每一个问题，都可以从他的回复中看出当初问题产生的原因以及解决方法，对于公司来说，这无疑是一笔财富。

    我的这个同事，并不是一个非常聪明的人，也不是一个很能说会道的人，却是一个勤奋、认真的人，也是一个知道自己要的是什么的人。在项目不紧张的时候，他会主动去研究公司的核心产品，尽管那不是他所负责的，但他的主动为他积累了基础，也为他积累了机会；他甚至还会去学习与IT毫不相干的法律，为了维护自己的合法权益。他知道上班时间，也知道下班时间，上班的时候全部投入认真工作，但下班之后就很难得在公司找到他的影子。因为他觉得，下班了，就是自己的时间了，应该回家跟家里人一起分享。我非常欣赏他的这样的一种工作状态，也非常欣赏他的生活态度。公司的人才保留机制做得不好，他来公司两年工资的提高并不是很大，但他还是坚持以学习的态度认真做好他的工作，当他所负责的项目接近了尾声，他觉得自己的努力付出并没有得到相应的回报，所以决定离开。他知道自己的英文口语并不太好，没有像我那样一心坚持进管理完善的外企；因为决定了要离开，他也不像别人那样，边工作边找工作；他看中了一间正在迅速发展的公司，请了10天的年假，开始了他的应聘之路，而他也真的幸运，一周不到，就收到了他想去的公司的offer，当然，最令人兴奋的是他想去的公司满足了他二十万年薪的要求。

    同事C去新的公司上班将近一个月了，我的其他同事和朋友说起他新的工作，仍然羡慕不已，但我会觉得，这不仅仅是因为他的运气，而是因为在过去的几年中，他努力的付出、认真的学习、塌实的工作，当然，更重要的是他清楚自己需要什么，也努力去争取自己想要的。我的身边，很多人都会在抱怨自己工资不高，也有很多人抱怨自己没有机会，但是，他们很少在自己的身上去找原因，只是将一切归于运气。我很想对他们说，你是否觉得C的运气很好？那你是否也像C那样在好运降临之前主动、认真、塌实地做好每一件事情？

    其实，机会，并不是天上掉下来的馅饼，而是抓住机会的本事。当你历练出了抓住机会的本事，好运自然降临。

     

     

    Written by smilings in GuangZhou, Jun. 5h，2007

     

    查看(1238) 评论(7) 收藏 分享 管理

  • 寄望与争议并存的美丽传说

    2008-07-13 21:35:27

    寄望与争议并存的美丽传说

                                        ——CMMI L5在DM中的实施体会与思考

    DM在项目启动前，开发经理跟我说，DM的测试负责人，就由你来做吧！我自然是乐颠颠地接受了，对于我来说这是一个学习和施展的机会。事后，他问我：“你已经作为两个核心产品的测试负责人了，下半年的IAGW还要靠你去主导，是否分配的任务太重了？”我跟他说：“没事，我能行。”说句心里话，当时自己也不是十分肯定可以同步应付那么多的工作，只是很珍惜这个机会。对流程管理，在自学过程中有了一定基础和思考，但是没有真正地运用起来，这个机会正好可以让我认真地去学习全面的流程控制知识，应用一些新的理念。

    对于我们的team来说，以往基本上没有任何CMMI的基础，现在以CMMI5的标准来要求项目的实施，实施起来也会有一定的难度，意味着需要投入更多的人力物力，也意味着项目实施的阵痛更加剧烈。DM这个项目，按我们以往的开发与测试模式，3个月之内会完成所有的工作，虽然测试一般都是在产品完成代码编写之后才参与，但因为公司比较重视测试，且开发与测试的水平都不错，产品的质量是比较有保证的，经我们发布出去的产品在现网运行效果一直有较好的口碑。只是，缺少需求、设计以及代码的评审，大部分的问题都是在测试阶段发现并解决，这样一来，问题的修改成本相对比较高，而且产品的质量很大程度上依赖测试人员的素质和对业务的熟悉程度。这一点，我在以往的测试中一直强调，希望问题能够及早发现，也希望产品的质量能够尽量少地依赖个人。CMMI5强调通过各种的活动及早发现并解决问题，通过流程的控制减少产品质量的人为因素，这些正是我们所需要的。

    不过，每件事情都会有两面性，一个本来3个月就可以完成的项目，按照CMMI5的流程来实施，需要6个月，而且需要耗费更多的人力资源。特别是在项目的前期，大量的文档、评审，的确是需要投入非常多的人力和时间，而且也不能马上看到效果。从短期来看，当然是不划算，也看不到真正的收益，这就是为什么在中国大多数的IT公司都不注重流程控制、也是为什么CMMI到了中国实施起来就变了味儿的原因之一。国内的很多公司，对CMM或CMMI都是本着对付认证的态度，有点像在学校的学生应付考试的意味，这样的一个立场必然会是形式多于实际，因而站在开发人员的角度，CMMI可以说是个吃力不讨好的东西，投入大量的成本，最后大家忙得云里雾去却不见项目有任何进展，也因此引起了对CMM或CMMI各种争议。国内公司对于CMM/CMMI的热衷并不因为争议而停止或反思，向往的公司希望认证能给公司带来更多的机会，当然，也希望认证可以使开发更加规范。CMM/CMMI依然在上演着期望与争议并存的美丽传说。我曾经跟一个资深的工程师探讨CMMI在项目中的应用，他跟我说，他反对将国外的CMMI不经消化便套到项目实施中，因为流程管理在项目的应用中没有起到效果，反而是让人疲于应付各种流程各种文档，导致项目的开展效率低见效少抱怨多。末了，他颇具幽默地对我说，其实，coding并不是靠所谓的管理给管出来的。

    在DM的开发过程中，经历了项目经理变更，经历了开发工具的转换，经历了项目计划的调整，项目组成员同时兼顾DM与其它项目的工作，还有大量的评审、文档与任务报告，而项目的进展在短时间内看不到突破，很多流程在实施起来的时候，实际与理论的确相差甚远。这些，的确让项目组中的成员疲惫过，也怀疑过。幸运的是，虽然我们经历了阵痛，但因为有经验丰富EPG与PPQA的指导，还有一个年轻积极的团队，阵痛过后一切又豁然开朗。我想，这也是流程控制的一个好处，在任何项目中都无何避免地出现问题，当出现了问题能够及时有效地解决确保产品以高质量按时发布，这就是CMMI所要达到的效果。现在再回头看看，如果领导层没有那么大的决心或投入，如果团队中的成员抵触CMMI，我们也不可能那么顺利地通过评估，项目也不可能按计划完成。非常感激我们的PPQA，给了我们很多实际的建议，教会了我们很多东西。

    CMMI L5评估已经通过，DM的测试工作也将近尾声，对于我们来说CMMI L5才刚刚开始。CMMI当然是值得肯定的，同时也是需要改进的，正如我的朋友所说的经过消化后应用到项目的开发中，这样的应用才会美丽。这些天，我一直不断地在思考，CMMI L5给我们带来了什么？公司获得CMMI L5认证对于各个项目组而言有什么意义呢？对于我们的团队来说，投入那么大的精力在一个项目中实施CMMI L5，是否值得？如果CMMI5是为了认证而认证，为了过程而过程，确实没有任何意义，浪费时间浪费精力，一阵风过后所有的东西就都会了无痕迹，只不过是一个向外炫耀的幌子罢了。CMMI5实施的真正意义在于学习它的理论，将其中的精髓应用于整个团队，改进团队的开发与测试流程，提高产品的开发效率与质量。否则，在一个项目中投入如此大的成本，就真的太不划算了。在对CMMI5的应用熟悉到一定程度之后，不必实施CMMI5的所有活动，完全可以适当地剪裁适合项目组的流程并应用，相信这样效果会更好。另外，不同项目组之间的测试与开发，也应该多一些的交流，吸取对方先进的流程或方法理念，应用于自己的项目组。这些，当然，需要管理层认为有用并下决心去推动，而且团队中的成员也要积极支持，才会出现积极正面的效果。 否则，也会让人反问，这就是传说中的CMMI L5吗？             

    查看(502) 评论(1) 收藏 分享 管理

  • 软件测试报告模板

    2008-07-13 21:30:13

    第1章          引言

    1.1   编写目的

    本测试报告的具体编写目的，指出预期的读者范围。

    实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试情况以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）并对测试质量进行分析。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。

    小TIPS：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。

    1.2   名词解释

    列出本计划中使用的专用术语及其定义

    列出本计划中使用的全部缩略语全称及其定义

    缩写词或术语

    英文解释

    中文解释

     

     

     

     

     

     

    1.3   参考及引用的资料

    列出本计划各处参考的经过核准的全部文档和主要文献。

    第2章          测试概述

    2.1   测试对象

    对测试项目进行简要的说明。

    2.2   项目背景

    对项目目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。

    2.3   测试目的

    对测试项目的测试目的进行简要的说明，主要描述测试的要点、测试范围和测试目的。

    2.4   测试时间

    简要说明测试开始时间与发布时间。

    2.5   测试人员

    列出项目参与人员的职务、姓名、E-mail 和电话。

    职务

    姓名

    E-Mail

    电话

    开发工程师

     

     

     

    CVS Builder

     

     

     

    开发经理

     

     

     

    测试负责人

     

     

     

    测试人员

     

     

     

    2.6   系统结构

    对系统的结构进行简要描述。参考系统白皮书，使用必要的框架图和网络拓扑图能更加直观。

    第3章          测试方法

    测试方法和测试环境的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。

    2.1测试用例设计

    简要介绍测试用例的设计方法，使得开发或测试经理等人员阅读的时候容易对测试用例的设计有个整体的印象，特别是一些异常的设计方法或关键测试技术，需要在这里进行说明。

    3.1   2.2测试环境

    3.1.1硬件环境

    描述建立测试环境所需要的设备、用途及软件部署计划。

    “机型（配置）”：此处说明所需设备的机型要求以及内存、CPU、硬盘大小的最低要求。

    “用途及特殊说明”：此设备的用途，如数据库服务器，web服务器，后台开发等；如有特殊约束，如开放外部端口，封闭某端口，进行性能测试等，也写在此列；

    “软件及版本”：详细说明每台设备上部署的自开发和第三方软件的名称和版本号，以便系统管理员按照此计划分配测试资源；

    “预计空间”：说明第三方软件和应用程序的预计空间；

    “环境约束说明”：建立此环境时的特殊约束。如需要开发外部访问端口，需要进行性能测试等。

    平台1：SUN

    机型（配置）

    IP地址

    操作系统

    用途及特殊说明

    软件及版本

    预计空间

    SUN450

    10.1.1.1

    　

    　

    oracle8.1.2

    2G

    　

    　

    　

     

     

     

    　

    　

    　

    　

     

    　

    　

    　

    　

    　

    　

    　

    平台2：IBM

    机型

    IP地址

    操作系统

    用途

    第三方软件及版本

    预计空间

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　

    　 查看(12201) 评论(1) 收藏 分享 管理

  • 测试实施难题和对策

    2008-07-13 21:28:33

    一、不能重现的bug该如何处理？

    bug应该可重现，问题重现才可以让开发快速原因定位并解决问题。在测试的过程中偶尔会碰到一些不能重现的问题，对于这类型的问题应该：

    1、  首先，测试人员应该想办法重现，如果实在不行，也应该将bug产生的条件和出现的问题做一个记录，建议开发根据问题的描述来进行原因定位。当然了，即使开发解决了问题，如果不能重现，也不能有效地验证。

    2、  根据经验，一般的问题的产生都可以找到重现的规律的，只是看花的时间和成本。严重的bug一定要想办法找到原因，而优先级别低的问题可以考虑成本先将bug搁置，以后重现的时候再让开发解决。通常，不能很快找到规律的问题都是一些比较重要且奇怪的问题，开发一般不能根据描述进行定位，此时测试工程师应该有很强的责任心和信心想办法重现问题。

    3、  关于bug的重现，有一点非常重要的是，一定要开发人员与测试人员很好地配合，bug的重现效率才会更高，测试人员千万一个人不要闷头闷脑地在那冥思苦想，而应该及时把问题和看法与开发人员交流，毕竟程序是他们写的，大家一起探讨可以有效地促进问题的解决。复杂的问题并不是一个人就可以轻易就解决的，而是一个团队的结晶，要懂得充分利用团队的力量。

    4、  注意bug出现的时候的日志，通常程序日志都包含着很重要的信息，从那些信息中分析出现问题的条件，并尝试重现。

    5、  碰到问题时，应该尽量将出错信息作为关键字在互联网搜索，有可能别人也碰到了类似的问题并解决了，即使没有人解决过相同的问题，在互联网上也有很多资料，可以帮助你获取灵感。

    6、  必要时，写一些简单的测试程序来帮助重现问题。

    下面我会讲一个在实际测试过程中不能重现的问题的解决方法与过程，可能这个问题对于刚入门的人来说有点难理解，不要紧，你不需要看明白问题的原因和代码，但需要学会这个复杂的问题的解决方法，并应用到实际的测试当中。

    1、  问题的描述：某短信发送模块出现core，但由于core信息紊乱不能定位到出错原因且无法重现导致core的规律。

    2、  问题重现过程：

    （1）       使用gdb对core原因进行追踪，发现core信息中含有的错误信息为：#0  0xff1c5a18 in _malloc_unlocked () from /lib/libc.so.1
    #1  0xff1c57f0 in malloc () from /lib/libc.so.1

    （2）       以这两句core信息作为关键字在google上搜索，一些文章上类似问题的分析中获取经验，初步推断是由于内存溢出而产生的core

    （3）       将这些文章转发给开发负责人，并讨论可能导致的原因，开发从文章中获取灵感，写测试程序对推断进行测试

    （4）       同时测试人员详细分析程序运行日志，发现出现core之前，短信编码为平时少见的245，而短信的长度则是一个临界值140字节

    （5）       测试人员从程序运行日志中得到启发，发送一条短信编码为245且短信长度为140字节的短信，果然出现了相类似core

    （6）       开发人员分析根据测试结果分析导致core的原因： 调用sprintf打印短信内容的时候导致了内存溢出，而这样溢出会覆盖它后面的内存块的内存管理区域，在紧接着的malloc操作中就会发生段错误，从而导致了core的出现。

    这个问题的原因，因为多人的参与，得到了准确的定位和解决，虽然原因是我最先发现的，但问题的准确定位和解决并不是归公到某个人，而是大家一起努力的结果，团队的结晶。

    二、暂时无法解决的问题

    在测试的过程中，开发可能会在bug回复的时候告诉你暂时无法解决该问题，这个时候作为测试的负责人，应该怎样处理呢？

    1、  首先，确实问题是否真的无法解决，解决需要付出的成本有多大。

    2、  其次，确认问题的严重性，如果此类问题不解决，是否会导致严重的后果。

    3、  对于会导致严重后果的问题，一定要坚持让开发解决，并且想办法帮助开发解决问题。测试人员应该主动协助开发人员找到问题的原因和解决方法，并充分利用团队的资源，请教对这个领域比较有经验的工程师，大家一起讨论问题的解决方法。

    4、  对于对系统不会造成危害的问题或虽然有微小的危害但修改成本过高而又可以人为避免，则可以将问题遗留到下一版本解决或关闭这个bug，并在bug报告中说明原因和注意事项。

    5、  这个时候，测试人员的态度非常重要，在告诉开发这个问题一定需要解决的时候态度是温和的坚定，并让他意识到问题的严重性。试想想，如果你板着脸孔冷冰冰地丢给开发一句“这个问题一定要解决！”扭头就走，他会是怎样的反应呢？可以笑的时候就笑吧，大家都是工作，不要将工作的氛围搞得太僵，大家在一个和谐的环境中工作才会保持愉悦的心情。

    6、  发现问题之后测试人员可能心里会嘀咕“反正这是开发的问题就让开发去折腾吧”，如果你一不小心这样想了，那就偷偷的想几秒钟好了，这个念头闪过之后，作为bug负责人的你怎么忍心看着开发一个人手忙脚乱呢？测试和开发其实是一个整体，在这个整体中的每个人都有责任去解决问题。

    三、测试工程师和开发工程师的意见不一致

    1、  首先，客观地比较自己的建议和开发的意见哪个更好。

    2、  如果开发的方法的确是比较优化，那就应该接受开发的意见；如果经过对比之后还是觉得自己的建议更好，那就坚持自己的建议，并详细给开发解释你的建议，通过对比两者之间的差别婉转地告诉开发你的建议值得采纳。

    3、  如果双方还是对各自的意见相持不下，可以跟项目经理一起讨论，由项目经理衡量应该采取哪种处理方法。不过，有时候，项目经理也不一定站在你这边，你可能还需要花脑筋说服项目经理或被项目经理说服。

    4、  当然，这个问题的讨论前提是问题值得花时间和精力去研究讨论，如果是一些比较简单或次要的问题，就没必要花那么长的时间去计较了，放过开发吧，也许他真的觉得这个问题没必要这样修改或者是他也修改到很累很烦了，这么简单的一个问题何不让开发轻松一下？

    四、开发工程师不配合工作

    1、  先进行一个自我检讨：我的态度有问题吗？我报的bug是否都描述清楚了？我所发现的问题是否有价值？如果这些问题的答案是否定的，那么自己先改正了，开发会看大到你的改变，也会调整自己的态度的。

    2、  在一个团队中有一、两个不合作的开发工程师是正常的，不可能每个人都那么配合那么好态度，也没必要自己觉得很难受，因为问题在于他的身上，你做对了自己该做的就行了。

    3、  不要去逃避，双方之间换一种有效的沟通方法。比如，在MSN上交流不清楚，就换成电话或面对面，听到你愉快的声音或看到亲切的面孔，对双方之间的互动更加有帮助。但不要说着说着就火冒三仗，面红耳赤了哦！如果你也是火暴的脾气，面对面交流双方很容易争执起来，那么就通过MSN或邮件来交换意见吧！总之，交流的方式是很多的，选择双方更能有效沟通的交流渠道会达到事半功倍的效果。

    4、  尽量避免与对方直接冲撞。人的自尊心都是很强的，学历越高或能力越强的人，通常自尊心也是越强，你尊重他他才会尊重你，说得通俗点，你给了他面子、给了他台阶，他才会给你面子给你台阶。即使双方之间发生了争执，也不要太过介怀，只是工作而已，大方点继续对他真诚的微笑。

    5、  如果他实在不配合，必要的时候，可以适当表达你的立场，或者委婉地向他的领导反映或者将你们之间的交互邮件抄送给他的领导。这是一个有效的方法，但同时也是一个容易引发新的矛盾的方法，记住这样做是为了有效解决问题，而不是在别人背后“打小报告”。这是在工作，对事不对人。

    在我的team中，有一个开发的态度非常不配合，不管是对我还是其它的测试人员。

    五、如何处理不能迅速定位的工程故障

    对于一些不能迅速定位的工程故障，开发很自然寄望于测试环境能将问题重现，如果能够轻易在测试环境重现，那肯定是一件好事，不过通常如果是一些简单的容易出现的问题，在测试的时候肯定就已经发现问题了；正是因为问题的复杂或者是一些测试时没有考虑过的问题，才遗留到工程上导致出现故障。

    1、  查看工程环境程序日志，如果没有查询的权限，请工程实施人员帮忙查找，分析日志查找到问题的原因或相关线索。

    2、  如果日志的提示信息足够，可以根据日志定位原因，则在测试环境中按照日志提示构造条件相同的测试案例测试，尝试在测试环境中将问题重现。

    3、  如果不能从日志中获取足够的信息，而且测试环境中也无法把问题重现，那么先跳出思维定势，想想为什么会出现这样的故障，可能导致的原因有那些，自己还有哪些测试点或异常没有考虑到，测试环境和配置与实际的工程环境和配置有哪些差异等等。同时主动与开发负责人、工程实施人员以及有经验的项目经理讨论，分析可能导致的原因。

    4、  请工程实施人员将工程环境的配置文件和执行程序帮忙ftp到本地测试环境，在测试环境中使用实际工程环境的配置文件和执行程序，并尽量模拟实际环境搭建测试环境。

    5、  在模拟实际环境的测试环境中，根据分析的可能原因构造测试案例测试，尝试在测试环境中将问题重现。

    6、  问题重现后协助开发解决问题。

    7、  验证解决后的程序是否仍然会出现类似故障。

    8、  总结出现故障的原因并作记录，如果是配置的问题需要提醒工程人员在实施的时候注意，如果是测试疏忽的测试点要在测试报告中记录并在案例库中增加相应的案例，如果是某些异常开发没有考虑全面要总结类似的问题并提示所有开发注意。

    下面是一个非常难定位的工程故障的实例，希望这个工程故障的解决方法和态度能够给你一些启示。

    1、  问题描述：在某省某短信业务高峰期，实际处理的短信比接受到的短信少，也就是在系统处理某环节丢失了部分短信。

    2、  问题进展：

    A、 实际工程环境的日志没有任何错误提示

    B、 相关模块的负责人进行代码白盒检查，也没办法从代码中看出缺陷

    C、 测试环境没有出现工程所描述的故障

    3、  问题解决：

    A、  登录实际的工程环境，查看所有相关的程序日志，但程序的日志都正常，不能从中得到启示和帮助。

    B、 根据推测可能的原因，在测试环境中试图使用大压力测试，但也没出现工程所描述的故障。

    C、 与开发负责人、项目经理和工程人员讨论可能导致故障出现的原因，并根据讨论结果设计测试案例、测试方案。

    D、将工程实际环境的配置和执行文件拿到测试环境，并模拟工程环境搭建测试环境，发现其中配置存放短信的配置项比实际测试环境的大两倍。也就是：

    ; queue size, in byte, 20MB

    QueueSize=20971520

    ; max ISMG queue length, 0 means no limit

    MaxQueueLen=50000

    E、 模拟出现故障时的业务压力，发现当发送队列MaxQueueLen超过了46807后，不会继续增大，永远不会到达50000，也就是说永远不可能出现队列满的情况，模块永远不会报队列满的错误；所以系统只要接收到信息就往队列里放（只有该模块队列满或者连接不上等异常出现的时候才会存放到短信缓存器），而该模块共享队列最大只能存放46807条信息，多余的信息也便丢失了。

    F、 建议开发人员修改程序，当短信存放超过了实际存放长度或配置长度，就提示错误并将短信存放到短信缓存器，确保短信在高峰期得到保障。

    G、给工程人员提供配置建议。共享队列大小、队列长度与网关连接个数之间的关系应该满足：对于共享队列大小为QueueSize=20971520，MaxIQueueLen，网关连接个数为之间的关系为：网关连接个数*MaxQueueLen<=40000。因此，若网关个数为1，则MaxQueueLen的安全大小是MaxQueueLen=40000。

    H、 开发人员修改程序之后验证问题：（1）、仍然保留MaxQueueLen=50000配置不变，压力测试，当短信发送队列MaxQueueLen超过了46807后，系统能够提示错误信息，并将短信缓存到短信缓存器。（2）、配置MaxQueueLen=40000，压力测试，当短信发送队列MaxQueueLen=40000的时候，系统提示错误，并将短信存放到短信缓存器。

    六、资源不足该怎么办

    1、  现有的资源是否能解决

    2、  能否可以借用资源

    3、  向领导反映并说明问题的严重性

     

    查看(404) 评论(0) 收藏 分享 管理

  • 性能测试小Tips

    2008-07-13 21:27:06

                                       性能测试小Tips

    1、  性能测试的目的：通过测试确认软件是否满足产品的性能需求，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

    2、  性能测试指标的来源：测试的依据是产品的需求规格说明书；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。

    3、  性能测试的指标：服务器的各项指标（CPU使用率、内存占用率、硬盘占用率等）、后台数据库的各项指标和软件的响应时间：

    （1）       操作系统有关的指标：CPU平均利用率、内存平均占用率、硬盘占用率、I/O数量、网络时延

    （2）       数据库有关的指标：I/Owait、Mem平均使用率、cpu平均使用率、在一次I/O操作中所读的最大BLOCKS数、Log的增长情况、数据库的访问速度、数据库能支持的最大用户数、数据库CACHE命中率、不同数据库参数下的性能情况、锁的处理

    （3）       软件有关的指标：交易的平均响应时间（从接收请求到回复响应的时间）、每秒交易数量（单位时间里的执行次数）、对中间件功能的调用、远程处理延迟

    4、  查看性能指标的命令和方法：

    vmstat：虚拟内存的统计（cpu/io）

    iostat：设备的IO统计

    netstat：网络活动信息统计

    top：内存统计

    cat /proc/meninfo：查看系统的总men大小

    cat /proc/cpuinfo：查看系统总CPU大小

    df –k：查看系统硬盘大小

    举例说明：

    （1）查看CPU使用情况的命令

    每5秒刷新一次，最右侧有CPU的占用率的数据：$ vmstat 5 
          top 然后按Shift+P，按照进程处理器占用率排序：$ top
     （2）查看内存使用情况的命令

         用free命令查看内存占用情况：$ free
         top 然后按Shift+M, 按照进程内存占用率排序：$ top 

     （3）查看网络流量

    可以用工具iptraf工具：$ iptraf -g
         针对某个Interface的网络流量可以通过比较两个时间网络接口的RX和TX数据来获得：$ date; ifconfig eth1或$ date; ifconfig eth1

    （4）查看磁盘i/o
         用iostat查看磁盘/dev/sdc3的磁盘i/o情况，每两秒刷新一次： iostat -d -x /dev/sdc3 2
        用vmstat查看io部分的信息： vmstat 2

    5、  常用的性能测试工具：

    MI:Loadrunner,
    Compuware:Qaload
    Rational: Rational PerformanceStudio

    6、  性能测试开始与结束时间：

    开始：系统功能测试完成之后，如果某个功能修改比较大或增加新的功能，也应该重新进行性能测试。

    结束：系统满足各项性能要求、能满足实际使用情况并提供测试报告。

    7、  性能测试、压力测试、负载测试与容量测试：性能测试包括负载测试、压力测试和容量测试三种主要测试类型。

    （1）       性能测试：在正常的负载和配置下程序的响应时间和吞吐率。性能数据的提取通常是通过不断调整压力来获得的。

    （2）       压力测试：通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变，考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在，模拟巨大的工作负荷以查看应用程序在峰值使用情况下的处理能力和承受能力。通常是通过不断调整压力来提取系统的最优性能数据的。

    （3）       负载测试：长时间在超负荷环境中运行，程序是否能够承担。这其实是长时间的大压力测试，主要检查系统的稳定性（比如程序在负载的时候是否会coredump）以及系统的资源占用情况是否合理（是否出现内容泄露或CPU爆涨或某资源使用之后不释放）或者是否会出现异常（比如系统不能正常运行）。

    （4）       容量测试：使程序经受大容量数据处理的检验，一般地说针对数据库而言，是在数据库中有较大数量的数据记录情况下对系统进行的测试。

    8、  性能测试方案的要素：

    （1）       确定性能指标

    （2）       设计测试场景

    （3）       确定需要测试收集的数据

    （4）       确定测试方法

    （5）       确定测试步骤

    9、性能调优工作的准备

    （1）收集系统信息

    A、  主要的服务或者应用

    B、  用户数及使用方式

    C、  系统有哪些进程，都在干什么，使用了多少cpu、mem

    D、  系统配置情况：cpu、mem、disk(连接方式RAID)及其占用情况

    E、  最近所做的改动（硬件、软件、内核）

    （2）判别性能瓶颈

     

     

     

    查看(324) 评论(1) 收藏 分享 管理

  • web测试实例

    2008-07-13 21:23:39

    第1章          引言

    1.1   测试目的

    走进1510部落，每天看里面的文章与评论，里面的文字透露出来的真实、正义、责任以及每个人为普通老百姓发出的声音，让我心里有一种非常特别的感动。因为这份感动，我开始思考我能为1510做些什么，我想，能为1510做的，肯定是积极的参与1510的建设。于是，我利用自己的空闲时间，以一个普通的用户的角度去访问1510部落，记录测试过程中发现的问题，希望自己的建议能使网站更加完善、专业、友好，也希望1510为越来越多的人喜欢。

    1.2   测试对象与范围

    测试对象：1510部落（http://www.my1510.cn/）

    测试范围：系统基本功能测试

    1.3   测试时间

    2007年6月

     

    第2章          系统功能与测试方法

    2.1   整体界面

    测试功能描述

    检查点

    整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感觉

    1、  每个页面是否都有导航条，导航条是否一致，从导航条链接到的每个页面是否正常，导航条是否直观

    2、  整个Web应用系统的设计风格是否一致

    3、  用户浏览Web应用系统时是否方便、友好，用户能否凭直觉可以方便找到要找的信息在什么地方

    4、  所有链接是否按指示的那样确实链接到了该链接的页面；所链接的页面是否存在；Web应用系统上是否没有孤立的页面

    5、  页面版式在600x800 或 1024x768 的分辨率模式下是否显示正常，文本和图片是否对齐

    2.2   网站核心功能（导航条功能）

    测试功能描述

    检查点

    首页

    1、  页面的整体风格是否一致、和谐、友好、直观、易用

    2、  能否正常阅读文章，文章的文字、图片和评论等能否正确显示

    3、  被打开的文章，尚未登录，能否被收藏，是否提示用户先登录再收藏；登录后，能否正常收藏，收藏后的文章能否打开

    4、  被打开的文章，尚未登录，能否发表评论，是否提示用户先登录再发表评论；登录后，能否发表评论，发表评论内容为空或过长或含有特殊字符是否处理恰当

    5、  被打开的文章，“顶一下该文”，能否增加分数

    6、  首页的其它功能，能否正常打开链接

    7、  “[部落头条]” 能否正常打开链接，能否正常阅读部落头条的文章，在该页面能否正常打开该页面其它功能链接

    8、  “[1510报童]”能否正常打开链接，能否正常阅读报童的报道，报道的呈现是否友好、直观

    9、  “[编辑推荐]”能否正常打开链接，能否正常阅读编辑推荐的文章，在编辑推荐的页面能否正常打开该页面其它功能链接

    10、          “[顶榜]”能否正常打开链接，能否正常阅读顶榜的文章，在顶榜页面的文章的排行榜是否正确、合理，在顶榜页面能否正常打开该页面其他功能链接

    11、          “[最新更新]”能否正确打开所列出的更新的文章

    12、          “[最新评论]”能否正确打开该评论所在的文章

    13、           “[部落视频]”功能能否正常打开链接，能否正常观赏视频，视频是否流畅，在该页面的链接能否正常打开

    14、          “[部落podcast]”功能能否正常打开链接，能否正常收听音频，音频是否流畅，在该页面的链接能否正常打开

    15、          “[看图说话]” 功能能否正常打开链接，能否正常观赏视频，视频是否流畅，在该页面的链接能否正常打开

    16、          “[收风站]”能否正常打开链接，未登录能否报料，登录后能否正常报料，报料内容为空或过长系统能否正常处理，email为空或不正确系统能否正常处理

    17、          “[好文共享]”链接能否正常打开，成否正常推荐文章，推荐文章时填写的URL不正确是否能否正常处理，尚未登录能否推荐文章

    18、          “[热门标签]”能否链接到相关标签所对应的内容

    19、          “搜索”功能能否正常搜索关键字，当搜索的关键字包含特殊字符、为空或过长，系统能否正常处理

    20、          分页显示是否正常

    事时观点

    1、  页面的整体风格是否和谐、舒适、直观

    2、  能否正常阅读文章，文章的文字、图片和评论等能否正确显示

    3、  被打开的文章，尚未登录，能否被收藏，是否提示用户先登录再收藏；登录后，能否正常收藏，收藏后的文章能否打开

    4、  被打开的文章，尚未登录，能否发表评论，是否提示用户先登录再发表评论；登录后，能否发表评论，发表评论内容为空或过长或含有特殊字符是否处理恰当

    5、  页面的其它功能，能否正常打开链接

    6、  分页显示是否正常

    所见所闻

    同上

    好书好电影

    同上

    财经看点

    同上

    科技新知

    同上

    我的空间

    1、  用户尚未登录，系统是否做了权限管理，不能访问该功能

    2、  其余同上

    1510房客

    1、  能否正常显示1510的房客信息以及房客的文章

    2、  点击某个具体的房客/推荐用户/普通用户能否正常进入该房客/用户的空间，进入房客/用户的主页后能否正常阅读该房客/用户的文章，能否打开该页面的其它功能链接

    3、  1510房客或推荐用户或普通用户多于一页，能否正常分页

    4、  操作是否友善

    2.3   My1510后台管理

    测试功能描述

    检查点

    权限

    1、  用户尚未登录，不会在导航条显示[我的空间]功能，不能操作[我的空间]所有功能

    2、  用户登录超时后，不能操作[我的空间]所有功能，系统应该提示用户登录后再继续操作

    3、  没有管理员权限的用户，不能执行登录超级管理页面

    发表文章

    1、  主题或内容或类别为空能否发表，主题或内容包含特殊字符能否处理

    2、  主题、内容和类别都合法，能否发表成功，发表成功后能否在相应的类别查看已经发表的文章、能否在自己的空间查看已经发表的文章

    3、  发表文章时，能否正常上传图片，如果上传的图片不止一张能否正常处理

    4、  发表文章时，上传图片为空、图片路径查找不到或图片太大等异常出现，系统能否正常处理

    5、  发表文章时，能否正常选择或填写标签，标签能否在发表的文章中正确显示

    6、  已经发表的文章能否正常删除，已经被删除的文章是否还可以浏览

    7、  已经发表的文章能否正常修改，已经成功修改的文章能否浏览到已经被更新后的内容

    8、  发表多篇文章，在我的空间的管理页面能否正常分页

    9、  增加/修改/删除/文章或图片的提示信息应该：

    （1）       是否有操作成功的提示，提示是否友好

    （2）       是否有操作失败的提示，提示信息是否完整、正确、友好

    （3）       删除操作前是否有确认删除的提示

    （4）       操作完成后的返回页面是否正确、合理

    10、          发表文章的操作是否友好、易用、完善

    11、          增加/修改/删除文章，执行以下排列组合：

    （1）       增加——>增加——>增加 （连续增加测试）

    （2）       增加——>删除

    （3）       增加——>删除——>增加 （新增加的内容与删除内容一致）

    （4）       增加——>修改——>删除

    （5）       修改——>修改——>修改 （连续修改测试）

    （6）       修改——>增加 （新增加的内容与修改前内容一致）

    （7）       修改——>删除

    （8）       修改——>删除——>增加 （新增加的内容与删除内容一致）

    （9）       删除——>删除——>删除 （连续删除测试）

    发表推荐

    参考“发表文章”

    发表报料

    参考“发表文章”

    发表悄悄话

    1、  收信人正确、内容合法，能否正确发表悄悄话

    2、  收信人不存在，系统能否正确处理

    3、  收信人与发信人相同，系统能否正确处理

    4、  发信内容为空或过长或包含特殊字符，系统能否正确处理

    5、  悄悄话发表成功后，能否在“我的发件箱”中阅读/回复或删除悄悄话

    6、  “未读信息”是否正确显示，能否正常阅读未读信息

    7、  “我的收件箱”功能能否正确显示收到的悄悄话，能否正常阅读、回复或删除信息

    8、  信息超过一页时，能否正常分页显示

    个人资料

    1、  注册时填写的资料，是否正确保存，能否在个人资料中正确显示

    2、  修改个人资料，能否正确保存与显示

    3、  能否正确更换图片，当图片为空、过大或查找不到路径时，系统是否合理处理

    4、  个人资料的完整性检查：

    （1）   昵称修改为中文/英文或空

    （2）   必填资料为空，系统是否合理处理或提示

    （3）   用户填写的出生日期等的格式不正确，系统是否提示恰当。

    （4）   密码与确认密码不一致或长度不正确，系统能否检测

    （5）   邮件的格式不正确，系统能否检测出来

    （6）   如果使用了默认值，检验默认值的正确性。

    （7）   输入特殊字符（英文单、双引号，&符号和%符号），检查系统对特殊字符的处理

    （8）   输入长度超过最大长度限制，看系统如何处理。

    （9）   在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型)，看系统是否检查字符类型，是否报错.

    管理收藏

    查看(701) 评论(0) 收藏 分享 管理

  • CMMI5在项目中的精简应用

    2008-07-13 21:10:40

    CMMI5在项目中的精简应用

       

         CMMI5在小型项目中的成本过高，根据自己对CMMI5的实施体会与在实际项目中的应用，在项目实施的过程中精简了CMMI5的实施流程和部分文档，这个精简的流程在项目实施的过程中既可以确保流程规范与质量信赖又可以节约项目成本。以下跟大家分享一下CMMI5在项目中的精简应用：

     

    一、需求与规范的管理

    1、               由测试负责人（或专门的需求分析负责人）统一接收来自移动总的行业网关相关规范和新需求，测试负责人浏览规范获知大意后回复邮件，将规范和新需求转发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；

    2、               测试负责人（或专门的需求分析负责人）、项目经理仔细阅读规范与需求后，对规范和新需求进行研究，并就难点和疑点进行讨论，整理出重点内容，并将重点内容发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；

    3、               开发经理、项目经理、测试负责人、需求分析负责人、相关的开发人员与测试人员开会对规范、需求和重点内容进行讨论，确定需求的具体含义以及最终实现的需求和功能点；

    4、               项目经理根据规范、需求和开会讨论结果编写《需求规格说明书》与《功能列表》，测试负责人（或专门的需求分析负责人）对文档进行检查并修改完善，然后commit到CVS；

    5、               测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS。

     

       二、项目计划与测试计划

    1、              由开发经理组织项目计划讨论会，在讨论会上各开发负责人对自己所负责的模块所需要的工作量进行评估，根据工作量和工程需求初步确定总体开发计划、测试计划和发布时间；

    2、              项目经理根据估算工作量和工程需求编写项目计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的项目计划；

    3、              测试负责人根据项目计划与发布时间编写测试计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的测试计划；

    4、              项目计划与测试计划编写完成后发送给开发经理、项目经理、相关的开发人员和测试人员，开发经理、项目经理、相关的开发人员和测试人员阅读项目计划、测试计划后将建议和意见以邮件的形式反馈给项目经理与测试负责人，项目经理与测试负责人收集大家的邮件分别对项目计划与测试计划进行修改完善，同时回复邮件说明项目计划与测试计划修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的项目计划、测试计划commit到CVS；

    5、              测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS。

     

    三、开发设计与评审

    1、               项目经理构思系统设计，项目组开发成员一起讨论系统的设计，对设计形成较为清晰的思路；

    2、               项目经理负责编写概要设计文档，与开发经理、开发团队成员与测试负责人一起讨论概要设计；

    3、               概要设计完成后，项目经理编写详细设计文档、数据库设计文档和编码规范，各模块负责人负责编写所负责的模块进行详细设计；

    4、               设计文档编写完成后，发邮件通知开发经理、项目经理、测试负责人、相关开发人员和测试人员；

    5、               开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的概要设计文档、详细设计文档进行审查，将建议和意见以邮件的形式反馈给模块负责人；

    6、               模块负责人收集邮件中的修改建议并对设计文档进行修改，同时回复邮件说明详细设计修改情况，修改后的详细设计commit到CVS；

    7、               如果对设计存在争议或出现明显不合理的设计，召开一个小型会议对异议进行讨论，有效解决设计所出现的分歧；

    8、               测试负责人（或专门的PPQA）对开发最终修改的详细设计计划进行检查，并确认所有文档都已经commit到CVS。

    注：在大型的项目中，必须先完成概要设计后再完成详细设计，在小项目或需求中可做适当剪裁概要设计与详细设计合在一起完成。

     

    四、测试方案与评审

    1、               在项目的设计阶段，测试负责人根据规范文档、功能列表和概要文档编写总体测试方案与性能测试方案；

    2、               测试方案编写完成后，发邮件通知开发经理、项目经理、相关开发人员和测试人员；

    3、               开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的测试方案进行审查，开发经理和项目经理对测试方案进行总体性的审查，而各模块负责人则负责相关模块或功能的测试方案的审查，将建议和意见以邮件的形式反馈给测试负责人；

    4、               测试负责人收集邮件中的修改建议并对测试方案进行修改，同时回复邮件说明测试方案修改情况，修改后的测试方案commit到CVS；

    5、               测试负责人（或专门的PPQA）对最终修改的测试方案进行检查，并确认所有文档都已经commit到CVS。

     

    五、编码实现与单元测试

    1、              在产品详细设计完成后，开发工程师依据设计进行编码工作；

    2、              编码完成后，开发工程师编写单元测试案例并进行单元测试，单元测试完成后提交单元测试报告；

    3、              项目经理根据项目实际情况对开发工程师编写的代码组织Code Review，记录相关问题；

    4、              产品模块单元测试完成后，开发之间进行产品联调测试，并修改所发现问题以及提交联调测试报告；

    5、              产品初步完成后，在提交测试前进行一次产品演示，参加人员包括开发经理、项目经理、测试负责人、开发工程师、测试工程师、售前工程师与售后工程师，在演示的过程中对产品提出改进建议；

    6、              各模块负责人对Code Review以及产品展示所发现的问题进行修改，相关的代码与文档commit到CVS；

    7、              项目经理对编码完成后的系统进行确认，确保提交测试的系统是可运行的，测试负责人（或专门的PPQA）确认所有文档和代码都已经commit到CVS。

     

       六、测试设计与评审

    1、              在项目编码阶段，测试方案编写完成后，测试负责人或相关测试人员根据测试方案、规范文档、功能列表和详细设计进行测试用例设计；

    2、              测试案例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等，在用例设计中，除了功能测试案例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题；

    3、              在编写测试案例的过程中，对于存在疑问的地方或测试重点，主动与开发负责人或项目经理沟通讨论，一方面有助于设计完善的测试案例，另一方面也有助于开发进一步清晰编码思路；

    4、              测试用例编写完成后，发邮件给开发经理、项目经理、相关开发人员和测试人员；

    5、              开发经理、项目经理、相关开发人员和测试人员对所提交的测试案例进行审查，开发经理与项目经理对测试案例进行总体性的检查，各模块负责人则负责检查自己所负责的测试案例，将建议和意见以邮件的形式反馈给测试负责人；

    6、              测试负责人收集大家的邮件对测试案例进行修改完善，同时回复邮件说明修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的测试案例commit到CVS；

    7、              测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试案例必须配套修改更新；在测试过程中发现设计测试案例时考虑不周，需要对测试案例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试案例存在漏洞造成，也需要对测试案例进行完善；

    8、              测试负责人（或专门的PPQA）对最终修改测试案例进行检查，并确认所有文档都已经commit到CVS。

     

    七、测试实施

    1、              代码提交前一天准备相关的测试环境（如服务器或数据库等），代码提交后测试人员向Build Master申请打包，并搭建正式测试环境，为了不做到测试以及确保产品可以跨平台，每个测试人员各自搭建一个测试环境，每个平台至少要有一个以上的测试人员负责；

    2、              测试环境搭建好后进行烟雾测试，如果烟雾测试通过则继续详细的功能测试，否则中断测试并返回给开发；

    3、              测试人员按照预定的测试计划和测试方案逐项对测试案例进行测试，在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录，在必要的时候协助开发追踪与修改所发现的问题；如果在测试的过程中发现重大的bug或因为某些bug导致测试不能继续，测试中断并返回给开发；

    4、              每个测试阶段测试结束后，由测试负责人总结测试情况，对测试结果进行分析和下一阶段测试测试计划与可能引进的bug数量进行预测，并提交“测试阶段分析报告”，并发送给开发经理、项目经理、相关测试人员和开发人员；

    5、              开发经理对测试阶段分析报告中存在的问题采取恰当的措施和调整相关资源，确保下一阶段的开发与测试计划顺利进行；

    6、              开发对bug进行修改；

    7、              开发对bug修改后测试人员进行回归测试，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试；

    8、              产品的功能比较完善后，进行产品的性能压力测试，并根据测试结果进行性能调优；

    9、              确认测试，在软件发布前，对产品进行确认测试；

    10、           当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，确认发布包和文档完整后进行产品发布。

     

       八、产品发布

    当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，在发布前对照功能列表进行一次全面的确认测试，确认发布包和文档完整后进行产品发布。对于新产品来说，必要的文档必须包括：（1） 产品安装操作手册;（2） 产品白皮书;（3） 产品管理维护手册;（4） 用户操作手册;（5） 总体测试报告（6）性能测试报告。

     

       九、版本控制

    在测试过程中，软件的打包统一由Build Master完成。新版本软件发布之后，马上对代码进行质量控制：（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为IAGW1.0.0，则给该软件源代码也打一个与发布版本相同名字的tag IAGW1.0.0。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源代码版本与当前最新的发布版本一致。

     

    十、自动测试

    产品稳定后，进行自动测试工具开发，对于稳定的功能使用自动测试工具进行测试，新增的功能使用手工测试，使用自动测试+手工测试的模式，可以大大提供测试效率。

     

    十一、小结：应用推广思路与体会

    整体思路是：首先对项目进行需求分析，有效的需求分析方法是需求分析人员、项目经理、开发经理与测试负责人分别阅读规范与原始需求，特别是需求分析负责人与项目经理，需要对需求进行深入的分析研究，然后开会讨论，消除对需求的误解与遗漏，讨论结束后编写功能列表说明文档与需求规格说明书并评审；对于规范中不明确的问题集中后由测试负责人（或需求分析负责人）直接与移动总规范负责人直接交流，确保不会因为规范的理解不正确导致项目实现与需求不一致。需求分析完成后，编写项目计划书与测试计划书；项目计划、测试计划编写前先开会讨论，由模块负责人估算工作量，能确定的问题和时间安排都在讨论中确定下来，然后根据工作量和工程需求制定项目计划和测试计划。开发在编码前需要进行概要设计和详细设计，开发工程师在编码前对系统的总体设计架构、各自所负责的模块有一个清晰的设计思路，经评审后确认模块的设计是否合理；开发在编码完成后在提交测试前必须进行单元测试与联调测试，提交给测试的软件是一个可运行的产品。测试工作中，在项目设计或编码阶段，测试负责人对项目进行测试设计，指导测试实施有依可循，在编写案例的过程中会遇到很多与流程和细节处理相关的问题，与开发一起讨论也有助于提前发现问题与完善代码；在测试实施阶段，测试人员记录所发现的问题，并协助开发及时解决，在测试过程中所遇到的问题，测试负责人进行记录和分析，在每个阶段完成后提交经分析后的测试阶段报告，在软件测试阶段报告中总结分析了测试过程中所发现的问题并对这些问题提出解决建议，在后续的开发与测试中进行改进与调整，确保项目能够按时保质发布。为了节约资源，计划或设计都是以邮件的形式进行评审；对于存在严整分歧的问题，组织一个小型会议进行讨论有效解决问题，小型讨论会是解决问题的一种有效途径，任何问题都可以通过face-to-face的交流达到共识。软件的管理和版本管理则由Build Master负责，确保软件得到良好的控制。在整个项目实施的过程中，需要有一个PPQA对流程进行检查与监督。
            这个精简的实施流程，不但确保了软件的质量，而且实施成本较低，在团队实施中非常容易推广。 在整个流程中，测试负责人除了负责测试相关任务以外，同时承担了需求管理、流程跟踪、协调沟通等工作（当然，也可由项目经理或开发经理等担任），在其中由测试推动项目开发与实现，在开发成员之间、开发与测试之间搭了一座沟通的桥梁，这样的一个协调与推动促进了项目的顺利完成，适合于五至二十的小型团队。不过这种测试与开发的模式，对测试负责人的要求很高，不但要求测试负责人具有很强的责任心与沟通协调能力，而且还需要具有很高的业务分析能力和CMMI5实施经验。

     

     
    Written by smilings in GuangZhou, MAR. 20th，2007

     

    查看(292) 评论(0) 收藏 分享 管理

  • 自动化测试架构设计

    2008-07-13 21:08:19

    第1章          前言

    目前市场上已经有了不少自动测试工具，不过满足自己需求的测试工具却很难找到或者是难以支付其昂贵的费用，对于在Linux/Unix后台运行的软件产品，自己开发一个自动测试工具，不但可以满足软件的测试需求，还可以节省一大笔费用。

    这个自动测试系统架构的设计，是基于Linux/Unix后台运行的软件产品，架构的思想，源于主流测试工具与前辈的实践经验。

    软件的自动测试，其实就是一种思想，不管是市场上的主流测试工具，还是自主开发的测试工具，都只是工具，关键的是怎样去组织一个工具，怎样将工具应用于软件测试中。

    第2章          系统架构

    2.1    设计思想

    1．            自动测试的组成：自动测试主要有几部分组成：（1）、自动测试工具（2）、测试案例（3）、模拟接口（4）被测试软件（5）自动编译与安装

    2．            自动测试工具：自动测试工具的主控程序不需要理解业务，所有的业务逻辑和测试数据都写在测试案例中，主控程序执行每个测试案例中的指令完成每个测试案例的测试，测试结果记录在指定的文件中。

    3．            测试案例：业务逻辑和测试数据体现在测试案例中，一个完整的测试案例应该包括测试条件预置、测试步骤、每个测试步骤的输入与输出、预期结果、实际测试结果的获取、实际测试结果与预期测试结果的对比。每个测试动作为一个操作指令，每个操作指令包括指令的ID、输入与输出，主动测试工具就是通过执行测试案例的这些指令来完成自动测试的。

    4．            黑盒测试：被测试软件对于自动测试工具来说，是一个黑盒子，自动测试工具不关心被测试软件的内部逻辑和业务流程，关心的被测试软件的接口以及每个接口的输入和输出。自动测试工具向被测试软件输入测试数据，在相应的接口获取测试结果，如果测试结果与预期结果相一致则测试通过，否则测试失败。

    5．            模拟接口：与被测试软件打交道的各个接口，需要模拟，在必要时可以设置模拟接口给被测试软件的返回值，以达到测试的目的。

    6．            自动编译与测试：自动编译就是自动到源代码管理服务器编译软件，将软件上传到测试服务器。自动测试就是自动更新或安装被测试软件，启动自动测试工具执行自动测试案例，记录测试结果并将测试结果以邮件的方式发送给相关的人员。

    7．            测试环境的恢复：在某个测试案例执行完成后，不管测试是成功还是失败，都需要恢复被该测试案例特殊化后的测试环境。

    8．            重用策略：公用的模块提取出来，被别的模块或功能调用，提高模块的公用性，减少程序冗余代码。

    9．            自动测试工具模块组成：

    （1）    主控程序：读取测试案例以及每个测试案例的操作指令，根据不同的操作指令调用不同的指令接口执行每个测试案例的指令，记录测试结果。

    （2）    指令接口：是测试案例操作指令与具体测试步骤实现之间的桥梁，与测试案例的操作指令相对应，指令接口就是实现测试案例的操作指令所需要做的事情，动作完成之后将该动作的操作结果返回给主控程序。

    （3）    驱动程序：驱动程序是实现具体的指令操作的程序，被指令接口调用完成具体的测试工作，并将测试结果返回给指令接口。

    （4）    辅助功能：实现系统的辅助功能，比如案例文件的处理，底层socket处理，文件处理或者数据库操作。

     

     

    2.2      系统架构

     

     

     

    2.3    系统流程图

                               

     

     

     

    第3章          自动测试核心设计

    3.1     系统组成

    自动测试工具由主控程序、指令接口、驱动程序和辅助功能组成。

    3.1.1                  主控程序

        控制模块不理解业务，把业务逻辑和测试数据全部写在案例里，控制模块读取所有需要测试的测试案例以及每个测试案例的每一个操作项的动作，调用不同的接口处理模块来实现整个测试流程。

    控制模块处理流程：

    1．            读取命令，获得需要执行的命令以及配置文件。

    2．            分析命令以及命令的参数，比如如果命令是想查看帮助，则打印帮助提示；如果命令是执行测试案例，则开始执行自动测试的测试案例。

    3．            分析配置文件，获取测试案例存放目录，需要执行的案例的ID文件，数据库连接信息，测试案例所使用到的参数。 (注：因为在测试案例的执行中，未必执行完整个测试案例，测试案例中的某些动作可能不需要执行，可在配置文件或测试案例中进行配置)

    4．            根据测试案例存放目录以及测试测试的ID文件获取具体需要测试的测试案例。

    5．            获取每个测试案例需要执行的动作指令以及输入数据。

    6．            逐个执行测试案例，根据测试案例的动作指令调用不同的接口执行不同的动作。

    7．            某个测试案例测试完成后，获取该测试案例的测试结果，并将测试结果输出到结果记录文件中。

    8．            继续执行下一个案例，直到所有的测试案例都被测试完为止。

    3.1.2                  指令接口

    是测试案例操作指令与具体测试步骤实现之间的桥梁，与测试案例的操作指令相对应，指令接口就是实现测试案例的操作指令所需要做的事情，动作完成之后将该动作的操作结果返回给主控程序。接口模块负责与接口的数据处理，包括输入和输出，同时必须包括数据处理的结果。主控程序在读取了测试案例的操作指令之后，调用这些操作指令所对应的指令接口执行相应的操作，如果该接口执行操作成功则主动程序继续下一步操作，否则测试终止，只有所有的测试步骤的指令都被成功之行，测试案例才通过。

    为了方便管理与调用，所有的接口都实例化都一个接口工厂中，在实现了相应的指令接口后，需要将这些指令接口增加到接口工厂中，接口工厂根据案例中的接口类型来调用不同的接口实例。

    指令接口，事实上就是执行测试案例中的每个指令要求做的事情，比如输入测试案例的测试数据、执行相应的测试步骤、获取测试结果、对比测试结果，指令接口完成一个指令之后将这个指令的操作结果返回给主控程序。

    比如，话单检查指令接口，指令接口需要做的事情就是初始化要监听的话单文件，获取话单文件，把获取到的话单文件同期望话单进行比较，返回比较结果给主控程序。

    又如：短信接收发送指令接口，指令接口的工作就是实现发送MT，收取状态报告并把收到的状态报告的状态值与期望的状态值进行比较，返回比较结果给调用者；收到本地MO，并把收到到的本地MO与期望的MO进行比较，返回比较结果给调用者。

    3.1.3驱动程序

    驱动程序是实现具体的指令操作的程序，被指令接口调用完成具体的测试工作，并将测试结果返回给指令接口。驱动程序是具体操作的完成者。

    比如，话单检查驱动程序，用于对特定话单格式的话单文件进行跟踪，并且能够把跟踪结果解析成话单，话单检查指令接口会调用话单驱动程序完成具体的每条话单的各个子段的比较，驱动程序完成检查后将结果返回给指令接口。

     

    3.1.4                      辅助功能

    实现系统的辅助功能，比如案例文件的处理，底层socket处理，文件处理或者数据库操作。

     

    3.2     测试案例

    3.2.1                  测试案例的组成

    测试案例包括了业务逻辑、测试步骤以及输入与输出，使用XML存储测试案例，可以提高测试案例的可读性、通用性以及可维护性。不过这样有一个不好的地方就是测试案例看起来会比较庞大，不够轻盈，但是非常清晰，即使是对测试案例完全不熟悉的人，只要看了也自然很快就对业务流程有了一个大致的了解；而且，业务逻辑体现在测试案例，也会增强系统的扩展性，如果需要增加某些测试步骤或修改测试数据，只需要修改测试案例即可。

     

    测试案例主要由测试案例ID、测试案例描述、以及测试操作指令所组成。测试案例ID就是测试系统的案例ID，测试描述包括测试案例的简要描述、测试产品名称、测试功能点、测试版本、测试类型以及测试案例的作者，测试操作指令是测试案例的核心，每个测试步骤就是一个操作指令，操作指令的顺序与业务逻辑或测试步骤相关。每个操作指令包括：

    （1）    操作指令ID，在Test Case中唯一；

    （2）    操作指令接口名称，自动测试工具所提供的指令接口名称，在一个Test Case中可以出现多次；

    （3）    操作指令接口动作名称，自动测试工具所提供的指令接口的具体操作的名称，在一个Test Case中可以出现多次，自动测试工具操作指令接口名称和操作指令接口动作名称调用不同的指令接口的功能完成相关的动作；

    （4）    操作指令的描述；

    （5）    模拟接口的信息，如果需要使用到模拟接口，需要将模拟接口相关的信息再测试案例中输入，模拟接口相关信息应该参数化；

    （6）    输入数据，也就是执行这个操作步骤所需要输入的测试数据或是预期的结果或延时等待时间等。

    （7）    输出数据，也就是这个操作步骤的输出结果。

     

    一个测试案例就是一个完整的测试流程，由不同的操作步骤组成，每个操作步骤就是一个操作指令，一个完整的测试案例可能包括这些操作指令：

    （1）                预置测试环境，比如修改某些特殊的配置、设置模拟接口的返回值、检查某些数据等；

    （2）                测试步骤，一个测试案例可能有多个测试步骤，每个测试步骤为一个操作指令，操作指令的输入就是测试需要输入的数据，动作就是需要执行的测试操作，测试案例的测试就是由一系列的操作指令完成；

    （3）                检查测试结果，一个测试案例中可能存在多个检查点，每个检查点为一个操作指令，这操作指令的输入就是预期的测试结果，操作指令的动作就是获取测试结果并将测试结果与预期测试结果相比较，如果相等则测试通过，否则测试失败；

    （4）                恢复测试环境，测试完成后应该恢复测试环境的原始数据或相关的资源。

     

    为了提高测试的扩展性与灵活性，测试案例中的测试数据应该可以参数化，这样即使是测试数据发生了变化，只需要修改参数的值即可，而不必把所有的测试案例的某些数据逐个修改。这些参数以及参数的值可以存放在配置文件中，被测试案例引用，自动测试工具根据测试案例的参数的名称到相应的配置文件中读取这个参数的值。

     

    3.2.2                  测试案例的命名

    为了提高测试的可维护性，测试案例的命名必须规范，在此约束为测试案例的名与测试案例的ID一致。

    3.2.3                  测试案例的存放

    对于不同的产品的测试案例，应该存放在不同的主目录中，对于同一个产品的测试案例，根据不同的功能存放于不同的子目录中。每个主目录或子目录应该有一个测试案例的ID文件，在这个文件中的测试案例会被自动测试工具执行自动测试。测试案例ID文件中，每一行为一个测试案例，每个测试案例由序列号、测试案例ID和该测试案例的描述组成。测试案例的存放位置，自动测试工具可通过配置文件获取。

    3.3   自动测试执行

    3.3.1测试案例的编写与测试

    自动测试工具实现后，接下来很大部分的工作就是测试案例的编写和测试了，根据业务逻辑和自动测试案例的规范将测试案例系统中的测试案例转化成自动测试案例脚本，自动测试案例脚本编写完成后对这些脚本进行测试，确保自动测试案例脚本能够被正确地执行且正确地测试了测试案例所描述的功能。在利用自动测试工具进行测试之前，首先要测试自动测试工具和案例能否正确地进行相关功能的测试，否则自动测试的结果不可信，自动测试也就没有意义了。

    3.3.2自动测试的执行

    自动测试案例编写完成后，自动测试就可以在无人干预的情况下进行测试了。

    （1）               需要进行自动测试的测试案例的ID写在一个文件中，自动测试工具只执行这个文件中的测试案例；

    （2）               自动测试案例的目录、数据库连接、模拟接口的IP和Port等参数写在配置文件中，自动测试工具会到配置文件指定的目录读取测试案例，也会读取自动测试工具所使用到的数据库连接信息和模拟接口信息；

    （3）               自动测试案例所使用到的参数写在参数配置文件中，自动测试工具根据自动测试案例的参数的名字到参数配置文件中读取该参数的值代替自动测试案例中的参数；

    （4）               指定测试结果的输出文件，自动测试工具在测试完一个测试案例之后，将这个测试案例的测试结果输出到测试结果文件中，测试结果文件每行表示一条测试案例，每条测试案例的输出结果包括测试案例的ID，测试案例的功能描述和测试案例的结果；

    （5）               自动测试工具在测试案例的过程中，需要记录测试日志，包括测试案例ID，读取测试案例的内容，测试步骤，各个测试步骤的测试结果，测试结果的比较等；

    （6）               自动测试工具自动执行所需要测试的案例，并记录测试结果，测试工程师在测试完成后查看测试结果，测试成功的测试案例意味着这个功能测试通过，对于测试失败的测试案例，需要根据日志分析原因，如果是测试环境或测试脚本引起的则修改环境或测试案例或自动测试工具，否则需要记录bug，通知开发修改测试失败的测试案例所发现的问题。

     

     

    第4章          自动编译与自动测试

    4.1.1自动编译

    自动编译就是在源代码管理服务器上进行自动编译，对编译的结果进行分析，并将编译成功的并且是自动测试环境需要的文件更新到测试环境中。

    自动编译的过程可分为：

    （1）    Update源代码服务器上的需要编译的所有相关代码，需要编译的代码的路径在配置文件中读取；

    （2）    自动编译需要编译的源代码；

    （3）    分析源代码编译结果，只有编译成功了的执行文件用于自动测试才有意义，将编译结果上传到测试服务器并发送给相应的人员；

    （4）    将需要更新的文件打包并上传到测试服务器，并将上传结果发送给相关人员。

    自动编译，可以写一个脚本交给crontab去调用自动编译程序，实现无人干预下的编译自动化。

    4.1.2自动测试

    这里所说的自动测试，就是自动更新或安装被测试软件，自动启动被测试软件，然后跑自动测试案例进行自动测试，并将自动测试的结果发送给相关的测试或开发人员。

    自动测试的过程可分为：

    （1）                到自动编译结果上传目录获取自动编译结果，分析自动编译结果，如果自动编译失败则自动测试结束，发送测试结果给相关人员，否则进行一步；

    （2）                到FTP被测试软件的安装文件上传目录获取FTP上传结果，分析ftp上传结果，如果ftp失败则自动测试结束，发送测试结果给相关人员，否则进行下一步；

    （3）                到被测试软件的安装文件上传目录获取安装文件；

    （4）                停止原正在运行的被测试软件，如果是全新安装的测试环境，不需要执行这一步；

    （5）                进行软件安装或更新：如果是一个全新的测试环境则进行软件的安装，如果是已经存在的测试环境则更新被测试软件；

    （6）                启动被测试软件；

    （7）                调用自动测试工具进行自动测试，记录测试结果；

    （8）                所有自动测试案例都测试完成之后，分析测试结果，将测试结果发邮件通知相关的测试和开发人员。

                

    自动编译，可以写一个脚本交给crontab去调用自动测试程序，实现无人干预下的测试自动化。

     

    配置文件应该包括以下信息：

    （1）    自动编译的结果文件和FTP的结果文件的路径、文件名；

    （2）    被测试软件的安装文件或更新文件的路径；

    （3）    存放自动测试结果的路径和文件名；

    （4）    停止原测试软件的脚本的路径和文件名；

    （5）    启动被测试软件的脚本的路径和文件名；

    （6）    启动自动测试软件进行自动测试的脚本的路径和文件名；

    （7）    测试结果发送的邮件地址。

     

     

    第5章          编后语

    来到新的公司，战战兢兢地接下了自动测试的重任，在软件测试的领域，这是我以往接触得最少的一部分，也是我最没把握的一部分，不过同时也是我最想学习的一部分。自动测试，在很早以前就想花时间去研究了，不过因为老公司产品的限制，也因为自己没有足够的决心去研究，所以一直没有动作。这篇文章的完成后，自己忽然有了一种豁然开朗的感觉，我知道我已经找到了自动测试的感觉。

     

    Written by smilings on October 6, 2007 in Guangzhou

     

    查看(434) 评论(1) 收藏 分享 管理

  • 自动化测试闲言杂语

    2008-07-13 21:06:09

    项目的自动化测试有了一个比较理想的结果，易于扩展、维护和使用的测试架构，接近80%的 覆盖率，项目组积极的反馈结果，半年的努力没有白费。回想起刚到公司时接下这个重任，自己并没有把握，甚至有些心虚，毕竟自动测试并不是我所擅长的，而 且，陌生的测试工具、庞大而复杂的测试系统，对我来说都是一种挑战。心里没有把握自然不能跟老板说，打电话给一个在这方面经验很丰富的朋友，他告诉我“要自信，要靠自己”，于是，摒弃了所有的杂念和依赖，一头扎进了自己底气不足的自动化测试。

    很感激我的mentor，在刚进公司的前两周，没有马上让我接手自动化测试，使我有足够的时间熟悉系统的基本功能，就这么一个缓冲，了解了系统的基本功能，也研究了一个基本的自动化测试架构的组成，对测试系统、对自动化测试自己有了感觉。熟悉测试系统，这是软件自动化测试的第一步。

    我的一些刚来的新同事或实习生，总是迫不及待地想学习自动化测试或者是想通过自动测试脚本学习业务，我总会告诉他们，熟悉业务是自动测试的基础，不要小看手工测试过大夸大自动化测试。如果一个系统你都没有亲自手工测试过，又怎会做好自动化测试呢？

     用 什么工具，我没有选择，因为项目组在我来之前就已经决定了。关于工具的选择，我看重的首先是它是否能够满足项目的需要，是否容易扩展，可以满足系统任何功 能的测试自动化；其次是它是否易用，能否容易上手；当然最重要的是它的稳定性，是否不需要人工干预就能稳定地批量运行所有的自动化测试脚本。这三点，项目 组所选择的工具都满足了，我自然乐于接受。选择合适的测试工具，是软件测试自动化的第二步。

     开始做自动化测试，是从系统的基本功能开始，目标是每次出built都需要花半小时以上的手工smoke test cases测 试自动化。在我接手前，已经有同事做了页面相关的功能测试，看了一些以前的脚本，只是简单的录制、回放，因为没有整理过，也就没有业务逻辑和注释，花了很 大的精力才弄清一个脚本的步骤和功能。而且，这些脚本中，关键字的参数化做得不好，每次运行都需要手工修改，需要手工来干预的脚本，只能算是半自动化。最 严重的问题是，同样的功能，同样的脚本，会被重复地拷贝，当这个功能或业务流程被改变的时候，所有相关的脚本都需要修改，那将会是很大的维护代价。思考了 一天，我决定放弃原有的所有脚本，重新设计系统的架构。放弃原有的两百多个脚本，有些可惜，但如果按照原来的思路走下去，我将会付出更大的维护代价。有舍 才会有得。

    问题我看到了，知道要改，但至于怎样改，心里并没有把握，我知道自己需要时间去研究。我将用于smoke test的系统最基本的功能挑出来，作为设计的研究对象。Web测 试自动化，无非就是录制、整理和回放，录制和回放都是简单的事情，关键是整理，好的脚本，应该容易扩展、维护和使用。这十几个脚本，我花了很多心思，不断 地思考、不断地改进、不断地与我的同事讨论。慢慢地，自己的思路清稀了起来，做出了自己想要的架构。首先是容易扩展，能够满足现在的功能需求，也能满足以 后需要测试的功能的需求。第二，容易维护，当业务流程、接口或页面变动的时候，只需要做一些简单的修改就可以实现。第三，可读性强，别人能够容易读懂和接 手维护。第四，容易使用，项目组的其他人想要使用的时候能够简单地搭建和运行。第五，有统一的编码规范、存储规范和编写风格。最后，是最重要的一点，是脚 本具有很高的可信性以及自动运行的稳定性。

    我像绣花一样一点一点地将这个自动测试架构绣了出来，比别人多花了N倍的心思和时间，晚上从公司走出来，傻傻的望着夜空数星星，虽然累很仍然很快乐。

    从 系统的基本功能入手，设计自动测试架构，这是软件测试的关键一步。架构的好与坏很重要，它影响到系统的扩展、维护和使用，如果想要系统容易扩展和维护，一 定要多花心思在设计上。很多同行问我使用什么测试工具，我会告诉他们，用什么测试工具其实并不那么重要，不同的人使用同样的测试工具，会做出效果完全不一 样的东西，那是因为他们的架构不同，设计比工具重要得多。

     架 构出来之后，就是系统功能的自动化脚本编写，因为项目的原因，当时的自动测试团队已经解散，我面临的是只有一个人的自动测试团队，怎样将上千个测试案例自 动化，成了我头疼的问题。至今仍然很感激我的老板和项目经理，调配给我足够的资源，真正的打开了项目的软件测试自动化之门。团队中的其它成员，都是没有自 动化测试经验的同事，给他们足够的培训和技术支持很关键。他们所负责的功能，我都会写一个例子，他们可以参照例子按照我们自动测试架构编写规范写脚本，遇 到技术问题或业务问题，我会协助解决，在整体的架构上，我会全局把握。那一段时间，特别忙，架构的扩展、业务的熟悉、问题的跟踪解决，有时候同时有好几个 问题在等着我解决，但就是这么一段忙碌的日子，从对系统基本业务的理解到系统业务的全面理解，从原来的只有十几个测试案例的自动化测试脚本到上千个自动化 测试脚本的实现。很感激我的这些同事，现在他们大部分都回到了他们原来的角色，我也将要开始担任新的角色，但那一段一起工作的日子，我会记在心里。也是因 为大家一起的努力，老板原要求实现web页面自动测试或系统30%功能的自动化测试，我们最终实现的是几乎所有接口所有检查点的自动化测试，接近80%的测试覆盖率。

    自动化脚本的编写，当然要注意全局的把握和review，不同的人会有不同的风格，稍不注意就会问题多多。

     脚本编写完成之后，自然是使用。脚本在前期的使用是功能测试和数据准备，在项目稳定之后的最大价值就是回归测试。我将脚本分为了三个级别：基本流程测试脚本，用于每次出新built安装后做smoke test；关键功能测试脚本，每次出新built后 对所有重要功能进行回归测试，确保改动不会对原有功能的造成影响；全面回归测试脚本，一般每周跑三次或者是系统经过比较大的修改后作回归测试。自动测试脚 本在回归测试中发挥了出色的作用，特别是系统在上线前夕，为了适应客户的需求，功能不断修改，对于原有的功能，自然不可能都手工测试，脚本在这个时候的意 义特别大。

     同事或朋友经常问我，自动化测试应该在什么时候介入？如果系统的功能需求和接口定义都很清晰，系统开发完成并且基本功能手工测试成功后，就可以开始编写自动化测试脚本了，一方面可以利用脚本做功能测试和bug验证，另一方面也可以用来做回归测试。但如果系统的变化比较大或接口的定义不够清晰，最好还是先手工测试，待功能比较稳定之后再写脚本，因为如果功能的变化太大，维护脚本的付出可能远远小于脚本可以带来的效益。

    当 然，并不是所有的系统都适合做自动测试，如果只是一些短期的项目，或者是脚本不会被重复利用，就没有做自动化测试的必要，成本会远远大于收益，也就没有做 自动化测试的必要了。反之，如果是产品的测试或长期的项目或是自动化测试脚本会被反复使用，自动化测试就显得很有必要了，做完一套脚本之后就会反复被使 用，当然可以节省很多成本，也可以提供测试的效率。

     这个架构，自己付出了很多心思，付出所得到的回报找到了自动测试的感觉，底气不足变成了胸有成竹。项目组的其它团队也看到了自动化测试的好处并打算参考我们的架构实现自动化测试，再做设计，扬长避短、一气呵成。

     敲完这些文字，也就意味着我的自动化测试工作暂告一段落，下周开始，因为项目的需要，将会开始我的另一个全新的角色。这个架构，绝对不是完美的，肯定还存在可以改进的空间，希望接替我自动化测试工作的同事，也能像绣花一样用心去完善它。

    查看(457) 评论(0) 收藏 分享 管理

  • 如何编写有效的Bug Report

    2006-12-22 17:50:50

    一、             编写Bug report的原则

    Bug report是测试中最重要的一部分，也是测试人员价值的终极体现，一个有效的Bug report，在编写的时候需要遵循以下原则：

    （1）                  Bug可重现，尽可能找到重现规律。测试人员在编写Bug report之前必须在检查问题是否可重现，问题重现才可以让开发更有效地查找到原因并解决问题，对于比较复杂的问题，最好能够将Bug现场重现给开发人员，以方便问题追踪和原因定位。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。

    （2）                  Bug描述简明准确，对于问题的描述，应该尽可能简明、准确。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤，不要出现在Bug report中。

    （3）                  一个Bug report只描述一个Bug，如果将几个问题都写在一个Bug report中，开发人员很难有效发现自己的问题并解决，从而导致有些优先级别高的Bug没有得到及时的解决。因此在写Bug report的时候，将Bug按照不同的优先级别将不同的问题指定给相应的开发人员。

    （4）                  Bug的唯一性，在提交Bug report之前，要先确认这个Bug是否已经被其它人发现并报告。

    衡量优秀的Bug report的质量指标：

    （1）       对管理层来说，是清晰明了的，特别是在主题概要这一级；

    （2）       对于开发人员来说，是有用的，主要是提供能够让开发人员高效地调试问题的相关信息，使其可以很快的将Bug从“Opened”状态转变成“Closed”状态，提高测试和开发的工作效率；

    （3）       对于后期的维护，能够有效从Bug信息查询出问题的描述和解决的方法。

    二、             如何编写Bug report

    Bug report作为测试和开发之间沟通的桥梁，测试人员在报Bug的时候，有效的Bug描述，会更加容易帮助开发解决问题。一般来说，作为一个优秀的Bug report，应该包括以下内容：

    1、  Bug标题：简明扼要地对Bug进行一个概述，让人看标题就知道大概出现了什么问题。比如：“smfilter模块在压力测试时出现内存泄露。”

    2、  Bug的属性，Bug的属性应该包括：

    （1）       产品名称：测试产品的名称。

    （2）       产品子系统：测试产品的子系统，如果产品比较小，该项可以忽略。

    （3）       产品模块：测试产品发现问题的模块的名称。

    （4）       测试版本：当前的测试版本。

    （5）       测试平台：Bug的产生跟平台有关，有些在suse下产生的Bug，在soralis下则正常，因为在报Bug的时候需要将当前测试的服务器的版本。

    （6）       测试阶段：模块测试、内部集成测试、外部集成测试。

    （7）       问题级别：紧急、严重、一般、轻微

    （8）       优先级别：高、较高、一般、低

    （9）       问题来源：测试、工程故障、升级、其他

    （10）   问题类型：功能问题、版本问题、遗留问题、新需求、低级错误、改进建议、移植修改、割接问题、配置错误、编译问题、性能问题、设计问题、兼容问题、新功能增强、偶发性出错

    这些属性在Bug跟踪管理系统中应该有默认值，在测试人员报bug的时候选择对应的属性值。

    3、  Bug负责人：

    （1）       开发人员：测试产品模块的开发人员

    （2）       测试人员：发现Bug的测试人员

    （3）       抄送：该Bug需要抄送给相关的开发人员或测试人员。一般来说，一个Bug除了发送给改Bug的开发负责人和测试负责人外，还需要抄送给项目经理、测试经理、该产品开发小组其他人员，该产品测试小组其他人员

    这些属性在Bug跟踪管理系统中也应该有默认值，在测试人员报bug的时候选择对应的负责人。

    4、  Bug的详细描述：这是Bug最重要的一部分，对Bug描述清晰准确，不仅有助于开发人员迅速定位解决问题，还对以后的维护工作有很大的帮助。一些比较简单的Bug，可以使用一两句话把问题准确描述，而对于一些比较严重或负责的Bug或者是新的需求，则应该详细说明。

    5、  附件：对于一些特殊的问题或者不能用语言很好地描述的问题，可以增加界面图形说明或参考资料或详细日志等附件。

    6、  其它属性：

    （1）       BugID：Bug的唯一标志

    （2）       建档时间

    （3）       建档人

    （4）       Bug回复时间

    （5）       Bug关闭时间

    一般来说，在报bug之后，这些属性一般由bug跟踪管理系统自动生成。

    三、             如何划分bug的严重级别

    Bug的严重级别指的是软件缺陷对软件质量的破坏程度，也就是该软件缺陷的存在将对软件的功能和性能产生怎样的影响。在软件测试中，软件缺陷的严重级别应该从软件最终用户的立场来做判断，考虑缺陷对用户使用造成的后果的严重性。

    1、   紧急

    （1）       Bug足以造成系统崩溃，造成文件不可靠或潜在的数据丢失

    （2）       Bug造成非正常地返回操作系统（系统崩溃或显示系统错误信息）

    （3）        Bug造成程序越或要求Reboot系统

    （4）        造成缺乏关键的程序功能并无法逾越

    （5）        由于设计问题，使系统存在严重隐患

    2、   严重

    （1）       Bug可能不会削弱系统，但将造成严重问题（如严重的格式化错误等）

    （2）       功能缺乏给用户带来极大不方便

    （3）       Bug可以绕过，但将会很不方便或很难实现

    （4）       存在不明确或不完整的错误信息提示，极大地影响产品使用

    （5）       由于Bug的存在使产品其它部分不能测试

    （6）        由于计算方法问题，使数据错误

    （7）        由于设计原因，造成前后不一致，但问题可恢复

    3、   一般

    （1）       这个Bug在将来是严重的，但比主要问题要轻。

    （2）       可以有一个比较简单的绕过Bug的解决方案

    （3）       存在不明确或不完整的错误信息提示，但对产品使用影响较小

    （4）        容错性方面存在不足

    （5）        由于精度问题造成数据不一致

    4、   轻微

    （1）       不可能被用户发现的Bug

    （2）       某个控件没有对齐，某个标点符号丢失等低级错误

    （3）        尚无法满足的新需求

    四、             如何划分bug的优先级别

    Bug的优先级是指解决软件缺陷的先后顺序，即哪些缺陷需要优先解决，哪些缺陷可以稍后解决。确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，同时需要考虑问题修改的成本与时间。

    1、   高

    这类Bug对产品影响非常大，造成产品不能移交。

    2、   较高

    这类Bug对产品影响比较大，如果产品带着Bug发布给用户将会产生麻烦。

    3、   一般

    这类Bug对产品影响一般，如果Bug被fix，产品会更好；或者是这类Bug对产品影响一般，如果fix bug 不影响产品的交付期，一定要fix。

    4、   低

    这类Bug对影响较小，只有在其它所有Bug已经被fix后，再fix这类Bug

    一般来说，严重级别高的bug具有较高的优先处理级别， 但是严重级别和优先级并不总是一一对应。有时候严重级别高的Bug优先级不一定高，而一些严重级别低的Bug却需要及时处理，具有较高的优先级。例如，如果某个严重的bug只在非常极端的条件下产生而通过配置或人为注意可以避免，则可以稍后解决。另一方面，如果软件缺陷的严重性很低，例如，提示错误，但是提示信息很容易造成别人的误解，则必须尽快修改。

    五、如何进行Bug描述

    1、   简明扼要的bug描述

    一些比较简单的Bug，可以使用一两句话把问题准确描述，比如：“在管理网页新增用户，当新增的用户登录名名称很长（例如登录名长度为输入框允许的最大长度），按‘新增’按纽新增后系统提示已经有该用户存在，而事实上该用户并不存在，建议对超长的用户名进行处理。”

    2、   严重的程序缺陷bug描述

    比较严重或复杂的Bug，应该在bug报告中进行详细的说明。对于产品的程序缺陷，也就是测试的时候发现的问题，此时作为Bug的详细描述，应该包括（根据实际情况选择）：

    （1）       测试要点：测试用例的测试要点

    （2）       测试配置：如果有特殊的配置，需要在Bug描述中说明

    （3）       测试环境：发现Bug的测试环境

    （4）       测试步骤：详细描述发现Bug的操作步骤和流程

    （5）       实际结果：按照测试步骤测试后实际出来的操作结果

    （6）       预期结果：按照测试步骤测试后原本预期的操作结果

    （7）

    查看(775) 评论(2) 收藏 分享 管理

  • 如何给开发报bug？

    2006-12-22 17:48:59

    首先，确保你所发现的问题是确实是一个bug，不要出现因为测试人员操作错误或配置错误所引起的“bug”，这样会降低你在开发人员心中的可信度。在测试的时候，如果发现测试的实际结果与预期测试结果不符时，不要着急马上报bug，先想想为什么会出现错误。作为专业的测试人员，应该能够对出现的问题进行跟踪，确认了在配置、操作没有错误的前提下，通过追踪分析确认所测试的业务流程确实是存在bug，并能大概对bug的产生原因进行定位。测试人员，需要做到专业，尽量少给开发找麻烦，不要制造实际上并不存在的bug。

    确认了所发现的问题是一个bug之后，按照测试步骤再执行一次，确保bug是可重现的而不是随机的。如果bug不能重现，应该尽量找到bug重现的规律，在一些比较难重现的问题可以找开发配合一起查找原因，如果还是无法重现则需要在bug report中对出现的问题描述清楚并说明出现的随机性。

    接下来就是填写bug report了，在填写bug report的时候，最重要的是bug的标题和bug描述。在bug报告中，首先用一句话对bug进行简要精确的描述作为bug的标题，让开发或项目经理一看就知道存在什么问题，比如“XX模块在压力测试2小时后出现内存泄露”。而在bug的描述中，需要使用简明准确的语言描写出现bug的测试步骤、实际的测试结果、预期的测试结果和结论；也就是说描述导致出现bug的操作步骤是怎样，由测试步骤所做的操作引起的测试结果是什么，而预期的结果应该是怎样，并由实际结果与预期结果相对比说明问题所在。比如：“在管理网页新增用户，当新增的用户登录名名称很长（例如登录名长度为输入框允许的最大长度），按‘新增’按纽新增后系统提示已经有该用户存在，而事实上该用户并不存在，建议对超长的用户名进行处理。”

    在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的流程？同一个故障是否会引起更加严重的问题？如果存在，也需要提出来让开发一并处理。

    在开发对bug进行修改之后，测试需要报着怀疑的态度认真地对问题进行验证，需要严格按照测试步骤来进行测试，检查开发是否已经正确修改了所出现的问题，以及开发对bug进行了修复之后是否会引进新的问题。不要相信开发说“已经修改好了，肯定没问题了”就不对问题进行细致的检查了，如果开发修改得不彻底，问题仍然会存在的，或者可能会由于开发在修改bug的时候忽略了另一些细节导致了新bug的出现。尽量不要在关闭bug之后，才发现这个问题还没有修改彻底；也不要出现bug关闭之后，出现了新的bug。

    测试对bug进行验证确认已经修改ok之后，关闭bug。在关闭的时候，应该对Bug最终修改结果进行简要描述，如果bug的修改引起配置或数据库或业务流程的变更，也需要在bug关闭描述中进行说明。

     

    Written by smilings in GuangZhou , 2006

    查看(643) 评论(0) 收藏 分享 管理

  • 测试驱动开发与CMMI5的精简应用

    2006-12-22 17:47:29

                            

       

                                第一部分  实施过程

     

      为了提高产品的质量以及更好地对项目进行控制，在产品开发与测试过程中，由测试驱动开发，并引进了CMMI5流程。考虑到CMMI5在小型项目中的成本过高，在项目实施的过程中精简了CMMI5的实施流程和部分文档，这个精简的流程在项目实施的过程中取得了良好的效果，在此主要就测试方面在项目中的应用进行简述：


        1    、需求与规范的管理：（1）由测试负责人统一接收相关规范和新需求，测试负责人浏览获知大意将规范和新需求转发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；（2）测试负责人与项目经理一起对规范和新需求进行研究，并就难点和疑点与项目经理讨论，整理出重点内容，并将重点内容发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；（3）开发经理、项目经理、测试负责人、相关的开发人员与测试人员开会对规范、需求和重点内容进行讨论，确定最终实现的需求和功能点；（4）项目经理根据规范、需求和开会讨论结果整理新功能列表，测试负责人对新功能列表进行检查并修改，然后commit到CVS；（5）测试负责人确认所有相关文档都已经commit到CVS。

      
       2    、项目计划与测试计划：（1）由开发经理组织项目计划讨论会，在讨论会上各开发负责人对自己所负责的模块所需要的工作量进行评估，根据工作量和工程需求初步确定总体开发计划、测试计划和发布时间；（2）测试负责人根据项目计划与发布时间编写测试计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的测试计划；（3）测试计划编写完成后发送给开发经理、项目经理、相关的开发人员和测试人员，开发经理、项目经理、相关的开发人员和测试人员阅读测试计划后将建议和意见以邮件的形式反馈给测试负责人，测试负责人收集大家的邮件中对测试计划进行修改完善，同时回复邮件说明测试计划修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的测试计划commit到CVS。


        3    、开发设计与评审：（1）项目经理负责编写概要设计文档、数据库设计文档和编码规范，各模块负责人负责编写所负责的模块进行详细设计，发邮件通知开发经理、项目经理、测试负责人、相关开发人员和测试人员；（2）开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的详细设计文档进行审查，将建议和意见以邮件的形式反馈给模块负责人；（3）模块负责人收集邮件中的修改建议并对详细设计文档进行修改，同时回复邮件说明详细设计修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的详细设计commit到CVS；（4）测试负责人对开发最终修改的详细设计计划进行检查，并确认所有文档都已经commit到CVS。

      

        4、测试设计与评审：（1）在项目的编码阶段，测试负责人根据规范文档、功能列表和设计文档编写测试方案和测试用例；（2）测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等，在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题；（3）在编写测试案例的过程中，对于存在疑问的地方或测试重点，主动与开发负责人或项目经理沟通讨论，一方面有助于设计完善的测试案例，另一方面也有助于开发进一步清晰编码思路；（4）测试方案与测试用例编写完成后，发邮件给开发经理、项目经理、相关开发人员和测试人员；（5）开发经理、项目经理、相关开发人员和测试人员对所提交的测试方案与测试案例进行审查，将建议和意见以邮件的形式反馈给测试负责人；（6）测试负责人收集大家的邮件中对测试方案和测试用例进行修改完善，同时回复邮件说明修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的测试方案与测试用例commit到CVS；（7）测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

      

       5、测试实施：（1）代码提交前一天准备相关的测试环境（如服务器或数据库等），代码提交后测试人员向Build Master申请打包，并搭建正式测试环境，为了不做到测试以及确保产品可以跨平台，每个测试人员各自搭建一个测试环境，每个平台至少要有一个以上的测试人员负责；（2）测试环境搭建好后进行烟雾测试，如果烟雾测试通过则继续详细的功能测试，否则中断测试并返回给开发；（3）测试人员按照预定的测试计划和测试方案逐项进行测试，在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录，在必要的时候协助开发追踪与修改所发现的问题；如果在测试的过程中发现重大的bug或因为某些bug导致测试不能继续，测试中断并返回给开发；（4）每个测试阶段测试结束后，由测试负责人总结测试情况，对测试结果进行分析和下一阶段测试可能引进的bug数量进行预测，并提交“测试阶段分析报告”，并发送给开发经理、项目经理、相关测试人员和开发人员；（5）开发经理对测试阶段分析报告中存在的问题采取恰当的措施和调整相关资源，确保下一阶段的开发与测试计划顺利进行；（6）开发对bug进行修改；（7）开发对bug修改后测试人员进行回归测试，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试；（8）产品的功能比较完善后，进行产品的性能压力测试，并根据测试结果进行性能调优；（9）当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，确认发布包和文档完整后进行产品发布，必要的文档必须包括：A） 安装操作手册、B） 产品白皮书、C） 管理维护手册、D） 用户操作手册、E） 测试报告


        6    、产品发布：当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，确认发布包和文档完整后进行产品发布。对于新产品来说，必要的文档必须包括：
    （1） 安装操作手册
    （2） 产品白皮书
    （3） 管理维护手册
    （4） 用户操作手册
    （5） 测试报告


        7    、版本控制：新版本软件发布之后，马上对代码进行质量控制。
    （1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为IAGW1.0.0，则给该软件源代码也打一个与发布版本相同名字的tag IAGW1.0.0。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。
    （2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。
         8    、在需求与规范管理中，由测试负责人与项目经理同时管理、控制与讨论，使需求的管理与变更有了一个严格的控制，经过开发经理、项目经理、测试负责人、相关开发人员和测试人员讨论过的需求实施起来更加准确完备，确保开发出来的产品符合规范和客户需求；测试负责人自需求阶段参与整个项目，有利于对项目的理解，为测试设计和测试实施打下基础，同时在此过程中可以起到保障产品质量的作用。

     

    第二部分  应用说明
            项目计划、测试计划编写前先开会讨论，由模块负责人估算工作量，能确定的问题和时间安排都在讨论中确定下来，然后根据工作量和工程需求制定项目计划和测试计划；开发在编码前需要进行概要设计和详细设计，确保开发在编码前对自己所负责的模块有一个清晰的设计思路，经评审后确认模块的设计是否合理；计划或设计都是以邮件的形式进行评审；对于存在严整分歧的问题，组织一个小型会议进行讨论有效解决问题，对于规范中不明确的问题集中后由测试负责人直接与移动总规范负责人直接交流，确保不会因为规范的理解不正确导致项目实现与需求不一致。
           测试工作中，在项目编码阶段，测试负责人对项目进行测试设计，指导测试实施有依可循，在编写案例的过程中会遇到很多与流程和细节处理相关的问题，与开发一起讨论也有助于提前发现问题与完善代码；在测试实施阶段，测试人员记录所发现的问题，并协助开发及时解决，在测试过程中所遇到的问题，测试负责人进行记录和分析，在每个阶段完成后提交经分析后的测试阶段报告，在软件测试阶段报告中总结分析了测试过程中所发现的问题并对这些问题提出解决建议，在后续的开发与测试中进行改进与调整，确保项目能够按时保质发布。软件的管理和版本管理则由Build Master负责，确保软件得到良好的控制。
            在这个小型的项目实施中并没有完整实施CMMI5，但是，CMMI5的思想在这个过程中得到了很好的体现，比如在需求与规范管理阶段：（1）需求由测试负责人收集，由项目经理、开发经理和测试负责人讨论，就相当于是一个小型的CCB，节约了资源，也确保了质量；（2）经初步讨论过的需求与规范整理出重点内容（相对于CMMI5的项目愿景与范围的简化版本）后，相关的人员再在一起讨论，这样可以更加有的放矢，需求讨论的效果更加明确；（3）在讨论过程中确定功能列表，明确了开发与测试的功能（相当于CMMI5的需求评审后的项目功能列表）；（4）所有的相关的文档都需要commit到CVS，测试负责人确认所有相关文档都已经commit到CVS，进行了PPQA的检查工作（在其余阶段也是如此）。
            在整个流程中，测试负责人除了负责测试相关任务以外，同时承担了需求管理、流程跟踪、协调沟通等工作（当然，也可由项目经理或开发经理等担任），在其中由测试推动项目开发与实现，在开发成员之间、开发与测试之间搭了一座良好的桥梁，这样的一个协调与推动促进了项目的顺利完成，适合于五至二十的小型团队。测试驱动开发的模式，对测试负责人的要求很高，需要测试负责人具有很高的业务理解能力、沟通协调能力和CMMI5实施经验。

    这个精简的实施流程，不但确保了软件的质量，而且实施成本较低，在团队实施中非常容易推广。

     

     

    Written by smilings in GuangZhou , 2006

     

    查看(717) 评论(2) 收藏 分享 管理

  • 软件测试流程

    2006-12-22 17:46:02

    软件测试流程

    一、新产品或工程管理流程

    1、  需求调研

    在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

    2、  制定测试计划

    进行每一种测试之前，测试负责人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施。

    3、  需求Review

    开发在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，对需求分析文档进行Review，检查文档是否满足了需求，是否与需求一致等等。

    4、  设计Review

    在软件分析设计阶段，测试人员参与设计讨论，了解系统的实现方式和原理，并对概要设计和详细设计提出自己的见解。设计结束之后，开发提交概要设计文档和详细设计文档，测试人员对设计进行Review，检查设计规划和实现方案是否合理，如果不合理，存在的问题是什么、如何改进等等。

    5、  测试设计

    在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。每个测试用例必须包括以下几个部分：

    （1）       标题和编号

    （2）       测试的目标和目的

    （3）       输入和使用的数据和操作过程

    （4）       期望的输出结果

    （5）       其他特殊的环境要求、次序要求、时间要求等

    6、开发测试工具和准备测试数据

       在软件测试中，为了提高测试工作的效益和质量，只要条件许可，应尽可能采用计算机自动或半自动测试的方法，利用软件工具本身的优势来提高工作效率。

    7、测试执行

    当所有必需的测试准备工作都已完成，并且产品已经开发完毕并提交测试，则可以按照预定的测试计划和测试方案逐项进行测试。在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录。为了能准确的找出问题产生的原因，及时的解决问题，保证测试工作的顺利进行，一般来说所发现的问题必须是能够重视的。

    8、回归测试

       在测试中发现的任何问题和错误都必须有一个明确的解决方法。一般来说，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试。另一方面，对于版本更新后的软件也必须进行同样的测试过程。

    9、测试分析报告

       测试结束后要及时地进行总结，对测试结果进行分析，由测试负责人提交“测试分析报告”。

    10、产品发布

       测试完毕，整理产品发布包和相关文档并发布。对于新产品来说，必要的文档必须包括：

    （1）       安装操作手册

    （2）       产品白皮书

    （3）       管理维护手册

    （4）       用户操作手册

    （5）       测试报告

    11、版本控制

    新版本软件发布之后，马上对代码进行质量控制。

    （1）       Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tag p2p3.3.2。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。

    （2）       Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。

    二、工程维护管理流程

    1、  收集新需求：新功能和不紧急的故障，其代码的修改操作不必马上进行，取而代之的是做好新需求与故障统计；对已经确认的故障也可以先在bug管理系统报bug，但只是记录，不需求马上修改。当然了，对于紧急的工程故障，需要马上修改和测试。

    2、  确认新需求：与工程人员或客户或产品经理确认新需求，确保需求被理解正确。

    3、  需求讨论：当需求与故障积累到一定数量或者工程有新版本需求，进行一次发布测试，在新版本开始修改之前把近期积累的需求与故障整理，与相关开发人员、测试人员、项目经理和测试经理讨论，确认哪些新功能可以实现、新功能的实现方法与业务流程、新功能开发修改时间、测试版本、测试时间与发布时间。

    4、  在bug跟踪管理系统报bug：确认所有需要修改的新功能和需求录入bug跟踪管理系统，并在bug跟踪管理系统中详细描述新功能需求和解决方法，同时整理相关bug列表，交付开发修改。

    5、  制定测试计划：

    A、 根据用户需求，定义并完善测试需求，作为测试的标准

    B、 确定重点测试事项，哪些功能需要重点测试

    C、 测试时间计划，并详细计划具体测试任务与时间

    D、风险说明

    E、 测试准备，提前对测试环境和测试资源进行准备

    F、 发布具体时间

    G、资源需求：包括测试人员、硬件需求、软件需求和培训计划

    6、  编写测试案例：根据功能需求编写测试案例

    7、  测试开发：开发自动测试脚本，补充自动测试案例

    8、  测试实施：按照测试计划进行测试，发现并申报bug

    9、  测试评估：

    A、 哪些需求通过了测试

    B、 有哪些遗留问题

    C、 测试效率评估

    D、开发质量度量和评估

    E、 并根据评估编写测试报告

    10、              发布新版本：

    A、 编写新功能文档，给工程提供新功能说明

    B、 编写升级文档，给工程提供升级参考方案

    C、 软件发布，包括新版本软件、新功能文档、升级文档和测试报告

    11、              代码版本控制：新版本软件发布之后，马上对代码进行质量控制。

    A、 Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tag p2p3.3.2。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。

    B、 Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。

     

    Written by smilings in GuangZhou , 2006

     

     

    查看(3208) 评论(20) 收藏 分享 管理

  • 软件测试计划模板

    2006-12-22 17:45:10

    第1章          引言

    1.1   目的

    简述本计划的目的，旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。

    测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。在计划目的中需要指明读者对象。

    1.2   名词解释

    列出本计划中使用的专用术语及其定义

    列出本计划中使用的全部缩略语全称及其定义

    缩写词或术语

    英文解释

    中文解释

     

     

     

     

     

     

    1.3   参考及引用的资料

    列出本计划各处参考的经过核准的全部文档和主要文献。

    1.4   计划摘要

    这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。

    1.4.1 重点事项

    列出测试的重点事项。可以将问题按重要程度和优先级罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在

    1.4.2 争议事项

    简要说明争议事项。

    1.4.3 风险说明

    通过对技术文档的阅读，对被测系统可能存在的问题：系统设计，数据库设计，响应时间，计费策略，因测试环境不足可能存在的测试缺陷事先评估出来，以指导测试方案，进行有重点的测试．

    1.4.4 时间计划

    简要说明测试开始时间与发布时间。

    1.4.5 质量目标

    简要说明测试发布的质量目标：

    测试计划中所有测试方法和模块已经执行通过

    所有的测试案例已经执行过

    所有的重要等级为1/2的Bug已经解决并由测试验证

     

    第2章          测试背景

    2.1   测试范围

    说明本计划涵盖的测试范围，比如功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。

    （1）简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。

    （2）如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。

    （3）列出可能会影响测试设计、开发或实施的所有风险或意外事件。

    （4）列出可能会影响测试设计、开发或实施的所有约束。

    2.2   系统目标

    系统目标对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。

    通常情况下项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。

    2.3   联系方式

    列出项目参与人员的职务、姓名、E-mail 和电话。

    职务

    姓名

    E-Mail

    电话

    开发工程师

     

     

     

    CVS Builder

     

     

     

    开发经理

     

     

     

    测试负责人

     

     

     

    测试人员

     

     

     

    2.4   风险及约束

    列出测试过程中可能存在的一些风险和制约因素，并给出规避方案。如：

    Ä 由于客观存在的设备、网络等资源原因，使得测试不全面。明确说明哪些资源欠缺，产生什么约束

    Ä 由于研发模式为现场定制，且上线时间压力大，使得测试不充分。明确说明在此中约束下，测试如何应对

    Ä 只针对专门的客户群需求的测试。明确说明此约束下的客户群和业务范围。

    2.5   测试文档

    列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置，测试完成后应产生的文档。

    2.5.1测试参考文档

    文档说明

    作者

    文档位置（CVS）

    需求文档

     

     

    总体设计

     

     

    白皮书

     

     

    使用手册

     

     

    管理手册

     

     

    测试文档

     

     

    API文档

     

     

     

     

     

    2.5.2测试提交文档

    文档说明

    作者

    文档位置（CVS）

    《总体测试计划》

     

     

    《总体测试方案》（可根据项目情况进行裁剪）

     

     

    测试用例

     

     

    《性能测试方案（报告）》

     

     

    《测试报告》

     

     

    《Readme》

     

    查看(6341) 评论(4) 收藏 分享 管理

  • 软件测试计划编写策略

    2006-12-22 17:43:01

        测试计划描述了如何完成测试，有效的测试计划会驱动测试工作的完成，使测试执行、测试分析以及测试报告的工作开展更加顺利。

    一、测试计划的重要性和目的

    1、  测试计划的重要性

    测试计划是在软件测试中最重要的步骤之一，它在软件开发的前期对软件测试做出清晰，完整的计划，不光对整个测试起到关键性的作用，而且对开发人员的开发工作，整个项目的规划，项目经理的审查都有辅助性作用。

    2、  测试计划的目的

    测试计划描述所要完成的测试，包括测试背景、测试目的、风险分析、所需资源、任务安排和进度等：

    （1）将需求和总体设计分解成可测试，应该测试，推迟测试和无法测试的范围

    （2）对每个范围制订测试的策略和方法

    （3）制订release和停止测试的标准

    （4）准备测试所需要的环境

    （5）确定测试风险

    （6）确定软件测试目标

    （7）确定测试所需要的资源其其他相关信息

    （8）制订测试进度和任务安排

    二、测试计划编写基本策略

    1、测试计划编写依据：项目计划、项目计划的评估状态以及业务的理解

    2、测试计划编写时间：尽早开始。原则上应该在需求定义完成之后开始编写测试计划，对于开发过程不是十分清晰和稳定的项目，测试计划也可以在总体设计完成后开始编写。

    3、测试计划的编写与实施：测试计划应该由测试小组组长或最有经验的测试人员来进行编写，测试计划由测试人员来实施，测试人员可以对测试计划进行相关人员确认后进行调整。

    4、测试计划的变更：测试计划是一个发展变化的文档，会随着项目的进展、人员或环境的变动而变化，确保测试计划是最新的而且依据测试计划执行测试工作。

    5、测试计划的优先级别：没有谁可以保证通过测试后的产品没有缺陷，也没有公司会允许无休止的测试。好的测试是一个有代表性、简单和有效的测试，在测试计划中，必须制定测试的优先级和重点。

    6、测试计划的评审：测试计划需要由高级测试人员或测试组长制订，在经验不足或条件限制的软件测试计划的制订时，需要多名测试人员共同制订和修正.

    （1）软件项目经理负责评审测试计划的方向正确性和软件开发按照总体设计方案实施(如有改动，需通知测试人员修改计划)，并保证软件具有可测试性

    （2）QA人员评审测试过程的正确性和能够按照计划要求的正确实施

    （3）高级经理评审测试计划的导言和范围的正确性

    7、测试计划的管理

    测试计划将按照项目编码或软件名称和版本进行管理，所有文档放置于CVS。

    8、测试计划制定过程：

    （1）       评估项目计划和状态

    （2）       组建测试小组

    （3）       了解项目风险

    （4）       制定测试计划

    （5）       审查测试计划

    9、测试计划的原则

    （1）       尽早开始

    （2）       灵活变更

    （3）       合理评审

    （4）       简洁易读

    三、测试计划的主要内容

    测试计划的内容会因不同的项目以及项目的大小而有所不同，一般而言在测试计划中应该清晰描述以下内容：

    1、  测试目标：对测试目标进行简要的描述。

    2、  测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。

    3、  测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。

    4、  重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。

    5、  质量目标：制定测试软件的产品质量目标和软件测试目标。

    6、  资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。

    7、  人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。

    8、  测试策略：制定测试整体策略、所使用的测试技术和方法。

    9、  发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。

    10、              测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。

    11、              测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。

    12、              风险分析：需要考虑测试计划中可能的风险和解决方法。

    四、软件测试计划模板

           请参考《软件测试计划模板》，在模板中详细讲述了如何编写测试计划。

     

    Written by smilings in GuangZhou , 2006

    查看(3183) 评论(5) 收藏 分享 管理

  • 如何编写有效测试用例

    2006-12-22 17:37:26

    测试用例，是一份关于具体测试步骤的文档，它描述了测试的输入参数、条件及配置、预期的输出结果等，以判断被测软件的工作是否正常。设计、书写和执行测试案例是测试活动中重要的组成部分，测试案例通常由测试案例管理系统或工具进行管理。

    一、编写测试用例的原则

    测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。测试用例编写应该遵循的原则：

    1、测试用例要达到最大覆盖软件系统的功能点。测试工程师应该在测试计划编写完成之后，在开发阶段编写测试用例，参考需求规格说明书和软件功能点对每个功能点进行操作上的细化，尽可能趋向最大需求覆盖率。

    2、测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。

    3、测试用例的设计应包括各种类型的测试用例。在设计测试用例的时候，除了满足系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受压力的能力等。

    4、测试用例的管理。使用测试用例管理系统对测试用例进行管理。

    一个好的测试用例应该具有较高的发现某个尚未发现的错误的可能性，而一个成功的测试案例能够发现某个尚未发现的错误，通常一个好的测试案例有以下特性：

    1、具有高的发现错误的概率

    2、没有冗余测试和冗余的步骤

    3、测试是“最佳类别”

    4、既不太简单也不太复杂

    5、.案例是可重用和易于跟踪的

    6、确保系统能够满足功能需求

    测试用例不可能设计得天衣无缝，也不可能完全满足软件需求的覆盖率，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试。

    二、如何编写测试用例

    测试用例的信息有很多，可以根据实际的情况进行增删，一般来说一个优秀的测试用例应该包含以下信息：

    1、产品相关信息

    （1）    软件产品或项目的名称

    （2）    软件产品或项目的版本

    （3）    功能模块名

    （4）    功能描述

    （5）    测试平台

    这些信息建议可以在测试案例手工选择。

    2、基本记录信息

    （1）    测试用例入库者

    （2）    测试用例入库时间

    （3）    测试用例更新者

    （4）    测试用例更新时间

    这些信息建议可以由测试案例自动生成。

    3、测试用例的属性

    （1）    测试用例ID：测试用例的ID（由案例管理系统自动生成，方便跟踪管理）

    （2）    测试用例名称：测试用例的名称

    （3）    测试功能点：测试的功能检查点

    （4）    测试目的：该测试功能点的测试目的

    （5）    测试级别：主路径测试、烟雾测试、基本功能测试、详细功能测试。     

    下面对这几个测试级别进行说明：

    A、                   主路径测试：对照需求中重要模块和功能的最主要功能路径，主路径测试为设计探针模块，快速检查程序的可测试性（可测试性还包括安装测试是否成功）的主要依据的测试案例

    B、                   烟雾测试：对照需求中所有模块的主要功能路径，主路径测试案例为烟雾测试案例的子集，烟雾测试为做回归测试的主要依据的测试案例。

    C、                   基本功能测试：对照需求和总体设计中所有模块和功能的基本功能路径，基本功能测试为测试软件产品的非重要级别模块，书写完全的自动测试脚本的主要依据。

    D、                   详细功能测试：对照总体设计中所有模块和功能的功能路径，测试各个模块及功能各个层次，各种类型。详细功能测试案例为对重点模块，易发生错误的模块的主要依据。

    （6）    测试类型：功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/停止测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。

    （7）    预置条件：对测试的特殊条件或配置进行说明

    （8）    测试步骤：详细描述测试过程，案例的操作步骤建议少于15个。

    （9）    预期结果：预期的测试结果

    例如：假设目前测试中国移动互联短信网关是否能正确发送短信给中国联通互联网关，测试用例的设计如下：

    （1）    测试用例ID：TC000001

    （2）    测试用例名称：中国移动全球通手机用户成功发送短信给中国联通手机用户

    （3）    测试功能点：中国移动全球通手机用户成功短信给中国联通手机用户，中国联通网关返回成功的状态报告

    （4）    测试目的：

    A、                  中国移动互联短信网关能否正确处理全球通用户发送给中国联通用户的短信；

    B、                  中国移动互联短信网关能否正确处理中国联通互联短信网关返回成功的状态报告的情况。

    （5）    测试级别：基本功能测试

    （6）    测试类型：功能测试

    （7）    预置条件：各网关实体按照组网图中的关系连接好，各实体之间的连接和通信正常。

    （8）    测试步骤：

    A、                  中国移动全球通手机用户（13901000001）给中国联通手机用户（13001000001）发送MO短信，内容为“测试”，目的号码填为中国联通手机号码；

    B、                  中国联通互联短信网关把短信下发给中国联通用户成功后，给中国移动互联短信网关返回一个标识成功的状态报告。

    （9）    预期结果：

    A、                  中国联通手机用户（13001000001）接收到了短信，内容为“测试”，源号码为中国移动全球通的用户号码（13901000001）；

    B、                  在中国移动互联短信网关上产生SMO话单，其中“短消息发送状态”填0（表示成功），“源手机号码”为13001000001，“目的手机号码”为13001000001。

    三、测试案例的模版

    下面是一个完整的测试用例的模版：

    测试用例ID

    TC000002

    测试用例名称

    非法用户登录管理网页

    产品名称

    互联互通网关

    产品版本

    V3.3.2

    功能模块名

    管理网页

    测试平台

    所有

    用例入库者

    smilings

    用例更新者

    smilings

    用例入库时间

    2006-5-30

    用例更新时间

    2006-5-30

    测试功能点

    输入错误的用户名和密码

    测试目的

    阻止非法用户登录系统

    测试级别

    详细功能测试

    测试类型

    功能测试

    预置条件

    登录用户名和密码为admin/test

    测试步骤

    1、输入用户名称为admin，密码为test%

    2、按“登录”按扭登录管理页面

    预期结果

    1、系统拒绝该用户登录

    2、提示错误信息：“对不起，您的用户密码不正确，请重新确认再登录！”

    四、测试用例设计过程

    对一个全新的产品来说，首先需要了解的是产品需求文档和产品模块之间的关系。然后需要从需求文档中书写与所有需求相对应的主路径测试案例和烟雾测试案例，这个时候也同时会包括一定的基本路径测试案例甚至是详细测试案例。在这个时候，因为对产品没有直接的使用感受，书写测试案例要考虑面广而不要太过精细。继续阅读产品功能定义文档，将所有的功能定义直接对应写相关的测试案例，这个时候，最好能够对程序的本身有一定的接触，加深对程序的了解，以便写出更好，更全面的测试案例。最后，在实际测试中，还需要不断扩充，修改以前的测试案例，得到完整的基本功能测试案例和详细测试案例。

    查看(3336) 评论(10) 收藏 分享 管理

  • 测试用例设计方法

    2006-12-22 17:34:58

    黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里，主要讨论的是黑盒测试的测试用例的设计方法。

    一、等价类划分

    等价列划分设计方法是把所有可能的输入数据划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例，测试某等价类的代表值就等于对这一类其他值的测试。

    使用等价类划分方法设计测试用例主要有两个步骤：（1）确定等价类；（2）生成测试用例。

    1、划分等价类

    等价类划分有两种不同的情况：有效等价类代表对程序的有效输入和无效等价类代表不正确的输入值，设计时要同时考虑这两种等价类。下面是确定等价类的原则：

    （1）              在输入条件规定了取值范围的情况下，则可以确立一个有效等价类（在取值范围之内）和两个无效等价类（小于取值范围和大于取值范围）。 例如：使用手机发送短信的时候，短信内容长度必须在70个字符之内，则有效等价类：短信内容长度在70个字符之内，无效等价类：短信内容长度为0、短信内容长度大于70。

    （2）              在输入条件规定了取值的个数的情况下，则可以确立一个有效等价类（在取值个数范围之内）和两个无效等价类（小于取值个数和大于取值个数）。例如：一名学生一个学期可以选修一至五门课程，则有效等价类为：1<=学生选修课程<=5，无效等价类为：没有选修课程、选修课程大于5

    （3）              在输入条件规定了输入值的集合的情况下，则可以确立一个有效等价类和一个无效等价类。 比如：发送短信的编码的取值范围是0、3、4、8、15或16，则有效等价类是：短信编码为0或3或4或8或15或16，无效等价类是：短信编码不是0或3或4或8或15或16其中任何一种。

    （4）              在输入条件规定了 “必须如何”的条件的情况下，则可以确立一个有效等价类和一个无效等价类。 例如：变量的命名比如以大写字母开头，则有效等价类为：变量命名以大写字母开头，无效等价类为：变量开头非答写字母开头。

    （5）              在输入条件是一个布尔量的情况下，可以确立一个有效等价类和一个无效等价类。 例如：在神州行手机号码预扣费成功的情况下，允许该用户发送短信，则有效等价类为：神州行预扣费成功，无效等价类为神州行预扣费失败。

    （6）              在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类。

    （7）              在规定了输入数据必须遵守的规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

    （8）              在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

    2、生成测试用例

    在确立了等价类后，可建立等价类表，列出所有划分出的等价类，过程为：

    （1）       为每一个等价类规定一个唯一的编号。

    （2）       设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。

    （3）       设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

    二、边界值分析法

    边界条件指的是输入和输入等价类中刚好处于边界、或超过边界或小于边界的状态，使用边界值分析方法设计测试用例应先确定边界情况，然后选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。

    基于边界值分析方法选择测试用例的原则：

    （1）              如果输入条件规定了值的范围，则应取刚达到这个范围的边界值设计有效测试用例，以及刚刚超过这个范围的边界值作设计无效测试用例。比如：短信内容的有效长度为70个汉字以内，则有效测试用例：短信内容长度为1，短信内容长度为70个汉字，无效测试用例：短信内容长度为0，短信内容长度为71个汉字。

    （2）              如果输入条件规定了值的数量，则应取最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试输入的数据。 例如：短信的有效编码为1~255，则应取0、1、255、256设计边界值测试用例。

    （3）              根据规格说明的每个输出条件，使用前面的原则1。

    （4）              根据规格说明的每个输出条件，使用前面的原则2。

    （5）              如果程序的输入或输出是一个有序集合，则应选取集合的第一个元素和最后一个元素设计测试用例。

    （6）              如果程序中使用了一个内部数据结构，应当选择这个内部数据结构边界上的值设计测试用例。

    （7）              分析规格说明书，找出其他可能的边界条件。

    三、因果图法

    因果图法是一种适合于描述对于多种条件的组合、相应产生多个动作的形式的测试用例设计方法。

    利用因果图生成测试用例的步骤为：

    （1）       将规范说明书分解成可执行的片段。

    （2）       确定规格说明书中的因果关系。分析软件规格说明描述中那些是原因，那些是结果，并给每个原因和结果赋予一个标识符。

    （3）       分析软件规格说明描述的语义，找出原因和结果之间、原因和原因之间的关系，并将其转换成因果图。

    （4）       在因果图上加上注解符号，用一些记号表明约束或限制条件。

    （5）       跟踪图中的状态变化情况，把因果图转换为判定表。

    （6）       把判定表的每一列拿出来作为依据，设计测试用例。

    四、 错误推测法

    错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

    错误推测法的基本思路是列举出程序中所有可能有的错误和容易发生错误的清单，根据清单设计测试用例；另一个思路就是在阅读规格说明时有哪些容易被程序员忽略的内容来设计测试用例。

    错误推测法是一种非常有效的测试用例设计方法，这要求测试人员有丰富的测试经验和对业务的处理非常熟悉。比如，在短信发送的时候，如果发送短信之后，对方网关没有响应或者超时响应或者没有回复状态报告，那程序怎样处理呢？

     

    参考资料：《软件测试的艺术》

    Written by smilings in GuangZhou , 2006

    查看(8606) 评论(12) 收藏 分享 管理

    • 211/212>