最有可能发生什么类型的问题?

时间:2010-03-04 01:42:20

标签: c# sql-server language-agnostic

如果我写道:

  1. 一个C#SQL数据库应用程序(一个简单的程序,包含一些带有逻辑的GUI,用于连接SQL数据库)
  2. 供家庭使用,不进行任何网络通信
  3. 使用简单,可靠且适当的SQL数据库
  4. 其GUI与逻辑
  5. 正确分离
  6. 具有完整且可靠的输入数据验证
  7. 已经过全面测试,以便100%的逻辑错误被消除
  8. ...然后如果程序是由随机用户在随机的Windows计算机上安装和运行的。

    Q1)最有可能出现哪些类型的技术(非程序性)问题和支持情况,以及它们的可能性有多大?

    Q2)我是否可以首先采取其他措施来防止这些问题并最大限度地减少所需的用户支持量?

    我知道一些答案将适用于我的特定平台(C#,SQL,Windows等),有些则不适用。

    请尽可能具体。

    Mitch Wheat在下面给了我一些非常有价值的建议,但我现在正在提供赏金,因为我希望能更好地了解我最有可能遇到的事情。

10 个答案:

答案 0 :(得分:13)

  • 永远不要相信未经验证的用户输入

  • 在您的应用程序中构建出色的错误日志记录(可能还有错误自动提交功能)。能够动态增加日志记录级别,以便可以在用户的​​桌面上打开详细日志记录。

  • 以友好的方式向用户报告错误;不要责怪他们!

  • 如果您的应用程序依赖于许多环境设置或可能被其他软件更改的第三方插件/库,请考虑运行初始化步骤,检查并记录预期版本和找到的版本。这可以帮你省掉头发!

答案 1 :(得分:7)

真正的用户会做的事永远不会让我感到惊讶。为任何事情做好准备。

答案 2 :(得分:6)

  

Q1)还会出现哪些类型的问题?

错误,设计缺陷,功能请求和可用性问题,与任何其他应用程序相同的问题。

  

Q2)解决这些问题需要多少时间和知识?

超过你想花的钱。

  

Q3)我首先要做的是尽量减少所需的用户支持量?

测试,测试和更多测试。聘请全职测试人员是最好的选择。否则,请确保为自己设置支持数据库,以便轻松查找过去的问题并将此知识传递给其他支持人员。

使用良好的错误跟踪/票证系统,最好是允许您公开或集成某种用户可访问知识库的系统。如果您很幸运,这将有助于减少数量的支持请求。


如果您想要非常积极主动,请在应用程序中构建行为跟踪系统(当然保留用户匿名性),这样您就可以了解用户花费最多时间的功能并了解您的心理模型所在的区域该应用程序与他们不相符。

哦,并尝试使程序优雅地失败。一个神秘的异常对话帮助没有人;有一个屏幕可以解释一般情况下出了什么问题以及他们可以做些什么来解决它(“再试30秒”,“重启应用程序”)。实际可能会以这种方式处理一些意外的错误情况,例如连接超时。使相同的屏幕可以选择自动提交异常报告或将调试信息复制到剪贴板,以便他们可以通过电子邮件发送。如果你有堆栈跟踪,你的工作将会轻松得多。

在我的一个应用程序中,我修改了全局异常处理程序,以显示某些类型的网络超时的特殊消息,并且彻底减少了提交的超时“错误”的数量。只要您跟踪异常报告,随着时间的推移,您将了解经常出现哪些类型的未处理异常/意外情况,并且能够......好好处理它们。

答案 3 :(得分:4)

如果你断言你的逻辑是正确的并且经过验证(根据你的问题),基本上会留下基于状态的问题来处理。

