软件复杂性的膨胀与测试

背景

而今工作已经4年，半年Django经验、2年接口测试， 半年安全测试 ，1年java后台开发。盘点一下我遇到的bug

作为消费者

1. 小米手机开热点，因为智能省电的原因，自动关闭Wi-Fi热点
2. 小米手机蓝牙偶发bug，因为蓝牙耳机距离逐渐远离手机时，蓝牙连接手机停止音乐再继续不播放音乐，只能重连，或者打个电话，切换听筒和蓝牙即可恢复。什么改开发者选项、绝对音量不管用；完全耗完电也无法修复。这个真想不出来是哪里发生的bug，最后解铃还须系铃人，以同样的方式，逐渐远离断开蓝牙而修复
3. 小米手机双系统 同步闹钟，退出另一个系统后闹钟仍然会响；消费者看到自己的闹钟是关闭的，但是不知道是另一个系统中“残留”的闹钟

作为工程师

1. 软件逐渐变得复杂 在修改某个功能时不知道、或者忘记了某个逻辑的存在；比如两个前台模块都使用同一个缓存，做了防止缓存穿透的功能，改了A，忘记改B；不知道曾经存在的同型号产品底层实现完全不同使用了相同的硬件版本；团队A在迁移了某数据后不知道团队B的功能依赖这个数据；修改A不知道 A的变动会产生事件，进而模块B消费了该事件，造成B相关功能错误。
2. 归属于工程师经验、软件发布流程的问题。开源组件使用不正确，不熟悉造成的异常时bug，高TPS时的bug；发布流程中考虑应配置验证、软件兼容性、性能测试等；

软件测试的思考

这里就不讲什么软件测试的具体方法了，什么边界设定，这是单元测试；因为根据我的目前的经验，软件开发根本没有一成不变的理论，都是要根据业务选择、设计、开发合适的流程。也许特定领域下可以用一个软件去描述另一个软件的各种参与者，以用程序辅助系统设计来预防缺陷，我觉得后端就很合适，各种数据都能记录入另一个库，然后画出一张图，拎起一个点就是一张网。
说说我的思考，首先我一开始思考这个问题时没有头绪，从何入手，虽然我对问题很清晰。（有一天夜里想来应该从定义开始）

1. 定义作用
2. 定义作用的铺垫条件（作用生效的正条件）
3. 定义作用的检验
4. 定义作用的约束条件（作用生效的反条件）
5. 定义作用间投射

为什么这里用作用，作用是什么意思？本来一开始我想在这里写功能，但是功能在一个场景上来说太过具体，实践中又太抽象的一个东西。对开发者来说，一个功能，比如写数据库，比如一个函数就是一个功能；对测试来说，一个接口、一个页面、App的一个响应才是一个功能，对产品来说，显示信息就是一个功能；更多时候功能大家是用于产品的。

开发者编写单元测试来保证其代码的正确性
测试者编写集成测试代码、或者运行软件来验证系统功能的正确性
产品体验产品来保证产品的一致性
他们都需要完成以上5个动作来确保软件的最终正确性。

什么是作用间投射，理论上，当两个、多个作用的铺垫条件、约束条件没有冲突时，他们都应该正确工作，在A生效的前提下，B是否生效等；所有最终软件进行的是各层内的无休止地投射测试。并且一般情况下，模块开发–集成测试开发–产品端的作用相关语义的定义 是由下自上进而实现组合。
这就产生许多未定义条件的组合