大话人生

在陪伴公司与之共同成长的2年半的测试之路上，走到今天自身遇到了前所未有的测试发展的瓶颈。

l 公司的测试部门如何发展？

l 如何提高测试部门的工作效率来保证产品的质量？

l 测试部门是否需要发生重大的变革?

l 如何提高测试人员在公司中的地位？

l 个人如何继续软件测试？

l 个人如何去培养和提高测试团队的战斗力？

l 我们的软件测试和大公司的差距在哪里？有多大？

……

这一系列的问题一直在困扰着我，也一直指引着我去寻找它的答案。

以自己作为一名普通测试员在公司的所见、所闻、所感，以及在工作中所面临的问题，急待想解决的问题进行了描述；仅仅针对工作中发现的一些问题以及自己加入clochase测试部门2年半来所经历的测试之路发表一些个人的想法，也希望能够帮助公司和自己快速成长。

测试工作中的疑问

对于自己在测试工作中，一直有些疑问没有解开。主要有两点：

第一个问题，测试部门的定位

自测试团队成立至今，公司一直称为QA（Quality Assurance），顾名思义：质量保证人员。一个对于整个软件项目活动中，对整个软件项目过程进行监控，以反馈给团队和客户质量的质控人员。而目前公司“QA”部门所做的是对已开发完毕的软件进行验证、测试以及反馈，发现足够多的问题和BUG从而来保证软件的质量，准确的说应该是软件测试人员。

我们如何来对自己的职位进行定位？是继续做一个合格的测试人员，作为软件工程中质量保证最后一道把关人，还是继续发展成为一个对软件工作流程进行质控，准确把握整个软件项目质量的QA？而我们如何在测试的基础上像QA的方向转型？或者说当公司有必要建立QA团队的时候，我们应该具备什么样的能力去与之匹配和胜任？

第二个问题，测试部门的发展方向
测试团队的发展是摆在目前团队面前很重要的一个问题，相信很多测试员工会有和我一样的疑问。测试部门的发展方向是否有考虑到发展测试团队成为一个有效的盈利团队，替用户设计解决方案，进行第三方测试，拓展新的业务领域？还是做一个自主研发产品，与软件开发紧密配合的协同人员？

如果说测试团队的发展方向是拓展新的业务领域，成为自主独立的团队。但是目前或者说接下来的几年里依靠什么样的的测试技术水平和素质才能实现此目标呢？

测试工作中面临的问题 

（1）测试管理流程不规范

测试版本由于缺乏合理的配置管理流程而失去控制，测试计划很难制定，基本上是等待开发人员开发完一个功能，马上进入测试，再反复修改、测试……

如何制定好有效的测试计划，让测试人员和开发人员之间的合作形成一种顺畅而且方便的沟通方式呢？

（2）测试用例的编写与管理以及执行力度不足

测试用例基本不够时间编写，或者在早期编写出基本的、粗糙的测试用例，后面基本上不会按这些用例来执行，因为程序的变更过于频繁，缺乏需求控制，另外，测试人员忙于应付开发人员提交的测试版本，不会有时间完善和修改测试用例，导致编写的测试用例成为一个形式意义上存在的工具。

因此，有时甚至完全抛弃测试用例的管理，不写测试用例。而实际上测试用例的编写还是有好处的，测试用例被称之为软件测试的“指南针”，是指导测试人员如何对软件进行有效测试的坐标，测试人员能通过编写测试用例熟悉系统的业务需求（虽然有时候很可能需求文档也是缺乏的！）。“探索性测试”的方法和“敏捷测试”的模式是这个阶段主要测试模式。

此时也效法教科书的做法，建立测试用例库，但是测试人员没有意识到如何充分利用好测试用例，没有充分理解测试用例的“设计”的重要性，停留在表面的测试用例书写上。如何让测试用例成为真实有效的一个测试工具成为困扰我的问题。

（3）测试过后没有测试报告

在一轮测试过后没有给出具体的测试报告，只是简单的把bug记录在bug管理器上，然后机械化的发布release notes。对于每次测试的时长和效率相比上次的测试效率没有有效的分析，不便于测试流程过程中的优化和改进，只是为了测试而进行机械化的测试。

