根据目前做的测试项目想总结一些如何对非业务行的项目做测试分析的方法，前几天在对公司培训是也提到了如何根据设计去挖掘测试用例，针对那些非业务行的项目是很有必要去思考和研究的，那么什么是非业务行系统呢？其实也不准确，是否应该叫非支持商业业务的系统，其实就是区分那些针对银行，保险，证券，电信等这些和行业邦定非常严的业务系统，他们应该是提供给业务支持的封装了底层的操作，有点类似中间件和平台支持系统。举个例子分布式文件系统，它是在技术实现上提供给其他应用系统的一个技术支持系统。 那么这一类，如果让开发人员去写需求说明书，大概就是一个简单的几句话，或有的开发人员也会说我们这个系统没有需求后需求很简单。没有错从业务功能上来说没有什么更多的描述，但是它从架构和设计的角度来说可能就会有很多的东东了。

　　因此我们在这里要介绍如何对这一类的系统来挖掘测试点或组织测试用例，那就是我前面提到的如何从设计类挖掘测试用例（也就是发现测试点）：首先我们必须清楚这个设计框架，该系统似乎如何架构的，如何应用在其他系统中的，对外提供一个什么接口。 架构如何分层，每层如何技术实现的， 学习架构的过程是对整个系统的设计了解过程打基础。 学习框架的方式应该是自学和开发培训相结合，学习的过程就是要理解如何此的架构有什么好处，可以解决什么样的问题。

　　第二步就是去分析设计，要找出并区主要模块，扩展模块，底层模块，第三方模块。然后再找出模块间调用和依赖关系。最后分析具体模块功能实现所用的技术。 抽象的描述就是找出点和线。线就是子模块或子系统间如何通信如何相互管理，相互调用的，点就是模块自己功能，或是如何数据处理，如何在和其他模块通信后获取数据或信息后如何进行处理。 线和点都有可能是性能平静。看如何分析它了。

　　举个类例子，一个分布式文件系统，它提供了三类模块，对外的客户端模块提供给第三方调用，数据服务模块提供磁盘存储数据和管理数据块服务，主业务模块他提供了所有文件信息的管理，负责分解数据块和管理数据块存放位置的算法。笼统的说我们找到了三个点，如何去找线呢，可以猜到，这三个模块之间一定是相互通信。 去三模块里去找吧，一定会有关联的功能函数或关联类。

　　找出点和线了，剩下就是要分析线的逻辑，点的逻辑 最好能画出了时序图出来，更能帮助找测试点。 直到现在我们总结一下，其实就是在解剖设计，找出关键器官和联系的几条大血管或神经。 从功能测试角度来说，这样的分析我们已经可以达到了覆盖其所有实现功能逻辑的目的。 那么如何去分析它可能的性能测试点呢？ 那么又要回到比较宏观的点和线了，那个点处理的数据最多，那根线运送的东西最多。 这就是我们要关心的平静。 点线结合就可找出一些性能测的场景了。

　　上面就是根据目前做的项目得来一点点总结。记录下来，欢迎深入探讨。对了还有就是测试这类项目，我们要明确不是测试他的代码，这些类项目的开发多事有多年经验的，所以如果你把精力放在找他的代码上的错误，比较浪费时间，不是不测试代码，把这类代码检测交给工具把。我们要做的是什么呢，是测试他是用的某一类技术，比如内存共享，socket编程，多线程实现，使用的HA技术是否正确，这类技术可能的常见问题，是否实现了功能需要等等。