功能设计

角色和需求 1，销售人员， 1.1，要对客户进行维护，可以对客户进行查看，新增，删除，修改，跟进等操作 代码上的要求： 增删查改各使用一个页面，然后根据每一个表的配置来控制，展示的字段，筛选字典，查询字段，批量操作，要求是可配置的， 1.2，最复杂的是客户查看页面，有查询，有筛选，有批量，有表头，有列表，有分页， 1.3，要有客户报名的业务， 2，讲师 1.1，要批量生成上课记录， 3，学生 1.1，要交作业， 4，老板 要看报表， 5，登陆，注册，菜单展示，权限控制， 来源： https://www.cnblogs.com/andy0816/p/12267532.html

上篇博客 【写自己的ASP.NET MVC框架（上）】 我给大家介绍我的MVC框架对于Ajax的支持与实现原理。今天的博客将介绍我的MVC框架对UI部分的支持。 注意： 由于这篇博客是基于前篇博客的，因此有些已说过的内容将会直接跳过，也不会给出提示。 所以，如果要想理解这篇博客，那么阅读上篇博客 【写自己的ASP.NET MVC框架（上）】 则是必要的。 回到顶部 MyMVC的特点 在开发MyMVC的过程中，我吸取了一些ASP.NET WebForm的使用经验，也参考了ASP.NET MVC，也接受了Martin Fowler对于MVC思想的总结。 在设计过程中，我只实现了一些必要的功能，而且没有引入其它的类库与组件，因此，它非常简单，且容易使用。 我们可以这样理解MyMVC： 它是一个简单，容易使用，且符合MVC思想的框架。 在MyMVC框架中，View仍然采用了WebForm中的Page，毕竟Page已经使用了十年，能经得起时间的检验，它仍然是我们可信赖的技术。 另一方面，Page也是ASP.NET中默认的HTML输出技术，使用它会比较方便。 MyMVC与微软的ASP.NET MVC不同的是： 1. 不依赖于URL路由组件。 2. 不提供任何HtmlHelper 3. Controller只是一个Action的容器，没有基类的要求。 4. Action处理的请求不区分POST,

转自：http://www.51testing.com/html/71/n-865171-2.html 可参考：http://www.cnblogs.com/TestWorld/p/5211043.html 待总结.. 一、测试用例的切面设计 　　所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。 　　1、功能点切面 　　这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。 　　2、特定切面 　　除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面

软件开发出来后，无非就两大团体来接触他。一个是用户，一个是开发者。所以在设计软件的时候这两个团体要同时考虑，从各个角度来权衡每个设计点的偏重点。 开发的软件是给用户操作的，用户每天都要与之打交道，所以界面的美观性，功能的实用性，操作的简易性，数据传递的速度以及比较贴近的业务逻辑对于用户来讲都是很重要的。 而对于开发者来说，软件开发完成后并不是就不用管了，软件的后期维护也是一项很重要，很繁琐的事情。用户会随着时间的推移，不断的改变着他的需求，要你对软件进行改进。当然，你会把一些需求挡回去，把一些需求通过现有的条件变种方式来实现，但总有一些你需要增加或修改。这时，你的软件在开始设计的时候是不是够灵活，在你修改的时候便知道了。 如果维护的软件让你头疼，宁愿重新开发也不愿意去修改，那就说明这个软件设计的很不成功。 要想让软件不发生腐化，使以后的维护工作更加容易，那么设计软件的时候应该尽量避免以下几个问题：  1. 僵化性（ Rigidity ）：设计难以改变 当用户提出一个新的需求时，需要对程序的一些地方进行改动，可当你打开代码，发现虽然是添加一个很小的功能，却牵涉到了很多地方。这样单一的改动导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。没人愿意为了一小块玉石而去移掉整座山，愚公移山的精神在这里不值得发扬。 2. 脆弱性（ Fragility ）：设计易于遭到破坏