（4）自动化测试的实施基本上不存在

公司基本上不引用自动化的相关测试，或者尝试自动化测试，但是没有收到很好的效果，资源缺乏，尤其是缺乏自动化测试的相关培训，除了一些对自动化测试感性趣的同事，其他测试人员要么对自动化测试“不感冒”，要么没有足够的脚本编写能力。另外，缺乏完善的项目管理、配置管理制度的配合，大家只能进行非常简单的自动化尝试，并且停留在小范围、个人的尝试。

在目前公司的测试工作当中，往往需要一人多职。在如此高强度工作任务之下，凭借纯粹的手工测试，可以说根本无法保证项目或者产品的质量。因此引入自动化测试的模式可能会成为一种比较好的测试方式。

（5）测试团队内部缺乏有沟通

目前测试小组之间的沟通和交流及其少，都忙于自己的测试工作或者项目。大家有下意识的认为，每个小组间的项目不同，所设计的内容和范围不同，在一起能讨论什么？以前的小组会议基本等同于工作汇报，没有真正起到交流和知识共享的目的。大家都一味的低头拉车，没有抬头看路，这样对测试团队的发展是很不利的。

（6）测试人员需要在技术方面进行提高

作为测试人员有时听到最多的话是，“你怎么搞的，这个问题都没有发现？”，“这个不是bug，我不认为需要修改”。出现这样的情况固然跟测试团队目前的技术能力有很大的关系，测试人员没有充分的了解整个项目构架，或者是开发中的某种技术。有时会把一些正常的现象当作bug处理，又或者是对于开发知识的缺乏，对有些可能潜在存在的问题却没有及时发现。所以有时测试人员在开发人员面前处于一种弱势，有点随开发人员的决定去走的情况。只有加强自身的专业技能，让开发人员认同测试人员的能力，才能更加有效的开展测试工作。

（7）质量如何保证？测试不仅仅是测试人员的专利

质量如何保证可能不仅是我们所考虑的问题，也是国内外几十年来，软件行业所考虑的问题，但是我们应该如何去面对和提高软件的质量？仅仅靠测试人员吗？有些开发人员对自己写的代码都不能保证没问题就丢给测试人员开始找bug，这样的测试不具备太多价值，或者这些代码根本不具备可测性。

测试人员仅仅是质量保证的一部分，而并不是质量保证的全部，它是质量保证上重要的一环，但可能有时它并不是质量保证中关键的一环。质量保证的概念不应该只有出现在测试团队的脑子里，而应该出现在整个项目团队的脑海中，从需求的分析的测试，架构实际的分析和测试，以及编码的单元和白盒测试等，质量应该贯穿整个项目团队。并不是说目前的测试团队都具备了架构分析测试和单元、白盒测试的能力，而是让具备这方面能力的架构师或者开发人员能够共同评审这些框架、代码，从而保证前期工作的质量。当经过项目前期的审核真正移交至测试人员测试号过后，这样的软件可能才更具备质量保证。

测试如何结合工作实际情况进行测试实施改进

（1）      测试流程的改进以及执行力度的加强

测试流程按照我们现行的机制是：

需求分析、编写设计测试用例、执行用例、release notes的发布

改进测试流程：
需求分析、制定测试计划、编写设计测试用例、执行用例、发布测试日志和测试报告、分析测试日志和测试报告、release notes的发布

流程图对比：

对测试流程的改进是让测试人员具有主动发现问题的能力。对每次实施测试过后对测试效果的评估，从而去发现测试方式的优劣，测试策略的是否有效实施，又或者是评估自己是否需要对测试计划进行调整，以完善测试部门对开发与测试部门交互过程中的监控。

（2）测试方式改进

目前的测试可以说没有太多技术含量可言，纯粹的手工黑盒测试。这样的手工测试或许对于老板说是比较放心的，看到员工实实在在的去点击或者查看软件。但是在每天高强度作业，有时测试很疲惫的时候，又或者更新很紧急的情况下，测试人员无法对于所有的流程进行完全的回归而遗漏掉一些常规需要测试的流程，心有余而力不足。

