探索式软件测试读书笔记--软件状态

      叠加着的软件状态。如测试一直在进行,软件会记录状态,大多数会累积或叠加。这里有一个系统崩溃例子:在我早期从事测试工作的时候，其中一个项目中有这样一个功能：可以查找每天每个资产的维护信息。问题是这样的，当查询次数超过一定次数的时候，系统直接崩溃。软件内部使用的是数据库连接池技术，可允许的连接数是固定的，每次查询就会开一个连接，但是查询完毕没有关闭；另外当连接数到达允许最大连接的时候，软件内部也没有异常处理代码。所以当查询次数累积超过最大连接数的时候导致系统直接崩溃（当时还有点小成就的感觉）。这是一个典型的软件状态叠加例子，也正是我写本文的目的（有些共鸣）。当时虽然知道了这个bug产生的原因，当时也没有看《探索式软件测试》，更没有深入再去分析。另外还有一些例如内存泄露，out of memory等问题也都是软件状态累积的后果。有些状态叠加往往要软件运行一段甚至很长时间才能显现出来，功能测试手段要测试出来这些问题往往力不从心，这就要借助其他测试手段或者工具：像性能测试中几十小时的稳定性测试容易暴露一些状态问题: 如内存泄露。

       软件状态＝＝输出。针对不同的系统，软件状态也是千差万别。软件状态也是软件的一种输出，这里引出书中另外一个重要的观点：输出指导输入（这个观点可能有点偏离本文主题，还是忍不住顺便提下了），这个也是非常值得去研究、实践。举一个非常有借鉴的例子(虽然是有关硬件产品的问题,但大同小异)，相信大家最近如果关注新闻或者使用苹果的最新产品都知道：iPhone6可以徒手掰弯或在一定的使用环境下变弯。苹果公司世界闻名，技术没的说，但是这次新品的发布带有这个缺陷不得不说还是有不小的遗憾。不过也再次强调了测试无尽头,测试的重要性!再次引用书中一句话"把输入和输出配对是最常用的一种手段,它可以保证所有有趣的场景都被测试到"。另外再次感慨下跟国外技术的差距或者自己技术的浅薄,还有国内有不少功能测试无用论、没前途论的声音,感觉那是没有深入的去做产品、做测试(top前几名或者自己没接触过的的有些公司做的不错,除外)。还等什么呢少年,赶紧拿起书研究、实践吧(开句玩笑,另外有给这本书做广告的嫌疑。不过,毋庸置疑,这确实是本好书!)。

       关注软件状态，挖掘软件内部更深入的问题。软件状态涉及到的问题,大多数都是程序内部问题,有些甚至是非常严重的问题。作为测试从业者, 如果要更深入的去测试软件，学习了解软件开发的知识是必不可少的，多了解软件内部逻辑结构，在测试过程中设计有关测试软件状态的用例，并时刻关注软件状态。

以上内容如有错误或问题请指出，也欢迎大家讨论，谢谢！