所以,你不得不担心的事情包括:

  1. 硬件故障

  2. 关键文件在意外时间在计算机上被破坏,而不是您的程序。

  3. 让您失望的依赖性更新。

  4. 整体系统状态 - 例如硬盘充满

  5. 数据库停止

  6. 卸载依赖项

  7. 此外,代码中假设外部进程正在运行且可用的任何位置只是等待发生的问题。你应该总是假设任何外部过程都是片状的,并且任意下降是预期的行为(这是你在不同进程中拥有东西的部分原因)。事实上,依靠任何你没有完全控制的国家本身就存在风险。虽然你可以在这条道路上过度偏执,但至少要考虑你所依赖的东西,并且非常谨慎和明确地说明你所做的假设是很好的(假设.NET框架可能是安全的,就好像不是,修复这个问题可能超出了你的范围。)

答案 4 :(得分:2)

首先,如果您要构建Windows应用程序,则需要考虑到每个人的Window安装都会有所不同。有些可能会运行其他安全应用程序。有些人可能有UAC;一些关闭。安装了不同的OS,不同的OS补丁。有些用户可能只在用户组中;管理员组中的其他人。只是让用户正确安装所需的.NET框架可能是一个挑战,如果他们的系统是部分fekawied。此外,您将拥有具有不同物理功能的机器。简而言之,您需要小心对用户机器上的内容做出任何假设。

您可以做的一件事就是减少安全软件的变化妨碍您使用最受限制的信任权限级别来运行您的应用程序。查看.NET信任级别。应用程序运行的信任级别越受限制,其他一些安全功能或应用程序对其使用的不确定性就越低。此外,您应该获得完整的代码签名证书来签署程序集。

您应该考虑的另一个决定是您使用数据库引擎。虽然SQLExpress很好,但它会为您提出的应用程序类型产生安装维护问题。如果他们安装了旧版本怎么办?如果他们安装了新版本怎么办?如果您使用的版本需要补丁怎么办?如果他们的安全软件阻止服务运行怎么办?您还没有提到应用程序中涉及多少数据,但您可能会考虑使用更便携的数据库格式,如SQLite甚至是Jet(Access)(尽管Jet还有其他问题需要解决),以避免必须安装用户机器上的另一项服务。

正如您所说,最大限度地减少用户支持是一个大问题,需要进行大量安装。正如其他人所建议的那样,为了减少支持电话并帮助您对应用程序进行更正:

  1. 测试。具体而言,自动测试单元和功能。为此应用程序编写的代码的75%应该是测试代码。
  2. 记录日志。除了记录错误的机制之外,您还需要构建一种机制,允许用户将这些日志发送给您进行故障排除。
  3. 坚如磐石的安装程序。您需要尽可能将安装作为防弹。如果用户无法安装您的应用,则无法使用它。因此,在测试应用程序时,您需要对安装例程进行大量自动化测试。理想情况下,您的应用程序将被封装,以便可以通过xcopy进行部署。

答案 5 :(得分:2)

答案 6 :(得分:1)

我们有一个客户曾经不想使用该软件,因为担心该软件会取代他。

他用叉车碾碎了运行该软件的掌上电脑。

答案 7 :(得分:1)

强制用户安装Microsoft SQL Server Express是一种巨大的依赖关系。我建议使用像SQLite一样重量轻的东西。

另外,如果你不注意我的建议并使用SQL Server,那么请配置它以便它只接受来自127.0.0.1的连接

为了使用户轻松完成整个过程,请尽可能多地使用脚本进行安装。不要试图强迫用户配置一些复杂的软件来使用您的应用程序。确保他们有一个单击默认安装,就像这样。

答案 8 :(得分:1)

根据我20年的经验,您的方案中最常见的问题不是构建错误的软件,而是构建错误的软件。

我的意思是,当您将软件产品引入用户的日常工作时,这个例程很可能会发生变化。如果它没有改变,你的sowftare将是一个失败,因为这将意味着它没有影响(即没有附加价值)。因此,假设它确实改变了用户的环境,我们也可以假设它会改变用户的需求,从而改变他们的需求,从而改变软件产品本身的适用性。

根据定义,成功的软件产品注定会在一段时间后变得尴尬。根据我的经验,每次都会发生 ,并且没有可以绕过它的技术或方法。 : - )

答案 9 :(得分:0)

您将遇到的最大问题是DUMB / AIRHEAD / LAZY用户。