考场纪律。对应我们软件过程中的开发标准。没有考场纪律，如何来规范考生行为呢？每个研发工程师的经验、工作能力和习惯都不同，如果任由发挥的话，肯定会答出一份千奇百怪的考卷来。

　　考生。对应我们软件项目中的研发工程师。研发工程师的工作就是拿到考卷（需求），把考卷（需求）上的一个个的考题（功能）逐一解答（功能实现），解答完成后需要回头再检查一遍答案是否正确，然后交卷就可以了。

　　阅卷老师。对应软件过程中的测试人员。监考老师把试卷收上来之后，确认试卷有效后，交给阅卷老师，阅卷老师可以批阅试卷了。

　　这时候需要强调两点，第一，试卷（待测系统）一定是由监考老师（项目管理者或质量人员）交上来的，考生（研发人员）不可能直接把试卷（待测系统）交给阅卷老师（测试人员）。第二，附带考卷交上来的，一定会有标准答案（详细的需求说明书、质量目标和性能指标等），不然阅卷老师根据什么标准来阅卷呢？

　　发布成绩。阅卷结束后，成绩发布，考生重新拿到考卷，把做错的考题改正，防止下次犯同样的错误。这就是我们工作中一个项目结束后，最好能有一次项目总结会，总结本次项目中有哪些创新值得发扬，有哪些不足需要借鉴。

　　整个考试过程我讲完了，是不是发现软件测试和考试有很多相似性呢？其实还不止这些，具体到测试方法上也适用，列举一些。

　　黑盒测试，就是不管解答过程，只看结果与标准答案对不对。

　　白盒测试，关注解题过程，要保证每一步都正确。

　　自动化测试，涂在答题卡上的选择题，能通过机器阅卷极大提高效率。

　　静态测试，判断题，通过阅读每行代码判断程序问题，不需要运行程序。

　　动态测试，分析题，结合上下文（编写驱动模块、测试桩），运行程序进行测试。

　　……，还有很多，不一一列举了，是不是很有意思呢？

　　通过分析考试过程，我们回归到我们的工作中，有哪些工作不符合考试流程呢？

　　1.我们没有出题人。没有专门的产品人员负责需求分析与制定的工作，需求一般由项目经理或者研发人员完成，并且很粗糙。

　　2.我们没有独立的考场，很多时候答题人、阅卷人都在同一个考场里完成工作。

　　3.没有监考老师。出题人直接把考卷给考生，考生直接把考卷给阅卷老师。

　　4.角色划分不清。项目经理经常是出题人又是答题人还经常客串监考老师。

　　5.没有标准答案。测试人员必须自己做一遍考题，才能阅卷，导致了测试进度缓慢也避免不了出错。如果阅卷老师对某道题本身不会，测试就进行不下去了。

　　6.考生拿到的考卷往往是一张白纸或者只是一些简单的要求。导致无法顺利的理解考题，也会经常自己出题自己解答。

　　7.系统发布后，很少回头总结项目中存在的问题，导致今天不断在重复昨天的错误。

　　其实，这就是一场班级级的小测验，不正规也缺少组织性。一场很奇怪的考试，题出的不好，答题也不规范，也就无从指望优秀的成绩了。