软件开发中,测试是一个必须环节,那么测试人员是如何来测试我们的代码呢,那前端的来说,一般是样式和ui一样不,项目的菜单结构是否是需求提供的一样,代码实现的功能是否和需求一样,比如点击什么出现什么,登陆的跳转,按钮的功能这些。一般要有数据库里面的数据脱敏以后提供测试案例,根据测试案例来一步步像用户一样操作,试验功能。
测试种类,在软件测试中UT,IT,ST,UAT指单元测试,集成测试,系统测试 ,用户接受测试。
一、UT(单元测试,Unit Test):
单元测试任务包括:
1、模块接口测试;
2、模块局部数据结构测试;
3、模块边界条件测试;
4、模块中所有独立执行通路测试;
5、模块的各条错误处理通路测试。;
二、IT(集成测试,Integration Test):
也称系统集成测试(System Integration Test)或结合测试,集成测试阶段是以黑盒法为主,在自底向上集成的早期,白盒法测试占一定的比例,随着集成测试的不断深入,这种比例在测试过程中将越来越少,渐渐地,黑盒法测试占据主导地位。
三、ST(系统测试,System Test):
从技术角度看,系统测试是整个测试阶段的最后一步,所有的开发和测试在这一点上集中表现为生成一个具有一定功能的软件系统。该阶段主要对系统的准确性及完整性等方面进行测试。
主要进行:
功能确认测试、运行测试、强度测试、恢复测试、安全性测试等。系统测试的测试人员由测试组成员(或质量保证人员)或测试组成员与用户共同测试。在整个系统开发完成,即将交付用户使用前进行。在这一阶段,完全采用黑盒法对整个系统进行测试。
四、UAT(验收测试,User Acceptance Test):验收测试是向未来的用户表明系统能够像预定要求那样工作。
经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。
下面是风险等级,缺陷之类的详解,可以参考管理工具来理解。
https://www.cnblogs.com/liuxiao01/p/8985640.html
所属项目:
也就是你对应的项目名称,比如微信
所属模块:
具体的功能模块,比如朋友圈首页
所属迭代:
每个app都有自己的版本号,一般来说在设置-关于里可以找到,比如微信目前的版本号是6.5.3
影响版本:
一般来说填测试版或者线上版
当前指派:
这里填写你要提交去解决的开发对象
截止日期:
也就是bug的修改截止日
Bug类型:
即对bug进行简单分类,比如有代码错误,界面优化,设计缺陷等待
操作系统:
如果是app测试的话,一般这里填写Android或者iOS,用于区分不同的平台
浏览器:
一般用于web兼容性测试,app测试的话可不填
bug标题:
对bug进行的简单描述,让开发理解就好,比如微信朋友圈点赞后无反应
严重程度:
不同的平台可能划分的名称不同,比如有的是以数字区分,1-4,1为最严重,或者是Low,High这样进行划分。一般来说最高级,比如1级bug意味着非常严重,影响到进程使用,比如登录后直接崩溃,这样的为1级bug。2级bug意味着严重,一般指重要功能出了问题,比如微信朋友圈打不开。3级bug意味着普通,一般来说在测试中提的最多的缺陷就是3级bug,比如微信朋友圈无法点赞。4级bug是对应一些建议性的问题,比如你觉得点赞的红心过大或者过小
优先级:
为建议开发处理的优先级,一般来说是越严重的bug越优先处理
重现步骤:
详细描述bug产生的操作步骤,出现后的结果,和期望结果,一般来说,有截图的话附带截图比较好。
测试方法
集成测试:黑盒或灰盒测试,将相关联的程序模块分别组合进行测试以检查模块间接口、功能、信息传递的正确性。侧重功能测试。
功能测试(function testing):是在规定的一段时间内运行软件系统的所有功能,以验证这个软件系统有无严重错误。
回归测试(regression testing):这种测试用于验证对软件修改后有没有引出新的错误,或者说,验证修改后的软件是否仍然满足系统的需求规格说明。
可靠性测试(reliability testing):如果系统需求说明书中有对可靠性的要求,则需进行可靠性测试。通常使用平均失效间隔时间MTBF与因故障而停机的时间MTTR来量度系统的可靠性。
强度测试(stress testing):强度测试是要检查在系统运行环境不正常到发生故障的情况下,系统可以运行到何种程序的测试。因此进行强度测试,需要提供非正常数量、频率或总量资源来运行系统。强度测试的一个变种是敏感性测试,以发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合。
性能测试(performance testing):性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对实时系统或嵌入式系统,软件只满足需求的功能而达不到要求的性能是不行的。性能测试可以出现在测试过程的各个阶段,当然,只有当所有系统的元素全部组装完毕,系统性能才能完全确定。
恢复测试(recovery testing):恢复测试是要证实在克服硬件故障(包括掉电、硬件或网络出错等)后,系统能否正常地继续进行工作,并不对系统造成任何损害。为此,可采用各种人工干预的手段,模拟硬件故障,并由此检查:
① 错误探测功能——系统能否发现硬件失效或故障;
② 能否切换或启动备用的硬件;
③ 在故障发生时能否保护正在运行的作业和系统状态;
④ 在系统恢复后能否从最后记录下来的无错误状态开始继续执行作业等。
如果系统的恢复是自动的(由系统自身执行),则应对重新初始化、数据恢复、重新启动等逐个进行正确性评价。如果恢复需要人工干预,就需要对恢复的平均时间进行评估以判定它是否在允许的范围之内。
启动/停止测试(startup/shutdown testing):这类测试的目的是验证在机器启动及关机阶段,软件系统正确处理的能力。
配置测试(configuration testing):这类测试是要检查计算机系统内各个配置或各种资源之间的相互联结和功能分配中的错误。它主要包括以下几种:
① 配置命令测试:验证全部配置命令的可操作性(有效性);特别对最大配置和最小配置要进行测试。软件配置和硬件配置都要测试。
② 循环配置测试:证明对每个设备物理与逻辑的、逻辑与功能的每个循环置换配置都能正常工作。
③ 修复测试:检查每种配置状态及哪个设备是坏的。并用自动的或手工的方法进行配置状态间的转换。
安全性测试(security testing):系统的安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用、有无漏洞。为此要了解破坏安全性的方法和工具,并设计一些模拟测试用例对系统进行测试,力图破坏系统的保护机构以进入系统。
可使用性测试(usability testing):可使用性测试主要从使用的合理性和方便性等角度对软件系统进行检查,发现认为因素或使用上的问题。
可支持性测试(supportability testing):这类测试是要验证系统的支持策略对于公司与用户方面是否切实可行。它所采用的方法是试运行支持过程(如对有错部分打补丁的过程,热线界面等),对其结果进行质量分析,评审诊断工具、维护过程、内部维护文档;衡量修复一个明显错误所需的平均最少时间。还有一种常用的方法是,在发行前把产品交给用户,向用户提供支持服务的计划,从用户处得到对支持服务的反馈。
安装测试(installation testing):安装测试的目的不是找软件错误,而是找安装错误。
互连测试(interoperability testing):互连测试是要验证两个或多个不同的系统之间的互连性。这类测试对支持标准规格说明,或承诺支持与其他系统互连的软件系统有效。
兼容性测试(compatibility testing):这类测试主要想验证软件产品在不同版本之间的兼容性。有两类基本的兼容性测试:向下兼容(测试软件新版本保留它早期版本的功能)和交错兼容(验证共同存在的两个相关但不同的产品之间的兼容性)。
容量测试(volume testing):容量测试是要检验系统的能力最高能达到什么程序。在使系统的全部资源达到“满负荷”的情形下,测试系统的承受能力。
文档测试(documentation testing):这种测试是检查用户文档(如用户手册)的清晰性和精确性。确保叙述正确无误。