需求文档

公司的软件测试流程： 1、采集用户需求（产品经理+软件实施工程师） 2、编写基础版需求文档（产品经理/产品经理助理） 3、需求文档评审（产品经理+开发经理+测试经理+客户） 4、沟通需求方，完成需求文档的修改（产品经理+客户） 5、下发需求文档至开发经理和测试经理 6、开发经理出具开发版需求文档，测试经理出具测试版需求文档 开发部门的运作流程 1、需求文档部门内部评审 2、下发开发任务（开发经理） 3、开发人员进行编码工作 4、开发人员本地环境下代码自测 5、自测完成合并代码至公司源码库 6、源代码打包部署至开发和测试环境 7、知会测试人员进行测试（showcase） 8、根据测试反馈进行bug解决 9、配合运维人员打包上线 测试部门的运作流程 1、需求文档部门内部评审 2、下发测试任务（测试经理） 3、测试人员根据需求模块分配进行测试用例的输出 4、测试用例评审 5、测试人员完成测试用例的修改，等待开发通知测试工作的开始 6、执行测试用例，提交bug 7、跟踪bug进行bug的回归测试 8、打包上线后进行回归测试 视频链接：https://www.bilibili.com/video/av47476628 来源： CSDN 作者： 飞翔的小仙女儿 链接： https://blog.csdn.net/weixin_43784779/article/details/103945225

此文章转载，由于作者不详，在次就没有注释，望其见谅！ 做测试快两年半的时间了，在测试过程中接触到了不少的事情，总结下自己测试工作中的一些经验吧： 　　1、充分理解需求，找出需求缺陷。 　　测试人员拿到需求、设计文档后，应积极地与需求、设计人员进行沟通确认，并及时地提出自己对相关文档的疑问，这样做的好处一方面在于帮助测试人员充分理解需求，以保证设计全面、正确的测试用例；另一方面在于帮助需求、设计人员找出文档中不完善甚至错误的地方，以便尽早解决，这样就降低了后续过程中的风险和成本，也缩短了研发的工作进度。 　　2、及时有效地沟通。 　　测试过程中，测试人员可能对设计文档有了新的疑问，或者程序实现出现了与设计不一致的地方，即程序实现的效果可能会达不到或者超出其他人（设计人员、测试人员）的预期（这种情况比较常见，因为大家看待事情的角度、表达方式、处理方式不一定一样，所以可能导致前者描述的事情，后者误解或者漏掉了其中一部分内容）。此时测试人员应该积极地与相关开发人、设计人进行沟通，保证大家对同一个需求的理解是一致的，这样才尽可能地保证了我们的产品做出来是满足用户需求的； 　　3、抱着怀疑的态度了解测试依据（需求和设计相关文档）。 　　测试人员应注重分析需求和设计相关文档，但又不只限于这些文档。当测试人员拿到需求和设计相关文档时，同样应该抱着怀疑的态度，仔细斟酌文档中的情景

软件需求分析与管理的十个问题 1.需求工作涉及到哪些内容 首先需求包括了产品需求，用户需求，软件需求。产品需求关注的是产品的标准化和通用化，会对收集到的用户需求进行分类和优化，结合业界标准系统模型进行抽象并通用化。用户需求反映的是用户面临的问题域，根据问题域用户期望的能够达到的解决效果；而对于软件需求则是用软件工程的语言结构化和文档化的对用户需求和产品需求的描述。 需求工作涉及到需求开发和需求管理。需求开发涉及到需求调研，需求收集，需求分析，需求开发等工作，其中的重点有业务流程，数据字典，业务规则，界面原型。对于基于面向对象的开发方法则涉及到业务用例，系统用例(涉众，基本流，扩展流，业务规则，界面，操作)等诸多内容。需求管理工作涉及到需求的状态管理，变更管理，需求的跟踪，需求的验证和确认等重要内容。 在我们需求分析和开发中，最容易忽视的主要有两点，一个就是缺乏需求分析和开发的过程，把用户需求直接作为了软件需求，没有需求建模和抽象的过程。另外一点就是对于性能，安全，易用性，可维护性和扩展性等非功能性需求没有考虑，导致开发出来的系统是一个不好用的半成品。CMMI把需求管理放到2级，需求开发放到3级，实际上真正的提高需求人员的需求分析和开发能力才是解决需求问题之道。需求分析开发做不好，需求变更或追踪管的再好也没有用处，在这点上一定不能本末倒置。 2.做好需求分析需要具备哪些知识

