一.概述：

作为一名软件测试人员，保障软件质量乃为天命。从测试的角度来谈谈个人对软件质量的理解。如何来保障软件达到较高质量交付！

二.目的：

1.总结软件测试理论知识，阐述踩过的坑

2.供别人参考借鉴

3.与大家一起探讨如何来提升软件质量

三.基础概念：

1.软件生命周期

定义：软件从产生到报废的生命周期

生命周期包括：项目规划、项目启动的、需求分析、软件设计、软件编码、软件测试(单元测试、集成测试、系统测试、验收测试)、系统上线和维护

2.软件测试的基本流程

测试流程：需求分析、编写测试计划、编写测试用例、评审测试用例、执行测试、提交bug、回归测试、编写测试总结报告

3.软件测试的目的

测试的目的是以最少人力、物力和时间找出软件中潜在各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

4.软件质量应该从哪些方面来评价

功能、易用性、外观、性能、可靠性、稳定性、安全性

5.测试结束的标准是什么

用例全部执行、覆盖率达到标准、缺陷率达到标准、其他指标达到质量标准

四.软件质量影响因素：

1.软件需求模糊以及软件需求的变更从根本上影响着软件产品的质量

软件是可视性很差的复杂的逻辑实体，不同于任何其他制造业的产品。使得软件质量难以把握的一个因素是软件需求。确定需求，在软件开发的初期阶段让它真正反映用户的意图是一件非常重要的工作，它既是后继阶段开发的基础，又是软件开发完成后验收的依据，而且还是工期和开发成本估计的出发点。

2.软件质量管理的实际困难

软件质量指标许多尚未量化。软件开发的管理人员往往更关心项目开发的成本和进度，因为成本和进度是显而易见的，并且易于度量，而软件质量则完全不同。

目前许多软件机构的产品质量责任尚未落实到人。如果软件开发的管理人员对于交付的软件含有多少错误并不负什么责任，那么他们必定没有多高的热情去控制开发的质量，更不必说保证质量并不容易，且保证质量是昂贵的。

3.项目流程不规范

开发流程：开发人员是否理解需求，是否完全依据需求来进行开发？

提测流程：开发人员开发完成后，是否进行了自测，是否达到提测要求？

测试流程：介入测试前，是否制定了测试计划，是否对测试用例进行评审，是 否制订测试开始/结束标准？

五.流程规范：

规范的测试流程有助于需求条理化，将测试工作模块化，一切跟着计划走比通过脑袋记忆要更加的有条理。有的时候，工作任务比较繁琐，脑袋记忆力容易出现乱成一锅粥的情况，特别这个时候，测试计划就更加重要。

作为测试人员，在需求评审过程中就要对比原始需求和需求基线的不同，给予自己的意见。在测试过程中不时提醒自己，对需求的理解是否深刻，要深入到用户实际的工作场景，了解实际业务和流程。而对于自己无法准确把握的，用户又无法准确提供的需求就要定好界限，实现到什么程度。好用的软件不仅是功能的实现，界面的友好体验同样重要。

1.一定要制定测试计划或测试工作表

大概了解需求内容之后，要对整个测试进行预期估算，制定测试计划和工作表，包括计划要测试哪些方面的功能，要计划分配哪些人员参与到测试中，哪些人负责哪个模块，以及按照交叉测试的方法，同时还要计划要测试的开始和结束时间，便于掌控这个测试进展等等。另外根据测试人员执行测试的情况，填入测试计划中可以直观的反馈测试人员的一些情况，是否延迟，新增测试用例数，发现bug数等。

2.需求分析，发挥主动性

在需求评审的时候，作为一个测试人员必须了解这次需求的内容，主动评估本次需求的用户体验和实现方式是否合理，如果有疑义及时提出，找产品进行及时沟通，确定结果。在开发阶段开始之前，修改需求代价最小，争取达成测试开发产品三方意见一致。需求评审结束后，要求产品更新此次评审过程中的所有改动部分，同时给出方案确保产品的任何改动都及时更新。因为测试依赖于产品输出的需求文档编写测试用例。

3.用例设计与评审，做到不遗不漏

测试用例是每个测试人员工作过程中必须要完成的工作，在测试工作中一是用来指导测试工作，二是相关业务的一个文档沉淀。

设计用例的时候要设计两类， 一类是开发自测和验收提测标准的冒烟测试用例，一类是针对需求的全面测试用例。写完用例要主动联系相关人员进行用例评审，强调开发自测，在评审过程是及时修改不合适的用例。

4.强调开发自测的重要性

