快速测试启发法测试策略模型软件测试面试必备.docx
《快速测试启发法测试策略模型软件测试面试必备.docx》由会员分享，可在线阅读，更多相关《快速测试启发法测试策略模型软件测试面试必备.docx（18页珍藏版）》请在冰豆网上搜索。
快速测试启发法测试策略模型软件测试面试必备
_软件测试面试必备
启发法测试策略模型
启发法测试策略模型是设计测试策略的一套模式。
这个模型的直接意图是提醒测试人员在创建测试时应该要想到的一些东西。
最终，这套模型要根据实际情况来定制，并用来在专业测试人员中促进交流、自学、并且更充分的进行有意识的测试。
项目环境包括资源、约束、以及项目中有助于我们测试的其它强力因素，当然也包括阻碍我们做好工作的因素。
当面对阻力时，先确认你是否利用了你所有可获得的资源。
产品元素就是你要测试的东西。
软件是如此的复杂和不可见，以至于你要特别小心的确保你确实测试了产品中需要测试的所有部分。
质量标准是允许你作为一个测试人员来判断产品是否有问题的准则、价值观和来源。
质量标准是多方面的，并且经常是隐藏的或者是自相矛盾的。
测试技术是创建测试时使用的策略。
所有的测试技术都包括对项目环境、产品元素和质量标准的某种分析。
看得见的质量是测试的结果。
你永远不可能知道一个软件产品的“实际”质量，但是通过对应用的各种各样的测试，你能对其质量做一个比较准确的评估。
1.常用测试技术
测试技术就是创建测试的方法。
这都是些有趣的技术。
下面列出了九种常用的技术。
使用“常用技术”这个词，我是想说这些技术足够简单和普遍，并在各种不同的环境中都得到了广泛的应用。
很多特殊技术都是基于这九种方法中的一种或者几种发展出来的。
通过对一种或几种常用技术用覆盖的思想来组合，就可以构建成无数的特殊测试技术，这些覆盖的思想都是来自启发式测试策略模型中的其它列表中的。
1.1.功能测试（FunctionTesting）
测试系统能够完成的功能。
Ø找出产品能够做的事情（功能和子功能）。
Ø判断你将怎么才能知道一个功能是否能正常工作。
Ø测试每个功能，一次测试一个。
Ø看看每个功能是否做了应该做的，而没有做不应该做的。
1.2.域测试（DomainTesting）
Divideandconquerthedata。
（与等价类划分＋特殊值的方法类似――译者注）
Ø分析产品的输入输出数据集。
Ø判断测试的特殊值。
考虑边界值，典型值，常用值，无效值，以及最具代表性的值。
Ø考虑需要在一起测试的数据的组合。
1.3.压力测试（StressTesting）
征服产品。
（在规定的规格条件或者超过规定的规格条件下，测试一个系统，以评价其行为）
Ø找出在挑战性的数据或者压倒性的资源面前对超载或者“破坏”敏感的子系统和功能。
Ø辨识出与那些子系统和功能相关的数据和资源。
Ø选择或生成测试所需的挑战性的数据或约束条件的资源：
例如，大量或复杂的数据结构，高负载，长时间运行，大量的测试用例，低速存储器的情况。
1.4.工作流测试（FlowTesting）
做完一件事再做另一件。
Ø定义把具体的多个活动首尾链接起来测试过程或者高水平的用例。
Ø在两个测试之间不要重置系统。
Ø改变时间和顺序，并且尝试并发的线程。
1.5.场景测试（ScenarioTesting）
作为一个强制性的故事来测试。
Ø首先，思考与产品关联的每一件事。
Ø设计把产品中有意义的和复杂的相互作用包括在内的测试。
Ø一个好的场景测试是一个关于一些人或事可能对产品进行怎样的操作故事。
1.6.约束测试（ClaimsTesting）
验证每一条约束。
Ø在产品的参考资料中辨识出其包含的约束（隐藏的或直接的）。
Ø分析单个的约束，并明确比较含混的约束。
Ø验证产品的每条约束是否是正确的。
Ø如果你测试的依据是详细的规格说明书，就很值得使用这个技术，并且会把产品做的比较标准。
1.7.用户测试（UserTesting）
涉及了用户的测试。
Ø分清楚用户的类别和角色。
Ø判断每类用户会执行什么样的用例，怎样来执行，以及这样做的价值。
Ø获得真实的用户数据，或者让真实的用户来测试。
Ø否则，就要系统地模拟一个用户了（当心――想像你是一个用户很容易，但是实际上你并不是）。
Ø非常有效的用户测试应该要涉及各种各样的用户和用户角色。
而不是仅仅一个。
1.8.风险测试（RiskTesting）
设想一个问题，然后去找到它。
Ø这个产品会有哪些种类的问题？
Ø哪种问题是最要紧的？
关注那些问题。
Ø如果真有这些问题，你将怎样来侦测？
Ø做一个有趣的问题的列表，并特别设计一些测试来发现这些问题。
Ø可能需要一些帮助，包括咨询顾问、设计文档、以前的缺陷报告、或者使用风险启发法。
1.9.自动化测试（AutomaticTesting）
运行大量不同的测试。
Ø寻找适合自动的生成大量的测试的机会。
Ø开发一套自动化的、高速评估的机制。
Ø写程序来生成、执行并评估这些测试。
2.项目环境
创建和执行测试是测试项目的核心所在。
然而，在你决定要创建什么样特定的测试时，项目环境中有很多因素都是关键性的。
对于下面的每个类别中的因素，都要考虑它们可能会怎样帮助或阻碍你的测试设计进程。
试着利用好每一个资源。
2.1.客户。
这个测试项目中作为客户的任何人。
Ø你知道谁是你的客户么？
谁的意见要紧？
谁从你做的工作中受益或者利益收到损害？
Ø你同你的客户联系和交流过了么？
可能他们对你的测试有帮助。
Ø可能你的客户对你要创建和运行的测试有很强烈的想法。
Ø可能客户之间对测试有相冲突的期望。
你可能不得不帮着分析清楚并解决这些冲突。
2.2.信息。
关于需要被测试的产品或项目的信息。
Ø有任何的可获得的工程文档么？
用户手册？
网上的资料？
Ø这个产品有历史渊源么？
有已经被修复或者遗留的老问题么？
客户有经常抱怨什么？
Ø在你知道怎么测试该产品之前，你需要更熟悉该产品么？
Ø你的信息是最新的么？
你怎样得知新的或者修改的信息？
Ø看起来信息好像异乎寻常少的产品中有任何复杂或者富有挑战性的部分么？
2.3.与开发人员的关系。
你怎样同程序员相处。
Ø傲慢型：
开发团队看起来对于产品的任何方面都过于自信？
Ø防卫型：
产品中存在开发人员似乎很奇怪地反对进行测试的部分？
Ø融洽：
你同开发人员发展出了一种伙伴合作关系？
Ø反馈环路：
你能同程序员根据需要进行快速交流么？
Ø反馈：
开发人员对你的测试策略怎么想？
2.4.测试团队。
任何会执行或支持测试工作的人。
Ø你知道谁会来测试这个项目？
Ø有不在“测试团队”中，但可能会有帮助的人么？
有人以前测试过类似的产品，并可能提供一些建议么？
作者？
用户？
还是程序员？
Ø你有足够的有正确的技能来执行一个合理的测试策略的人么？
Ø这个团队有没有基于一些特殊技能或者动机地需要，来刻意执行使用一些测试技术？
Ø需要任何的培训么？
可以获得一些什么培训？
2.5.设备和工具。
管理测试所需要的硬件、软件或者文档。
Ø硬件：
我们有执行测试所需要的所有的设备么？
是否已经安装好，并准备运行了？
Ø自动化：
需要使用任何的自动化测试工具么？
工具是否都准备好了？
Ø探测器：
在测试产品时，需要任何辅助性的工具来帮助我们观察么？
Ø矩阵和一览表：
有需要跟踪或者记录测试的进程的任何文档么？
2.6.时间表。
项目事件的顺序、持续时间和同步。
。
Ø测试设计：
我们有多少时间？
这些测试晚一点创建是否会好一点？
Ø测试执行：
测试应该什么时候执行？
是否有些测试要被重复的执行，比如说，在回归测试中？
Ø开发：
版本什么时候可以来测试，增加了功能，代码冻结，等等？
Ø文档：
用户文档什么时候可以评审？
2.7.测试要素。
被测试的产品对象。
。
Ø范围：
在你的测试职责范围中，包含产品中的哪一部分功能，不包含哪些？
Ø可用性：
你有需要被测试的产品么？
Ø易变性：
产品是否在不断的变化？
再次测试时需要些什么？
Ø新元素：
最近，产品中新增或者修改了些什么？
Ø可测试性：
产品的功能和可靠性是否足够让你能有效的来进行测试？
Ø将来的版本：
你测试中哪部分，如果有的话，必须被设计来应用到产品的将来的版本中？
2.8.可提交物。
测试工程的可以看得见的提交物。
Ø内容：
你要提交哪种报告？
你会分享你的工作记录，还是只有结果？
Ø目的：
你的提交物是不是作为产品的一部分？
有别的其他人要运行你的测试么？
Ø标准：
你有要遵循的一些特别的测试文档标准么？
Ø媒体：
你要怎样记录和并与其它人交流你的报告？
3.产品元素
一个产品，最终是要提供给客户一种体验或者是一个解决方案。
产品是有很多尺度的。
因此，为了获得好的测试结果，我们必须检验这些尺度。
下面所列的每一类，都代表着一个产品的重要的并且是独一无二的一个方面。
测试人员如果对这些方面关注得很少的话，很可能会错过很重要的Bug.
3.1.结构。
构成产品本身的任何东西。
Ø代码：
构成产品的代码结构，从可执行到独特的例程（fromexecutablestoindividualroutines）
Ø接口：
子系统间连接和通讯的点。
Ø硬件：
对产品必不可少的任何硬件组件。
Ø非可执行的文件：
与多媒体和程序不同的任何文件，例如文本文件，样品数据，或者帮助文件。
Ø附属品：
产品中除了软件和硬件之外的任何其它部分，例如纸质文档，Web链接和内容，包装，许可声明，等等…
3.2.功能。
产品能做的任何事情。
Ø用户界面：
用来给用户交互数据的任何功能（例如，浏览器，显示界面，数据输入窗口）。
Ø系统接口：
用来给不同于用户的其它事物交互数据的任何功能，例如，其它程序，硬件，网络，打印机，等等。
Ø应用：
用来定义或区分产品或者实现核心需求的任何功能。
Ø算法：
任何计算的功能或者算法的操作嵌入在其它功能里面的。
Ø与时间有关的：
暂停时间设置；每日或每月报告；每晚的批处理作业；时区；商业假日；利息算法；条款和担保期；以及要求精确的功能。
Ø改变：
修改或改变某些东西的功能（例如，设置字体，插入剪贴画，从账户中取钱）
ØStartup/Shutdown：
启用和初始化或者退出产品时需要用到的任何方法与接口。
Ø多媒体：
声音，图片、视频、或者嵌入在产品中任何图形化的显示。
Ø出错处理：
侦测错误并从错误中恢复的任何功能，包括所有的错误信息。
Ø集成交互：
产品的功能之间的任何交互或接口。
Ø可测性：
提供的可以用来帮助测试的任何功能，例如诊断（diagnostics），日志文件，断言，测试的菜单，等等。
3.3.数据。
产品处理的所有东西。
Ø输入：
产品要处理的任何数据。
Ø输出：
产品处理过的结果数据。
Ø预设值：
作为产品的一部分提供的任何数据，或者直接在产品中创建的数据，例如初始化数据库，系统默认值，等等。
Ø配置项：
任何内置的并且会在多个操作持续使用数据。
包括产品的状态或样式，例如参数设置，视图模式，文档目录，等等。
Ø数据排序：
数据的任何顺序或排列，例如文字的排序，分类或未分类的数据，测试顺序。
Ø数据规模（Bigandlittle）：
数据的大小和聚集的变化量。
Ø异常数据：
以不受控制或不正确的方式产生的无效的、被破坏掉的、或者产生的任何数据或者状态。
Ø生命周期：
在数据实体的整个生命周期中的变化，包括创建、访问、修改和删除。
3.4.平台。
产品所依赖的所有事物（并且也是你项目的外部环境）
Ø外部硬件：
并不是要交付的产品的一部分，但是是为了保证产品运行的必须的硬件组件和配置（或者是可选的）：
CPU，内存，键盘，外设，等等。
Ø外部软件：
：
并不是要交付的产品的一部分，但是是为了保证产品运行的必须的软件组件和配置（或者是可选的）：
操作系统，同时执行的应用程序，驱动，字体，等等。
Ø内部组件：
被嵌入在你的产品中，但是不是由你的项目生产的库或者其它组件。
既然你不能控制它们，你必须决定如果它们失效了该做些什么来解决问题。
3.5.操作。
产品将会被怎样的使用。
Ø用户：
各种不同的用户的属性。
Ø环境：
产品操作所在的物理环境，包括例如噪音、灯光、和分心的事物这样的元素。
Ø正常操作（CommonUse）：
产品输入的模式和顺序可能会与通常的使用习惯冲突。
这根据用户的不同而不同。
Ø异常操作（DisfavoredUse）：
由不了解、误解、不小心或者恶意的使用产生的输入模式。
Ø极端操作（ExtremeUse）：
挑战与产品期望的使用方法一致的输入模式和顺序。
3.6.时间。
产品与时间之间的任何关系。
Ø输入/输出：
什么时候提供输入，什么时候创建输出，以及他们之间的时间联系（延迟、间隔，等等）。
Ø快/慢：
用“快速”输入或者“慢速”输入来测试；最快和最慢；快和慢结合起来测试。
Ø变化率：
加速和减慢（峰值、突然爆发、中止、瓶颈、中断）。
Ø并发：
一次发生超过一件事情（多用户，分时，线程、信号、和共享数据）。
4.质量标准类别
质量标准是一些定义产品应该是什么样的需求。
通过对不同种类的标准的观察和思考，你会能够比较好的制定一个快速发现重要问题的测试计划。
下面每一个列表中的条目都可以被认为是一个潜在的风险区域。
对于下面的每一个条目，判断对于你的项目是否是重要的，然后思考你怎样得出产品是否运行得很好还是很差的结论。
4.1.操作标准（OperationalCriteria）。
Ø能力。
是否能完成需要的功能？
Ø可靠性。
是否运行得很好并且在所有需要的情况下都不会失效？
出错处理：
产品在出错的时候抵制失效，并很快恢复，这在失效时是非常棒的。
数据完整性：
系统中的数据避免丢失或被破坏。
安全：
产品失效也不会对生命和财产造成威胁和伤害。
Ø可用性。
对于一个真实用户来使用这个产品到底有多容易？
可学习：
产品的预期用户能够很快的掌握其操作。
可操作：
产品操作起来不会很费劲，也不会很麻烦。
可接近：
产品接近相关的标准，并且与操作系统的相关标准比较接近。
Ø安全。
在保护产品不受到非法的使用或入侵上做得有多好？
证明：
系统验证用户的确是她所说的那个人的方式。
授权：
授予被证明的用户不同程度的权限级别的权利。
隐私：
客户或雇员数据避免受到未授权的人的危害的方式。
安全漏洞：
系统不能保证安全的方式（例如社会工程的脆弱性）
Ø可度量。
产品按照比例放大或缩小的部署表现得有多好？
Ø性能。
系统有多快的响应速度？
Ø可安装。
产品安装到目标平台上有多容易？
系统需求：
如果一些必须的组件缺失或者无效，产品是否能够识别？
配置：
系统的哪一部分会受到安装的影响？
这些文件和资源都保存在什么地方？
卸载：
当产品被卸载时，是否可以干净的移除？
升级：
新模块或者版本是否能很容易的增加？
它们是否不改变已有的配置。
Ø兼容性。
同外部组件和配置一起运行得有多么好？
应用兼容性：
产品和其它软件产品一起运行。
操作系统兼容性：
产品运行在特定得操作系统上。
硬件兼容性：
产品运行在特定的硬件组件和配置上。
向后兼容性：
产品同自身早期的版本一起运行。
资源利用：
产品没有使用不必要的大量内存、存储空间，或者其它系统资源。
4.2.开发标准（DevelopmentCriteria）
Ø可支持性。
是否可以很经济的为产品的用户提供支持？
Ø可测试性。
产品能够被如何有效的测试？
Ø可维持性。
是否可以很经济的对产品进行打包、修复或者增强？
Ø可移植性。
是否可以很经济在其它地方移植或重用该技术？
Ø本地化。
产品是否可以很经济的适应其它地方？
规则：
是否有超越州或国家边界的不同的规则或报告的需求？
语言：
产品能容易适应更长信息,从右到左或者表意字的字体么？
货币：
产品能够支持多币种么？
币种汇率呢？
社会或文化差异：
顾客可以发现文化参考资料中有令人费解的或者侮辱的吗?
原文：
TheHeuristicTestStrategyModelisasetofpatternsfordesigningateststrategy.Theimmediatepurposeofthismodelistoremindtestersofwhattothinkaboutwhentheyarecreatingtests.Ultimately,itisintendedtobecustomizedandusedtofacilitatedialog,selfdirectedlearning,andmorefullyconscioustestingamongprofessionaltesters.
ProjectEnvironmentincludesresources,constraints,andotherforcesintheprojectthatenableustotest,whilealsokeepingusfromdoingaperfectjob.Makesurethatyoumakeuseoftheresourcesyouhaveavailable,whilerespectingyourconstraints.
ProductElementsarethingsthatyouintendtotest.Softwareissocomplexandinvisiblethatyoushouldtakespecialcaretoassurethatyouindeedexaminealloftheproductthatyouneedtoexamine.
QualityCriteriaaretherules,values,andsourcesthatallowyouasatestertodetermineiftheproducthasproblems.Qualitycriteriaaremultidimensional,andoftenhiddenorself-contradictory.
TestTechniquesarestrategiesforcreatingtests.Alltechniquesinvolvesomesortofanalysisofprojectenvironment,productelements,andqualitycriteria.
PerceivedQualityistheresultoftesting.Youcanneverknowthe"actual"qualityofasoftwareproduct,butthroughtheapplicationofavarietyoftests,youcanderiveaninformedassessmentofit.
GeneralTestTechniques
Atesttechniqueisawayofcreatingtests.Therearemanyinterestingtechniques.Thelistincludesninegeneraltechniques.By“generaltechnique”Imeanthatthetechniqueissimpleanduniversalenoughtoapplytoawidevarietyofcontexts.Manyspecifictechniquesarebasedononeormoreofthesenine.AndanendlessvarietyofspecifictesttechniquescanbeconstructedbycombiningoneormoregeneraltechniqueswithcoverageideasfromtheotherlistsintheHeuristicTestStrategyModel.
FunctionTesting
Testwhatitcando
1.Identifythingsthattheproductcando（functionsandsubfunctions）.
2.Determinehowyouwouldknowifafunctionwascapableofworking.
3.Testeachfunction,oneatatime.
4.Seethateachfunctiondoeswhatitissupposedtodoandnotwhatitisnotsupposedtodo.
DomainTesting
Divideandconquerthedata
1.Lookforanydataprocessedbytheproduct.Lookatoutputsaswellasinputs.
2.Decidewhichparticulardatatotestwith.Considerthingslikeboundaryvalues,typicalvalues,convenientvalues,invalidvalues,orbestrepresentatives.
3.Considercombinationsofdataworthtestingtogether.
StressTesting
Overwhelmtheproduct
1.Lookforsub-systemsandfunctionsthatarevulnerabletobeingoverloadedor“broken”inthepresenceofchallengingdataorconstrainedresources.
2.Identifydataandresourcesrelatedtothosesub-systemsandfunctions.
3.Selectorgeneratechallengingdata,orresourceconstraintconditionstotestwith:
e.g.,largeorcomplexdatastructures,highloads,longtestruns,manytestcases,lowmemoryconditions.
FlowTesting
Doonethingafteranother
1.Definetestproceduresorhighlevelcasesthatincorporatemultipleactivitiesconnectedend-to-end.
2.Don’tresetthesystembetweentests.
3.Varytimingandsequencing,andtryparallelthreads.
Scena
升级会员 