![]() |
1
20
不同的人对什么构成什么样的测试有着稍微不同的看法,但这里有一些我认为每个术语的含义。请注意,这严重偏向于服务器端编码,因为我倾向于这样做:) 单元测试 一个单元测试应该只测试一个逻辑代码单元——通常是整个测试用例的一个类,以及每个测试中的少量方法。单元测试(理想情况下)很小而且运行成本很低。与依赖项的交互通常与 双重测试 集成测试
系统测试 系统测试类似于集成测试,但也有真正的外部服务。如果这是自动化的,通常系统被设置成一个已知的状态,然后测试客户机独立运行,像真正的客户机一样发出请求(或任何请求),并观察效果。外部服务可以是生产服务,也可以只是在测试环境中设置的服务。 探测试验 这就像一个系统测试,但是使用生产服务来完成一切。它们定期运行以跟踪系统的运行状况。 验收试验
黑盒子还是白盒子? 测试也可以是“黑盒”测试,只接触公共API,也可以是“白盒”测试,利用一些额外的知识使测试更容易。例如,在白盒测试中,您可能知道某个特定的内部方法被所有公共API方法使用,但更容易测试。您可以通过直接调用该方法来测试大量的角落案例,然后使用公共API进行较少的测试。当然,如果你 设计 另一方面,黑盒测试通常没有白盒测试那么脆弱:根据定义,如果您只测试API在其契约中保证的内容,那么实现可以在不改变测试的情况下随意改变。另一方面,白盒测试对实现更改很敏感:如果内部方法发生了细微的更改(例如,获得了一个额外的参数),那么您需要更改测试以反映这一点。 测试公共API。对我来说,这感觉更教条,而不是务实,但我也能看到好处。 开始 现在,关于下一步应该去哪里-单元测试可能是最好的开始。您可以选择在设计类(测试驱动开发)之前编写测试,或者在大致相同的时间编写测试,甚至在几个月之后编写测试(这并不理想,但是有很多代码没有测试,但是应该有测试)。您会发现您的一些代码比其他代码更易于测试。。。两个 使测试可行的概念(IMO)是 (编写接口代码并向类提供依赖项,而不是让它们自己实例化这些依赖项)以及 (例如,模仿框架,让你测试交互,或者伪造实现,在内存中以一种简单的方式做每件事)。 |
![]() |
2
1
我建议至少读一本关于这方面的书,因为这个领域相当庞大,而且书往往能综合更好的概念。 Software Testing Testing Across the Entire Software Development Life Cycle (2007)
|
![]() |
3
1
嗨,我想补充一下乔恩·斯凯特先生的回答。。 基于白盒测试(或结构测试)和黑盒测试(或功能测试),以下是各类别下的其他测试技术:
压力测试
例如。 可能是你可以采取系统溢出的条件,如试图提取超过可用的银行余额不应该工作和提取到一个最大的阈值应该工作。 使用时间
执行测试 这样做是为了检查一个系统的熟练程度。 例如。 计算交易的周转时间。 在开发过程的早期,查看是否满足性能标准。 恢复测试 看看系统在发生故障后能否恢复到原来的状态。 例如。 在日常生活中,一个非常常见的例子是Windows操作系统中的系统还原。。 它们有用于恢复的恢复点,这是众所周知的。 用于以下情况:
您可以使用的其他类型的测试include:-
符合性测试
需求测试 回归测试 错误处理测试 手动支持测试 系统间测试
平行测试 质量保证研究所(QAI)的William Perry有一本非常好的书,书名是Effective methods for Software Testing,如果你想深入研究w.r.t.软件测试,我建议你一定要读这本书。 关于上述测试类型的更多信息肯定可以在本书中找到。
手动测试 :这是为用户界面完成的。 :基本上包括白盒测试或已完成测试的测试 通过Load Runner、QTP等软件测试工具。
详尽的测试
|
![]() |
4
0
开始测试 1.烟雾测试。一旦通过,继续进行功能测试。这是测试的支柱。如果功能正常,那么80%的测试是有利可图的。 2.现在进行用户界面测试。有时,用户界面比功能更能吸引客户。它是外观&感觉客户对它更感兴趣。
快乐测试:) |
![]() |
Tim Kirkwood · 比较空数据帧 6 月前 |
![]() |
nerrood · 为什么在笑话测试中不调用save 1 年前 |
![]() |
eof · Chrome块文件下载-selenium 1 年前 |
![]() |
Display name · Ember.js辛烷值验收试验 1 年前 |
![]() |
Vitto · 理智和回归测试是如何在一个简单的场景中协同工作的? 1 年前 |
![]() |
mattsmith5 · 使用特征文件并行计算空手道跑场景 1 年前 |
![]() |
Norronas · 采用裸机编程的寄存器单元测试 1 年前 |