1Django框架的初使用 说起Django框架，肯定需要首先明确一个概念，即软件框架。下面就是第一个问题： 1 软件框架（software framework） 1.1 概念界定 软件框架：通常指的是为了实现 某个业界标准 或完成 特定基本任务 的软件组件规范，也指为了实现 某个软件组件规范 时，提供规范所要求之 基础功能的软件产品 。 1 软件框架是具有基础功能的软件产品： 基础功能：可以理解为为了满足某类业务场景而设定的功能。 软件产品：软件框架是为了针对某一类软件设计问题而产生的。 1.2 形象理解 其实可以将软件框架想象成一个公司，公司中有各个职能部门，每个部门各司其职，通过部门之间的配合来完成工作，这些部门就形成了一个公司的组织架构。 软件框架也是如此，只是说一个公司，它是针对某一市场而成立的，而软件框架的设计是针对某一类软件问题而设计的， 其目的主要是提高软件开发效率 。 软件框架是由各个模块组成，各个模块都会有不同特定的功能。模块与模块之间相互配合来完成软件的开发。 在介绍完软件框架是什么之后，就需要研究一下具体的框架模式，这里介绍下MVC框架模式： 2 MVC 2.1 框架、设计模式、架构 笔者曾很困扰于这问题，查找了很多相关文字，作下总结和体会表述： 基本概念： 框架 通常是 代码重用 ； 设计模式 是 设计重用 ，其只有实例化之后才能用代码表示； 框架 则

A Role-Based Access Control (RBAC) system for PHP PHP基于角色的访问控制系统设计 By Tony Marston 13th May 2004 Amended 9th March 2008 介绍 什么是“访问控制”？ 什么是“基于角色”？ - 基于等级的访问控制 - 基于用户的访问控制 - 基于组的访问控制 - 基于责任的访问控制 什么是“菜单系统”？ 我当前的设计 结论 其它类型的访问控制系统 修正历史 介绍 “访问控制”系统，即“安全系统”，或“权限系统”。在我长期的工作中我曾经参与设计和开发了几个这样的系统： 20世纪80年代我用古典的 COBOL 设计编写了一个“ 菜单安全系统 ”。 20世纪90年代我又用很少人知道的第四代语言UNIFACE编写了这个“ 菜单安全系统 ”。 2003年我使用PHP+MySQL重写了这个” 菜单安全系统 “用于管理Web应用程序的安全。 这篇文章将描述一些早期我使用过的系统中的特点，并解释我当前的设计的主要特性。 什么是“访问控制”？ 在单用户应用程序如典型的桌面应用程序中不需要任何访问控制，用户可以访问程序的全部功能。然而，当一个程序被部署到多台联网的机器上，并被多人使用时，不是所有人都拥有是用应用程序所有功能的权限了。这种情况下，就需要一个适当的方法来控制某些功能只能让被授权的人访问

1 目的 测试用例是测试人员执行测试的基本依据，因此测试用例质量的高低直接影响测试的有效性和效率。为了保证测试执行人员使用最有效的测试用例，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产品、系统或者模块的测试质量，最终提高仁科互动公司产品线的质量。特编写统一测试用例编写规范，为测试设计人员提供测试用例设计编写指导，提高编写用例的可读性、可执行性、合理性。 2 用途 适用于对各业务线测试人员对功能测试用例和接口测试用例的编写。 3 用例设计流程 测试分析： 进行测试用例编写的前提。测试人员根据产品部门提供的PRD、用户故事以及研发部提供的设计文档进行测试需求分析，找出明显的和隐含的需求。有些需求无法从需求文档中获得，可借助概要设计文档或者详细设计文档，或直接从最终的软件产品上获得。 测试设计： 依据测试分析整理并编写出测试用例大纲，并将测试大纲细化为测试用例。测试用例大纲用脑图的形式进行管理，在时间受限的情况下，测试用例评审对象是脑图，详细测试用例会抽取一些作为附加评审对象。参加的人员应包括测试负责人、项目经理、开发人员及其他相关的测试人员。 测试用例完善： 测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须定期修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；产品上线后客户反馈的软件缺陷

