软件测试之需求管理有哪些难点？

软件测试之需求管理有哪些难点？

每一位产品负责人、项目经理或业务分析师都需要了解需求管理的重要性。无论是传统项目管理还是敏捷软件开发，成功或失败的基础都取决于需求管理。

需求管理的方法不仅应用在敏捷研发或传统项目管理之中，还适用于金融，制造，建筑，能源，电信等其他行业。

有分析师报告称，需求管理不善导致项目失败的比率高达71%。与技术缺陷、超出时间期限或管理变革失败等原因相比较，需求管理不善的后果更加严重，是项目失败的最主要原因。

因此，在管理需求范围和定义需求的工作中，团队经常会花费会很大精力避免出错。但是在实际的需求实施过程中仍然存在许多问题。

随着项目与业务的复杂性逐渐增加，需求管理不再是简单地管理需求文档，记录相关信息。如今，需求管理中更重要的是要使团队（包括利益相关者）与项目目标保持同步，并构建正确的需求，保证团队顺利实施研发。

在本文中，我们将讨论产品负责人、项目经理和业务分析师在需求管理中面临的几个难点。

01、 什么是需求管理

需求管理就是要识别所有产品和服务的需求，以支持市场的职能。是一套流程，在市场中，一套策划，执行，控制和监督产品的设计，价格，促销，分销的流程，目的是通过满足组织和个人的需要而带来业务

02、 需求池

需求管理难点之一是建立需求池并将其与业务体系关联起来。需求只有与业务使用场景相结合时才有价值。产品负责人也可以将需求按照业务体系进行组织管理，使团队成员能够更好地理解需求。

什么是需求池？

需求池是一种集中存储需求的方法，将未规划的，未开发的，评审中的和已规划的等不同状态的需求集中管理。需求池充当需求的唯一来源，方便产品负责人（包括利益相关者）查询浏览。

需求信息如果不集中管理，会非常影响团队协作。而仅依赖文档和电子表格也无法解决这个问题，长期维护文档会打断团队成员手头的研发工作，因为通常文档版本很多，不容易快速确定需求的变更、审批、实施进度等最新信息。

03、 变更需求产生的影响

在实际业务中，需求不仅仅是文字记录，而是结构化的信息，具有多个依赖和引用关系。更改一个需求会产生对其他需求，包括史诗，特性，用户故事，任务，缺陷或测试用例的一系列影响。

业务需求和项目复杂度逐渐增加，在研发过程中变更需求会产生怎样的影响，现在也变得不好确认，包括对相关需求和目标用户的案例也要进行调整。

因此，产品负责人手动维护表格或使用文档，很难有效率地管理数百项需求以及变更。

04、 建立需求标准

产品负责人或项目经理面临的另一个难点是：客户或利益相关者会频繁变更需求。客户提出了一系列需求，无论是否确认了需求文档，他们随时都会想要变更需求。

如果项目需求范围发生变化，新的需求可能会增加成本预算，甚至导致项目计划重新安排。团队很有可能会面临预算超支或返工。

频繁变更需求的主要原因在于：需求文档编写和确认过程中，利益相关者没有完全参与进来。如果团队要遵循标准化的需求制定方案，利益相关者应预先确认需求变更的可控范围，团队才能以此进行工作量和成本推算。

05、 版本管理

在项目进行过程中，客户与利益相关者的一些需求变更没有办法避免。几乎40％的需求至少要变更一次，大约10％的需求变更两次甚至更多。

因此，产品负责人需要一个好的方式来管理这些需求以及变更记录。让团队成员可以明确了解，在每个版本中需要做哪些新功能或优化。另外，合理地复用需求也可以极大地减少返工并提高团队的生产力。

现在一些团队仍然在使用Word和Excel进行需求管理，它们没办法解决项目实施过程中的复杂问题。团队需要功能更强大的需求管理工具来进行改善和提高。

如果使用优秀的需求管理工具，如Jira、PingCode等，那么就可以轻松解决所有上述问题。

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系我，我们将立即处理

软件测试需要会什么？难学吗？

学会测试不难，难点在于提升测试技术
首先，学测试要学会写用例，写大纲，即你面对一个软件产品，需要能独立分析有哪些测试点，这需要大量的练习与实践
然后，根据不同的产品形态和内容，需要确定用什么测试手段或方法（白盒测试，接口测试，性能测试，黑盒测试，安全测试等等）
根据不同的测试手段确定使用什么样的工具

ERP软件测试实例及分析-01

 ERP软件测试相对于其他的软件测试有业务流程较复杂、功能点较多、集成性较高的特点，那么ERP 是什么样的软件来着呢？

