入职新公司第一次分享

上一篇 / 下一篇  2018-11-16 11:35:53

  新公司每周都有分享会,本周轮到我,工作很多年,仍然处于社会主义中级阶段,上升高阶有待提升,如果想在测试的道路上继续走下去,还需要多多深入了解,多多加油
  将我分享的内容,想在这里标记一下,可以供新人或者和我一样的人参考
  从bug的来源,bug的等级以及测试常见的风险等

一;bug点来源
1.“Bug”的创始人赫柏的报告格蕾丝·赫柏(Grace Murray Hopper),是一位为美国海军工作的电脑专家,也是最早将人类语言融入到电脑程序的人之一。而代表电脑程序出错的“bug” 这名字,
正是由赫柏所取的。1945年的一天,赫柏对Harvard Mark II设置好17000个继电器进行编程后,她的工作却毁于一只飞进电脑造成短路的飞蛾。在报告中,赫柏用胶条贴上飞蛾,并把“bug”
来表示“一个在电脑程序里的错误”,“Bug”这个说法一直沿用到今天。
2.Bug一词的原意是“臭虫”或“虫子”
3.与Bug相对应,人们将发现Bug并加以纠正的过程叫做“Debug”,意即“捉虫子”或“杀虫子”。遗憾的是,在中文里面,至今仍没有与“Bug”准确对应的词汇,于是只能直接引用“Bug”一词。
虽然也有人使用“臭虫”一词替代“Bug”,但容易产生歧义,所以推广不开。
二:
缺陷的等级(分类)
软件缺陷的等级可以用严重性和优先级来描述;
严重性:衡量缺陷对客户满意度影响的满意程度,分为
1,致命错误,可能导致本模块以及其他相关的模块异常,死机等问题;         (eg:事故级别的)  
2.严重错误,问题局限在本模块,导致模块功能失常或异常退出;           
3.一般错误,模块功能部分失效;                                   
4.建议模块,测试人员对有问题的模块提出改进建议(UI级别的/用户体验的等)
优先级:缺陷被修复的紧急程度;
1.立即解决(P1级):缺陷导致系统功能几乎不能使用或者测试不能继续(冒烟测试不通过),需立即修复;   
2.高优先级(P2级):缺陷严重,影响测试,需优先考虑;
3.正常排队(P3级):缺陷需要正常排队等待修复;
4.低优先级(P4级):缺陷可以在有时间的时候被纠正;
备注:分享过程中有开发提到对P1:测试不能继续有疑问,特此解释,测试不能通过,就是冒烟测试不通过,那么后面的测试就无法进行,所以级别为P1。
三:软件测试工程师的职责
就是主动地发现,暴露产品存在的风险和缺陷,并协同团队成员,一起解决风险并做好容灾解决方案。
备注:做好容灾解决方案,暂时还无法达标,正式一般大一些的公司都会有预发布和灾备系统,上线后有问题,就做回滚操作
四:软件测试常见风险
1.需求风险(产品的需求不明确,对产品需求理解不准确或者不到位,导致测试范围存在误差,测试的过程中可能就会漏掉部分需求等)
2.测试用例的风险 (测试用例或者测试点设计等不完整,忽略了边界条件,异常输入等情况,需求覆盖不全,有些case就会有意或者无意等被漏测)
3.缺陷风险(某些缺陷偶发,难以重现,容易被遗漏;缺陷跟踪不够积极主动,没做好缺陷记录和及时更新,同样的缺陷,导致的原因可能不同,对这点没意识到导致的线上生产问题等)
4.代码质量风险(代码可读性差,重构性差,没做好注释等原因导致缺陷较多,修改难度增大;另外还有系统架构设计的不足,导致的扩展性不足,性能兼容差等问题)
5.测试环境风险(测试环境和生产环境配置不同,测试环境交叉影响较大,测试环境数据量不足导致的测试结果误差等问题)
6.测试技术风险(技术水平相对较差导致测试进展缓慢,测试结果准确性不够,项目发布日期延期等问题)
7.回归测试风险(介于之前回归测试时间不够,我们对测试时间和回归时间节点进行调整,避免由于时间问题,回归测试不全面导致漏测问题)
8.沟通协调风险(关于需求:之前和产品沟通的较少;关于缺陷沟通:不需要单独沟通,有问题群里沟通,提高效率;需求变更沟通不及时;测试结果的反馈不及时等问题。)
9.研发流程风险(其中包括从产品需求评审、研发设计、代码提交、测试发布等一些列流程,流程的不规范不协调很可能导致很多问题;比如开发在不告知其他成员的情况下提交代码,发布没有预生产环境,生产出现
问题无法及时回滚等很多说烂了的情况。流程没必要一板一眼的执行,但没有流程是万万不行的)
10.其它不可预计风险
(一些突发状况、不可抗力等也构成风险因素,且难以预估和避免。对于这种情况,往往一时无法解决,建议做好备份方案和容灾机制,或者采用灰度发布等措施。)
PS:以上是测试过程中可能发生的风险及原因,其中有的风险是难以避免的,如缺陷风险;有的风险从理论上可以避免,如需求风险,沟通风险等;还有些风险在实际操作过程中出于时间和成本的考虑,也难以完全回避,如回归测试风险等。
对于这些风险的存在,要尽量避免,也要做好备份方案和容灾机制,规范流程,明确职责,尽可能将风险降到可接受范围内。
五:测试过程中考虑开发修复缺陷的时间,测试验证问题的时间。(新公司入职不久,还不适应之前的发布时间,导致上次发布的时候线上出现不该出现的bug,分享会中提出来,大家公知,特此提醒同行小伙伴有问题就要大胆的提出来,以免上线后出现问题,谁来背锅这个问题)
六:关于发布时间:有的公司做的是海外项目的话,发布时间就要把控好,避免出现用户不可用等操作

暂时就以上几点,下次分享再来写文章
                                分享日期:2018-11-15



TAG:

sz140王浩的个人空间 引用 删除 sz140王浩   /   2018-11-19 23:28:34
3
blum的个人空间 引用 删除 blum   /   2018-11-16 15:38:47
 

评分:0

我来说两句

Open Toolbar