| |
 |
我们是以数据库应用管理软件开发为主的；因此搞清楚整日围绕我们工作周围的各种数据很有必要。
一套应用系统按照其包含或者管理的数据作用大致可以分为如下几部分：
1. 结构数据
又可叫做元数据，该部分数据是程序的一部分，该数据的设计产生过程属于程序的设计开发过程，该部分数据的变化通常导致用户最终应用软件自身的变化。如：我们所开发应用软件的所有表、字段、关系、约束等等对象名称。“员工信息” ，“姓名”这就是元数据；是一种描述用户数据的数据。通常最终是作为程序提交件存在的《系统数据字典》就是这部分数据的整理文件。
2. 系统基础数据（配置数据）
这部分数据实际上是由软件开发或设计者进行维护的，根据不同的数据内容，同一个应用程序能够体现出不同的应用功能。该部分数据是作为某一具体应用系统的一部分存在的；是系统赖以运行的基础；缺少这部分数据系统就是一个单一的框架并不能被使用，通常这部分数据是和程序直接挂钩的，通过不同程序和不同数据之间的关系设置可以进行软件功能的变化。比如：系统模块信息、系统操作信息等等；有了这样的设计可以实现系统的模块儿插拔式管理。这部分数据的维护操作是由软件开发者或者软件发布者进行的，往往对于最终用户是不可见的；最终用户是直接使用该部分数据的。
3. 业务基础数据
这部分数据表示的是业务上的具体定义规则，按照程序所提供的功能，设置不同的数据，使其业务含义不同。这就是通常我们所说的系统的基础编码，如：民族信息、岗位信息、计量单位信息等等。通常这部分数据需要软件提供其维护的功能和操作界面。这些数据是由用户按照其实际需要进行自行维护的数据。这些数据可以随业务应用时间或者业务数据范围变化而变化。这部分数据是以编码形式被应用程序的业务系统所调用，通常是以编码形式被引用，用以保证整个业务系统的数据完整性和一致性而做的如此设置。这部分数据在异构数据库或者不同业务系统中做数据整合或迁移的时候是至关重要的，是核心部分。
4. 业务数据
又可叫做用户数据，该部分数据是用户利用应用软件自身业务功能直接增、删、改等操作形成的；反应用户具体业务的数据，是随着用户使用过程中不断变化的。如：工资数据、人员信息、工作流内容、生产进度数据等等。
我们所做系统在交付测试的时候应该是以上第1，2部分数据被维护完善的和代码程序一并交付的；第3，4部分数据应该是空的。因此界定好整个系统中的这四类数据有利于避免测试和开发之间的意见分歧。比如：当测试人员在A环境中发现一个BUG，然后提交给开发人员，但是开发人员在B环境中却没有发现该BUG，那么我们开发人员往往会认为是数据问题造的，因此通知测试人员不属于BUG。那么究竟算是BUG吗？
我认为“是”。
因为两个环境中的代码是一致的，因为交付的时候将第1，2部分数据都一并交付了也是一致的（这部分数据某种意义上可以认为是程序不可分割的一部分）。那么引起问题的原因就是程序中可供用户（测试人员）直接维护操作的数据发生变化了，而实际上这部分的数据就应该是随时随地都会变化的可能被删除、可能被修改、当然也可能会被增加。如果这部分的数据（第3，4部分）被变化后引起了程序上的问题，那么可以认定是程序的BUG，只要提供出来的所有操作所能引起的所有异常后果都应该被设计或开发人员所考虑到（这就是开发上的“临界判断和措施”一定要有），测试人员本也应该测试这部分的内容；
因此程序绝不能依赖业务数据这是最起码的系统要求！ |
|
|
|