1.ERP软件简介：

    企业资源计划(Enterprise Resource Planning，ERP)即 ERP 企业资源计划是一种先进的企业管理理念，它将企业各个方面的资源进行充分地调配和平衡，为企业提供多重解决方案，使企业在激烈的市场竞争中取得竞争的优势。ERP主要侧重于对企业内部人、财、物等资源的管理，并且扩展了管理范围，它把企业需求和制造活动以及供应商的制造资源整合在一起，形成了一个完整的供应链，并且将供应链上所有环节如订单、采购、库存、计划、生产、发货和财务等所需的所有资源进行统一的计划和管理。ERP软件的特点是业务流、数据流、资金流、管理流集成化程度高，并且各模块联系紧密。其主要功能包括生产制造控制、物流控制、财务管理、人力资源管理、设备管理、质量管理、库存管理等。

2.ERP软件测试的难点：

    ERP软件是一种流程复杂、功能点多且关联性强的系统。如果按照对一般应用软件的方法进行测试，即使耗费很大的人力、物力进行测试，保证大部分功能点都正确，也不能保证可以正常地使用，因为ERP软件的业务流顺畅、集成性高是更重要的要求。针对这样的难点，我们将测试重点应该放在流程正确集成上。

    测试ERP软件，要求测试人员不仅要掌握ERP业务流程和ERP管理思想，还要了解行业及企业的需求。在项目实施过程中要求测试工程师协同工作，共同来设计ERP软件的测试用例，并进行测试。

这里我们提出以业务流和数据流为主驱动的方法设计用例。

3.ERP软件测试实例及分析：

本实例以适用于制造业、面向订单的生产方式的一类ERP软件为例，对其基础数据模块、销售管理模块、计划管理模块、采购管理模块、生产管理模块的主要功能和基本流程测试进行介绍。实例模拟了销售部门签订销售订单，之后转到计划部门对销售订单进行物料需求计算，采购部门和生产部门根据计划部门下达的计划进行生产和采购，最终完成发货并关闭销售订单的基本流程。该实例采用的流程图的方式，侧重于业务流、数据流、资金流以及管理流的测试。

用例设计首先使用场景法，对系统运行流程进行分析，从宏观考虑用例应该包括的那些基本流和被选流，其次在设计具体的数据流时以业务流为驱动，结合等价类划分、边界值分析、因果图等方法进行具体数据的设计。

3.1前期分析：

由于ERP软件的流程比较复杂，如何选择有限的有代表性的流程达到测试需求，在设计测试用例前，利用场景法对软件的流程进行分析，通过用例场景并结合各路径的触发条件来确定用例应遵从的流程。

所谓用例场景，就是在测试用例设计方法中介绍过的，通过描述流经用例的路径来确定测试用例的过程，这个流经路径要从用例开始到结束，遍历其中所有基本流和备选流。

3.1.1业务流程图

（图1）

3.1.2主备选流图

根据上面的流程图和用户使用手册，我们可用归纳出一个看上去比较清晰的主备选流关系图，如下面所示以及各路径与触发条件的对照表：

（图2）

各路径的触发条件对照表如下（表1）：

路径

触发条件

基本流

库存可用产品数量不满足销售需求

库存可用零部件数量不能满足生产要求

所采购的部件入库质检全部合格

所生产的部件及产品全部合格

备选流1

库存可用产品数量满足销售要求

备选流2

库存可用产品数量不满足销售需求

库存可用零部件数量能满足生产需求

备选流3

库存可用产品数量不满足销售要求

库存可用零部件数量不满足生产需求

所采购的部件入库质检部分不合格

备选流4库存可用产品数量不满足销售需

求所生产的部件及产品需要返工

备选流5

库存可用产品数量不满足销售需求

所生产的部件及产品有废品
3.1.3场景分析

从上面所示的路径，可用确定不同的用例场景，从基本流开始，将基本流和备选流结合起来，可以确定各种场景（如图2中只是列出部分的场景）。

场景路径表（表2）

场景1

基本流；

场景2

基本流；备选流1；

场景3

基本流；备选流2；

场景4

基本流；备选流3；

场景5

基本流；备选流4；

场景6

基本流；备选流5；

场景7

基本流；备选流2；备选流4；

场景8

基本流；备选流3；备选流4；

场景9

基本流；备选流5；备选流1；

场景10

基本流；备选流2；备选流5；

场景11

基本流；备选流3；备选流5；

场景12

基本流；备选流5；备选流4；

