Question

我最近的任务是，

“测试您可以想到的每个场景并尝试打破组件”

当应用程序是网站时，“一切”可能是明智的吗？

注意：这个特定的站点是带有MS-SQL的ASP.NET，但是，我想知道一般的内容。谢谢大家的好评！

Answer 1

每种语言的每个浏览器
每种语言的每个操作系统
各种屏幕分辨率
Javascript开/关
图像开启/关闭
CSS开/关
启用/禁用Cookie
搞乱网址
各种输入变体，特别是测试XSS攻击，非ASCII字符，无效输入
键盘辅助功能
服务器相关问题 - 例如软件/硬件重启后应用程序是否正常工作？
在多个标签/窗口中打开网站是测试任何与会话相关的奇怪问题的好方法

Answer 2

尝试考虑角落情况，不要忘记常见情况。
压力测试。
单击每个按钮，然后扭转用户界面上的每个旋钮，确保反馈合理且合适。
尝试从每个潜在用户的角度来看待用户界面，是否存在令人困惑的部分，容易被误解甚至没有意义。
仔细研究所使用的隐喻，它们是否合适并且使用一致。
尝试乱码作为输入。
尝试输入代码，例如Javascript，确保它能够很好地抵御黑客攻击。

当然还有基础知识（复制自Bobby Jack和博士，还有学分到期）：

每个浏览器
每个操作系统
Javascript开/关
图像打开/关闭
CSS开/关
改变屏幕分辨率
启用Cookie

Answer 3

一个定义：测试每个代码分支。 [100％覆盖率] 当然，这仅适用于非静态网站。

Answer 4

我从烟雾测试开始 - 一个检查最基本功能的广泛测试。然后按重要性顺序列出最重要的功能，并为该顺序的那些创建测试。如果该网站是任何规模并定期更新，您将需要使用硒等自动化这些测试。

Answer 5

其中一些取决于具体情况。以下是一些不太明显的内容：

网站的“流量”是什么？是否有用户应该访问的订单？

尝试无序
尝试跳过步骤
离开并回来

是否涉及表格？

试用XSS
尝试SQL注入

是否涉及到Cookie？

尝试从http://domain.com而不是http://www.domain.com访问该网站（是的，如果程序员不小心，www有时会导致问题）

Answer 6

不要忘记“笨蛋”测试。

打开页面，单击“提交”按钮。表格是否正确处理完全没有提交？

将光标放在文本框字段中。按键几次（键盘上的爆炸猫，炸掉的咖啡漏掉了东西）。输入验证是否与“非标准”数据一起使用？

提交表格/请求。点击后退按钮。表格是否重新提交？应该是吗？回来时是否显示正确的数据？

在过去的“骨头”情况下，我多次被烧伤，你会感到惊讶。

Answer 7

除了Bobby Jack的名单，还有NomeN，以及其他所有人......我没有特别提到这一点;道歉，如果是的话。您没有提到这是什么类型的网站，但根据问题域，特别是格式错误的数据可能会导致令人头疼的问题。例如：在电子商务网站中，如果有人试图订购负数，该怎么办？很多事情可以通过“向后”（缺乏更好的词）输入来打破。

Answer 8

另外请不要忘记验证工具。万维网联盟是网络的标准组织，与其他优秀组织一样，提供了大量的工具。以下是一些很好的在线工具：

验证HTML（例如W3C HTML validator）。
验证CSS（例如W3C CSS validator。
检查链接（例如W3C link checker）。
检查辅助功能（例如Wave）。
检查网页加载速度（例如Google's Page Speed）。
检查打印时页面的外观（很少检查，但有时你会发现有损于专业外观的文物）。
之前曾提到检查所有浏览器，但未提及的是有一些工具可以快速为您提供多个浏览器视图，从而将不切实际的内容带入实际领域;考虑这些Browser Testing Tools。
检查可用性;有点无定形的目标，它往往超出技术测试人员的职责或预算。我最近遇到了usertesting.com，它既便宜又快速地提供了真实的用户反馈。
校对！错别字是说你的网站很傻的最快方式。

