2021-10-11 15:49发布
看是什么样的问题了,如果是严重程度低的问题就无所谓了。其实软件测试一切要以需求文档为标准。不能只听开发人员的,需要满足需求。你可以向你的上级反应这个问题。如果是严重的BUG,开发人员需要按照需求文档修改系统.如果都按照系统实现为标准还测试什么呢.
跟经理反馈,然后根据需求修改
凡事多和领导沟通,不要自作主张 随意听人意见
要及时的与项目经理进行沟通协调。要在邮件中详细的把不完善不准确的地方描述出来,并提出自己的意见。
测试需求分析 发现需求文档不完善或者不准确,应该立即和相关人员进行协调交流。
所以,显性需求是用户需求的表层形式,而隐性需求正是被表层需求掩盖的真实需求,也就是用户留给我们可以深度挖掘的产品目标。那么,怎么去挖掘这份隐性需求呢?
1.可用性测试行为记录
让一群具有代表性的用户对产品进行典型操作,同时观察员和开发人员在一旁观察,聆听,做记录。(可以联系之前讲解过的Alpha测试,但是有些不同的,大家要提高警惕哦)
在测试过程中,我们要观察并记录用户的各种行为,包括操作的流畅度、停顿、误操作以及用户的神态表情等。
但是要注意整个过程中不要给用户任何操作性提示或行为性诱导,以便对用户的行为做日常状态下最真实的记录,因为只有如此,才能知道用户的真正诉求和想法,才能挖掘到最真实的隐性需求。
2.平时日常生活中观察积累
这就需要各位在生活中多多留心了,我们要巧妙的把生活中的经验应用到工作中,只有把生活中的内容变成工作,让自己都分不清楚到底是在生活还是在工作,这就说明你已经进入状态了,这样的话,你的经验就完全可以应用到需求分析中,直接作为客户的隐形需求来使用
3.同类竞品功能对比
在我们生活中,很多人的习惯可能都是跟第一次使用或者使用频率极高的同类竞争品有关系,比方说有的人一有不懂的东西,旁边人就会提醒他可以去百度一下;
如果需要购物可能大多数人下意识反应就是淘宝;而如果在网络上进行网络聊天的时候,大多数人都是按着录音键,讲完话之后再发送,这也是微信和QQ中的操作方式。而这些方式在融入习惯的时候已经引不起大多数用户对他的关注了,用户是在使用一种没有意识的行为进行操作。
一、项目经理通过和客户的交流,完成需求文档,由开发人员和测试人 员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地 方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合 开发人员,测试人员以及客户的意见,完成项目计划。然后sqa进入项目,开始进行统计和跟踪。二、开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或 者双方理解不同的地方。测试人员完 成测试计划文档,测试计划包括的内容上面有描述。三、测试人员根据修改好的需求分析文档开始写测试用例,同时开发人 员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写 测试用例的补充材料。四、测试用例完成后,测试和开发需要进行评审。五、测试人员搭建环境六、开发人员提交第一个版本,可能存在未完成功能,需要说明。测试 人员进行测试,发现 bug 后提 交给 bugzilla。
七、开发提交第二个版本,包括 bug fix 以及增加了部分功能,测试人员进行测试。八、重复上面的工作,一般是 3-4 个版本后 bug 数量减少,达到出货 的要求。九、如果有客户反馈的问题,需要测试人员协助重现以及回归测试。 在传统的 bugzilla 中,bug 描述应该包括以下的信息:① 和 bug 产生对应的软件版本;② 开发的接口人员;③ bug 的优先级;④ bug 的严重程度;⑤ bug 可能属于的模块,如果不能确认,可以用开发人员来判断;⑥ bug 标题,需要清晰的描述现象;⑦ bug 描述,需要尽量给出重新 bug 的步骤;⑧ bug 附件中能给出相关的日志和截图。 高质量的 bug 记录就是指很容易理解的 bug 记录, 所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位。
理论上说如果已经在执行测试过程中才发现需求文档不完备,是有人失职了。但是实际情况还是很常见的,比如新产品开发,原型开发模式等等
虽然从事开发行业的女生越来越多,但女生的比例还是远比不上男生。软件测试的男女生比例则基本相当,软件测试要求细心、耐心,大部分女生也是比较适合学的。而且软件测试课程分为手工测试和自动化测试,手工测试分为功能测试、性能测试、接口测试。自动化测试...
需要。很多人当初抱着测试不需要懂代码,才选择了这个行业,这个就要看对自己的职业定位了,是止步于月薪过万就可以了,还是往20k、30k去突破,如果这样的话,是肯定要会接口、会自动化,就必然要涉及到代码。如果真的看不懂代码,实际的测试后期的工作会出现...
在我看来游戏开发挺难的,尤其像手游一类的还有网游,里面有很多的程序代码而且伤神又费力,不过也有女生在这方面做的很好的,如果你感兴趣,非常想学,可以试试
软件测试专业现在很火热,很缺少人才,25岁学软件测试能学会,就业薪资也高,工作也相对轻松
测试类型有:功能测试,性能测试,界面测试。功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用...
这个其实和接口测试的场景密不可分的,比如说:外部接口测试: 必须先接口测试通过了,才能执行功能测试子系统或者各个模块之间的联调测试: 必须各子系统后台代码完成,并提供接口才可以完成测试,一般来说都要求各子系统功能测试通过后再进行...
这个是会因为公司的架构不同而不同的,并不是固定的,但是一般是会有专门的测试部门,或者叫质量保证部,也有可能是叫别的名字。
移动端测试,包括App兼容性测dao试,7*24小时稳定性测试,功耗性能测试,UI测试,交互测试等,课程主要学习的内容有:1、功能测试主要包括计算机基础、软件测试核心理论、Linux、数据库,学习目标是掌握软件测试核心理论,结合Linux、数据库等可实现移动端、w...
标题 1. 首先要做一个标题党(此标题党非彼标题党)。标题一定要清晰简洁易理解,不应该臃长 2. 尽量前缀要规范,例如模板: [Product][Version]_[Feature]_[Title],这样描述会很清晰,也方便查找 3. 缺陷的标题一定要描述在什么情况下发生了什么问...
1、 缺陷报告可以记录缺陷2、可以对缺陷进行跟踪管理3、可以对缺陷报告进行分类 总结 统计
1、缺陷编号(Defect ID),提交BUG的顺序。2、缺陷标题(summary),简明扼要的说明一下这个BUG。3、缺陷的发现者(DetectedBy) ,一般是自己。4、发现缺陷的日期(Detected on date),一般是当天。5、缺陷所属的模块(subject), 在测试哪个模块的时候发现的BUG...
缺陷标题好的缺陷标题需要让相关人员一目了然,一般建议的格式是条件+失败。缺陷类型缺陷类型也是根据具体的项目而定的。但一般情况下分为功能、界面、建议。重现步骤重现步骤的编写规则可以参考测试用例中的操作步骤 ,一定要足够详细、说明清楚问题的操作顺...
工具:NoSQLUnitJsTestDriverQTRunnerVenusFluintBuster.JSSQLUnitECUTQTestlibUnitilsgreatestDbUnitAbbotGoogleTest框架:JUnitMoqJSCaptureMockCUnitPyUnitCppUTestCppUnitzCUTcipra
JunitTestNGGoogleTestpytestunittestJmockitJaCoCogcov、lcov、gcovrCoverage.pyEvoSuiteDiffblue Cover
React Hooks测试库( Testing Library)是一个简单而完整的React Hooks测试工具。 React Hooks测试库让用户可以为React钩子创建简单的测试工具,自定义钩子的输入和检索输出,以处理在功能组件体内运行的情况。 使用React Hooks,用户不必为了测试而去担...
1、单元测试注重代码逻辑,接口测试注重业务逻辑;2、单元测试的粒度最小,是测试最小独立的单元模块(不依赖其他模块);接口测试不是,会覆盖很多;3、单元测试是白盒测试,接口测试是黑盒测试;4、单元测试关注的是代码的实现和逻辑,测试范围较小,保证实...
最多设置5个标签!
看是什么样的问题了,如果是严重程度低的问题就无所谓了。其实软件测试一切要以需求文档为标准。不能只听开发人员的,需要满足需求。你可以向你的上级反应这个问题。如果是严重的BUG,开发人员需要按照需求文档修改系统.如果都按照系统实现为标准还测试什么呢.
跟经理反馈,然后根据需求修改
凡事多和领导沟通,不要自作主张 随意听人意见
要及时的与项目经理进行沟通协调。要在邮件中详细的把不完善不准确的地方描述出来,并提出自己的意见。
测试需求分析 发现需求文档不完善或者不准确,应该立即和相关人员进行协调交流。
所以,显性需求是用户需求的表层形式,而隐性需求正是被表层需求掩盖的真实需求,也就是用户留给我们可以深度挖掘的产品目标。那么,怎么去挖掘这份隐性需求呢?
1.可用性测试行为记录
让一群具有代表性的用户对产品进行典型操作,同时观察员和开发人员在一旁观察,聆听,做记录。(可以联系之前讲解过的Alpha测试,但是有些不同的,大家要提高警惕哦)
在测试过程中,我们要观察并记录用户的各种行为,包括操作的流畅度、停顿、误操作以及用户的神态表情等。
但是要注意整个过程中不要给用户任何操作性提示或行为性诱导,以便对用户的行为做日常状态下最真实的记录,因为只有如此,才能知道用户的真正诉求和想法,才能挖掘到最真实的隐性需求。
2.平时日常生活中观察积累
这就需要各位在生活中多多留心了,我们要巧妙的把生活中的经验应用到工作中,只有把生活中的内容变成工作,让自己都分不清楚到底是在生活还是在工作,这就说明你已经进入状态了,这样的话,你的经验就完全可以应用到需求分析中,直接作为客户的隐形需求来使用
3.同类竞品功能对比
在我们生活中,很多人的习惯可能都是跟第一次使用或者使用频率极高的同类竞争品有关系,比方说有的人一有不懂的东西,旁边人就会提醒他可以去百度一下;
如果需要购物可能大多数人下意识反应就是淘宝;而如果在网络上进行网络聊天的时候,大多数人都是按着录音键,讲完话之后再发送,这也是微信和QQ中的操作方式。而这些方式在融入习惯的时候已经引不起大多数用户对他的关注了,用户是在使用一种没有意识的行为进行操作。
一、项目经理通过和客户的交流,完成需求文档,由开发人员和测试人 员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地 方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合 开发人员,测试人员以及客户的意见,完成项目计划。然后sqa进入项目,开始进行统计和跟踪。
二、开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或 者双方理解不同的地方。测试人员完 成测试计划文档,测试计划包括的内容上面有描述。
三、测试人员根据修改好的需求分析文档开始写测试用例,同时开发人 员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写 测试用例的补充材料。
四、测试用例完成后,测试和开发需要进行评审。
五、测试人员搭建环境
六、开发人员提交第一个版本,可能存在未完成功能,需要说明。测试 人员进行测试,发现 bug 后提 交给 bugzilla。
七、开发提交第二个版本,包括 bug fix 以及增加了部分功能,测试人员进行测试。
八、重复上面的工作,一般是 3-4 个版本后 bug 数量减少,达到出货 的要求。
九、如果有客户反馈的问题,需要测试人员协助重现以及回归测试。
在传统的 bugzilla 中,bug 描述应该包括以下的信息:① 和 bug 产生对应的软件版本;② 开发的接口人员;③ bug 的优先级;④ bug 的严重程度;⑤ bug 可能属于的模块,如果不能确认,可以用开发人员来判断;⑥ bug 标题,需要清晰的描述现象;⑦ bug 描述,需要尽量给出重新 bug 的步骤;⑧ bug 附件中能给出相关的日志和截图。
高质量的 bug 记录就是指很容易理解的 bug 记录, 所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位。
理论上说如果已经在执行测试过程中才发现需求文档不完备,是有人失职了。但是实际情况还是很常见的,比如新产品开发,原型开发模式等等
相关问题推荐
虽然从事开发行业的女生越来越多,但女生的比例还是远比不上男生。软件测试的男女生比例则基本相当,软件测试要求细心、耐心,大部分女生也是比较适合学的。而且软件测试课程分为手工测试和自动化测试,手工测试分为功能测试、性能测试、接口测试。自动化测试...
需要。很多人当初抱着测试不需要懂代码,才选择了这个行业,这个就要看对自己的职业定位了,是止步于月薪过万就可以了,还是往20k、30k去突破,如果这样的话,是肯定要会接口、会自动化,就必然要涉及到代码。如果真的看不懂代码,实际的测试后期的工作会出现...
在我看来游戏开发挺难的,尤其像手游一类的还有网游,里面有很多的程序代码而且伤神又费力,不过也有女生在这方面做的很好的,如果你感兴趣,非常想学,可以试试
软件测试专业现在很火热,很缺少人才,25岁学软件测试能学会,就业薪资也高,工作也相对轻松
测试类型有:功能测试,性能测试,界面测试。功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用...
这个其实和接口测试的场景密不可分的,比如说:外部接口测试: 必须先接口测试通过了,才能执行功能测试子系统或者各个模块之间的联调测试: 必须各子系统后台代码完成,并提供接口才可以完成测试,一般来说都要求各子系统功能测试通过后再进行...
这个是会因为公司的架构不同而不同的,并不是固定的,但是一般是会有专门的测试部门,或者叫质量保证部,也有可能是叫别的名字。
移动端测试,包括App兼容性测dao试,7*24小时稳定性测试,功耗性能测试,UI测试,交互测试等,课程主要学习的内容有:1、功能测试主要包括计算机基础、软件测试核心理论、Linux、数据库,学习目标是掌握软件测试核心理论,结合Linux、数据库等可实现移动端、w...
标题 1. 首先要做一个标题党(此标题党非彼标题党)。标题一定要清晰简洁易理解,不应该臃长 2. 尽量前缀要规范,例如模板: [Product][Version]_[Feature]_[Title],这样描述会很清晰,也方便查找 3. 缺陷的标题一定要描述在什么情况下发生了什么问...
1、 缺陷报告可以记录缺陷2、可以对缺陷进行跟踪管理3、可以对缺陷报告进行分类 总结 统计
1、缺陷编号(Defect ID),提交BUG的顺序。2、缺陷标题(summary),简明扼要的说明一下这个BUG。3、缺陷的发现者(DetectedBy) ,一般是自己。4、发现缺陷的日期(Detected on date),一般是当天。5、缺陷所属的模块(subject), 在测试哪个模块的时候发现的BUG...
缺陷标题好的缺陷标题需要让相关人员一目了然,一般建议的格式是条件+失败。缺陷类型缺陷类型也是根据具体的项目而定的。但一般情况下分为功能、界面、建议。重现步骤重现步骤的编写规则可以参考测试用例中的操作步骤 ,一定要足够详细、说明清楚问题的操作顺...
工具:NoSQLUnitJsTestDriverQTRunnerVenusFluintBuster.JSSQLUnitECUTQTestlibUnitilsgreatestDbUnitAbbotGoogleTest框架:JUnitMoqJSCaptureMockCUnitPyUnitCppUTestCppUnitzCUTcipra
JunitTestNGGoogleTestpytestunittestJmockitJaCoCogcov、lcov、gcovrCoverage.pyEvoSuiteDiffblue Cover
React Hooks测试库( Testing Library)是一个简单而完整的React Hooks测试工具。 React Hooks测试库让用户可以为React钩子创建简单的测试工具,自定义钩子的输入和检索输出,以处理在功能组件体内运行的情况。 使用React Hooks,用户不必为了测试而去担...
1、单元测试注重代码逻辑,接口测试注重业务逻辑;2、单元测试的粒度最小,是测试最小独立的单元模块(不依赖其他模块);接口测试不是,会覆盖很多;3、单元测试是白盒测试,接口测试是黑盒测试;4、单元测试关注的是代码的实现和逻辑,测试范围较小,保证实...