软件工程学习笔记11——软件测试篇

一、谁该为产品质量负责

软件开发是多个环节组成的，从最开始的需求，到后面的设计、开发，每个环节都可能会导致质量问题。

1、什么是软件产品质量

功能质量、代码质量和过程质量这三个方面组合在一起，很好地概括了软件质量。

功能质量
满足用户需求，是对功能质量最基础的要求。在这个基础上，Bug 数量、性能、UI/UX 都是很重要的质量指标。

代码质量
虽然用户不能直接感知到代码，但是代码质量高低会直接影响功能质量，同时代码质量低也会影响后续的维护升级。代码质量指的是实现软件功能的架构和代码的质量。

代码的质量主要体现在以下这些方面：可维护性、可读性、执行效率、安全性、可测试性。

过程质量
过程质量虽然也是用户不能直接感知的，但是过程质量会直接影响代码质量和功能质量，甚至是产品的成败。

2、谁该为产品质量负责

既然产品质量是由功能质量、代码质量和过程质量共同决定的，那么对产品质量负责，意味着要对这三方面共同负责。

在说到责任之前，先补充一下权责对等的问题。责任和权力是需要对等的，比如说你让开发人员对软件开发过程负责，那么前提是他必须有权力去影响和控制开发过程。

• 软件测试，可以对功能质量负责，对软件产品进行测试验收，以确保产品满足功能需求，有好的功能质量。但是通常不能对代码质量和过程质量负责。
• 开发人员，可以对代码质量负责，也可以写测试代码，通过自动化的方式做功能测试，虽然还不能完全替代手工测试的作用，所以也可以算得上对功能质量负责。但开发人员通常对过程质量影响有限。
• 项目负责人，可以对过程质量负责，而且过程质量的水平高低，会间接影响代码质量和功能质量。但因为项目负责人不直接编码和测试，所以无法直接影响代码质量和功能质量。

所以综上，我觉得如果要排序的话，软件质量的首要负责人是项目负责人，其次是开发人员，然后才是软件测试。

虽然从权责的角度看，项目负责人是最应该对项目质量负责的，但是从效果来说，却是开发人员对项目质量负责最有利。

3、如何做到“人人为产品质量负责”

只有真正在团队中建立了一种重视产品质量的文化，每个人才会确确实实地对质量负责。那么有哪些方法可以帮助团队建立这种“人人都重视产品质量”的文化呢？

• 可以参考敏捷开发中的扁平化管理。
• 可以选择将团队拆小。
• 也可以鼓励工种之间的融合。这样不只是局限于各自负责的质量领域，也同时关注其他质量领域。
• 制定相应的制度，鼓励大家重视质量。

二、专职测试

从这些年业界发展趋势来看，看起来很多公司都不需要专职测试了，只需要开发兼任测试工作就可以了。但这样真的可行吗？

1、软件测试的主要工作

如果对软件测试的工作简单总结一下，就是发现 Bug，报告 Bug，跟踪 Bug。
从测试的角度看，没有必要每一个可能都去测试，可以通过一些科学的方法来通过有限的测试用例，保证尽可能多的测试覆盖。比如：

• 等价类划分。就是把所有用户可能输入的数据分类，如果一类数据对于发现 Bug 的效果是一样的，那么这类数据就是一个等价类，测试的时候只要从里面任意选取一个值就好了。
• 边界值分析。边界值是对等价类的补充，因为输入输出的边界是非常容易出错的一个地方。
• 探索性测试。探索性测试就是根据前面的测试结果，通过有效的策略进行测试。

软件测试怎么报告 Bug
在测试的过程中，如果测试人员发现了 Bug，就会通过 Bug 跟踪系统提交 Bug 给开发人员。测试人员要做的就是创建一个新的 Ticket。

软件测试怎么跟踪 Bug
开发人员修复完一个 Bug 后，测试人员首先会验证这个 Bug 是不是真的被修复了，然后还要对整体功能做一个回归测试，确保不会因为修复 Bug 而引起其他功能出现问题。

回归测试是指修改了旧代码后重新进行测试，以确认修改没有引入新的错误或导致其他代码产生错误。

2、为什么有些公司可以没有专职测试

完全由开发人员兼职测试，还是很有难度的，不仅对开发人员要求非常高，而且需要开发人员承担所有的开发和测试的压力。

为什么有些公司可以没有专职测试：

• 大量优秀的工程师，可以同时兼任开发和测试；
• 有大量的自动化测试代码覆盖；
• 强大的发布和监控系统；
• 时间进度比较宽松；
• 用户对 Bug 容忍度较高。
• 对于不能满足上面条件的公司，有专职的测试是更有利于软件项目开发和质量保障的。

大厂不设专职测试的启示

• 用自动化测试代替重复性的手工测试是必然趋势。
• 测试设计是软件测试人员的核心竞争力。
• 开发人员和测试人员的更多融合是一种双赢。

三、Bug 跟踪工具

测试人员发现 Bug 只是第一步，还需要报告 Bug 让开发人员可以知晓和定位，并且跟踪整个 Bug 修复的过程。

Bug 跟踪工具，采用结构化的数据来定义 Bug，每一个 Bug 都有一些关键的信息可以对 Bug 进行分类和检索。

