网站开发html文件规范,青岛专业做外贸网站,wordpress访客ip记录,展厅设计ppt汇报目录 1. 什么是需求 1.1 需求的定义 1.2 为什么有需求?为什么需求对软件测试人员如此重要? 1.3 测试人员眼里的需求(重要) 1.4 如何深入了解需求 2. 测试用例 2.1 什么是测试用例 2.2 为什么有测试用例 3. 什么是BUG 3.1 BUG定义 3.2 如何描述一个BUG 3.3 如何定义bug的级别 … 目录 1. 什么是需求 1.1 需求的定义 1.2 为什么有需求?为什么需求对软件测试人员如此重要? 1.3 测试人员眼里的需求(重要) 1.4 如何深入了解需求 2. 测试用例 2.1 什么是测试用例 2.2 为什么有测试用例 3. 什么是BUG 3.1 BUG定义 3.2 如何描述一个BUG 3.3 如何定义bug的级别 3.4 BUG的生命周期 BUG状态转换图 4. 软件生命周期 5. 开发模型 5.1 瀑布模型(Waterfall Model) 5.2 螺旋模型(Spiral Model) 5.3 增量, 迭代 5.4 敏捷 敏捷宣言 scrum scrum里面的角色 迭代开发 scrum的基本流程 5.5 软件测试V模型 5.6 软件测试W模型 6. 软件测试生命周期 7. 如何开始第一次测试 1. 什么是需求 1.1 需求的定义 需求就是 满足用户期望或正式规定文档(合同、标准、规范)所具有的条件和权能包含用户需求和软件需求。 IEEE定义: 软件需求是 (1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 在多数软件公司会有两部分需求一部分是用户需求一部分是软件需求. 用户需求:可以简单理解为甲方提出的需求如果没有甲方那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。 软件需求: 或者叫功能需求该需求会详细描述开发人员必须实现的软件功能。 大多数公司在进行软件开发的时候会把用户需求转化为软件需求(需求文档)开发人员和测试人员工作的直接依据就是软件需求 软件需求是测试人员进行测试工作的基本依据. 【软件需求规格说明书】 1. 引言 本文档旨在定义软件平台支持邮箱注册功能的需求规格。平台的主要目标是允许用户通过邮箱进行注册并为他们提供相关服务。本文档将涵盖对该功能的详细描述包括功能性需求、非功能性需求、用户界面设计以及安全性考虑。 2. 功能性需求 2.1 用户注册 用户应该能够通过邮箱注册一个新的平台账号。在注册过程中用户需要提供以下信息 - 邮箱地址作为唯一的用户标识符用于登录和与用户进行沟通。 - 密码用于保护账号安全性的用户选择的密码。 2.2 邮箱验证 在用户完成注册后系统应该向提供的邮箱地址发送验证邮件其中包含一个唯一的验证链接或验证码。用户必须通过点击验证链接或输入验证码来确认并激活账号。 2.3 密码重置 在用户忘记密码或需要更改密码时系统应该提供一个密码重置功能。用户应该能够通过邮箱收到包含重置链接或验证码的邮件以重置密码。 3. 非功能性需求 3.1 安全性 为了保障用户数据安全平台必须采取适当的安全措施包括但不限于以下要求 - 使用加密协议保护用户登录和注册时传输的数据。 - 对用户密码进行哈希加密存储确保即使数据库泄露用户密码也不会暴露。 - 限制账号激活邮件中的有效期以防止链接失效后被滥用。 3.2 可靠性 平台需要保证邮箱注册功能的稳定性和可靠性尽量避免系统崩溃或故障。在高负载情况下系统应该能够正常处理用户注册请求。 3.3 用户友好性 用户界面应该设计简洁、直观并提供相应的提示信息帮助用户顺利完成注册流程。错误处理应该友好向用户展示清晰的错误信息帮助用户及时纠正错误。 4. 用户界面设计 4.1 注册页面 - 提供一个输入框让用户填写邮箱地址。 - 提供一个输入框让用户设置密码。 - 提供一个按钮允许用户提交注册请求。 4.2 邮箱验证页面 - 在用户注册后提示用户检查收件箱并点击验证链接或输入验证码。 - 提供一个输入框让用户输入收到的验证码。 - 提供一个按钮允许用户提交验证请求。 4.3 密码重置页面 - 提供一个输入框让用户填写与账号关联的邮箱地址。 - 提供一个按钮允许用户请求重置密码邮件。 5. 测试计划 在开发完成后需要进行全面的功能和安全测试确保邮箱注册功能的正确性和稳定性。测试计划应该包括以下方面 - 功能性测试验证所有注册、验证和密码重置功能是否按照规格要求工作。 - 安全性测试检查系统是否正确地处理安全敏感信息如用户密码和验证码。 - 可靠性测试模拟高负载场景测试系统在不同负载下的性能表现。 6. 总结 本文档定义了平台支持邮箱注册功能的需求规格包括功能性需求、非功能性需求、用户界面设计和测试计划。通过遵循这些规格我们将确保平台提供安全、可靠且用户友好的邮箱注册功能满足用户的需求。 1.2 为什么有需求?为什么需求对软件测试人员如此重要? 从软件功能需求出发无遗漏的识别出测试需求是至关重要的这将直接关系到用例的测试覆盖率对于识别出的每个测试需求点需要采用具体的设计测试用例的方法来进行测试用例的设计 1.3 测试人员眼里的需求(重要) 需求是测试人员开展软件测试工作的依据. 在具体设计测试用例的时候首先需要搞清楚每一个业务需求对应的多个软件功能需求点然后分析出每个软件功能需求点对应的多个测试需求点然后针对每个测试需求点设计测试用例。 过程如下业务需求一软件功能需求点一测试需求点一测试用例 以“用户登陆”为例来阐述下整个过程: 1.4 如何深入了解需求 测试工程师在需求分析和设计阶段就开始介入因为这个阶段是理解和掌握软件的原始业务需求的最好时机。 只有真正理解了原始业务需求之后才有可能从业务需求的角度去设计针对性明确从终端用户的使用场景到端到端的覆盖率较高的测试用例集。 参加需求评审会议查阅需求文档团队沟通 2. 测试用例 2.1 什么是测试用例 测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合这组集合包含: 测试环境、操作步骤、测试数据、预期结果等要素。 测试用例解决了两大问题: 测什么怎么测. 2.2 为什么有测试用例 测试用例提高测试人员工作效率 / 降低测试人员工作的重复性问题测试用例是建立自动化的基础 3. 什么是BUG 3.1 BUG定义 BUG是: 当且仅当规格说明(软件需求/需求规格说明书)是存在的并且正确程序与规格说明之间的不匹配才是错误。 当需求规格说明书没有提到的功能判断标准以最终用户为准: 当程序没有实现其最终用户合理预期的功能要求时就是软件错误。 3.2 如何描述一个BUG 一个合格的bug描述应该包括以下几个部分: 1、发现问题的版本 开发人员需要知道出现问题的版本才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。 2、问题出现的环境 环境分为硬件环境和软件环境如果是web项目需要描述浏览器版本客户机操作系统等如果是app项目需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。 3、错误重现的步骤 描述问题重现的最短步骤 4、预期行为的描述 要让开发人员指导怎么样才是正确的尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障能写明需求的来源是最好的。 要相信:测试人员是最懂需求的 5、错误行为的描述 描述错误的现象。crash等可以上传logUI问题可以有截图. 6、其他 某些公司会有一些其他的要求例如故障的分类:功能故障界面故障兼容性故障等。有些有优先级的分类严重影响测试需要开发人员优先修改的可以设置优先级为高。 7、不要把多个bug放到一起 在无法确认是同一段代码造成的故障时不要将bug放在一起提交. 提交了如下bug: 1、在短信列表选择一条短信进行删除删除失败 2、在短信列表选择一条短信进行查看在查看页面进行删除删除失败 很明显上述bug描述中, 第二条描述较清楚, 符合bug的描述要求. 3.3 如何定义bug的级别 通过bug的影响程度, 我们对其分级别定义, 注意bug的定义每个公司都不一致在定义级别之前需要查看公司规范. 以下为样例 1、Blocker崩溃 阻碍开发或测试工作的问题造成系统崩溃、死机、死循环导致数据库数据丢失与数据库连接错误主要功能丧失基本模块缺失等问题。如代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等该问题在测试中较少出现一旦出现应立即中止当前版本测试。 注: 如果发现该级别的bug, 此时就需要停止测试, 打回给开发, 让开发修复, 再进行测试. 2、Critical严重 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符模块无法启动或调用程序重启、自动退出关联程序间调用冲突安全问题、稳定性等。如软件中数据保存后数据库中显示错误用户所要求的功能缺失程序接口错误数值计算统计错误等该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试。 3、Major一般 功能没有完全实现但是不影响使用功能菜单存在缺陷但不会影响系统稳定性。如操作时间长、查询时间长、格式错误、边界条件错误删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多 4、Minor次要 界面、性能缺陷建议类问题不影响操作功能的执行可以优化性能的方案等。如错别字、界面格式不规范页面显示重叠、不该显示的要隐藏描述不清楚提示语丢失文字排列不整齐光标位置不正确用户体验感受不好可以优化性能的方案等此类问题在测试初期较多优先程度较低在测试后期出现较少应及时处理 3.4 BUG的生命周期 每个公司、每一个工具对bug生命周期的定义都是不一致的下面仅是一个常见的例子 测试人员应该跟踪一个Bug的整个生命周期从Open到Closed的所有状态。 BUG状态转换图 New: 新发现的Bug未经评审决定是否指派给开发人员进行修改。 Open: 确认是Bug并且认为需要进行修改指派给相应的开发人员。 Fixed:开发人员进行修改后标识成修改状态有待测试人员的回归测试验证。 Rejected: 如果认为不是Bug则拒绝修改。 Delay:如果认为暂时不需要修改或暂时不能修改则延后修改。 Closed: 修改状态的Bug经测试人员的回归测斌验证通过则关闭Bug。 Reopen: 如果经验证Bug仍然存在则需要重新打开Bug开发人员重新修改。 无效的bug: openc1osed open-rejected-cTosed 4. 软件生命周期 软件的生命周期包含以下几个阶段: 需求分析: 分析用户需求是否合理(市场分析, 技术上分析......) - 软件需求文档;计划: 指定需求执行计划;设计: 将需求细化成一个个任务, 进行技术设计(设计哪些接口, 采用哪些技术) - 产出设计文档;编码: 开发人员按照需求文档以及设计文档来进行编码;测试: 测试人员参考测试用例来执行测试;运行维护: 项目上线后对产品进行线上的维护. 注: 维护有以下几种: 修复性维护: 对项目中未发现的问题进行修复 完善性维护: 对功能进行完善 预防性维护(居安思危): 为了避免产品在线上出现一些其他的问题, 进行一些预防的手段. 5. 开发模型 5.1 瀑布模型(Waterfall Model) 瀑布模型在软件工程中占有重要地位是所有其他模型的基础框架。 特点: 瀑布模型的每一个阶段都只执行一次因此是线性顺序进行的软件开发模式 优点: 强调开发的阶段性强调早期计划及需求调查强调产品测试。 缺点: 依赖于早期进行的唯一一次需求调查不能适应需求的变化;由于是单一流程开发中的经验教训不能反馈应用于本产品的过程;风险往往迟至后期的测试阶段才显露因而失去及早纠正的机会。 适用项目: 小型项目 瀑布模型的一个最大缺陷在于可以运行的产品很迟才能被看到。这会给项目带来很大的风险尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现通常会导致前面阶段的工作大面积返工业界流行的说法是:“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷例如在前期阶段未发现的错误会传递并扩散到后面的阶段而在后面阶段发现这些错误时可能已经很难回头再修正从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想在这个基础上做出自己的修改。例如细化了各个阶段在某些重点关注的阶段之间掺入迭代的思想. 在瀑布模型中测试阶段处于软件实现后这意味着必须在代码完成后有足够的时间预留给测试活动否则将导致测试不充分从而把缺陷直接遗留给用户。 5.2 螺旋模型(Spiral Model) 一般在软件开发初期阶段需求不是很明确时采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一. 优点: 强调严格的全过程风险管理。强调各开发阶段的质量。提供机会检讨项目是否有价值继续下去。每个阶段都会进行风险分析, 避免一些线上问题发生. 缺点: 引入非常严格的风险识别、风险分析和风险控制这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。 适用项目:规模庞大、复杂度高、风险大的项目。 5.3 增量, 迭代 增量开发能显著降低项目风险结合软件持续构建机制构成了当今流行的软件工程最佳实践之一。增量开发模型鼓励用户反馈在每个迭代过程中促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此在这种开发模式下每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本意味着测试需要频繁进行测试人员需要与开发人员更加紧密地协作。 增量通常和迭代混为一谈但是其实两者是有区别的。 增量是逐块建造的概念例如画一幅人物画我们可以先画人的头部再画身体再画手脚..... 而迭代是反复求精的概念同样是画人物画我们可以采用先画整体轮廓再勾勒出基本雏形再细化、着色。 5.4 敏捷 敏捷宣言 2001年以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的轻量过程派聚集在犹他州的Snowbird决定把敏捷(Agile)作为新的过程家族的名称。 在会议上他们提出了《敏捷宣言》 ( Manifesto for Agile Software Development ) 敏捷软件开发宣言 我们一直在实践中探寻更好的软件开发方法 身体力行的同时也帮助他人。由此我们建立了如下价值观 个体与交互重于过程和工具 可用的软件重于完备的文档 客户协作重于合同谈判 响应变化重于遵循计划 在每对比对中后者并非全无价值但我们更看重前者。 由敏捷宣言可以看出敏捷其实是有关软件开发的社会工程(Social Engineering)的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情这是在软件工程几十年的发展过程中相对被忽略的领域。 敏捷开发有很多种方式其中scrum是比较流行的一种. scrum scrum里面的角色 scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成 其中product owner负责整理user story(用户故事)定义其商业价值对其进行排序制定发布计划对产品负责。scrum master 负责召开各种会议协调项目为研发团队服务研发团队则由不同技能的成员组成通过紧密协同完成每一次迭代的目标交付产品。 迭代开发 与瀑布不同scrum将产品的开发分解为若干个小sprint(迭代)其周期从1周到4周不等但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。 scrum的基本流程 scrum的基本流程如上图所示: 产品负责人负责整理user story形成左侧的product backlog。发布计划会议: product owner负责讲解user story对其进行估算和排序发布计划会议的产出就是制定出这一期迭代要完成的story列表sprint backlog。迭代计划会议: 项目团队对每一个story进行任务分解分解的标准是完成该story的所有任务每个任务都有明确的负责人并完成工时的初估计。每日例会: 每天scrum master召集站立会议团队成员回答昨天做了什么今天计划做什么有什么问题。演示会议: 选代结束之后召开演示会议相关人员都受邀参加团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来由po整理形成新的story。回顾会议: 项目团队对本期迭代进行总结发现不足制定改进计划下一次迭代继续改进已达到持续改进的效果。 5.5 软件测试V模型 在V模型中, 用户需求 是指 产品经理将用户需求收集成软件需求;需求分析与系统设计 是指 验证需求是否正确, 确定编程语言与框架;概要设计 是指 项目结构如何设计;详细设计 是指 设计好每个接口, 有涉及哪些库表, 具体完成哪些任务;编码 是指 写代码;单元测试 是指 测试程序中的每一个方法;集成测试 是指 将许多的方法, 集成到一起测试;系统测试 是指 测试模块和模块之间有没有影响;验收测试 是指 确定软件的实现是否满足用户需要或合同的要求. 特点: 左边是开发, 右边是测试, 类似于瀑布mox 优点: 测试被划分成许多类型 缺点: 测试人员介入太晚, 发现问题时机太晚. 有局限性, 仅仅把测试作为在编码之后的一个阶段未在需求阶段就进入测试. 5.6 软件测试W模型 W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成分别代表测试与开发过程图中明确表示出了测试与开发的并行关系。W模型特点: 测试的对象不仅是程序需求、设计等同样要测试测试与开发是同步进行的W模型优点: 有利于尽早地全面的发现问题。 例如需求分析完成后测试人员就应该参与到对需求的验证和确认活动中以尽早地找出缺陷所在。同时对需求的测试也有利于及时了解项目难度和测试风险及早制定应对措施显著减少总体测试时间加快项目进度. 局限性: 需求、设计、编码等活动被视为串行的;测试和开发活动也保持着一种线性的前后关系上一阶段完全结束才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况W模型并不能解除测试管理面临着困惑. 6. 软件测试生命周期 软件测试的生命周期: 需求分析-测试计划-测试设计、测试开发-测试执行-测试评估 需求分析: 测试人员了解需求, 看需求是否完整, 对需求进行分解, 探讨需求是否正确 测试计划: 确定软件由谁测试, 什么时候开始测试, 什么时候结束测试, 测试哪些模块. 测试设计, 测试开发: 写测试用例(手工测试用例, 自动化测试用例), 编写测试工具 测试执行: 执行测试用例 测试评估: 测试人员产生测试报告. 测试报告 项目名称电子商务网站 测试日期2023年8月1日至2023年8月2日 测试团队QA测试团队 测试目的对电子商务网站的登录功能进行功能和安全性测试确保登录功能的稳定性和安全性。 测试环境 - 操作系统Windows 10 - 浏览器Chrome、Firefox、Edge - 设备PC、手机、平板电脑 测试用例 1. 用户名和密码正确登录。 2. 用户名正确但密码错误登录。 3. 用户名错误但密码正确登录。 4. 用户名和密码均错误登录。 5. 登录失败超过3次账户锁定。 6. 密码重置功能测试。 7. 找回密码功能测试。 8. XSS攻击测试。 9. SQL注入测试。 10. 密码规则测试。 测试结果 - 登录功能测试通过所有测试用例均正常运行。 - 安全性测试无发现安全漏洞。 建议和改进 - 建议在账户锁定后提供恢复账户的功能。 - 增强密码规则要求包含数字、大写字母和特殊字符。 总结 登录功能经过全面测试目前运行稳定符合预期要求。未发现严重的缺陷和安全漏洞。建议在后续版本中考虑加入更多的安全性验证措施和密码规则以进一步提升系统的安全性。 测试团队 日期2023年8月2日 7. 如何开始第一次测试 首先要开始第一次测试工作, 需要先充分理解需求, 可以借助产品文档, 技术文档等文档进行理解, (项目功能相关问题可以问产品经理, 模块底层相关问题可以问开发人员), 然后就要确定测试计划, 接下来执行测试, 注意 当BUG开发修复了之后一定要进行验收, 最后就是项目的上线维护工作.
文章转载自： http://www.morning.rpzqk.cn.gov.cn.rpzqk.cn http://www.morning.zlbjx.cn.gov.cn.zlbjx.cn http://www.morning.sknbb.cn.gov.cn.sknbb.cn http://www.morning.shinezoneserver.com.gov.cn.shinezoneserver.com http://www.morning.0dirty.cn.gov.cn.0dirty.cn http://www.morning.rhfbl.cn.gov.cn.rhfbl.cn http://www.morning.cplym.cn.gov.cn.cplym.cn http://www.morning.pjwrl.cn.gov.cn.pjwrl.cn http://www.morning.pdmml.cn.gov.cn.pdmml.cn http://www.morning.mxnrl.cn.gov.cn.mxnrl.cn http://www.morning.brwp.cn.gov.cn.brwp.cn http://www.morning.qjghx.cn.gov.cn.qjghx.cn http://www.morning.jzgxp.cn.gov.cn.jzgxp.cn http://www.morning.qkrgk.cn.gov.cn.qkrgk.cn http://www.morning.sfwfk.cn.gov.cn.sfwfk.cn http://www.morning.kcbml.cn.gov.cn.kcbml.cn http://www.morning.cpfbg.cn.gov.cn.cpfbg.cn http://www.morning.pqkrh.cn.gov.cn.pqkrh.cn http://www.morning.drbwh.cn.gov.cn.drbwh.cn http://www.morning.trtxt.cn.gov.cn.trtxt.cn http://www.morning.mldrd.cn.gov.cn.mldrd.cn http://www.morning.znpyw.cn.gov.cn.znpyw.cn http://www.morning.fgkwh.cn.gov.cn.fgkwh.cn http://www.morning.llllcc.com.gov.cn.llllcc.com http://www.morning.gwwky.cn.gov.cn.gwwky.cn http://www.morning.nypgb.cn.gov.cn.nypgb.cn http://www.morning.lxmmx.cn.gov.cn.lxmmx.cn http://www.morning.zxznh.cn.gov.cn.zxznh.cn http://www.morning.hmtft.cn.gov.cn.hmtft.cn http://www.morning.rklgm.cn.gov.cn.rklgm.cn http://www.morning.fsbns.cn.gov.cn.fsbns.cn http://www.morning.fqqcd.cn.gov.cn.fqqcd.cn http://www.morning.wjhqd.cn.gov.cn.wjhqd.cn http://www.morning.fhrgk.cn.gov.cn.fhrgk.cn http://www.morning.zhmgcreativeeducation.cn.gov.cn.zhmgcreativeeducation.cn http://www.morning.xptkl.cn.gov.cn.xptkl.cn http://www.morning.dgpxp.cn.gov.cn.dgpxp.cn http://www.morning.grjh.cn.gov.cn.grjh.cn http://www.morning.thbqp.cn.gov.cn.thbqp.cn http://www.morning.rykn.cn.gov.cn.rykn.cn http://www.morning.bby45.cn.gov.cn.bby45.cn http://www.morning.tnfyj.cn.gov.cn.tnfyj.cn http://www.morning.gskzy.cn.gov.cn.gskzy.cn http://www.morning.bpmtg.cn.gov.cn.bpmtg.cn http://www.morning.zzhqs.cn.gov.cn.zzhqs.cn http://www.morning.bprsd.cn.gov.cn.bprsd.cn http://www.morning.lznqb.cn.gov.cn.lznqb.cn http://www.morning.kjsft.cn.gov.cn.kjsft.cn http://www.morning.gqfbh.cn.gov.cn.gqfbh.cn http://www.morning.fjtnh.cn.gov.cn.fjtnh.cn http://www.morning.rdnpg.cn.gov.cn.rdnpg.cn http://www.morning.pgggs.cn.gov.cn.pgggs.cn http://www.morning.tmpsc.cn.gov.cn.tmpsc.cn http://www.morning.tkxr.cn.gov.cn.tkxr.cn http://www.morning.sryyt.cn.gov.cn.sryyt.cn http://www.morning.mbnhr.cn.gov.cn.mbnhr.cn http://www.morning.wxccm.cn.gov.cn.wxccm.cn http://www.morning.lsmgl.cn.gov.cn.lsmgl.cn http://www.morning.qckwj.cn.gov.cn.qckwj.cn http://www.morning.hlnys.cn.gov.cn.hlnys.cn http://www.morning.kdldx.cn.gov.cn.kdldx.cn http://www.morning.ryfpx.cn.gov.cn.ryfpx.cn http://www.morning.xkhhy.cn.gov.cn.xkhhy.cn http://www.morning.kgqpx.cn.gov.cn.kgqpx.cn http://www.morning.slnz.cn.gov.cn.slnz.cn http://www.morning.dmnqh.cn.gov.cn.dmnqh.cn http://www.morning.zstbc.cn.gov.cn.zstbc.cn http://www.morning.cgntj.cn.gov.cn.cgntj.cn http://www.morning.pxdgy.cn.gov.cn.pxdgy.cn http://www.morning.rmyt.cn.gov.cn.rmyt.cn http://www.morning.klwxh.cn.gov.cn.klwxh.cn http://www.morning.zqfjn.cn.gov.cn.zqfjn.cn http://www.morning.zcwtl.cn.gov.cn.zcwtl.cn http://www.morning.dmcqy.cn.gov.cn.dmcqy.cn http://www.morning.fdfsh.cn.gov.cn.fdfsh.cn http://www.morning.thlzt.cn.gov.cn.thlzt.cn http://www.morning.jfmyt.cn.gov.cn.jfmyt.cn http://www.morning.crhd.cn.gov.cn.crhd.cn http://www.morning.zrgsg.cn.gov.cn.zrgsg.cn http://www.morning.ycmpk.cn.gov.cn.ycmpk.cn
