[如需转载，请在转载时注明出处，并保证本文的完整性]
——我们的目的是什么？
想起之前经常被分组经理质疑的问题：你们到底知不知道我们做这些事情的目的是什么？不想去纠结事情的前因后果以及事情后面的各种情绪，回到问题本身：作为测试人员，我们测试的目的是什么？
为了发现更多bug？
刚开始做测试的时候，发现bug就觉得好兴奋，自觉不自觉地就去统计自己发现bug的数量，遇到L1、L2的缺陷就有莫名的成就感，可是慢慢这种兴奋感没有了，取而代之的是：为什么会有这么多缺陷？为什么L1、L2级别的缺陷要遗留到系统测试阶段由测试人员来发现？
为了保证质量？
看过好多关于这个的争论，于是开始认同，测试人员并不是质量的保证，质量从来就不是测试人员单方面测出来的，而是需求阶段、设计阶段、编码阶段、测试阶段大家共同努力的结果。
我们在做的是质量预防，降低风险。
作为测试人员，我们的目的是在项目计划的时间内交付达到质量要求的产品，我们在做的是质量预防，降低风险。这里的风险，既有产品质量的风险，也有项目进度的风险。
我们正在做这些事情，可是如何才能做到这些事情——貌似目前还只有问题，没有答案。。。
——我们能做什么？
软件测试应该从需求阶段开始介入，贯穿于软件研发过程的各个流程环节——这是理论，于我目前项目中的实际，并非如此。回过来头发现这一点，才自觉自己所做的原来是如此随意和不规范，回顾点理论吧，希望能照进后续的现实。。。
需求阶段：
先从测试需求开始，这个“测试”是动词，没有错，除了测试软件系统我们测试人员还有一项重要的工作就是测试我们的需求！测试需求，就是对软件需求本身的检查，优秀的需求规格书应该具有完整性、正确性、可行性、必要性、无二义性、可验证性等特性。当然，这是理想状态，而我们工作中的现实往往是一些粗略的原始业务需求，甚至只是SA邮件中的只言片语，越是如此，需求分析就越是重要。对需求的分析的过程也是了解我们要“测什么”的过程，进而依此确定测试范围，梳理需求跟踪矩阵，确保后续测试对需求的覆盖及跟踪，避免漏测。
设计阶段：
直接跳过吧，什么详细设计文档、概要设计文档、数据库设计文档统统都是传说，无从谈起。。。
编码阶段：
编码阶段貌似都是开发人员的事，测试人员能掺和点什么呢？以前在石竹的时候倒是有dev demo。关于dev demo在网上没有查到相关的资料，以前的做法是开发人员完成一个功能点的开发之后，就会把相关的开发、测试人员叫过来，给大家讲解及演示，这是及早发现缺陷，降低修复成本的好方式。
测试阶段：
这个阶段要干的事情可多了，简述吧。
* 测试用例设计，用例设计的核心应该是提高测试覆盖率，除了覆盖从需求提取出来的功能列表之外，还包括各种隐藏的内部处理、业务规则、业务场景的覆盖。还有用例设计方法的运用、测试用例粒度的划分、测试用例的可读性和可维护性都是要考虑的。
* 用例评审
* 测试环境搭建
* 测试数据准备
* 冒烟测试
* 系统测试执行
* 缺陷跟踪
* 。。。（用省略号代替了好多好多，之所以省略，不是因为它不重要，而是因为目前的工作中没有真正去做过，例如性能测试、自动化测试、质量度量等等等等）
——我们在忙什么？
从入职开始，项目组一直都是忙忙碌碌，加班已经是常态了，可是，为什么会这么忙？工作量超负荷？效率低下？工作重复冗余？忙碌都最后质量是否得到了保障？有好多好多没有答案的问题，做测试的时间也不短了,鄙视一下自己，当然不是完全一点原因都不知道，但确实还不知道如何解决，或许后续是应该调整自己的方向和关注点了。
