---专家系统给测试和测试人员带来了不同的挑战.
我们日常接触到的软件大多为通用软件或者企业应用, 使用起来比较简单, 易于理解.与之对应的, 有一类软件我们称之为专家系统, 它们协助某个领域的专家来做出判断和决策. 比如地质监测, 天气预报, 还有我们经常在电影里看到的科学家使用的各种模拟软件: 龙卷风灾难模拟, 变态教授的分子化学和新药品实验等.
直观的感觉, 这类软件已经与我们日常使用的软件不同. 具体一点, 我们从软件测试的角度来来理解一下专家系统带给我们的不同于通用软件的挑战:
使用者需要具备必需的专业知识, 而这个门槛通常不低.
算法可能要求大量的输入, 数据不好准备
算法的输入空间和结果空间太过巨大, 而且没有直观的对应关系. 即给定输入不能一眼就看出输出.
一些类型的专家系统其界面展现是非常复杂的,远非普通的企业应用和个人软件可比.
没有找到太多这方面的资料, 仅就以往经验和微博上的讨论做些总结.
1. 测试问题本质上是设计问题. 可测试性是很重要的设计约束. 表示逻辑和业务逻辑的分离,在复杂系统中更显必要和迫切. 所有的计算和推理的算法,都应该是UI无关的. UI只负责处理用户输入和显示计算结果. 这样从测试的角度来看,核心逻辑可以不需要通过UI来测, 那基于UI的测试的重点就可以转移到验证用户交互而不是业务相关<wbr>的逻辑. 这是我们一直推崇的, 但其它类型应用中UI测试的方便性降低了对它需求的迫切性.</wbr>
2. 测试问题本质上还是知识问题. 测试人员必须具备判断对错的知识. 这看起来是常识, 但在专家系统的测试中,这一点并不总是被很好的满足的. 软件规模较小的时候, 我们可以通过教会专家编程让他们自己来编写自己需要的软件. 软件规模较大的时候,<wbr>我们可以招聘相关专业的从业人员人员而不是软件专业的人来帮助测<wbr>试. 如果这些条件都不满足的话,<wbr>我们只能培训目前的测试人员让他们掌握领域知识了.</wbr></wbr></wbr>
3. 专家系统演化的一个约束是它的计算结果不应该变差, 要么不变, 要么越来越精确. 这给了基于基准的测试(Benchmark)一个可能. 在软件稳定运行一段时间之后, 我们可以收集一组用户认为正确的输入输出,作为基准, 后续版本的改动不应该产生不一样的结果, 除非改的就是算法本身. 这是某种形式的regression, 但它的应用场景相对有限, 毕竟专家系统的核心就是算法, 新feature大都是算法的enhancement. 这样基准测试就不work了.
4. 那么好,算法的测试如何做? 我觉得这是专家系统测试最困难的部分. 困难在于算法的输入空间和结果空间是很广泛的, 并且实际算法的输入和输出之间的关联不像求平方或斐波纳契序列那<wbr>样明显,好消息是在现在的计算机体系结构中, 算法总是确定的, 规范的, 即给定输入, 你总是能得到相同的输出. 这还是一个设计问题:小处来讲,算法的分解;大了说,体系结构,<wbr>比如知识库和推理机的职责划分. 简单的数学公式的实现我们总是可以测的. 如果能把复杂算法分解为简单算法的组合,<wbr>我们至少可以保证每一步测试的直观性和可理解性<br></wbr></wbr></wbr>
这里有一个重要的区别: 验证算法本身的正确性和实现的正确性.
算法本身可能是纯数学的, 与编程无关的, 是solution, 而不是implementation. 这个意义上的正确性超出了我们今天讨论的范围, 它应该由专家来保证. 在微博讨论中提到的根据历史数据来测试算法的方法, 测的就是算法本身, 而不是算法的实现. 我们focus在实现的正确性上.几个具体的策略.
基准测试. 前面提到过了.
定性 over 定量. 定量是相对困难的, 因为这类软件的特点决定了结果的不确定性. 但正确结果的性质, 比如应该是正数还是负数, 数量级等, 都是可以确定的
区间. 定性 over 定量的一个实际例子. 结果落在我们指定的一个区间内就是可接受的.
测试人员必须具备领域知识. 我们日常对此感觉没那么必要只是这条规则在领域门槛较低情况下的<wbr>一种近似.</wbr>
表示逻辑必须与业务逻辑分离. 我们不那么严格而没有遭太多报应只是在UI测试比较方便的情况下<wbr>的一种运气.</wbr>
算法本身的正确性和算法的计算机实现的正确性分开测试. 前者靠掌握了相应知识的人来判断(通常是专家), 后者更易于测试(通常是QA), 更易于自动化.
附: 专家系统介绍
根据维基百科:
"专家系统是早期人工智能的一个重要分支,它可以看作是一类具有专门知识和经验的计算机智能程序系统,一般采用人工智能中的知识表示和知识推理技术来模拟通常由领域专家才能解决的复杂问题。
一般来说,专家系统=知识库+推理机,因此专家系统也被称为基于知识的系统。一个专家系统必须具备三要素:
领域专家级知识
模拟专家思维
-
达到专家级的水平
专家系统适合于完成那些没有公认的理论和方法、数据不精确或信息不完整、人类专家短缺或专门知识十分昂贵的诊断、解释、监控、预测、规划和设计等任务。一般专家系统执行的求解任务是知识密集型的. "
网上找到的一个专家系统的图:
分享到:
相关推荐
3. **文献综述**:对现有研究成果的深入理解和批判性评估是必不可少的。通过阅读和分析相关文献,可以了解研究现状,发现知识空白或改进之处。 4. **假设设定**:在明确研究目标后,需要提出假设或研究问题。在AI中...
为了简化专家系统的开发,出现了各种专家系统开发工具,如CLIPS、KEE、Prolog等,这些工具提供了方便的知识表示和推理机制,帮助开发者构建和测试专家系统。 【分布式与协同式专家系统】 随着技术的发展,分布式...
- **系统测试:** 在所有组件集成后进行的整体测试,以验证软件是否满足业务需求。 - **验收测试:** 最终用户参与的测试,以确认软件是否符合预期的要求。 - **回归测试:** 在软件修复缺陷或添加新功能后,重新...
在软件开发过程中,软件测试是不可或缺的一环,它确保产品的功能、性能和稳定性达到预期标准。通过对软件进行系统化的测试,可以发现潜在的错误、缺陷和漏洞,从而提高软件的质量和用户满意度。 二、软件测试的基本...
6. **反馈修正**:根据测试结果调整测试策略,必要时修改用例。 #### 8. 单元测试的策略有哪些? 单元测试的策略主要包括: - **白盒测试**:基于对代码结构的理解来设计测试用例,确保每个逻辑路径都被测试到。 -...
【校园招聘系统测试计划】 1.简介 本测试计划旨在为校园招聘...总之,校园招聘系统测试计划的实施将严格按照CMMI 3级标准进行,确保系统在上线前经过充分验证,以提供优质、稳定的服务,满足企业和求职者的需求。
- 系统测试:验证整个系统是否符合规格要求。 - 接受测试:用户或客户对软件的最终验证。 二、测试原则与策略 1. 白盒测试:基于代码结构,理解内部逻辑进行测试。 2. 黑盒测试:不考虑内部结构,仅关注输入和...
包括测试计划、测试用例、测试报告等,它们是测试过程中必不可少的组成部分。 十、测试团队的角色 1. 测试工程师:负责设计和执行测试用例,编写测试报告。 2. 测试经理:协调测试活动,管理测试资源。 3. 测试分析...
测试策略通常包括但不限于: 1. **黑盒测试**:仅根据软件规格说明书进行测试,不考虑内部结构和实现细节。 2. **白盒测试**:基于对代码的深入理解,设计测试用例来覆盖所有可能的路径。 3. **灰盒测试**:结合...
可能包括但不限于:回归测试策略(每次修改代码后重新运行受影响的部分)、冒烟测试策略(验证核心功能是否正常)、探索性测试(自由形式的测试,寻找未知问题)等。 - 配合与协作:测试过程可能需要与开发团队、...
7. 系统测试:整体测试软件系统,包括硬件、网络和数据库等组成部分。 8. 用户验收测试:最终用户对软件进行验证,确认满足业务需求。 11© 2005-2006, Saga Technologies. Confidential and Proprietary. Do not ...
在软件开发过程中,软件测试是不可或缺的一环,它确保了产品的质量和稳定性。下面将详细讨论“软件测试”这一主题,以及与之相关的知识点。 一、软件测试基础 软件测试是验证和确认软件产品是否符合预定需求的过程...
专家控制器是指将专家系统作为核心的控制系统,通过模拟人类专家的控制策略来实现对系统的自动控制。它能够处理非线性、不确定性和复杂的控制任务,具有良好的适应性和鲁棒性。 **2.3 专家控制系统的工作原理** ...
在软件开发过程中,软件测试是不可或缺的一环,它旨在确保产品的质量、稳定性和可靠性。"软件测试基本理论"这一主题涵盖了测试领域的核心概念,对于初入行者或初级测试工程师来说,理解这些基本理论至关重要。以下是...
综上所述,软件质量管理与自动化测试策略是现代软件开发不可或缺的部分。通过采用科学的方法和工具,可以显著提高软件产品的质量和开发效率。对于软件开发团队而言,深入了解这些技术和策略将大有裨益。
《设计与验证:Verilog HDL》是一本全面介绍Verilog HDL语言设计方法的专业书籍,不仅适合作为高校教学材料,也是行业专业人士不可或缺的参考书。通过学习本书,读者能够系统地掌握Verilog HDL的基础知识和高级应用...
"软件测试基本功"涵盖了测试的基础理论、方法和工具,对于任何想要进入或提升在软件测试领域的专业人员来说,这些都是必不可少的知识。 一、测试基础理论 1. 测试定义:理解软件测试的目的是为了发现软件存在的问题...