进到一个新项目，作为测试人员应该都是想把测试做好，项目在符合客户质量要求的情况下按时交付的吧。但往往都事与愿违，造成这个结果的原因有很多很多。通过这段时间做自动化测试，站在自动化测试的角度看手工测试，以及排除其他部门的问题，单说测试自身的问题来和大家分析讨论一下怎样我能做到更好。

　　先说一下背景，我是中途进的项目，项目需要做自动化测试，依据是手工测试人员开发的用例。从测试用例和测试流程两方面来进行阐述吧。

　　首先说说测试用例。当前大部分的项目一般都是任务重时间紧，往往为了能保证能把项目“做”完，挤压了测试开发、执行和需求分析的时间。测试用例设计开发作为测试团队主要的工作任务，其重要性仅次于需求分析。如果测试用例的质量出现问题会产生一连串的影响，比如不能让新进开发团队的人员了解系统、以手工用例为基础的自动化测试开发人员无从下手或繁重的修改工作、最重要的是增加了回归测试执行的时间及风险。

　　在测试用例开发上，比较常见的问题就是用例有量无质。用例的数量上去了却无质量可言，大量重复的又缺乏测试必要的用例。做为测试团队重要的输出物之一，如果不能保证用例的质量那系统的质量又从何谈起呢？测试用例的质量我觉得体现在以下两个方面：

　　1、测试用例不够详尽、缺乏目的性、重复性高

　　测试用例的详细程度是一个相对的问题。太详尽了使操作步骤过于繁琐冗长，测试人员操作完之后无法对测试用例有一个整体认识；过于简约的用例同样无法让测试人员了解测试目的，应该如何操作。在我的想法中，一个具有一定质量的测试用例应该经过多方面配合的，比如用例描述信息、用例名称及操作步骤等等。描述信息中可以描述出测试用例是由谁、在和情况下、做了什么事及最后的结果；用例名称显示出是对哪个业务进行的正面/反面测试；如果说名称和描述为辅助的信息，那么测试步骤无疑是在一个相对比较重要的位置上了。测试步骤的来源是什么？是系统需求。那么系统需求的好坏就决定了测试步骤的好坏。如果需求详尽，简洁省时的方法当然可以用直接引用的方式，这样正确性有所保证也为开发其他用例节省了时间；相反的，需求不够详尽，是否应将测试步骤进行一定的扩展，避免操作步骤的混淆，让对系统不熟悉的人尽快了解系统功能。在测试开发的迭代周期中，最常见的问题就是需求的更改，这个是无法避免的。那么对于测试用例，我们如何应对这种变化呢？我想除了不要将用例中的期望结果过于详细外，应当勤于进行用例的开发迭代以符合系统需求，关于这一点，我们稍后再说。

　　测试用例缺乏目的性、重复性高是造成用例数量直线上升，质量直线下降的一个重要因素。假设一个用户注册的场景，用户可通过不同的证件类型完成注册，如何设计这个用例呢？我的想法是，对于注册成功的预期结果，只安排一个用例，在用例的前提条件或描述信息中突出需通过不同证件类型参数进行测试。从开发人员的角度和2/8原则的角度讲，他们的主要精力会放在将正常的注册功能开发完成，即假定用户输入的值都是合法的。实际上，测试往往就是对那些无法顺利完成功能的场景，输入无效值或测试反面场景以覆盖完全的测试场景。在设计用例时，就应当将更多的精力放在这些场景的设计上。有些人可能会说，如果将手工用例参数化，在执行用例的时候，不同的测试人员往往不会按照用例的描述，分不同的数据要求去执行，这个无法保证。从我的角度来说，一方面需要测试领导的信任，一方面也许要对测试人员进行监督。对同事信任，相信他们会进行全面的测试。对按用例要求进行测试的人员给予奖励，对不能认真完成测试用例要求的测试人员实施惩罚，这样鼓励已经做好的人继续保持，还没做好的往好的目标前进。

　　2、用例更新滞后

　　在软件开发周期中会经过几次迭代过程，每一次迭代都会经历大小不同的需求变更、系统实现变化等等。在需求发生变化后，应及时更新测试用例，以保证测试用例适用于当前的系统实现，这样才能保证回归测试的执行是有效的，并节省下更多的人力物力到更容易发生错误的地方。除了新需求的增加、老需求的变更，实时的对测试用例进行重构也是必要的，如同对系统代码进行重构一样，这样才能让系统跑的更快更安全，以更少的测试用例覆盖更多的功能点和业务规则。最初开发测试用例，由于对系统需求缺乏深入理解或开发时间紧，不能覆盖全面的测试场景或者用例重复性较高，这都需要及时的通过测试用例的重构提高系统测试用例的有效性。我认为，应该尽量争取在下一个迭代周期结束前进行或完成之前一个迭代周期中测试用例的重构。积压的测试用例越多进行重构的难度越大，耗费的精力越多，风险也就越大。需求的遗忘、变更，需要修改的用例数量之大，加之有限的时间等等，都会给测试用例重构造成隐患，延误回归测试的进度。看着上千的测试用例，谁都会头疼吧。说起来我们有几千个用例测试系统可在真正执行时有多少是能发挥效果的呢？

　　其次再说说测试流程。最早接触的是CMMI，现在慢慢的随着客户需求日新月异，加上新的流程概念的引入，越来越多的项目采用了敏捷开发的概念。就我对敏捷开发的认识，从形式上来说敏捷与CMMI的区别是，注重敏捷的沟通多于文档这些形式上的产物，当然敏捷开发不是简简单单注意沟通就可以的。对于刚刚引入敏捷概念的项目，团队之间的契合度不高，理解不深，加之大家还没有脱离CMMI的形式，导致项目流程既不敏捷，也不CMMI。说是CMMI可流程执行力度不够，说敏捷沟通又不够。我的理解，敏捷与CMMI在工作内容、职责上并无太大变化，不同的是需要加强团队之间的沟通，任何的变化都应该是连环动起来的，而不是变化传达到第一个人就结束了，就像军训时的向右看齐，只有每一个人都向右看，最后一个人才有可能和第一个人在一个水平线上。在我经历的几个项目中，沟通不够往往表现在几个方面，项目信息共享，包括技术的和业务的、需求变更、用例变更、开发进度等等。有多少会做到开发进度实时更新，更新了有多少人会去看，不如当面锣对面鼓的说清楚。在变化快的情况下，过于依赖文档反而会让大家对项目不甚了解或知之甚少。敏捷强调沟通也是为了避免在文档的更新上各个环节出现之后。再者文档对信息的传达力有多大也是个问题，举个例子，比如用例进行重构，测试人员通过映射表记录用例的变化情况，哪些是过期的，哪些是修改了步骤的，哪些是新增的等等。在设计这个映射表要提供哪些信息时一定要想谁会去看这些信息，所以哪些信息对他们是有用的，能让他们快速的找到他们想了解的东西，这些信息一定要记录。

　　这里记录了一些在项目中遇到的问题，希望可以给自己更多的思考，在以后自己的工作中可以避免，也是把一些问题拿出来和大家讨论，希望集大家之广议共同提高，有些说的不清楚，更像是抱怨别人的问题，可能因为自己的认识还不够深刻吧，会在以后的时间中改进，多写一些改进措施。对于测试会有这样的现象出现也不是测试单方面的责任，很有可能是需求没有做好，或开发的问题。对于敏捷，我们应该想的更多做的更多，才能把项目做好。