关键词：
软件测试 过程实践 测试用例 RUP
RUP(Rational Unified Process ，Ratinaol 统一过程)是rational公司提出的一套软件开发过程，目前最新的版本是2003。RUP的最大特点就是它提供了一套完整的软件开发过程框架，任何人或组织都可以根据自己的需要来对这个过程进行裁剪，并根据自身需要进行调整后使其成为个性化的过程。读者可以参考网络上流传的《RUP2000中文版》。
(Rational以及 Rational Unified Process 均系 Rational Software Corporation 在美国和其他国家的商标或注册商标。)
有句老话说：万事开头难。说的是在做事情的时候，通常都是一开始觉得非常困难，但是只要上了道，入了门，就会越来越容易、越来越顺了。写文章也是如此。不过笔者这里说的开头难并不是不会写文章，而是专指不会写文章的开头部分。过去看到过的很多小说，无论是言情的或者武侠的，都会拿很长的篇幅出来作为“引子”，或者叫“楔子”，用来交待一些同小说相关的信息。而一部小说是否能够吸引读者，这部分内容也起了很大的作用。不过，笔者作为一个技术工作者，写的大多数都是技术文章，一般来说文章的内容、结构都是一早就想明白的，唯独这个开头，实在不知如何写起。不过想想也罢，既然不擅长这个，那就努力把内容写的详细、易懂一些，尽量让读者不会有上当的感觉吧。
软件测试作为一个独立的职位或者说行业，并不是软件业的新生事物，但的确是随着最近两年一些新的思想注入国内软件行业(比如敏捷开发过程、测试驱动开发等)，才得以红火起来的——这一点，从相关书籍的出版和销售就可以看得出来，从事软件测试工作的人也渐渐多了起来。但是也因为是刚刚起步，同时国内大多数软件公司都还处在中小型开发团队甚至作坊式开发的层次，不可能提供太多的测试职位，想找到一些高水平并且富有经验的测试人员更是难上加难。这最终也就导致了国内大多数测试从业者都处在“初级阶段”这样一个结果。
笔者长期活跃在国内的几个比较知名的测试论坛，发现大家希望讨论的问题主要可以分为两种：一种是对于一些测试工作具体操作方法的提问，一种是对于测试工具使用的提问。总体看来，更多的问题集中在了后者。这似乎已经成为了国内软件业的通病，无论是开发还是测试，总希望可以通过某个工具或者语言来一劳永逸的实现某个理想。如果真的希望工具可以改变一切，那么这种愿望总是会落空的。而前者，大多是因为进入了一些刚刚开始重视软件测试的中小型软件公司，而公司的开发团队中负责软件测试的可能只有一两个对软件测试一知半解的新手，当公司需要开展某些方面的测试工作时，缺少这部分相关经验的朋友变选择了通过网络求助。
测试工具的应用，的确可以提高工作效率，而对于测试工具方面的提问，本来也是无可厚非的，但是在笔者的实践中，如果希望提高一个团队的工作效率和改善工作效果，关注于过程和方法要远远好于关注工具。测试工具的学习、引入和使用，本身就是一个需要消耗大量资源的过程，而且对于工具的选择和引入工具时机的选择也是非常关键的，如果负责这项工作的并不是一位在软件行业沉浸多年，有着丰富测试经验并熟知开发过程的资深人士，那么开发团队将为此承担巨大的风险。即使成功的引入了测试工具，工具本身可以带来的效率的提高也不是在短期内可以体现的。
在这里，笔者希望刚刚或者正在准备组建测试团队的软件公司在考虑测试流程的搭建和测试工具引入时，不要给刚刚进入测试行业的朋友太多压力，因为这两项工作都不仅仅同软件测试本身相关，同时也会涉及到项目管理、开发过程方面的内容。轻易的做出一个决定只会对将来在团队中测试工作的开展带来不利的影响。
在这篇文章中，笔者不打算对测试工具方面的问题提出任何建议，而将对网络上大家关注的测试过程和测试方法方面给出一些具有实际参考价值的经验。
测试工作应该什么时候开始?
测试用例是不是一定要写?如果写，应该详细到什么程度才会比较好用又容易维护?
文章来源于领测软件测试网 https://www.ltesting.net/