刚刚结束了一个项目的开发，也是我第一次正式的组织开发一个软件，软件不算大，但是在组织的过程中，却发现了自己很多地方的不足，现总结如下： 一．项目整体部分： 1． 在以后的项目管理中由项目经理首先确定一个中期目标，给项目组成员一个总体认识，然后写好项目任务进度表，把每月、每星期、甚至每天（如果需求足够明确的话）任务进度表示清楚，并按部就班的执行。 2． 交流沟通问题：根据项目的进展程度，采用随时和阶段交流。 二．项目开发模式部分： 1． 项目开发模式将根据具体情况来确定，以何种模式开发将根据具体的情况，讨论后执行。切不可一味执着于某一种开发模式。 2． 模式确定后，将根据具体情况进行适当的调整，切不可对现有的项目进行全盘的否定。 三．需求及设计部分： 1． 对需求设计不要求大量的人员参与，只需要 2-3 个人就可以完成任务。但在此过程中需定期和其他人员讨论，并提出想法和修改意见，并着情况做适当的改进。 2． 整体需求过程中，没有设计并论证好详细的流程，导致逻辑的可行性不可保证。（主要针对已经确定的功能需求。） 3． 需求设计部分文档： a) 一切想法和思路都要形成于文档，文档是体现需求设计思想必须的形式，并且在形成文档后更有利于发现在设计过程中的不足。例如：流程文档要先于编码等。 b) 在设计时应及时的记录下来设计思想和解决问题的标准办法

需求工程的活动 划分为以下5个独立的阶段： 需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求； 需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义； 形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约； 需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性，包含有效性检查，一致性检查，可行性检查和确认可验证性； 需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。 需求获取阶段 需求获取首先需要的是技术的支持，其次，在需求获取工作中主要涉及了 3 个至关重要的因素：应搜集什么信息；从什么来源中搜集信息；用什么机制或技术搜集信息。再次，需求获取的开始，代表着软件项目正式开始实施，正所谓万事开头难。综合上述 3 个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的方面。在工作开展中，主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进行沟通，挖掘系统最终用户的真正需求，把握需求的方向。在需求获取调研会中首先对需求获取方法作了验证。现行的需求获 　　取方法一般有基于调查的需求获取方法、基于用例的需求获取方法、原型法等几种方法。各种需求获取方法各有利弊。[7] 需求分析阶段

刚读了《敏捷软件开发原则、模式与实践》第一章敏捷实践，对照现在正在进行的2个项目，感触挺深，特别是设计与文档，在当初实际编码的时候看来就存在意识上的偏差，所以借此机会写下来。 前段时间公司在过CMMI2，由于之前在软件开发过程中极不规范，特别是项目管理，完全是出于项目经理个人意识的管理，所以在推行CMMI的时候特别强调开发过程，一切都按规范来走，因为CMMI2是项目管理级，所以这也是重中之重了。这是这2个项目启动时候的大环境，再来说说项目环境。这2个项目都是学校项目，一个是学校门户与协同办公，一个仅为协同办公，在前期，就决定用MOSS2007来实现，包括与Exchange和LCS的整合。 第1个项目我是全程参加的，从投标到后面的验收，这个项目难道不大，需求很明确，通过2个星期左右的需求调研，形成了比较完善的需求文档，用户也签了字。这个项目的参与人员包括一个项目经理、2个开发人员（我是其中一员，并带另一个今年毕业的同事）、QA、CM、测试人员2名。我和刚毕业的同事没有使用SharePoint做过开发，只有很少的使用经验来自于使用公司内部信息门户，对SharePoint的认知算是很少吧，虽然我在前一个项目投标中搭建过MOSS2007环境，并完善了投标书系统部分功能，其实这个项目就是我要说得第二个项目了。 需求确定下来后，我开始概要设计文档的编写，在这过程中，和项目经理发生了一些分歧

