从科研系统验收谈对场景测试和UML与认识.docxVIP

从科研系统验收谈对场景测试和UML的认识我们怎样面对科研系统的系统交接验收工作，由此想到了验收过程，想到了系统测试，想到了测试的方法和实践过程。理论上，我们都知道：场景是从用户的角度来描述系统的行为，它反映了系统的期望运行方式。场景可以看作是用户需求的内容，完全站在用户的视角来描述用户与系统的交互操作，而系统的功能需求规格说明，则是用户需求的分解结果和对系统功能及性能的规格描述。针对用户需求内容的测试，即为场景测试；而用户需求分解的结果，也就是功能特征的测试，对应了系统的功能测试。　　功能测试主要关注系统提供的功能特征是否满足需求，测试功能的不同处理流程（正常或异常处理）；理论上，一个功能测试用例仅用于测试一个功能，一个功能可能需要多个功能测试用例来覆盖，所以，功能测试用例的设计一般需要遍历系统的全部功能，其复杂和严谨程度仅次于路径测试，因而设计工作量比较大，对技术的要求也比较高。运维组对系统功能测试用例的设计工作延伸出对系统需规分析说明书的补充和修订和规范性问题，问题越来复杂，解决问题的前提是要在这一阶段投入大量的工作量保障，演变成一个Mission Impossible。　　基于场景的测试关注于系统的不同操作场景、事务、业务流程和数据的相关性，可能仅用到各个功能的一部分处理流程；每个场景测试用例仅测试一个场景、事务或业务流程。场景测试首先必须在系统但愿测试和系统集成测试已经完成通过的前提下实施，在用户对系统的确认阶段，由系统开发者和系统用户共同执行场景测试来进行系统验收，因而，发现问题解决问题的效率比较高。实际上，功能测试是场景测试的先决条件，只有功能测试已经完成并且其发现的问题得到解决，场景测试才可能有效实施。然而面对诸如科研系统这样一个比较体系化的较大规模的MIS系统，一般并不能苛求所有的功能测试都完毕之后，才能执行场景测试。在建设组目前实行的迭代式开发模型下，集成测试过后，也比较推崇以场景为目标进行的迭代测试，即先测试某个场景上用到的功能是正确可用的，然后确认该场景测试通过，然后再执行下一个场景所用到的功能。如此循环往复，根据场景优先级逐步完成系统测试。　　目前系统交接阶段的工作重点，应该放在系统验收和对系统运行数据质量的保障方面。对一个已上线应用近两年即将验收的系统，力求再做一次基于功能和性能的全面测试，体现系统开发阶段的规范性，实际上无此必要，也已不可行，因为面对系统庞大的功能特征将使得我们测试的工作量投入成为一个天文数字，相对而言，采取以结果为导向的场景测试，将会得到最大的投入产出比。所以，测试场景的主要价值在于使用用户典型的应用场景，按用户的最常用操作和重要业务流程进行测试，使得测试工作高效。但是，有一个残酷的现实，那就是凡是提供给用户的功能，用户就可能用到，就有测试的必要。所以场景的概念应该是需要延伸到开发阶段的，在开发阶段，可以根据场景优先级开发需要的功能，那些场景用不到的功能就先不做，从而在开始就规避掉不必要的工作量投入，这也是一种基于快速原型法的软件开发模式，符合迭代式模式的目的和要义。实际上，开发（系统建设）也并不是真正的源，真正的源头应该是来源于系统用户的需求分析。对我们构造一个应用系统而言，用户的实际应用需求是最有发言权的，所以解决好与用户沟通的方法，将用户的需求完整地表述出来才是王道，这也是我们推崇采用UML统一建模语言来完成系统需规分析和系统设计的初衷。UML目前看来是比较具有应用场景发言权的描述工具，能够比较好地描述出用户的典型应用场景，然后再描述出设计这些场景所需要用到的功能特征。所以要做到场景测试，实际上需要我们从UML学习和实践开始，需要我们从需求开始做起，注重与用户的沟通，确认用户的实际场景，然后分析这些场景，并据此设计出系统解决方案，得到用户使用系统的应用场景，并排列出优先级；然后据场景优先级开发出应用系统；最后的验收测试则是根据场景优先级进行的测试，并结合系统实际应用情况，总结出拓展场景，提前给出《用户使用操作说明》，引导用户确认并作为下一阶段系统开发的基本需求。　　以上只是一个认识，希望引起探讨，探讨目的也就一个，那就是工作的高效源自于能够探索找到一个切合实际的工作方式，引导我们做好规划，规划越充分，最后的实践也越顺利。