场景13

基本流；备选流5；备选流2；备选流4；

场景14

基本流；备选流5；备选流3；备选流4；

场景15

基本流；备选流2；备选流4；备选流5；备选流3；

以上我们讨论了ERP几个子模块之间的业务流程图，同时模块内部还有较复杂的业务流程，在实际测试时我们不可能对所有流程一一验证，这就引出一个问题：如何选择”性价比“较高的业务流程，使它们尽量覆盖较多的场景，然后根据所选业务流设计数据流，为了解决这个问题，我们建立了路径触发条件与场景关系表，如表3所示。

（表3路径触发条件与场景关系表）

序号

路径触发条件组合

覆盖的场景

1库存无可用产品数量库存无可用零部件

所采购的部件入库质检全部合格

所生产的部件及产品全部合格

场景1

2

库存可用产品数量满足销售要求

场景2

3

库存中有可用产品但不满足销售需求

库存无可用零部件

所采购的部件入库质检全部合格

所生产的部件及产品全部合格

场景1、场景2

4

库存中有可用产品但不满足销售需求

库存有可用零部件但不满足生产需求

所采购的部件入库质检全部合格

所生产的部件及产品全部合格

场景1、场景2、场景3

5

库存中有可用产品但不满足销售需求

库存有可用零部件但不满足生产需求

所采购的部件入库质检全部不合格

所生产的部件及产品全部合格

场景2、场景3、场景4

6

库存中有可用产品但不满足销售需求

库存有可用零部件打但不满足生产需求

所采购的部件入库质检部分不合格

所生产的部件及产品全部合格

场景1、场景2、场景3、场景4

7

库存中有可用产品但不满足销售要求

库存有可用零部件但不满足生产需求

所采购的部件入库质检部分不合格

所生产的部件及产品全部返修

场景2、场景5、场景7、场景8

8库存中有可用产品但不满足销售要求

库存有可用零部件但不满足生产需求

所采购的部件入库质检部分不合格

所生产的部件及产品全部为废品

场景2、场景6、场景10、场景11

9库存中有可用产品但不满足销售需求

库存有可用零部件但不满足生产需求

所采购的部件入库质检部分不合格

所生产的部件及产品部分为废品，其余部分需要返修

场景2、场景5、场景6、场景7、促进、场景10、场景11

10

库存中有可用产品但不满足销售需求

库存有可用零部件但不满足生产需求

所采购的部件入库质检部分不合格

所生产的部件及产品部分为废品，其余部分需要返修；部分合格

场景1、场景2、场景3、场景4、场景5、场景6、场景7、场景8、场景10、场景11

分析：从表3中可用看出第10组条件组合所覆盖的场景很多，应该按照这个组合设计案例（实际测试中可以根据软件需求和测试需求的不同，添加或减少触发条件），但其同时存在着优点和缺点。

缺点：对循环执行业务考虑得不全，如未覆盖9、12、13、14、15，归其原因是在于没有考虑执行备选流5以后的场景触发条件。

        优点：覆盖了全部流程分支，且可以按照实际测试需求，根据这个条件组合循环执行案例，达到要求的场景覆盖率。

    通过以上工作我们确定了在设计该ERP软件案例时”性比价“较高的流程，以及触发流程所需的基本条件，这样在准备案例的数据流时就有了”根基“，使一套测试数据能够覆盖尽量多的流程分支及功能点，反之，如果盲目的选择流程进行案例设计，结果可能是重要的流程分支及功能点没有覆盖到，或者是虽然流程分支及功能点覆盖到了，但进行了大量重复性劳动，造成了人力、物力的浪费。

    下期我们就以表3中的第10组条件组合为列，进行案例设计。

请问由软件开发转行到软件测试的难点在哪里？

难就难在你一般都会按照正常的流程去测试（毕竟做开发时，我们必须按照需求去开发），这样一般测不出来什么问题。

。关键你得把自己下意识的当作一个新手，想一想一般一个新手都会怎样？新手不可能知道整个流程是怎么走下来的，说的白一点他肯定得先挨个按钮点点看看都是干什么用的。这样要是出现bug了那就是程序员的失误了呗。测试人员不要把需求看得太多，要把自己当成一个普通用户，一点点去摸索程序。

软件测试可以自学吗？软件测试自学难不难？

