从测试的角度看系统，此中的系统属于实施型的应用系统。我将其分为两种，输入输出型系统和仅输出型项目。

　　输入输出型项目，就诸如我们一般的门户网站，后台编辑在某频道的某门类上发表某文章，该文章具有添加，修改，删除的功能。然后一般用户可在前台查阅即可。举例为最简单的WEB1.0时代的功能索取型网站，即使是发展到WEB2.0时代具有RSS功能的信息定制推送型及现在以微博为代表的信息共享型，都是一样的道理。有输入，那我们必可在某一地方寻找到原模原样的输出，只要直接校验即可。

　　此类的项目，还有一般具有业务性质的工作流型系统，诸如OA办公系统，督查，值班等等，无非就是呈报者添加某信息，浏览者不再是广大网民，而是某个指定的角色罢了。

　　此类系统是最好进行测试的系统。测试人员，只要明确业务规则，将详细的业务流程多进行分支性测试，一般功能测试的任务就可以完成了。

　　在进行功能测试时，有如下技巧可遵循：

　　1、分空验证。一般根据数据库的设计，不会所有的字段都可不输入，所以在页面上，程序员应该对一些特殊字段进行非空的限制。或者其自行在后台代码中对非空字段进行处理。不管使用哪种方法，至少测试人员不应该让页面直接报出数据库的错误问题，或者是提交成功的记录，无法正确显示的问题。

　　2、临界值。这个也是针对数据库设计进行的验证，每个字段不可能都是无限大，所以系统应该在UI交互层告之用户输入的范围。从用户体验的角度来讲，个人希望系统可以直接告诉用户此处的临界值是多少，而不是自行将用户的输入内容控制在有效范围内。

　　3、时序性。这个比较麻烦，举例来说明。有一功能为，用户提问，管理员回答。用户可对自己的发言进行修改及删除。这样的功能，测试就应注意，若用户提交了某问题后，管理员正在进行回答，管理员没进行提交时，该用户又自行将自己的发言删除了。那这样在管理员提交回答时，如果没有很好的代码控制，会出现数据库异常。

　　但由于此类系统，一般的特点是，用户量大，数据量大。所以，相对于功能测试来说，性能测试也是重中之重。没有经验的测试人员，在进行性能测试时，仅对首页进行性能的测试及优化。但比较有经验的测试人员，会在性能测试前，随机抽取用户进行咨询，对业务动作进行模仿，除针对首页外，还应该放50%的并发，在用户经常访问的功能点上。

　　用户多了，那自然就会出各种情况，诸如多个IE版本，多个操作系统版本，多个使用习惯等。这些想要遍历的彻底，只能靠平时对用户操作习惯的观察和测试经验的积累了。

　　仅输出型项目一般属于业务性较强的系统，最简单的体现就是以前的财务报表，销售报表，现在比较流行的BI等。主要特征就是，数据源属于日常的流水记录，有海量的数据。开发人员根据业务用户的要求，对这些海量数据进行加工，重组和趋势分析等功能。此类项目的主要瓶颈就在于开发及测试人员的业务瓶颈。

　　首先，需求调研人员是否真正的理解业务人员的需求，是否能够将已有的数据源字段和相应的业务代码联系起来，再能否正确的用已有数据的字段公式表达出业务人员的真正需求。

　　其次，测试人员需要有强大的SQL功底及严密的逻辑思维能力。在对该类系统进行测试的时候，关键点已经不是测试需求的界定，而是测试用例的设计及测试的执行工作了。

　　该类系统，具有庞大的数据源，而在代码处理的过程中，添加了很多业务逻辑类的整合和转换，所以在页面上显示较为简单的数据，实际上是经过了一番很繁琐的业务转换得到了。这类系统，建议测试人员使用半透明的黑盒测试方法进行。即，我们看到页面上的报告，某字段显示为3的时候，一定要搞清楚，这个3是如何得到的，是1+2=3？4-1=3？还是1+1=3？如果业务规则及基础数据的整合应该是1+1，那么页面上显示的3就是缺陷了。

　　综上所述，可以很轻易的看到，仅输出型项目的测试难度要大大的超过输入输出型项目。所以，在测试人员的配备过程中，一般将有项目开发经验，有技术背景的测试人员安排到输出型项目中。