敏捷测试的实践

PAGEPAGE1敏捷测试的实践摘要：在敏捷测试流程中,参与单元测试,关注持续迭代的新功能,针对这些新功能进行足够的验收测试,而对原有功能的回归测试则依赖于自动化测试.由于敏捷方法中迭代周期短,测试人员尽早开始测试,包括及时对需求、开发设计的评审,更重要的是能够及时、持续的对软件产品质量进行反馈.关键词：敏捷测试;敏捷开发;开发周期;单元测试1引言之前跟众人一样对敏捷开发比较熟悉，觉得新鲜而有效率。刚看到老师给的题目时才知道敏捷测试这个概念，自己一直局限于测试方法的学习，并没有系统并从大体框架去学习和了解测试这个行业。在学习敏捷测试过程中了解到这样几个概念：TDD（测试驱动开发TestDrivenDevelopment）、ATDD(验收测试驱动开发AcceptanceTestDrivenDevelopment)、UTDD(单元驱动测试UnitTestDrivenDevelopment)以及精益方法，并由此开始了解到软件测试和其他知识领域的交叉处。敏捷测试进入国内研究领域还是一个新生力，查找到的国内文献也是极其有限的，在这里也只是发表自己浅陋的理解。通过之前的对软件项目案例的学习，我比较欣赏的是软件生命周期中的螺旋式模型，那敏捷是先于开发，也就跟传统的测试有本质的区别。传统的测试是先写测试计划，此后的测试过程分布在螺旋式模型中的每一次完善的循环中，而敏捷测试则是在开发前写好了用例，根据用例再去开发系统，可以减少很多错误，但这也就意味着开发人员的主导作用更明显。与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。敏捷测试接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分。2敏捷测试背景2.1敏捷测试敏捷测试是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，如图1所示。图1敏捷测试定义的形象描述2.2敏捷测试的核心首先要从整个项目全局考虑，及早发现需要更改设计的问题。其实这个测试更多的是观察与思考，而是否能发现问题就要看开发人员对需求掌握是否透彻，对整个项目是否有一个全局的把握，是否从最终用户角度去考虑问题，是否以实现客户的商业价值为目标。然后在最短时间内完成所有功能和业务逻辑的测试，最好是每人分配不同的功能和业务逻辑进行测试，这样就可以在最短时间内及时将优先级较高的缺陷及时反馈给开发人员。最后在开发人员忙于修改那些优先级较高，难度较大，比较耗时的缺陷的同时测试人员可以有充分的时间来对这一迭代进行较细致的测试，发现功能和业务逻辑中不易察觉的问题，次要功能问题、验证、界面等。那么，作为一个测试工程师在测试中使用敏捷的思想进行测试，并且需要敏捷测试中需要保证其工作符合相应的准则：①获取和明确用户的质量期望；②建立合适的系统测试、用户验收测试质量标准；③推进单元测试、开发测试；④建立持续构建框架；⑤持续改进自动化测试；⑥保持质量度量结果的可见性。2.3敏捷测试流程优化在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的主测试计划书，然后再建立每个功能任务的测试计划书，测试计划书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员（包括测试经理）讨论，最终得到大家的认可和签字才能通过，仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库（在线管理系统）中。在敏捷测试中，可能不需要测试用例，而是针对UseCase或UserStory直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如图2所示。图2敏捷测试流程简要图在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。参与代码复审（CodeReview），并适当辅助开发人员进行单元测试。通用电子商务平台测试用例的设计及执行（实践部分）1.负责的任务和执行在本次测试过程中，由于之前有功能测试的经验，所以被安排设计测试用例并执行。但在实际的工作中仅仅按照等价类划分和判断表驱动法这样的分类方法去设计用例，并相应的删除冗余。首先，熟悉了解需要测试的两个模块：购买模块以及注册模块；然后根据系统设计文档列出系统的待测功能点。第一部分是购买模块的功能点，这部分主要是单元测试，除了购物车部分，其他部分均不需要输入值，依次点击链接查看功能是否实现。购物车物品数量部分本应该只存在正数，在我们输入不合法字符之后，系统有提醒输入异常，但当输入的为负数值时，系统却在结算部分显示了相应的负数金额，这在实际操作中是不合理的，并且很有修改的必要。结算部分就算购物车没有商品，它依然会跳转至结算页面，而按照需求和设计文档，此部分应该提示购物车为空。购买流程测试：expectedresultpracticeresultcase01点击商品，查看信息链接到商品详情页面链接失败failcase02多次点击购买，刷新链接正常，数据添加成功链接失败，数据无法添加failcase03点击购物车链接链接正常链接正常passcase04删除购物车物品链接正常，数据删除成功链接正常，数据删除成功passcase05变更数量1180180passcase06100018000180000passcase07-1提醒输入异常-180failcase08-100提醒输入异常-18000failcase09a%提醒输入异常无反馈failcase10商品金额总计只存在合理的正数金额值数量为负，金额总计也为负failcase11恢复记录恢复恢复passcase12继续挑选商品链接链接正常链接正常passcase13无商品，测试结算功能提示购物车为空进行结算fail第二部分是注册模块测试，因为系统需要输入值的模块并不多，所以特意选取了输入值要求比较多的注册模块。在设计测试用例的过程中，由于需求和系统设计文档等资料不详细，所以在邮箱这部分的测试比较琐碎，甚至为了测试用例覆盖比较完整，特意去研究了邮箱的校验机制varpattern=/\b(^['_A-Za-z0-9-]+(\.['_A-Za-z0-9-]+)*@([A-Za-z0-9-])+(\.[A-Za-z0-9-]+)*((\.[A-Za-z0-9]{2,})|(\.[A-Za-z0-9]{2,}\.[A-Za-z0-9]{2,}))$)\b/;这部分的测试用例主要是针对邮箱校验的每一部分，但仅仅根据这个还是不够的，因为这部分校验机制也不一定完整并且合理，所以主要是校验机制和大型邮箱网站的校验机制想综合进行测试用例的设计。此外根据之前的测试经验进行了冗余测试用例的删除，减少了测试用例的数量，使得执行效率变高。另外一个问题比较集中的是昵称部分，在测试到此部分时，发现校验机制做的饼不完善，无论输入任何不合法的字符或者超过正常昵称长度的昵称都可以通过验证，这在实际的项目中是一个比较严重的问题。在实际的测试中我们第一部分进行的是静态测试，正常的代码走查需要4个人左右，主要人员包括：总协调人1名、参与项目的程序员1名、设计人员1名、测试专家1名。而我们的项目中由于自己之前的经验，所以充当了总协调人和测试专家的角色，当然除了程序的设计者和程序员，我们还安排有其他组员一起发现代码设计或者采用框架上的不足。前期的代码走查也为后期我做注册部分的测试用例设计提供了很大的帮助，我不仅仅了解其他邮箱网站的输入合理性，也了解本系统的校验机制以及邮箱校验的不合理之处、昵称输入的缺陷等问题。2.收获和体会之前在公司做测试时主要的是执行测试用例以及做回归测试，有试着写过测试用例，但效果不理想，后期得益于组长的指导，对根据设计文档写测试用例有了一定的了解，但还不熟练，这一次在小组中由于自己的组织能力和之前的经验，虽然不想担任组长的责任，但仍然做着组长的事情，因为我想知道自己一个人去安排并负责这些到底能不能行。第一次去自己独立完成测试用例，心里还是比较紧张的，不知道能做到什么样的程度，首先是回顾之前自己学的测试的知识以及老师课堂教授的内容，然后列出功能点，再依次列出各部分需要执行的条件，一路走下来，对自己还是比较满意的，因为老师给了这样一个机会去让我看到自己是可以做到这些的，虽然在测试用例的设计中还存在很大的问题。3.实践中的困难一个主要的问题，并且一直放在心上的是，老师课堂讲授的正交表排除冗余，当时没有听懂，课下也一直因为事情比较多，所以至今未深入学习这部分，但我知道我一定要学会这个知识点，不然自己在测试的路上还会积累更多的疑惑。本次测试过程中本来想实际应用下老师讲的减少冗余的方法，但对这些方法掌握有限，所以做不到灵活的运用。读软件工程，很多同学是为了做开发，很多人跟我讲测试开发人员都会做等这样轻视测试人员的话，但我从未放弃，我的目标至始至终都是为了成为了一名顶尖的测试大师，我学习各种算法，我努力研究项目管理，各种过去的以及现在流行的测试手段及方法，在年初实习的时候就已经完整了读完了《theartsof