收获在一次惊涛骇浪的“软件测试”（二）

    上篇文章我们写的都是在处理事情上的一些收获，这篇文章我们主要说一下开发软件方面的。

一：团队开发。

    团队开发中，对于人员和任务的分配是重中之重。对于人员管理，我觉得应该先小人后君子。把一切规范和奖罚

措施都在项目开始之前就制定好，并严格按照规范执行，防止项目拖延。每个人都按照自己的计划去执行，而且每天

的晨会或者例会都要有它存在的意义，不能说每天都汇报，却不统计任务的完成情况。做事和做人分开，只要是关于

项目的，都严格按照规范执行，凡事对事不对人。而任务的分配，就需要根据人合理安排任务，通知要有任务清单，

这个任务安排给谁了，什么时候完成，如何验收都要写清楚，同时必须要检测，而不是分配出去就算完事了。争取每

个错误只要出现就解决或者记录。这次的开发过程出现了很多关于这方面的问题，比如：2.0出现的问题在这版里面依

旧存在。管理端没有很好的融合到考试系统里面来等。

二：业务为王。

    这是大家都知道的一句话，可是知道是一回事，真正拿我们做的东西去给客户使用是另一回事。我们所有的功能

都应该建立在对业务的了解和对客户需求的充分分析上，而不是想当然的去做。有时候我们以为对的，以为人性化的

东西，客户不一定会接受。尤其是针对不同的客户需求时，更应该根据各种需求合理设计我们的软件。不能为了某个

客户的需求而忽略其他客户的感受。

三：统一规范。

   每次开发之前都要将软件使用，代码规定等统一了，而且组长要做好检查工作，这有会给后期开发省去很多不必

要的麻烦。比如：数据库版本，静态变量的使用，数据类型等。而且每次规范的变更都要通知到每位组员。这次我们

在这方面基本上撞的头破血流了，希望大家引以为戒，后面会有专门的学术报告讲这个。这些貌似不起眼的错误，会

给我们软件的使用带来毁灭性的打击。

四：反馈。

    单独把它拿出来说，是因为这次这个系统中这部分基本上是空白。反馈不仅是指客户对我们的软件提意见，还有

我们在设计软件时，每一步的操作都要有记录，每一次数据的变动都应该提示客户哪些地方发生了变化，比如：导入

题库，应该反馈给用户导入成功多少条数据，多少条没有导入成功，没有成功的是如何处理的。导入学生要跟基础数

据库比对，告诉客户那些学生存在问题，和保证学生导入的准确性。同时，我们上面说的，任务布置出去以后也必须

有反馈才算这个任务完成了。

五：软件管理。

    所有需要我们手动记录或者去数据库操作的都应该可以在软件后台可以实现。所有可能改变的地方，都应该可以

在后台灵活配置。这样才能做出来灵活性和扩展性都俱佳的软件。

六：权限管理。

    想做出一个多功能大型的软件，权限管理必须做好。一个只供三四人使用的软件不需要权限管理。就像提高班随

着人数的增多，为了方便管理，各种委员会就会相应的诞生。软件也一样，要想发展壮大，就必须分配好权限。每个

角色都有只属于自己权限，只能操作属于自己的那部分。

    以上只是这次考试过程中遇到或者想到的一部分内容，大家可能都知道这些，但是真正的做出来让别人去用去评

价那将是另一个概念，我们应该把我们平时学习的东西和别人总结的都应用到平时的开发中去，拿别人撞的头破血流

的经历作为自己的经验！这样才能让我们的软件被更广泛的认可。