软件测试是在测试中识别软件产品和服务的准确性和质量的过程。显然,它的诞生是为了验证产品是否满足客户的特定先决条件和需求。
软件测试在规定的条件下对软件进行操作,以发现错误,对软件质量进行评估 软件测试的范围:对软件形成中的文档,数据及程序进行测试
……近年来,软件测试一直呈现出火爆的发展势头。
接下来我们就来聊聊做测试工作的规范,也是避免自己背锅,这还是很有用的。
测试计划,描述了要进行的测试活动的范围、方法、资源和进度,确定出测试项、被测特性、测试任务、谁执行任务、各种可能的风险。
通常测试计划的范围包括以下几点:
1.描述测试的各个阶段(例如,单元测试、集成测试或系统测试),并说明本计划所针对的测试类型(如功能测试或性能测试)。
2.简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
3.如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施,则列出所有这些假设。
4.列出可能会影响测试设计、开发或实施的所有风险或意外事件。
5.列出可能会影响测试设计、开发或实施的所有约束。
6.规划测试进度,分配测试任务至个人
需要借助自动化进行测试时,计划好自动化参与的时间,如何部署自动化测试环境以及具体的执行步骤等。
测试计划制定完成后,即开始进行测试设计,内容包括:
1.测试场景设计,针对不同的模块、不同功能、各业务流程和逻辑分支,分别进行测试场景设计。相同的功能在不同的模块,可以参考已有的测试场景进行设计。
2.测试用例设计。新模块测试用例按照测试用例模板进行编写;已有模块更新或优化需要更新原有case。
3.用例评审(重要,面试这一块也会问)
完在测试用例设计之后为了保证测试用例的覆盖率,需要对测试用例进行评审,评审可以是交叉review或开会讨论的形式。
主要从以下几方面进行评审。
测试过程中发现任何问题,包括产品设计、开发代码错误等问题,需要一律记录在缺陷管理工具中,方便跟踪和总结。
提交bug时需注意以下几点:
1.确认该bug是否复现以及复现的步骤。
2.Bug库中是否已存在同一问题描述的bug。
3.确认该问题是否为真正的bug,比如不满足产品需求、影响产品使用等等。
4.思考该问题是否还在其他场景下复现。
提交bug时,各个参数根据bug规范进行填写,summary要简单明了,复现步骤要清晰直接,另外,必要时提供相关测试数据和文字说明,上传图片或附件,以便更加直观的说明问题。
发现产品缺陷时,测试人员要对软件缺陷进行分类,以简明扼要的方式指出其影响,以及修改的优先次序。
回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
通常有下列几种方法来确定回归测试范围:
1.测试全部用例。这种方法比较安全,但往往带来很大的工作量。
2.基于风险选择测试,先运行最重要的、关键的和可疑的测试,而跳过那些非关键的、优先级别低的或者高稳定的测试,测试过程从主要特征到次要特征。
3.基于操作剖面选择测试,可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障。
再测试修改的部分。测试者可以通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和它的接口上,使回归测试尽可能覆盖受到影响的部分。
测试人员除了需要注重与产品人员和开发直接的沟通,团队各成员之间沟通也应高效及时,避免测试人员之间测试结果互相影响、重复测试、重复与开发沟通确认浪费开发时间等,从而提高测试工作的效率。
因此,要求测试人员做到以下几点:
1.测试前期,沟通结果实时共享。
2.测试过程中,以更高的实时性进行沟通,特别是和产品和开发沟通结果会对其他测试人员工作产生影响的情况,有助于团队其他人员的工作,提高团队协作能力。
3.和产品和开发沟通的结果,及时以文档形式记录下来并进行内部沟通。
其实一份测试规范的内容很多,将目录结构列出后,只是一个指引,其中列出了几项需要关注的点,具体的规范,不一定都要依据如此,但是如果能对你有所启发,那就是一份好的规范,会让你省去很多不必要的麻烦,希望可以规范的实践起来,以此达到更高效的工作与配合。
你要尽全力保护你的梦想。那些嘲笑你梦想的人,他们必定会失败,他们想把你变成和他们一样的人。你要坚信,只要心中有梦想,你就会与众不同。
宁可做拼搏的失败者,也不要做安于现状的平凡人!人生就像舞台,不到谢幕永远不会知道自己有多精彩。
每个人的努力程度不同,而不是每个人的命运不同。命运是靠自己去改变的,但是努力程度是靠你自己选择的。所以不用羡慕别人的人生,更应该做的是付出比别人更多的努力!