软件测试新人入职新公司第一次分享

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

一、bug点来源

“Bug”的创始人赫柏的报告格蕾丝·赫柏（Grace Murray Hopper），是一位为美国海军工作的电脑专家，也是最早将人类语言融入到电脑程序的人之一。而代表电脑程序出错的“bug” 这名字，
正是由赫柏所取的。1945年的一天，赫柏对Harvard Mark II设置好17000个继电器进行编程后，她的工作却毁于一只飞进电脑造成短路的飞蛾。在报告中，赫柏用胶条贴上飞蛾，并把“bug”
来表示“一个在电脑程序里的错误”，“Bug”这个说法一直沿用到今天。
Bug一词的原意是“臭虫”或“虫子”
与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:以上是测试过程中可能发生的风险及原因，其中有的风险是难以避免的，如缺陷风险；有的风险从理论上可以避免，如需求风险，沟通风险等；还有些风险在实际操作过程中出于时间和成本的考虑，也难以完全回避，如回归测试风险等。
对于这些风险的存在，要尽量避免，也要做好备份方案和容灾机制，规范流程，明确职责，尽可能将风险降到可接受范围内。