在 Bug 跟踪工具使用中，一个基本的 Bug 信息包括：

• 标题；
• 描述（包括期望结果、实际结果和重现步骤等关键信息）；
• 优先级；
• 指派人；
• 状态（New、Open、 Rejected、Fixed 等）；
• 其他。

这样对于开发人员来说，可以直观的看到自己有哪些 Bug 需要处理，Bug 的描述信息也可以帮助重现 Bug、快速定位到 Bug 的原因；对于项目经理或者测试人员来说，可以直观的看到哪些 Bug 还没解决，及时了解项目进展。

在软件项目中，要把好的实践流程化，把好的流程工具化。Bug 跟踪工具则很好的贯彻了这一点，将 Bug 的解决过程流程化。

通过这样的流程，开发人员就可以集中对 Bug 进行分配、按照优先级分别解决，而测试人员则可以第一时间知道 Bug 处理的状态变化，及时验证，方便跟踪整个过程。

使用 Bug 跟踪工具的注意事项

• 所有的 Bug 都应该通过 Bug 跟踪系统管理和跟踪，不应该再通过 QQ/ 微信 / 邮件的方式跟踪 Bug。
• 不能把多条 Bug 合并成一条，一个 Bug 创建一个独立的 Ticket。
• 描述清楚如何重现 Bug 非常重要。
• 不要把 Bug 跟踪系统当成讨论板用。

自动化测试工具
未来自动化测试会占据越来越多的比例，很多手工测试的工作会逐步被自动化测试代替。

除了 Bug 跟踪工具和自动化测试工具，软件测试中还有性能测试工具、安全性测试工具、兼容性测试工具等，这些工具都可以更好的帮我们发现软件中的质量问题。

四、软件开发中的安全问题

1、安全问题本质是技术风险

安全问题，本质上也是一种技术风险，没发生问题的时候一切都好，一旦发生就会有严重的影响。

在对安全问题的应对上，你也可以借鉴对风险管理的方法来改进软件的安全问题，也就是风险识别、风险量化、应对计划和风险监控。

软件中的安全问题来源主要可以分为以下三大类：

第一类：恶意输入
很多我们熟知的软件安全问题都属于此类型，就是黑客通过恶意输入，然后绕过软件限制对系统进行攻击和破坏。像 SQL 注入、 XSS 攻击等。

第二类：假冒身份
很多程序对于用户身份的校验比较弱，可能会导致黑客假冒用户身份做出超越权限的事情。

如果对用户的身份不做严格的验证，很可能就会导致假冒身份的安全问题。应对策略就是要对用户的身份做验证，尤其是涉及敏感权限的操作，甚至要做两重验证。

第三类：数据泄露
对于软件来说， 我们不能假设数据存储是安全的，而是要考虑到数据是有泄漏的可能，提前做好预防措施，对敏感数据进行加密。

2、如何预防软件中的安全问题

在整个生命周期中都做到重视安全问题，各个阶段都考虑到安全方面的问题，才能真正做到防患于未然，构建出安全的软件。

那么在软件开发的各个阶段，都需要如何考虑好安全方面的问题呢？

需求阶段

在确定需求，做产品设计的时候，不仅要考虑到功能上的需求，还要同时考虑到安全方面的要求。这样当你在架构设计的时候，就不会轻易遗漏安全方面的架构设计。

设计阶段

在做设计架构时，最重要的事就是要把安全加入到设计目标，有了安全方面的设计目标，自然能找到很多安全相关的解决方案。

现在架构设计领域，也有了一些业界公认的好的安全相关的设计原则，比如说攻击面最小化、权限最小化、纵深防御等。

• 攻击面最小化
  攻击面就是指程序被用户直接访问到的部分，比如 API、网站等，这些暴露给用户的地方也是最可能被黑客攻击的地方。
  暴露的面越多则风险越高，攻击面最小化的设计原则，就是说尽量减少暴露黑客可能发现并试图利用的攻击面数量。
• 权限最小化
  权限最小化的设计原则就是对于系统的用户、文件访问、进程运行等，都只给予其能拥有的最小权限，这样可以保证一个应用程序或者网站被攻击、破解，能将损害降到最低。
• 纵深防御
  纵深防御的设计原则，指的是从不同的维度去实施安全保护措施，从而缓解被攻击的风险。纵深防御并不是同一个安全方案要做两遍或多遍，而是要从不同的层面、不同的角度对系统做出整体的解决方案。

开发阶段

对于开发阶段的安全问题预防，需要从以下几个方面入手:

• 编码规范中加入安全相关内容
• 要有代码审查
• 增加安全相关的自动化测试

测试阶段

在测试阶段，除了功能测试以外，增加对安全性方面的测试。除了增加相应的测试用例，也可以借助一些安全测试工具来进行测试。

上线维护

上线部署时，不部署源代码，只对编译后程序部署；删除 Debug 文件。

3、如果真的出现安全问题怎么办

安全问题就像程序的 Bug 一样，没有谁能保证绝对的安全，就像风险管理的最后一步风险监控那样，我们必须做好 Plan B，万一出现安全问题，马上应对，将损失降到最低。

• 要设立应急的流程。
• 要分析程序的漏洞在哪里。
• 要总结原因。