达?矢抾哆拉?
软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素，因此对于需求分析和需求变更的处理十分重要。 软件需求变更会给项目带来巨大的风险，会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降等不良后果，因而需求变更在软件开发项目中应该尽量避免。然而由于政府对特定软件的相关要求、用户部门市场战略的调整、工业界的发展等因素都可能带来需求的变更，而这些因素往往不可避免。在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。因而，对于需求变更应该正确的对待，尽量将其负面影响降低到最低。 2、减少需求变更 正如前文所说，需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更，可最后需求变更总是会出现。但是这并不意味着项目开发人员不应该做这方面的工作，项目开发人员对于需求变更的正确态度应该和软件测试的态度一样，在需求并更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。项目开发人员切忌在项目设计之前试图消除需求变更，这样做往往费力不讨好。 相比于需求开发人员而言，客户可能对需求变更认识不足，认为他们出钱，程序员或软件开发公司就要为它服务，因此客户对需求变更往往将需求变更视为儿戏，随个人喜好随意变更需求。因此，在需求人员同用户代表或用户部门主管人员接触时，就应该向他们挑明态度，和他们协商好，特别是应该让他们清楚软件的定价应该与软件的功能相关，以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。通过这样做，让客户在需求分析之前就尽量对他们所需要的功能有个整体的了解和确定的思路，而不是等到程序员开始编码了，才提出以前原本在需求分析时就可以提出的需求。 让客户明白减少需求变更的重要性后，需求分析人员应该采取合适的方法同客户交流，帮助他们明确他们的需求。需求分析人员和客户的关系不应该仅仅是记录人员和需求提供者，他们的关系应该更多的是战略合作伙伴关系。虽然需求分析人员和客户存在着服务商和顾客的关系，但是他们有着一个共同的目标：开发出适合客户需求的软件，因此需求分析人员除了记录客户提出的需求以外，还应和用户讨论，提出一些建议，使用合适的工具帮助客户提出需求。在需求分析时，尽量多的召集需求研讨会，邀请开发人员和客户共同协商探讨，在研讨会上允许任意的提出需求，并将这些需求整理成档后由客户代表和需求分析人员共同商议可选的功能，这样能够尽量使得需求完备。在需求开发时，开发人员采用原型的方法启发客户思考功能需求也不失为一个好办法。 虽然需求不可能是完备的，但是在项目开始设计时尽量使得需求完备还是应该的，也是值得的。 3、规范文档 需求文档作为客户和开发人员的接口在整个项目开发过程中起着举足轻重的作用。需求文档应该按照一定的格式和规范书写，而且应该具备完整性、一致性、基线控制、历史记录等特性。文档书写完毕以后应该交给客户审阅，在客户满意的基础上确定基线。一个完整规范的需求文档不仅能够有助于设计人员和编码人员完成项目开发，更重要的是它作为一个阶段性的成果可以供软件需求变更时参考。 需求变更发生后，也应该生成相应的文档，并且这些文档的书写也应该采用规范的形式书写。需求变更文档也应该包含基线以供下一次修改参考，还应包含历史记录以供开发人员和客户清楚当前的文档内容的新旧以及历史文档的情况，以备以后查看。 4、设计良好的体系结构 开发软件就如同建造一座房屋，软件体系结构则如同建房屋时的规划。两层高的家庭住宅和几十层高的商业大厦建造时的规划必然不同，同样，大型软件和小软件采用的体系结构也必然有所区别。因此，设计一个合理的体系结构对于项目的成败也是十分关键的。 体系结构的建立一般位于需求分析结束之后，软件设计之前。软件体系结构的设计是从结构的角度对整个系统进行分析，选择合适的构件，安排构件间的相互作用以及他们之间的约束，形成一个系统框架以满足用户需求。在设计软件体系结构时，不仅应该想到如何完成满足现在已经提出的用户需求，同时也应适当地考虑到需求的变更。 采用有弹性和可扩展的软件体系结构设计可以有效地降低需求变更引起的风险和维护代价，能够在项目范围未发生变化的前提下很好地适应需求的变化。体系结构的灵活和可扩展性设计使得开发者可以在这种体系结构上面进行各个功能层的组合和分离，也可以将各个功能层分布在各个不同的服务器上共同提供服务，因而能够快速的对需求变更作出响应，并且对已经开发好的系统产生尽可能少的影响。 体系结构的设计除了考虑到体系结构的灵活性和可扩展性以外，还应尽量采用松散耦合的结构，使得结构中的各个构件之间的关联程度尽可能的少，这样就能在需求发生变更时一个构件的变化对另一个构件产生尽可能少的影响。 现有的软件体系结构很多，包括管道-过滤器结构、B/S结构(含C/S结构)、解释器/虚拟机结构、黑板系统以及基于中间件技术的体系结构。在设计体系结构时，首先应该选出适合项目需求的系统结构，然后在从中挑选出那些扩展性比较好，构件之间耦合性比较小的体系结构。基于中间件技术的体系结构就是扩展性比较好的体系结构。采用中间件技术，中间件作为用户界面和操作系统以及网络的连接点，向上为用户提供服务，向下屏蔽操作系统和网络的细节。这种分层的思想能够很好的适应操作系统和网络的变化，可扩展性十分的好。同时，可以在中间件中给出容易改变的接口或是为系统将来改变预留接口来实现功能上的需求变更。当然可扩展性比较好的体系结构远不止基于中间件技术的体系结构这一种，具体的选择和运用应该由设计人员根据实际需要考虑。 5、采用面向对象思想 需求是不稳定的，因而没有不变的需求，然而需求之中却有稳定的东西，这就是对象。世界都是由对象组成的，而对象都是持久的，例如动物、植物已经有相当长的时间。虽然对象也在变化，动物、植物也在不断的进化。但对象在一个相当长的时期内都存在，动植物的存在时间肯定比任何一家企业长久。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。 面向对象(OO)技术的三大特征保证了采用OO技术可以建立易于改变和加强可重用性的软件系统。封装可以把问题影响的范围缩小，外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中，从而改变系统的一部分相对简单;继承可以使改变基于原有技术基础，很大程度上减少重复开发工作;多态的应用可以使开发和设计人员在相对统一的接口下更改系统的实现细节，从而改变系统的行为。 显然，OO技术是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法，可以在一定程度上快速对需求变更进行反应，并可相对减少需求变更需要的成本。因此，在系统开发过程中应该尽量的采用面向对象的思维方式来构建系统和开发系统。 6、需求变更控制 正如前文所言，需求变更不可避免的会发生，那么当需求变更发生后项目开发人员应该如何应对呢? 一般来讲，需求的变更通常意味着需求的增加，需求的减少相对很少，而且处理也比较容易。当客户提出新需求的时候，项目开发人员应该分析这些新需求对项目现阶段带来的风险，得出双方实现变更需求的需要的成本，包括时间、人力、资源等等方面，再与客户商讨是否有必要进行变更和如何在最小代价下实现变更。 当客户确实希望进行需求变更时，可以让开发人员开发一个快速原型，让用户体验一下，以确保客户确确实实的希望添加这些需求。在客户和项目开发人员共同确定了需求变更后，项目开发人员应该与客户签订一份新的合同。 当客户提出需求变更并且签订了合同后或是开发人员根据市场和国家政策作出的需求变更得到确证后，项目开发人员应该决定何时实施这些变更。对于那些对系统影响不大和一些优先权十分高的需求变更可以立即在项目中实施，而对于那些对于整个系统现阶段的开发影响很大，而且又不是十分紧急的需求可以放在下一个版本中进行。无论是立即实施还是放在下一个版本中，都应该给新的需求一个充足的开发和测试时间，保证产品质量。 结论 在面对需求变更时，除了通过减少需求变更和规范文档，从分析和设计的角度通过采用合理的分析和设计方法适应需求变更以外，还应该改变我们设计的意识和对需求变更的理解，做好对需求变更的控制和管理，做到对需求变更的灵活应对，在一定程度上降低维护代价和提高用户满意度。
软件测试记录应包括哪些内容
软件测试的流程，以及各阶段的相关文档
无论是采用瀑布式还是其他的产品生命周期模型，软件测试分为如下几个阶段：
1、测试需求分析阶段。
测试需求分析阶段主要工作是获得测试项目的测试需求（测试规格）。
输出产物：《可测试性需求说明书》和《测试规格》
2、测试计划阶段。
以测试需求为基础，分析产品的总体测试策略。
输出产物：《产品总体测试策略》
3、测试方案设计阶段。
本阶段主要是以测试规格为基础获得特性测试方案，对于有自动化测试的项目，
进行自动化测试的分析，获得测试策略。
输出产物：《产品或者版本总体测试方案》
4、测试用例实现阶段。
本阶段主要是完成各个特性的测试用例的编写和自动化脚本的编写。
输出产物：《产品自动化测试用例》和《手工执行测试用例》
5、测试执行阶段。
本阶段是根据测试策略开展测试执行和回归测试。
输出产品：《产品或版本测试报告》和《缺陷分析报告》
6、评估与关闭阶段。
只对前面的各个阶段的执行情况，
完成对测试项目的关闭，
同时提供完整的度量
数据和项目总结报告。
输出产物：《遗留问题风险分析报告》、《度量分析报告》和《测试关闭报告》
请问软件测试的整个流程是什么(从项目需求开始到项目结束的整个流程)?
理论上越早参与越好！
当接到一个开发项目是，软件测试就要介入，一般认为从需求分析开始！
你可以看看双V模型，国内游一部分公司采用这种模型进行软件开发、测试流程。
软件测试界有一句名言叫做：尽早了解被测系统！但是真正能做到这一点的又能有几个呢？！
当你从事这个行业的时候，你就会有真实的体验，理论和现实区别……
当然有些大型公司做的还是比较好的！
要求写出或谈谈对软件测试的认识
1.软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。
2.从测试方法的角度可以分为手工测试和自动化测试。 手工测试：不使用任何测试工具，根据事先设计好的测试用例来运行系统，测试各功能模块。 自动化测试：利用测试工具，通过编写测试脚本和输入测试数据，自动运行测试程序。目前最常用的自动化测试工具是基于GUI的自动化测试工具，基本原理都是录制、回放技术。
3.从整体的角度可以分为单元测试、集成测试、系统测试、确认测试。
测试流程依次如下：
（1）需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。--testing team
（2）测试计划: 根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。---testing leader or testing manager
（3）用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。---testing leader, senior tester
（4）执行测试：根据测试用例的详细步骤，执行测试用例。--every tester(主要是初级测试人员)
（5）执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员)
（6）defect tracking：追踪leader分配给你追踪的bug.直到 bug fixed。--every tester
（7）测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.
（8）用户体验、软件发布等……
总之，就是找出软件中存在的bug，提高产品的质量，提升用户的体验！
软件测试的方法一共有几种
1、从是否关心内部结构来看
（1）白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。
（2）黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。
（3）灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。
2、从是否执行代码看
（1）静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
(2)动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。
3、从开发过程级别看
（1）单元测试：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。
(2)集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。
（3）系统测试：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
在系统测试中，对于具体的测试类型有：
（1）功能测试：对软件需求规格说明书中的功能需求逐项进行的测试，以验证功能是否满足要求。
（2）性能测试：对软件需求规格说明书的功能需求逐项进行的测试，以验证功能是否满足要求。
（3）接口测试：对软件需求规格说明中的接口需求逐项进行的测试。
（4）人机交互界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的需求。
（5）强度测试：强制软件运行在异常乃至发生故障的情况下（设计的极限状态到超出极限），验证软件可以运行到何种程序的测试。
（6）余量测试：对软件是否达到规格说明中要求的余量的测试。
（7）安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，
（8）可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能（其输入覆盖和环境覆盖一般大于普通的功能测试）
（9）恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况，逐一进行的测试。
（10）边界测试：对软件处在边界或端点情况下运行状态的测试。
（11）数据处理测试：对完成专门数据处理功能所进行的测试。
（12）安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。
（13）容量测试：检验软件的能力最高能达到什么程度的测试。
（14）互操作性测试：为验证不同软件之间的互操作能力而进行的测试。
（15）敏感性测试：为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。
（16）标准符合性测试：验证软件与相关国家标准或规范（如军用标准、国家标准、行业标准及国际标准）一致性的测试。
（17）兼容性测试：验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。
（18）中文本地化测试：验证软件在不降低原有能力的条件下，处理中文能力的测试。
4、从执行过程是否需要人工干预来看
（1）手工测试：就是测试人员按照事先为覆盖被测软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输 入执行，包括与被测软件进行交互（如输入测试数据、记录测试结果等），然后观察测试结果，看被测程序是否存在问题，或在执行过程中是否会有一场发生，属于比较原始但是必须执行的一个步骤。
（2）自动化测试：实际上是将大量的重复性的测试工作交给计算机去完成，通常是使用自动化测试工具来模拟手动测试步骤，执行用某种程序设计语言编写的过程（全自动测试就是指在自动测试过程中，不需要人工干预，由程序自动完成测试的全过程；半自动测试就是指在自动测试过程中，需要手动输入测试用例或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试）
5、从测试实施组织看
（1）开发测试：开发人员进行的测试
（2）用户测试：用户方进行的测试
（3）第三方测试：有别于开发人员或用户进行的测试，由专业的第三方承担的测试，目的是为了保证测试工作的客观性
6、从测试所处的环境看
（1）阿尔法测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试
（2）贝塔测试：是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本，并要求用户报告
扩展资料
软件测试的内容：
1 得到需求、功能设计、内部设计说书和其他必要的文档
2 得到预算和进度要求
3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )
4 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制
5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
6 确定对测试环境的要求 ( 硬件、软件、通信等 )
7 确定所需的测试用具 (testware) ，包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等
8 确定对测试的输入数据的要求
9 分配任务和任务负责人，以及所需的劳动力
10 设立大致的时间表、期限、和里程碑
11 确定输入环境的类别、边界值分析、错误类别
12 准备测试计划文件和对计划进行必要的回顾
13 准备白盒测试案例
14 对测试案例进行必要的回顾 / 调查 / 计划
15 准备测试环境和测试用具，得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据
16 得到并安装软件版本
17 进行测试
18 评估和报告结果
19 跟踪问题 / 错误，并解决它
20 如果有必要，重新进行测试
21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
参考资料：百度百科-软件测试
软件测试记录应包括哪些内容
软件测试记录的话，看具体要求，不知道这个测试记录到底是指什么，一般来讲，测试完毕后都会出一份测试报告。包括测试需求点，安装包地址，用例执行粒度，测试覆盖的系统，机型，发现的Buglist，延期的Buglist（这些是需要产品，研发，测试三方共同确认的），测试达到发版条件，可以发版
软件测试的流程，包含各阶段会产生什么文档
无论是采用瀑布式还是其他的产品生命周期模型，软件测试分为如下几个阶段：
1、测试需求分析阶段。
测试需求分析阶段主要工作是获得测试项目的测试需求（测试规格）。
输出产物：《可测试性需求说明书》和《测试规格》
2、测试计划阶段。
以测试需求为基础，分析产品的总体测试策略。
输出产物：《产品总体测试策略》
3、测试方案设计阶段。
本阶段主要是以测试规格为基础获得特性测试方案，对于有自动化测试的项目，进行自动化测试的分析，获得测试策略。
输出产物：《产品或者版本总体测试方案》
4、测试用例实现阶段。
本阶段主要是完成各个特性的测试用例的编写和自动化脚本的编写。
输出产物：《产品自动化测试用例》和《手工执行测试用例》
5、测试执行阶段。
本阶段是根据测试策略开展测试执行和回归测试。
输出产品：《产品或版本测试报告》和《缺陷分析报告》
6、评估与关闭阶段。
只对前面的各个阶段的执行情况，完成对测试项目的关闭，同时提供完整的度量数据和项目总结报告。
输出产物：《遗留问题风险分析报告》、《度量分析报告》和《测试关闭报告》费这劲儿就给0分....-_-!
软件测试碰到的问题举个例子
1、这个bug我这边重现不了
解决办法
Bug应该简明扼要，重点突出。如果描述存在歧义，一定要总结并尽快改进。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现的条件。
在复现问题时，希望能大致判断几个问题点，然后和测试人员沟通下，需要如何捕获信息，捕获那类信息？是不是提供debug版本进行复现，或者根据预判的点增加打印信息版本进行复现？
2、这个不是代码问题，需求这么定义的
解决办法
需求也是人定的，如果觉得有异议，可以找需求人员询问清楚，为什么这样定义，把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。但是我们可以保留交流的记录，证明曾经在这里发生过歧义。
3、这块是别人负责的，我负责的部分没有问题
解决办法
如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。
4、有问题吗？（也就是开发不认为这是个问题）
解决办法
测试人员一定比开发要敏感，对bug的容忍度也要低一些。特别是一些不符合用户习惯的bug，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能，而且也有解决办法，所以不认为是bug。这个时候，就要发挥测试的本事了，嘴甜一点，说说好话，态度柔和一些。因为既然是小问题，解决起来一定不难，耐心地催开发的改过来就好。催一次不行催两次，记住态度一定要好。
5、用户不会像你这样操作的！
解决办法
用户怎么操作，谁都预料不到。我们不可能覆盖所有可能性，但是大多数用户会出现的操作，我们当然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要满足用户需求的。如果最后还是没能说服他，第一向上级反映，第二做好沟通的记录，将来备份在测试报告里。
以上就是软件测试中遇到的常见问题及沟通方法，如果觉得麻烦可以考虑用一些APP自动化测试工具
转载请注明出处51数据库 » 软件测试需求问题记录 如何正确对待软件测试需求的变更
