概率性的bug比较恼人(软件质量不是一句废话)
2014-07-25 23:57
330 查看
在软件开发中, 必现的bug比较好定位修改, 但是概率性的bug有时就很难搞定了。
测试组的MM提出一个概率低于1%左右的bug
, 真不知道她们是怎么确定的。 要解决, 咋办? 首先, 要定位, 因此至少要重复100次左右的操作, 假设运气好, 复现了, 那好, 看日志。 晕, 竟然没有记录的日志。 所以只能加日志, 重新编译, 把新版本刷进去, 继续重现。 又要搞100次左右。 假设运气好,
重现了。 好, 分析日志, 假设运气好, 日志中刚好有记录信息。 现在你要分析日志啊, 要定位啊, 要修改啊。 修改后,重新编译, 再把版本刷进去。 可别高兴太早, 还要进行改后的测试呢, 至少要重复100次吧, 到100次后, 发现没有出现问题。 这个时候, 你仍无法判断是原来那个bug没有出现, 还是修改后才没有出现的。 所以要继续测试100次左右。 假设运气好, 还没有出现, 这个时候, 你仍然不能肯定自己修改好了。 没办法, 只能提交修改单。
然后测试的MM继续测试, 假设运气好, 那个问题确实修改好了, 那还算ok, 假设测试MM测试的时候又重现了, 把你叫过去, 你能咋办? 哭吧
!
软件开发的成本就类似于这样。 一般而言, 概率性的bug多数是由于程序猿考虑不周全造成的, 所以严密的逻辑思维和良好的程序风格是多么重要啊。
下面来看一个例子:
上程序中, 模拟客户端给服务端发送消息, 服务端校验了消息头的长度。 容易知道, 上述程序可能会出概率性bug, 改为如下比较好:
不多说。
现在这个年代, 手机不常关机的人很多, 假设一个手机连续运行一个星期后, 会死机一次, 作为用户, 你肯定会抱怨。 作为开发人员, 遇到这种问题,要定位分析并修改并自测试, 也是相当头疼的事情。 所以软件质量, 真的不是一句废话。
习惯会改变人的一生。 你要好的, 还是坏的, 习惯?
测试组的MM提出一个概率低于1%左右的bug
, 真不知道她们是怎么确定的。 要解决, 咋办? 首先, 要定位, 因此至少要重复100次左右的操作, 假设运气好, 复现了, 那好, 看日志。 晕, 竟然没有记录的日志。 所以只能加日志, 重新编译, 把新版本刷进去, 继续重现。 又要搞100次左右。 假设运气好,
重现了。 好, 分析日志, 假设运气好, 日志中刚好有记录信息。 现在你要分析日志啊, 要定位啊, 要修改啊。 修改后,重新编译, 再把版本刷进去。 可别高兴太早, 还要进行改后的测试呢, 至少要重复100次吧, 到100次后, 发现没有出现问题。 这个时候, 你仍无法判断是原来那个bug没有出现, 还是修改后才没有出现的。 所以要继续测试100次左右。 假设运气好, 还没有出现, 这个时候, 你仍然不能肯定自己修改好了。 没办法, 只能提交修改单。
然后测试的MM继续测试, 假设运气好, 那个问题确实修改好了, 那还算ok, 假设测试MM测试的时候又重现了, 把你叫过去, 你能咋办? 哭吧
!
软件开发的成本就类似于这样。 一般而言, 概率性的bug多数是由于程序猿考虑不周全造成的, 所以严密的逻辑思维和良好的程序风格是多么重要啊。
下面来看一个例子:
#include <iostream> #include <ctime> #define MAX_CHAR_VALUE 127 #define MAX_MSG_LEN 100 #define LEN 24 using namespace std; int main() { // 客户端 unsigned char head[LEN + 1] = {0}; int i = 0; srand(time(NULL)); for(i = 0; i < LEN; i++) { int randNum = rand(); head[i] = randNum % (MAX_CHAR_VALUE + 1); } char message[MAX_MSG_LEN + 1] = {0}; _snprintf(message, sizeof(message) - 1, "%s%s", head, "xxx"); // 服务端会对head长度进行校验 return 0; }
上程序中, 模拟客户端给服务端发送消息, 服务端校验了消息头的长度。 容易知道, 上述程序可能会出概率性bug, 改为如下比较好:
#include <iostream> #include <ctime> #define MAX_CHAR_VALUE 127 #define MAX_MSG_LEN 100 #define LEN 24 using namespace std; int main() { // 客户端 unsigned char head[LEN + 1] = {0}; int i = 0; srand(time(NULL)); for(i = 0; i < LEN; i++) { int randNum = rand(); head[i] = randNum % (MAX_CHAR_VALUE + 1); if(0 == head[i]) { head[i]++; } } char message[MAX_MSG_LEN + 1] = {0}; _snprintf(message, sizeof(message) - 1, "%s%s", head, "reset"); // 服务端会对head长度进行校验 return 0; }
不多说。
现在这个年代, 手机不常关机的人很多, 假设一个手机连续运行一个星期后, 会死机一次, 作为用户, 你肯定会抱怨。 作为开发人员, 遇到这种问题,要定位分析并修改并自测试, 也是相当头疼的事情。 所以软件质量, 真的不是一句废话。
习惯会改变人的一生。 你要好的, 还是坏的, 习惯?
相关文章推荐
- 软件质量,CMM不是惟一
- (ZT)几个BUG追踪管理软件 bugzilla,bugfree,mantis 比较
- 软件企业ISO9000质量体系与CMM的比较分析
- 软件企业ISO9000质量体系与CMM的比较分析
- 软件质量BUG等级定义
- 软件测试是找BUG,不是找茬
- 软件质量重心应该在设计开发上,而不是测试上
- 搁置比较久了,这段突然发现拿出来当上网本本很不错,躲床上玩,以前用2K,因软件需要用XP,装了XP后,发现XP默认的驱动不对,会导致蓝屏,网上找半天也找不到合适的驱动,不是不能用就是装上蓝屏,用驱动精
- 软件质量,CMM不是惟一
- 软件企业ISO9000质量体系与CMM的比较分析
- 软件测试是找bug,不是找茬【转载】
- 软件测试是找bug,不是找茬
- 基于ISO9000、CMMI、六西格玛软件质量度量及其保证的分析与比较
- 中美两国软件开发管理的比较与启示
- 关于软件质量和软件测试的一点点看法
- 软件测试的重要环节:Bug管理流程
- 中外ERP厂商及软件比较
- 软件版本比较不用ini记录的另一种方法
- 提高小团队软件质量的一点想法
- 语言转换软件都是不可靠,甚至可能造成大的bug