首先是软件开发的流程，比较常见的瀑布式开发，整个过程是单向的，优点是过程可控，产品一步到位，缺点是需求变更麻烦，流程繁琐，项目周期长。
瀑布式开发看起来很像盖房子，在前期需求确认的时候十分小心，因为整个项目的设计图一旦确定，成本和风险就确定了，如果中途出现新的需求，就好象盖房子的时候突然决定在楼顶再加个塔楼，不是不可以，但是变更起来要走很多流程。
瀑布式流程里，测试环节就比较固定，显示单元测试和集成测试，以白盒或者灰盒测试为主，主要是开发人员来做，会发现一些逻辑和接口的问题，和交互没多大关系，主要是测试对数据处理的正确性。然后是系统测试、验收测试和安装测试，这些都是黑盒测试，下面说明一下这几种测试都干了些啥。
系统测试
系统测试简单理解就是对一个完整产品做全面测试，包括很多测试方法：比如功能测试，性能测试，压力测试等，有人统计过有16种。系统测试的目标是一个功能完整的稳定版本，也就是需要完成的功能应该都已经完成了，不然系统测试没有多大意义。
在瀑布式开发环节里，应该会有一些项目里程碑，这时会输出一个相对完整的版本，虽然不能发布，也需要做系统测试，只不过这时的系统测试里缺少了一些完整的模块，会不完整。这时系统测试的目的就是为了确认已集成模块是没有问题的，如果通过系统测试，那么在开发计划上，这一阶段的工作就算完成了。
验收测试
验收测试主要是根据需求定义文档，对待发布版本做一个验证测试，不过这部分工作有一大半其实在系统测试里已经做过了，比如功能测试和性能测试的测试标准就是依据需求定义文档完成的，如果说流程上没有那么严格，通过系统测试的版本和实际交付的版本其实没有太大区别。
不过保险起见，还是再做一遍测试。
安装测试
这个测试环境实际上是在与客户相同的环境上部署系统，其实也有点多余，在系统测试阶段肯定会有这部分测试用例，比如兼容性测试，客户潜在可能使用的系统或者没有的系统都会要求安排测试。
通过上面的分析，其实对于黑盒测试人员来说，工作的重点应该是系统测试，或者说对于整个测试环节，系统测试是否有明确的测试标准至关重要。
瀑布式开发的另一个特点就是测试周期长，版本稳定周期长，在某些时候，这种情况会造成资源浪费，因为在目前已开发的产品未被验证之前，继续开发可能会有很大的风险，所以有人改进了瀑布式开发，在里面加入的迭代的概念，就形成了敏捷开发，将一个大的瀑布式流程分解了多个小的瀑布式流程，要求每个阶段的产品都是可以发布的最终版本，通过版本升级来添加新的需求。
敏捷式开发的特点就是需求变更可以非常及时，这种情况对于测试人员来说并不是好事，因为持续的集成与发布会压缩测试的时间，一旦第一个版本发布，其余的版本在很短的时间就会持续的出现，系统测试的周期会逐渐延长，但是版本之间的间隔可能反而会缩小。
敏捷开发下的系统测试
敏捷式开发的特点决定了系统测试的重点是软件产品的基本功能，因为即使新版本出现问题，也可以通过回滚的方式回到上一个较为稳定的版本，也可以迅速发布一个新版本来解决这个问题，这是产品的特性之一。对于测试人员来说，其实在系统测试的第一个版本上就必须充分验证这种特性，对于可能引起升级失败或者打补丁失败的因素做一个彻底的分析。
回归测试
系统测试里还包含一个十分重要的测试环节，就是回归测试。在正常的测试流程中，会出现很多未通过测试的软件版本，这些软件版本在经过问题修改之后会重新安排测试，这时如果继续全面的来一遍系统测试，成本很高，而且很可能在系统测试快要完成的时候又出现无法通过测试的严重问题，所以在安排系统测试之前会对这一个版本的修改做一个回归测试，涉及到基本功能和主要修改点。
好的回归测试可以快速发现问题，从而缩短软件版本通过系统测试的时间，如果测试人员对项目十分熟悉，并且能够获得足够多开发人员的支持，回归测试的效率会提升不少。
敏捷式开发的回归测试
在敏捷式开发中，只有在两个版本之间差异极大的时候才会安排系统测试，剩余时间回归测试就替代了系统测试，这时的回归测试目标并不是找出当前系统中的所有问题，而且给出一个明确的答复，就是当前版本是否可以更新。这时回归测试也会被叫做冒烟测试。
冒烟测试除了关注当前版本修改或添加的内容是否起效，还关注是否影响了整个系统的稳定性，由于冒烟测试的周期很短，就要求测试人员能在短时间内发现严重问题，除了要求测试人员经验要十分丰富，还有必须是个“快速手”。