最后，这是一个人对合理的checklist的看法，这是一个具有online everything checker宏伟主张的网站。

Answer 9

用于CYA目的 - 请参阅Bobby Jack的回答

各种屏幕分辨率

Answer 10

忘记你对系统的了解，试着把它看作是第一次。
质问一切。
尝试不同的浏览器，设备，分辨率。
尝试在未安装打印机的情况下进行打印。
尝试在不触碰鼠标的情况下使用本网站。
尝试在不触摸键盘的情况下使用本网站。
获取GUI的屏幕截图并变为灰度。你还能读懂文字吗？

Answer 11

除了Bobby Jack的列表之外，我还建议保护您的网站免受大多数愚蠢用户和黑客用户的攻击 - 除其他外，这意味着要正确保护您的网址和QueryString。

Answer 12

有很多测试类型可以通过一个软件来执行，列表是无穷无尽的并且由多种不同类型覆盖，没有一个答案就足够了。

功能测试，集成测试，性能测试，渗透测试，回归测试，浏览器的兼容性测试，压力测试 - 列表继续。

这是在你深入研究每一个并开始讨论诸如css / xss攻击等细节之前

Answer 13

对于网站而言，您在开发过程中会考虑的大多数常见故障一些大的是：防止mysql注入防止未经授权的访问（非会员进入会员部分）如果您在任何时候提交表单，请考虑如果用户更改了get或甚至发布数据会发生什么

这些是我现在所能想到的，所有这些你都不会“试图打破”网站，你只需要在你的代码中加入一些东西。

Answer 14

实际上，最好从非常常见的情况开始。获取一组典型的用例，并确保这些用例都经过彻底测试。然后，开始分支到稍微不那么常见的情况。

测试始终是一种组合情况，因此您无法测试每个方案。考虑10个浏览器x 10种类型的用户x 10种方法x 10 OS x 10种形式= 100,000种测试方案。

对于任何合理大小的应用程序，可能存在数十亿个场景。

因此，您需要从最常见的场景开始，然后从那里开始工作。您还需要考虑测试的正交性。蛮力“测试所有场景”是行不通的。

Answer 15

“测试你能想到的每一个场景都是不切实际的”。为什么会这样？在这里仅使用其中的14条建议，主要来自Bobby Jack的优秀答案，您最终将获得2,654,208项可能的测试。实际上，你不会或不能测试每一个。那你该怎么办？

这是成对（或其他更高级的组合测试方法）非常有用的一个很好的例子。仅38个测试不仅会覆盖每个参数值至少一次，而且还会包含至少一个测试用例，其中涵盖了彼此交互的参数值的每个对。（例如，浏览器=“Opera”和CSS =“on”将进行测试，Simulate Dropped Connectivity？=“Y”，Cookies Enabled =“N”将进行测试等。）来自Hexawise的几个屏幕截图，一种新的（目前免费的）测试设计工具，可以使这一点比单词更好：

第一张图片显示14个参数中的每一个，每个参数最多6个值

 Image 1 -  http://pea.to/cU

第二张图片显示：（A）输入创建了2,654,208个可能的测试用例/场景，以及（B）在至少一个测试用例中，只有38个测试用例将测试每一对可能的参数值。（例如，浏览器=“Opera”和CSS =“on”将进行测试，Simulate Dropped Connectivity？=“Y”，Cookies Enabled =“N”将进行测试，等等。）

 Image 2 -  http://pea.to/8B

有关在尽可能少的测试用例中最大化覆盖率的此方法的其他信息，请访问www.combinatorialtesting.com，特别是在http://www.combinatorialtesting.com/clear-introductions-1

贾斯汀

Justin Hunter - Hexawise的创始人兼首席执行官 - 更多报道。更少的测试。 www.hexawise.com

如何解读'测试你能想到的每一个场景'

15 个答案: