在软件工程导论（第六版）书上的质量保证中有写到，所谓正确性，是系统满足规格说明和用户目标的程度，即在预定环境下能正确地完成预期功能的程度。对于顾客也就是说，他要认为这个程序能按照他的需求工作。软件可靠性是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。规定的条件是指直接与软件运行相关的使用该软件的计算机系统的状态和软件的输入条件，或 统称为软件运行时的外部输入条件；规定的时间区间是指软件的实际运行时间区间；规定功能是指为提供给定的服务，软件产品所必须具备的功能。软件可靠性不但 与软件存在的缺陷和（或）差错有关，而且与系统输入和系统使用有关。软件可靠性的概率度量称软件可靠的。感觉上软件的可靠性包括了软件的正确性以及软件的健壮性。（健壮性：在硬件发生故障，输入数据无效或作物操作等意外环境下，系统能做出适当的相应的程度。），所以我记得一个程序既争取又不可靠完全可能。程序员只能保证他按照需求说明书等条件来完成程序，但程序并不是100%满足顾客的条件，他也不是100%满足现在的条件与现状。一个程序总能让人找到bug，（若没有bug，那很多游戏就不会存在外挂了），但它不可靠却能由很多的原因产生，比如硬件故障，你又硬件故障让程序死了，你总不能怪程序员啊。个人认为可靠性要高于正确性。用软件系统规模越做越大越复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，在一些关键的应用领域尤为重要。在许多项目开发过程中，对可靠性没有提出明确的要求，开发商(部门)也不在可靠性方面花更多的精力，往往只注重速度、结果的正确性和用户界面的友好性等，而忽略了可靠性。在投入使用后才发现大量可靠性问题，增加了维护困难和工作量，严重时只有束之高阁，无法投入实际使用。比如我宁愿火箭升空后满足不了我的通话功能，我也不要火箭一升空就gg。
突然觉得acm就和做软件一样一样的，题面有英文有中文，就好比需求说明书，然后你要读题读题，虽然废话很多，英文看得心累。样例就好比具体的功能。然后你要实现啊。OJ的评测机就好比你的用户（好像做个oj，但不会啊），你的程序写完了，你自己验证他的正确性了，你能满足需求了，你就可以往上交了。然后你就会被实时返回一个答案，如果你是神犇，那么你很可能是ac，然后你的可靠性就保证了。但像我等蒟蒻，那么久有可能是wa,tle,ce,re等，那么就是可靠性不满足，重新debug，再来过。
从原来非专业的角度上觉得，正确性也就是程序能不能跑嘛，满足语法即可，而可靠性就是能不能满足你的功能嘛，你要实现a+b，我给你敲了个prim。比如在acm竞赛中，我们做出了一道题，往往过来样例就敢往上怼，然后会出现各种tle,wa,re等等等等。然后了，你又得下来debug（debug往往是最烦人的）。就拿浙江省省赛这道题而言，http://acm.zju.edu.cn/onlinejudge/showContestProblem.do?problemId=5706 一拿到手以为是最小树啊，然后敲啊敲啊，板子敲完了，然后队友才发现，maya，样例没过，但是我们的程序满足正确性啊，他能跑啊，但是能，交上去肯定wa，可靠性不满足。然后发现这是个最短路（不过要加限制条件，什么优先队列之类的，要不就会炸），但是到最后我们都没有出这道题...gg。（第三段全是非专业理解加废话）