1、问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2、问：给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 提交功能的测试。 多媒体元素是否可以正确加载和显示。 多语言支持是否能够正确显示选择的语言等。 界面测试可以包括但不限于一下几个方面： 页面是否风格统一，美观 页面布局是否合理

PRD（Product-Requirement-Document，产品需求文档），这对于任何一个产品经理来说都不会陌生的一个文档，一个PRD是衡量一个产品经理整体思维的标准，一个PRD可以看出一个产品经理在某个领域的专业性，同时也可以反应出一个产品经理的整体产品思维。 产品经理的整体思维体现在： 1、提炼核心需求 2、思考满足核心需求的方式 3、评估方式优劣选定方案 4、思考功能概要 5、思考支撑功能和关联功能 6、细化设计功能 7、子功能（功能间迭代） PRD其实就是将以上的思维整体走向写出来，同时将产品的思想提炼出来，用文字表示给开发者，给UI、给视觉、给老板……PRD给的是一种思想，将产品的整体思想和核心需求灌输给产品的相关人员，都说PRD是个承上启下的功能，因为上接MRD，下对MRD进行技术性的描述。 网上已经有太多互联网公司的PRD文档，淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范，适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例，讲解一下PRD的主要内容。 1、文件命名（编号） 文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名

李子骅--石墨文档技术总监。 一个产品有需求的提出、评审、确定，以及实际的开发测试和交付这几个阶段。从2001年敏捷被提出开始到现在已经有越来越多的项目在使用敏捷。现在的敏捷已经变成一种常态，这个时候讨论敏捷实践中被大家的忽略点就变得非常有意义。 今天我们会围绕两个关键的点来讨论：一个是关注非功能需求，另一个是DevOps相关的策略。 关注非功能需求 这是一个网站的截图，上面有两个文本块，第一个是标题，第二个是答案。 看到这个图，首先大家会想它是什么东西，其次是为什么会有人问这个问题。 这是现在最流行的前端开发框架 React 的新一代的核心算法，Fiber的提出有两个背景原因。 第一个原因 是现在越来越多的产品和网站非常复杂，尤其体现在交互和功能方面。就比如石墨文档可以让很多人同时在线编写 Word 文档，这和之前传统的类似博客和新闻的Web 应用不一样，现在我们会有更复杂的交互，所以复杂交互带来什么呢？越来越多的用户发现虽然网站功能越来越多，但是好像网站也随之变得更卡了。滚动的时候会有一些延迟，打开一个网页会越来越慢。Fiber专门是为了解决这个问题，也就是说当你的网站很复杂的时候它可以让你的网站速度响应更快一些。 第二个原因是什么呢？ 经过长期的发展，React是现在最流行框架之一，全世界用户都在向它提各种需求：我想加这个功能，要那个功能，但是长期发展过程中也积累了很多技术债

1.问：你在 测试 中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。 　　首先，将问题提交到 缺陷管理 库，类似禅道，进行备案， 　　根据需求文档，产品说明，设计文档等，确认实际结果是否与计划有不一致的地方， 　　如果没有文档，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 　　根据一般用户的使用习惯，来确认 　　与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 　　合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪 　　等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。 　　 2. 给你一个网站，你如何测试？ 　　首先，查找需求说明、网站设计等相关文档，分析测试需求。 　　制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试； 性能测试 ； 数据库 测试；安全性测试；兼容性测试 　　设计 测试用例 ： 　　功能性测试可以包括，但不限于以下几个方面： 　　链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 　　提交功能的测试。 　　多媒体元素是否可以正确加载和显示。 　　多语言支持是否能够正确显示选择的语言等。 　　界面测试可以包括但不限于一下几个方面： 　　页面是否风格统一