川石信息
关于自学
第一、你的自制力是否能让你持续的投入学习？
第二、你的自学能力如何？
第三、你的解决问题能力如何？
第四、你能否找到项目进行实战清楚，行业需要那些技术？
如果以上都能做到，我毫无犹豫的说，自学吧，你是非常有潜力的，加油！
总结：自学消耗的时间比较长，如果没有基础的话，想要自学也是比较难的，相对于有一定基础的，一般都是在空闲之余用碎片化的时间去学习，想要在软件测试的领域小有所成，找到一份正式工作，怎么也得一年半载吧。自学需要强大的自制力，需要耐得住寂寞，每天固定的坚持学习，但是遇到技术难点很容易做牛角尖，导致半途而废。
培训
优势：学习时间相对较短，整体学习比较全面，学习内容也比较集中。专业老师按照大纲进行系统授课，在学习中遇到技术问题能够快速得到解决，同时还有专项的练相对于自学，学习气氛更加浓厚，跟同期学员对问题的探讨，对拓展思路有很大的帮助。让学习变成一件很快乐的事情，学习起来也会很有动力，学习的效果会更好。
劣势：相对于自学，培训是需要金钱成本，一般的培训机构学习费用都在一万五到三万不等左右，还要加上学习期间的生活费，学习成本比较高。PS：从时间就是金钱的角度来看，上面说的自学优点反而不成立啦，提前工作半年的薪资估计不止一两万吧。
如果你不是一个自制能力很强的人，又想能够尽快的提升技能，最好是找一家靠谱合适的培训机构进行学习，毕竟培训价格不是小数目，主要是看钱花得值不值，主要取决于培训机构的质量。不过无论是培训还是自学，自己都得努力去学习，不然说什么也无济于事。
在这里顺便提下如何选择一家培训机构去学习。
在选择培训机构时就一定考虑到以下几点：
1、课程选择：不要只是简单的学习功能测试，而是会涵盖有现在流行的性能测试、自动化测试、接口测试和测试开发等内容；
2、课程教学：培训机构的教学不仅仅是教会你做标准的软件测试，而是要教你一些测试逻辑，教会你使用工具但又不依赖于这些工具也可以完成性能测试、自动化测试、接口测试，也就是其背后的底层的工作原理，这些东西才是真正能够内化成属于你个人的核心竞争力。
3、现在的移动互联网企业对自动化测试的需求非常大，也会要求学员掌握程序设计的原理，所以测试开发性综合性人才才是未来IT行业的需求方向。
4、一定要去参加试学，因为很多人目标不明确，甚至是迷茫的，所以去试学一周，看看自己是不是真的想做技术，或者适合做技术。
5、授课方式，有些是面授，有些是视频授课，各有优点，就看自己喜欢哪种。线下面授的学费应该更高，毕竟成本在那里，学习时有老师盯着，有同学陪着，能够更快的进入学习状态。
发布于 2019-10-23

请问软件功能测试应注意哪些问题

1:你要熟悉整个软件的数据结构2：熟悉整个数据库的各个表结构3：软件流程要熟悉4：软件测试的时候一定要注意数据关联性，数据类型变化测试，稳定性能，导航是否清晰太多了，你如果是新手就这样，如果你是个专业的就用大型的测试工具测试，

谁可提供一些软件测试标准啊?