如何做到短时间内彻底回归测试而且保证回归的质量了？说到底，测试是门完完全全的技术活，而非真正微软公司夸张的请一些已婚主妇就能测试的体力活，我们需要引入自动化测试。如何进行自动化，怎么样进行自动化是放在我们身边的一道难题。我们需要足够的了解自动化测试概念，了解测试工具，制定测试框架，需要强大的技术储备和专业技能知识。

对于我们目前可能会比较难达到完全去自动化实施测试，但是如果想测试工作的有效实施、快捷反应，自动化测试是必须去走的路，我们无法逃避。

自动化测试的优点：能够快速回归并且效率很高，在脚本对整个项目覆盖率很高的情况下完全相当于增加了一名测试人员。缺点也很明显：如果项目的框架不稳定，需求变化太频繁的情况下不适合用自动化测试，脚本维护的成本会远远大于实际手工测试的成本，但是结合目前我们公司的实际情况，维护项目过多，而需求的变更并未影响主题架构变化的情况下，完全可以使用自动化测试工具测试。

除此之外很多自动化小工具的应用对于项目的局部测试很使用，并不需要多昂贵的资金和多专业的技能知识。可以引导员工从比较容易上手的自动化工具开始入手。比如firefox自带firebug调试测试工具，xenu的链接测试工具等等。

我们的目的应该是鼓励员工，引导加指导员工迈进自动化测试，对软件测试有更加深刻的理解。

（3）测试团队引入需求配置和版本配置管理

项目中经常会碰到需求变更太快，以及需求来的频繁过多，测试人员怨声载道，导致测试人员无计划、无针对性的去组织测试，给人的感觉是计划永远赶不上变化。项目中的需求变化多、更新频繁是很正常的事情，正是由于市场的变化太快，所以需求也不得不随之变化。

如何对每天来的需求进行有效的配置和管理了？不是每天的等待PM分发需求，说做什么而做什么，测试人员应该有权利和有责任主动的去评估哪些需求是紧急的，哪些需求是可以缓和的。需要“量力”而行，保证质量。因此在测试队伍中，测试人员应该对每天来的需求进行归档编号，定义测试级别，以此制定测试计划。

版本的管理同样重要，例如一个项目中，在3天中获得3个不同模块的更新包A、B、C，更新至STAG环境，这些包并不需求马上更新至生产，需要通过市场部或者上层领导的认可才能进行发布，但是这时有可能市场反馈需要对B（此称为B1包）包里的某个界面不满意需要修改，当修改过后，更新至STAG，覆盖掉了原又的B1包，但是市场对更新过后的B2包依然不满意，甚至回滚至以前的B1包，但此时可能由于当初的更新覆盖，以及丢失了以前的那个B1包，此时测试人员手中和开发都没有此包，如果开发手中还有此包，或者你有幸没有删除以前的B1包，问题并不严重，但是如果没有任何B1包的存根，需要开发人员重新开发，这就是很严重的问题。

如果某段时间内像上述的情况反复发生，那么孤寂测试人员的头已经大了。因此作为发布更新包和release notes的关键人员，测试团队应该有效的对需要对发布的版本进行配置管理。

（4）加强和调动员工自身素质培养

目前由于测试组的技术力量以及工作经验都处在一个学习和摸索阶段，测试组的综合实力较低，大多数的测试组员的技术知识比较薄弱，需要引导和加强他们在技术知识上的学习以及让他们更多的更加丰富的认识测试这个行业。

可以通过测试团队集体交流的方式来加强和调动员工素质的培养，比如通过定期的测试团队内部会议分享经验，或者在论坛上做一个每周一话题这样类似的专栏，来提高组员对测试话题的兴趣。鼓励大家勇于参与，给大家一个自由发展和言论的平台。

前面提到的优势也是目前测试部门的劣势，由于国内测试部门的起步不久，大家对测试的认识不足。以至于测试所具备什么样的能力，该像什么方向发展都存在疑问，如何找到正确的测试方向成为劣势转变成优势的关键。

公司目前20人左右的测试团队在小中型企业来说相对资源丰富了，但是测试人员的自身专业技能参差不齐，甚至具备的计算机知识很少，有的成员又或者没有具备一点开发知识，如何让测试团队由目前的中级阶段向上发展，成为了制约其成员发展的瓶颈。