软件可靠性（Software Reliability）可以定义为：在规定环境，规定时间内（自然单元或时间单元），一个系统或其功能无故障运行的可能性。
    其中：
 规定的环境包括硬件环境和软件环境。软件环境包括允许的操作系统、应用程序、编译系统、数据库系统等；硬件环境包括CPU、内存、I/O等。
 规定的时间一般分为执行时间、日历时间和时钟时间。其中执行时间（Executing Time）是指执行一个程序所用的实际时间和中央处理器时间，或者是程序处于执行过程中的一段时间；日历时间（Calendar time）指的是编年时间，包括计算机可能未运行的时间；时钟时间（Clock time）是指从程序执行开始到程序执行完毕所经历的钟表时间。
 自然单元除时间外，跟软件产品处理数目相关的单元如运行、电话呼叫、API调用等都可以看作是一个自然单元。

[ Last edited by 天网 on 2004-9-18 at 11:19 ]

我想对于软件可靠性的度量来说，对于软件可靠性模型的使用来说，软件测试的时间单位很重要。正如您说的有日历时间、执行时间、CPU时间，事实上，实际的执行时间对我们来说才是最重要的，如果有了精确的执行时间，那么另外两个就完全可以不要。关键问题是，我们没有办法很精确的指导我们的软件到底实际执行了多少时间。我们只好用我们的日历时间或者说处理器时间来近似，现在的问题就是如何去近似，我们该怎样根据具体的环境做这个转换工作。

   请教版主，您在实际实践当中是怎么做的，这个时间的转换有什么方法和算法，希望交流！

首先需要了解用户是如何使用软件系统的，即用户的使用模式，其中最主要的是需要得到用户使用各功能的概率，这样层层分析来得到软件系统的可操作概图，这是定量分析用户如何使用一个系统的框图，其中可能有很多东西需要测试和用户去沟通、或者进行假设；

接下来要根据上面的可操作概图（里面包含了用户使用软件功能和各操作的概率），设计可靠性测试用例，用例中要根据各功能和操作出现的概率，模拟用户使用软件系统的各功能。例如用户一年只使用某操作300次，那么在用例中该操作被执行了300次，就可以模拟系统一年的运行时间。当然其中还要结合其他的操作被执行的概率一起进行组合。这样各种不同的组合考虑就可以得到不同的用例；

最后需要借助自动化测试工具来执行前面设计的用例，得到模拟时间内的故障率，得到可靠性指标。

这个只是根据我做过的一点可靠性测试的尝试来讲讲我的做法，希望对你有所借鉴。每个人面对的测试对象是不一样的，可靠性理论只能提供理论依据和思考的方式，具体情况还需要根据实际情况去分析。

[ Last edited by 天网 on 2004-9-18 at 11:53 ]

我再说几句：
  1  你没有正面回答我的执行时间、日历时间和CPU时间的转换问题；
  2  事实上操作剖面很难开发，也很难完整的反映具体的运行剖面。当然，这种想法是可行的，但是不知道到具体的实践当中是否容易实施，您都遇到过什么样的困难？

   在怎样获得这个更精确的是将方面，我很困惑，就像给我一堆别人的没有注释的代码让我分析一样，我手足无措！

1、可靠性的度量时间不一定非要用执行时间。当然如果做研究，是需要精确，但做软件是一项工程，它的度量是允许一定的误差的。我不否认用执行时间来度量更加精确，但这需要你的被测对象支持进行这样的度量，并且我认为到了系统级的测试后，进行这样精确的度量不一定会有很好的效果；

2、操作概图不难开发，同样需要根据被测对象的分析结果来考虑进行哪些功能操作、如何进行组合。具体到我进行过的实践，这部分倒还没遇到过什么问题，但其他被测对象怎样我就不知道了

理论研究与实践是有很大差距，两者同样重要！

    能否给一些你做过的实例让我学习学习！
    将非常感谢！