一、软件测试综述 完整的软件测试是评定软件性能和质量的重要手段，该测试可以用来检查软件是否满足设计和项目合同书所规定的技术要求，检验软件对误操作的处理能力，并为软件可靠性与安全性的评估提供依据。软件测试有许多不同的分类方法，如按测试用例设计方法可分为白盒测试和黑盒测试；按测试策略和过程可分为单元测试、集成测试、确认测试和系统测试；从是否需要执行被测软件的角度，可分为静态测试和动态测试。上述各种方法都已被证明是行之有效的，在测试中应根据测试目的适当选择。通信软件测试和一般的软件测试适用于同样的测试方法、流程和工具，但又具有一定的差异性，特别是针对诸如手机终端软件的测试。对于手机软件这样一个人机交互频繁、人性化要求高的应用系统的测试，电信运营商需要从两个角度考虑：一方面从开发人员的角度思考，要求测试系统提供足够证据来证明软件系统的功能是可行的；另一方面则应该从使用手机终端的用户角度出发，要求测试系统提供手机软件系统的缺陷和不足信息。二、手机终端软件测试难点及可行的解决方案 恰当地评测手机软件产品并非易事，一方面，手机终端的软件和其硬件直接相关，而硬件开放的接口可能是受限的；另外，各个终端的软件千差万别，难以直接套用通用的测评工具。对于手机终端软件的评测很困难并不意味着手机终端软件是不可测的，手机软件包括了Protocol、MMI（人机接口）两个主要部分以及应用软件/应用系统。Protocol部分是通过了FTA（全面型号认证）才能使用的（针对GSM手机而言），其无线资源管理、移动性位置管理和通讯管理软件部分必须满足制式对应的标准，可以使用自动测试系统来对协议进行跟踪和测试。应用软件/系统则基本适用于一般的软件测试流程和工具。如何测试MMI部分是测试的难点，鉴于Protocol、MMI这两部分相互影响不能截然分开，MMI软件的问题也会影响Protocol部分。目前大多数公司没有自动化的测试软件，只能通过模拟用户的办法来操作手机，在出现问题的时候进行跟踪。而部分生产商其软件底层有测试代码支持，可以实现自动化测试，实现方法是开发测试代码并加入到手机原代码中去，但这对于电信运营商来说并不现实。对于上述问题，目前可行的解决方案之一是软件模拟，即通过软件模拟器来实施软件测试，在模拟器平台上可以对手机软件完成覆盖率测试、内存测试、性能测试和一致性测试。对MMI而言，将手机应用程序移植到模拟器平台上运行，可以模拟显示MMI菜单树，也可通过模拟网络消息来模拟短信和打电话等功能，并可对部分代码进行单元测试和集成测试。需要说明的是，利用模拟器对手机软件进行测试不能作为唯一测试途径，但往往可以通过与目标系统相同版本进行交叉测试或测试对比。解决方案二是开发测试系统，提供ProtocolStack和MMI的跟踪分析以及模拟用户硬件功能。系统可通过线程调用来进行控制，包括用户界面线程、脚本解析线程、串口控制线程和设备线程。用户界面线程提供测试的人机界面；脚本解析线程响应用户界面线程发送的控件消息，负责解析脚本文件并执行解析后脚本；串口控制线程控制测试系统和被测系统之间的数据传输；设备线程实现根据测试要求自动设定设备参数的功能。尽管测试系统的开发可以采用模块化的方式，但仍存在开发难度较大、测试对象属性差异较大的问题，更加简单的方法是基于现有的测试平台/系统进行开发，如基于Ageresystem的Optitrace套件的开发等。三、3G环境中手机终端软件的测试 鉴于3G技术更加复杂，且终端定制将成为主流，3G手机软件的测试工作值得深入研究。3G业务在国外已经开展了一段时间，在手机测试方面也已经有一定的积累，目前已经有相应的测试工具被开发出来，业界正在对业务测试平台进行论证。从目前的情况看，在3G环境中开展手机软件的测试过程中，一致性测试成为新的难点。一致性测试是用来确认设备是否符合对其功能要求方面的规范或协议的测试过程，一致性测试标准包括3部分：抽象测试集（ATS）、协议实现一致性说明（PICS）和协议实施附加信息（PIXIT）。可执行测试集（ETS）在以上3部分的基础上生成。协议一致性测试和射频一致性测试是其中最复杂也最重要的部分，协议一致性测试属于软件测试的范畴，在一定的网络环境下，对被测协议实现（IUT）进行黑盒测试，通过比较IUT的实际输出与预期输出的异同，判定IUT在多大程度上与协议描述相一致，从而确立通过一致性测试的IUT在互联时成功率的高低。实际上，2G系统同样需要进行一致性测试，3G系统因相对于2G系统更加复杂，而使得一致性测试显得更加重要。协议一致性测试可测试手机和网络之间的信令协议是否符合TS34.123规范，3GPPTS34.123定义了约700个TTCN测试用例，对RLC层、MAC层和RRC层分别进行测试。全球认证论坛GCF也制定了测试用例/策划平台认证的流程以及终端产品认证注册的流程，按照优先级将测试用例划分为7个Batch，从高到低进行认证。从目前的情况来看，能提供协议一致性测试设备的厂商并不多，但这是软件测试的一个不可或缺的环节。在多个厂家进行设备互联时，通过一致性测试会提高人们对设备符合相应协议标准的置信程度，提高相同标准不同实现之间互联的概率，这对于我国自主知识产权的TD-SCDMA设备来说具有现实意义。对于3G手机而言，除上面提到的协议一致性测试之外，MMI以及应用软件/应用系统的测试仍将是测试中的主要工作，而且随着手机智能化程度的不断上升，这部分的测试工作会给电信运营商带来更大的挑战。

以上就是学分高考的小编对软件测试之需求管理有哪些难点？以及软件测试之需求管理有哪些难点？的详细介绍与分解，相信大家看完之后都已经对这方面有了更详细的认识与了解。（本文共10713字）