如何进行软件可靠性和稳定性测试啊?
公司现在做的系统，要求对可靠性和稳定性有比较高的要求，系统必须满足7X24的运行模式，并且要求因系统软件故障导致的停机时间，年累计不得超过1小时。
请问这样的需求，应该如何进行测试，应该采取方法来进行测试?能设计出来相关的测试用例么?
[解决办法]
1.这是纯粹的宣传口号
2.做这样的测试，方式是比较简单的：
硬件，没什么好说的。买个HP，DELL的服务器都满足，说明书上都有这样的指标，7X24主要是硬件。
软件，纯粹的人为因素了。要进行临界状态的测试，就是满负荷下的程序运行--目的就是看看有没有BUG，一般都没有：-）。
可以采用loadrunner等软件进行连续测试1天、2天的都可以。
[解决办法]
跑一个7*24看看。
[解决办法]
凭你的描述是不可能做测试的。关于可靠性、稳定性，要首先进行软件论证，也就是了解软件的架构、模块、源代码，然后就把测试细分到针对各个子系统、主要程序单元的稳定性、可靠性测试上，然后再细分.......直到每一个测试可以直接写为代码而不需要花时间去论证了！
如果你还搞不清楚应用软件会怎样使用，那么你根本写不出靠谱的测试用例，你的测试就无法把压力放到需要测试的地方（反之就是有许多地方根本没有测试）。在这种情况下，即使你架好了服务器然后运行一个测试软件也是自欺欺人的。所以完成高标准的测试要求的关键是你首先以白盒的方式了解了被测试的软件，然后制定有针对性的全面的测试。
[解决办法]
实际的开发过程充满了变化和重构，所以往往并不能采取细分的做法。细分只能作为一种纯粹理论化的方法来描述概念。当你的项目经常变化时，要达到比较高的测试要求，就要使用以测试为软件设计驱动因素，在设计各个框架、组件单元的时候就想好测试用例甚至写好测试程序，然后才编写完成程序的代码。把测试工作深深地推入开发过程中，随时进行回归测试，就能保证所开发的产品随时都有比较好的质量。
保证所谓7*24小时服务，许多时候靠策略，而不是技术。使用比较廉价的服务器硬件，使用经常崩溃的应用软件，仍然可以做到7*24小时稳定可靠地运行，这就是架构比较好从而可以利用一些故意设置的冗余能力来提升其稳定性。如果开发时追求技术上新奇技巧，反而可能降低代码质量。
[解决办法]
to sp1234：
概念说的比较明确与清楚了，佩服。不过一些观点略有微词:
1."如果开发时追求技术上新奇技巧，反而可能降低代码质量."
不追求，怎么尝试呀。您在数据库分页操作时，使用rowcount、limit，还是next一条一条过？先一棒子打死再在有成果的时候肯定--狠狠让人所不齿。技术是软件开发的原动力，需求是推力；不要把这个关系搞乱，新技术会满足更多的需求（至少是性能），新技巧是新技术的前提。代码质量是纯粹的人为因素，讲究统一的代码风格不需限制个人的编程风格。不可能只停留在以前的技术环境上，到时候不是环境换了就是人换了。
2.“即使你架好了服务器然后运行一个测试软件也是自欺欺人的。”
怎么说呢，只要在整体测试完没有BUG出现，这个系统就是可信的、稳定的、可商用的。M$不也是每天都发补丁吗？win95/98的蓝屏并没有让他们丧失多少用户。现实的开发环境，到最后还是需要进行“好了服务器然后运行一个测试软件”的，之前的东西都是在开发过程中要解决的，不是开发完后要讨论的。
to LZ：
推论一下LZ的现状：系统已经开发收尾阶段，需要根据客户说明书中的要求对性能有所保障。咋办？
商务上是很好办的，回答“全满足”就行了，最多提交一个整体测试报告。技术上，整体测试保证没有出现BUG也行了。如果时间紧，以上就是方法。就我之前接触的电信级应用来说，许多东西（性能、可靠性）都是蒙人的，出现故障很常见的（在之前的项目投标时，肯定是不允许的），及时解决也就过去了；除非出现“大事”否则都是正常的过程。
to ALL：
我们最终能够达到这样的结果“客户在系统测试过程中，未出现BUG、无明显性能问题”就OK了，性能的改进可以在之后再进行也允许。怎么达到这一步呢？就是“sp1234”所描述的整套；如果时间紧，就不必拘泥这些了，开发完疯狂找bug吧。