带图更精彩 ！ 第一章软件工程概论 一、软件 软件：程序、数据及其相关文档 特点：抽象性、无明显制造过程、无老化、对硬件依赖性。 分类：系统软件、支持软件、应用软件 软件设计过程中，随着时间的推移，软件比硬件投入逐渐增大。 发展阶段：设计-系统-工程 过程：软件规格说明、软件开发、软件确认、软件改进 特性：易理解性、可见性、可支持性、可接受性、可靠性、健壮性、可维护性、速度等。 步骤： 1.制定计划：总目标、功能性能可靠性接口要求、可行性研究 2.需求分析和定义：需求定义图表表示、软件需求说明书。 3.软件设计：概要设计，划分模块；详细设计，确定模块内结构及接口。 4.程序编写 5.软件测试：单元测试、组装测试。 6.运行维护：改正性维护、适应性维护、完善性维护。 二、软件开发模型 第一次实验探索开发，再进行进一步的开发。 渐增模型，基于原型。 螺旋模型：制定计划，风险分析，实施工程，客户评估。四个象限轮转，每转一圈产生一个原型。 喷泉模型：可迭代 三、软件生存周期 系统开发生命期：计划阶段，分析阶段，设计阶段，实现阶段，支持阶段。 四、软件工程 软件工程定义：软件工程是开发、运行、维护和修复软件的系统方法。 软件工程三要素：方法、工具、过程。 软件工程项目基本目标：低成本，达到要求，较好性能，易于移植，维护费用低，按时交付。 软件工程七条原理: 1. 分阶段的生存周期计划严格管理

一. 摘要 这篇文章详细介绍了一个“多路信号采集系统”的开发过程。“多路信号采集系统”是一个可伸缩的信号采集系统，通道可以选择从0~100路不同的信号源。单个采集板都能够采集10路数据，用户可以根据自己的需求方便地扩展或者收缩信号通道数。本系统可以用于常见的民用或者工业现场监控、仪器仪表等数据采集场合。该系统基于Arm Context M3内核处理器实现，有基板和采集板两大部分组成，基板主要负责整个采集时序的控制，而采集板则完成真是的数据采集并将采集到的数据发送到数据总线，进而传输到主机端。数据传输采用了串口通信的方式（RS485），并采用Modbus协议实现，从而方便地实现了采集板地址的检索、数据量控制、以及CRC校验值确定等功能。软件系统则采用了固件库编程的方式，全程开发均使用C语言完成，从而为以后升级做好准备。开发使用了今日标企业工作平台以及Github代码托管平台相结合完成开发的方式，使用今日标企业工作平台管理项目开发流程，而使用Github则方便地实现了不同地区开发者协作开发的目的。而系统调试则选择了传统的调试方式，先进行单个功能模块测试，再测试系统功能，进而Burning实验。 二. 本文提纲 1. 摘要 2. 本文提纲 3. 项目起始 4. 开发方式选择 5. 系统构架 6. 硬件设计 7. 软件设计 8. 系统调试 9. 总结 三. 项目起始

一般情况下，企业开发软件时会按照基线和定制两块并行方式执行项目开发工作。无论什么公司，都需要遵从一套成熟的产品研发过程体系，才能做出质量较好的产品。因此，如果出现项目较多的情况，应该合理地安排基线和定制之前的里程碑，让基线产品能够尽量多地收集用户的通用型需求，为定制项目进度实现技术支撑，减少定制项目中大量更改代码、需要新增模块情况发生。此外，产品研发过程体系也需要按照业务实际时间要求变化，不要拘泥于一定要按照瀑布方式，或是敏捷方式进行管理，凡事都需要找到契合自己的方式。 【这里以一个基线产品开发过程作为流程解释基础，需要注意的是，以下说描述的各个阶段，在项目执行前要明确各个阶段的目标、指定计划、及时沟通，并确保各个时期所有成员对项目理解一致】 项目启动会 项目启动会的目标是明确该产品开发项目的目标。目标不是孤立存在的，目标与计划相辅相成，目标指导计划，计划的有效性影响着目标的达成。所以在执行目标的时候，考虑清楚自己的行动计划，怎么做才能更有效地完成目标，是每个人都要详情清楚的问题，否则，目标越是不清晰或是过高，都会影响项目的实际结果。 项目启动会需要说明项目目标、阶段划分、组织结构、管理流程等关键事项，并将这些内容写入 PPT（最好是有固定格式和范文，让团队内部或者公司内部共同遵守规范），需要大家达成一致。对于关键角色任命，事前也需要听取相关领导和项目主要干系人的意见。 用户需求