开发没有自测，到测试这边一堆问题，问题一多，测试就容易乱了，很容易遗漏问题。另外就是开发没有自测过的，容易造成反复测试及版本多等现象，那测试人员就会被占用了。那组内测试计划就很不好安排。

5.关注项目进度

必须有关注整体项目的意识。如果你不关注项目进度，什么时候提测你什么时候开始测试，在测试过程中你就会遇到测试的内容和最初的需求不一致，增加新的内容从而增加工作量，或是产品和开发一起来压缩测试时间的情况。

关注排期的必要性：很多时候项目进度是由产品经理或者项目经理把控，但测试人员身为一线工作人员，必须要对整体项目进度保持关注，做到心中有数。需求变更、开发遇到困难导致延期等情况比较常见。需求变更可能会导致开发人员需要重新实现，交付时间延后，也可能导致测试方案需要重新设计，或者测试工作量增多;开发遇到困难导致延期，可能会导致交付时间延后，也可能因为部分功能在实现时比预期要复杂很多，需要重点测试，测试工作量增多。若不关注这些情况的话，很可能会导致实际测试内容和最初需求不符，测试时间被压缩，以至于测试不充分、项目意外延期、测试严重加班等情况。

6.Bug提交要描述清楚

说到这个简直是一把辛酸泪啊。跟熟悉你的开发一起，随便说几句他都懂，但是新来的你必须跟他讲清楚这个页面叫什么，那个页面叫什么，而且每一个步骤都要描述清楚，要改动的地方要标注清楚，不然他就按照他自己的意思改了，甚至不知道你在讲哪里的问题。所以，bug描述清楚很重要，可以节省沟通成本，不用那么劳心劳力。

7.要督促程序员改bug

为什么说到这个呢?这个真的是大多数开发的通病啊，如果测试的不督促，有些bug就一直放那里发霉发臭了的。甚至如果你只是口头跟他讲，虽然他应了，但是转眼他就忘了。所以说一定要把每个bug都记录下来，跟踪修改进度。

8.做好文档的管理和分类

测试文档多，且项目一多，文档更是多得不行，测试服务器上的文档管理分类也至关重要。做好测试文档的管理和分类，能让平常的工作便捷很多。建议文档的命名，对当前项目或任务有意义，做到见名知意。

文档编写不能太粗糙，需要尽可能详细。一是自己在写的过程中，能发现更细微的问题;二是就算交接给别人，别人也能快速准确的上手。

9.发布版本的时候，一定要再三检验版本是否正确。

六.测试原则：

1.明确开发需求任务，争取达成测试、开发、产品三方意见一致，必要时需要和客户反复确认

2.测试要尽早开始，越早发现，修复成本越低

3.制作有效的测试计划，要有用例设计，并按照计划执行,不能随意的开展

4.Bug的跟踪，要有自己的主见、原则

5.测试结果的把握，要有结果分析。项目的上线，要综合你的测试过程，结合目前的情况总结报告，甚至是项目经理也要听取你的意见。你的角色不仅是测试，也是质量保证。

七.对其他部门提出合理要求：

一个产品的诞生，需要整个团队的共同努力，因为我们的目的是一致的，就是将产品做到更好。为了提高产品质量，对于团队中其他岗位人员应提出些合理的要求：

1.对产品组的要求

1.需求文档及设计文档要完整、细致，保持三方的文档同步

2.需求的更改必须群里或者邮件方式通知三方，严禁口头协定

2.对研发组的要求

1.代码和功能模块需要自测

八.题外话：

1.测试人员需要有主见

测试人员在开发过程中处于弱势地位，这是一个不可回避的现象，有些开发人员可以随意的让测试人员做自己认为需要的测试，而测试人员是没有办法拒绝的，甚至连具体测试的方法和手段开发人员都要干涉，而一旦出问题，首先怪罪测试人员，而不是找自己的责任，测试人员成了项目失败的替罪羊。

开发人员和测试人员在测试过程中交流过多，在测试过程中由于相关文档不全或者质量问题，测试人员经常需要开发人员进行交流，这种交流是必要的，但也容易产生问题，比如测试在发现一个问题的时候，开发人员总会用这样或那样的借口告诉开发人员这不是问题，不用写在问题报告里，结果很多问题即使被测试出来也被这种糟糕的交流给掩盖起来了。

测试工作要保持自己的独立性，发现的问题是否是BUG，是测试人员来决定，测试人员判断是否是问题的标准就是测试结果和测试预期结果是否相同，只要不相同，就算问题。其他人员无权对这个原则提出异议。

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。