自动化脚本checklist

⑴ 面试题: 如何对一个游戏进行设计测试用例.

一、游戏软件与通用软件的区别 a) 通用软件的需求明确，游戏软件需求理想化 i. 通用软件中用户每步操作的预期结果都是明确且有规范可参考的，而网游中并 不是所有的需求都有一个明确的预期结果，拿技能平衡性来说，我们所谓的平衡也只是相对的平衡，而非绝对的平衡。没有什么明确的参考参数。只能根据以往游戏的经验获得一个感知的结果。 ii. 网络游戏中的某些功能是有预期结果可参考的。例如组队、交易，而另外一些 带有策划创意的功能，却是根据策划个人的理解，来确定其预期结果的。人的思考力都是有限的，所以不能保证在他的创意中会考虑到各种各样复杂的细节。也不能够保证这个创意就可以完全被用户所接受。 当你作为游戏测试人员时，很多时候你需要做的不仅仅是验证功能。也需要帮助开发者和用户找到一个互相容忍的平衡点。游戏软件的测试员带有对策划需求的怀疑，力求通过自己的努力在玩家和开发者之间将可能产生的矛盾减小。 b) 通用软件开发过程中需求变更少，游戏软件开发过程中需求便更快 i. 通用软件的使用人群和软件的功能针对性，决定软件从开始制作就很少再有新 的需求变更。而游戏软件，为了满足玩家对游戏的认可度，策划需要不断的揣摩玩家的喜好，进行游戏功能的改进。加之网游制作本身就是一个庞大复杂的工程，开发者不可能做到在开发的前期，就对游戏架构及扩展性做出最好的评估。所以导致为了满足用户的需求而不断的进行一些基础架构的修改，基础架构的修改必然导致某些功能的颠覆。所以就出现了，游戏开发过程中的一个恶性循环，当基础架构修改到满意了，玩家的需求又有了新的变化，随之而来的又要进行新的调整，再进行新的修改。最终导致了游戏软件的开发周期不断加长。任何一个有经验的团队，对于每一个影响基础的改动都应该做出正确的评估。 二、网游有哪些测试内容 a) 性能 i. 客户端性能 ii. 服务器端性能 1. 服务器 2. 数据库 iii. 网络 b) 功能 i. 从运行完game.exe打开游戏界面后可进行的各种操作、玩法 ii. 界面 iii. 音乐 c) 自动化 i. 测试工作组织实施中需要的工具、软件、平台的开发 ii. 自动化的回归测试作用：游戏中基础的、变动不大的、出错率高的、可进行 checklist重复测试的功能、性能等自动化是一个好方法 iii. 任何时候自动化都取代不了人脑，它只是将一些重复性的劳动从我们测试人员 身上去掉，让我们有更多的时间做更有意义的事情，如果你觉得你做一件事情是重复的，且有规律可行的，不防考虑自动化 三、游戏中针对功能性测试测试用例编写浅谈
国际体验设计协会IXDC 历届大会精彩集锦
游戏用户体验大会 互联网产品大会 交互设计体验周
作者：sunli 制作时间：2008年10月份 个人空间地址：
[url]http://www.51testing.com/?89706[/url] 本文档仅供学习参考，请误擅自转载
2 / 3 先了解下游戏中有哪些功能： a) 游戏发开中的功能有哪些 i. 不同的游戏对于功能的划分不同，但是目前主流一些功能划分中有以下内容： 1. 基础操作 2. Npc 3. 地图 4. 装备 5. 剧情 6. 技能 7. 人际 8. PVP 9. …… 这样我们很简单的将整个游戏的功能进行了划分，划分完毕，下来的工作就是针对某个功能的测试了。很多人都问过一个问题，游戏测试中测试用例到底有什么用。下面继续~ b) 游戏测试的测试用例有什么作用 i. 测试执行过程中，按照用例指示的操作检查操作结果是否正确，记录测试过程 中发现的bug ii. 按照用例的执行结果确认功能的通过与否，也有的按照用例的覆盖率来确定单 服测试的通过与否 iii. 便于回归测试的执行 这样讲应该比较明白了吧。 c) 测试用例应该包括什么——测试执行过程中所需的所有信息，举例说明下。例如： i. 表头：功能名称、案例编写人员、编写时间、测试人员、测试时间 ii. 正文：功能点、测试点、测试输入、预期结果、实际结果 iii. 用例执行结果统计 d) 功能点模块化理念 都知道一个复杂庞大的系统，程序在实现时会将其分成若干模块按照模块功能优先级进行实现。我们测试过程中也采用这种方法，将复杂的功能点按照实现功能进行分类，分类后的测试点，再进行分类，直至细分成为一条条用例。就像庖丁解牛那样。 按照等价类划分法，将同一判断条件的测试点组成一个集，在这个条件基础上再次判断的条件，我们假设它已经成立。这样在用例设计过程中就需要测试人员清楚的知道，哪些条件是一类需优先确认的，哪些是以这类条件为基础的。我们最终形成的测试用例一定确保的是一条用例只检查一个测试点。 这样设计也有另外一个好处，如果一条用例不能走通，其它的还可以继续检测，经常会遇到测试过程中由于一个bug，导致测试工作停滞。现在这样子我们就可以采取脚本调试，或者其它方法跳过有bug的测试内容，继续进行其它测试点的测试了。 e) 场景测试法协助功能点细分 游戏测试中，场景测试方法是经常用到的一种方法，什么是场景测试法，及按照功能设计要求，在脑中模拟出来的一个功能使用时的操作流程。按照每步操作的针对点，将针对点划分为所用例设计时的小功能点。划分时需每步针对点的各种检查点分到该功能点内设计为该功能点的检查点。再根据检查点进行测试输入（及操作过程）的编写。用例编写过程中的思考方式就如上了。讲起来比较抽象，希望对
作者：sunli 制作时间：2008年10月份 个人空间地址：
[url]http://www.51testing.com/?89706[/url] 本文档仅供学习参考，请误擅自转载
3 / 3 大家有所帮助。 f) 用例的设计原则——一直有人问到底要详细到什么程度 i. 我们不期待用例编写到任何人都可以执行，也没有这个必要 ii. 我们针对的是网游的测试人员，至少是玩过网游的人，这些人对于游戏中的基 础设定都有认识，我们不可能对着一个不知道任务界面是什么的人大讲怎么测试任务。所以我们用例编写的原则就是针对我们测试组内的测试人员。 iii. 但是，请不要简略到别的测试人员看不懂，特别是当你是专职的用例编写人员 时，编写时请多考虑下语言描述的方式。请让你的同伴可以看懂，你所要表达的意思。 iv. 用例是没有固定格式的，它的主要原则就是，测试中所需所有信息，我通过你 的文档都能够获取到。所以不要再执着的像别人要模板。模板你自己都可以设计，发挥你的创意。 四、编写过程注意事项 与设计人员的沟通 拿到一份文档时请不要急于编写，在这之前很多事情需要做，请先将文档阅读至少三遍，然后思考下，你自己大脑中是否有你所看文档功能点的一个流程图，当确认已经准备好了。开始设计用例，用例设计的过程就是与设计人员不断沟通，深入了解功能的过程。你会发现，或许跟你之前流程图中想象的并不完全一样。这个时候不必惊讶，去找他们核对就好。不怕发现问题，就怕没有发现问题，最终做了很多无用功。编写过程中发现的没有预期结果的内容，请及时与策划人员、程序人员核对，必须三方核对。核对完毕提醒策划人员及时更新设计案，提醒程序人员设计案新修改内容。这样你会发现，设计测试用例过程的本身就是发现策划案不完善的过程。 请运用你的思维，采用边界法、等价类划分法、错误推断法、以及以往的经验，将每一个测试点的所有需检查点进行充分的设计。发挥你的主动性，和测试组内其它人探讨你认为可能存在风险的测试点，以便得到更多有价值的信息

⑵ 冒烟测试是什么

冒烟测试和回归测试的区别
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

冒烟测试冒烟测试( *** oke test)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Tes穿优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。

冒烟测试是自由测试的一种。
什么是软件冒烟测试，希望有个实际例子说明
冒烟测试，是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑的起来，可以进行后续的正式测试工作。

举个简单的例子：新开发一个加法软件，答错后会显示正确答案。测试者故意输错答案后却没有显示正确答案，就直接退回给开发人，不必去考虑其他原因。这个就是冒烟测试。
冒烟测试是什么
冒烟测试是指对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
什么是冒烟测试及实际工作中如何操作
在水管系统应用中，冒烟测试是指在水流经管路系统之前，先用实际的烟雾穿透整个管路系统，从而检查出是否存在渗水的地方。在木制乐器的修理应用中，做冒烟测试时先堵住乐器的未端,然后把烟从另一端吹入检测是否有渗漏（这种检测方法不常用）。在电子工程领域的应用中，冒烟测试是指当电路设计好，第一次加电自检时检测在设计或线路上是否存在缺陷，如果存在缺陷常会出现板子冒烟的现象。在娱乐业应用领域，冒烟测试时使用大量的演习烟雾，以确保在事件发生期间在案发现场的烟雾探测器不会被引发爆炸。软件工程中的tt应用：冒烟测试是指对提交测试的软件在进行详细深入的测试之前而进行的预测试，这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题。冒烟测试可以由开发人员执行，也可以由测试人员来执行。即，在版本编译后正式提交测试之前由开发人员执行；或开发发布版本后，测试人员在接受这个版本作为正式版本进一步测试前执行。微软提出在审查了变更的代码后，冒烟测试是确认修复的缺陷及功能变更是否有效的最经济有效的方法。冒烟测试能手动执行，也可以在版本编译后自动化执行，它是对基本功能的确认，非深入测试，但要覆盖到面，即所有的更改点都要进行确认。采用自动化执行是，可以结合每日构件后进行自动化的每日 *** oking test，如果测试通过，则把更改后的代码自动合并到主干代码仓库中，作为正式提交测试的版本。对于 *** oking test在软件开发过程中的应用，下面提出一种可实施的步骤：1. 根据软件的变更，包括新需求的实现、bug修复，设计出更改满足预期的功能级checklist。2. 准备好测试环境。如：软件的运行环境是嵌入式产品，如手机，数码相机，医疗仪器等，需准备好用户使用的真实运行环境。如果是windows平台运行环境，请准备干净的操作系统。3.执行checklist，确认基本功能有效，足以支持更进一步的详细、全面测试。文章来源于领测软件测试网
冒烟测试又叫什么
冒烟测试是指对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
软件测试的冒烟测试一般在哪个阶段测试呢
冒烟测试在刚开发完的时候进行的。

关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的 基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。
冒烟测试和回归测试的区别
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

冒烟测试冒烟测试( *** oke test)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。

冒烟测试是自由测试的一种。
软件测试方法的测试分类
β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。当开发和测试要完成所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。α测试_Alpha测试α测试，英文是Alpha testing。又称Alpha测试.Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。可移植性可移植性测试，英文是Portability testing。又称兼容性测试。可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。 用户界面测试，英文是User interface testing。又称UI测试。用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。 冒烟测试，英文是Smoke testing。冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。冒烟测试的对象是新编译的每一个需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。 随机测试，英文是Ad hoc testing。随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressive testing)一起进行。
软件测试的目标和准则是什么？有哪些测试方法？测试步骤有哪些
具体地讲，测试一般要达到下列目标：

1、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。

产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期利益看，这是很不划算的。领测认为接触过的软件产品，很少有向方正这样大大的产品、薄薄的文档。

当然，书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难，也是最容易被忽略的。

最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。

2、 确保产品满足性能和效率的要求

使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。

用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。

3、 确保产品是健壮的和适应用户环境的

健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。

另外就是不能假设用户的环境(某些项目可能除外)，如：报业用户许多配置是比较低的，而且是和某些第三方产品同时使用的。

测试的原则---Good Enough

对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的， 什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。最明显的例子就是FIT3.0中文报版的产品测试。

测试的规律----木桶原理和80-20原则

1、木桶原理。

在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

2、 Bug的80-20原则。

一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

软件测试的方法：

1、按是否查看程序内部结构分为：

（1）黑盒测试（black-box testing）：只关心输入和输出的结果

（2）白盒测试（white-box testing）：去研究里面的源代码和程序结构

2、按是否运行程序分为：

（1）静态测试（static testing）：是指不实际运行被测软件，而只是静态地......
跪求“冒烟测试”具体步骤
冒烟测试

冒烟测试 ( *** oke testing)，据说是微软起的名字。在《微软项目求生法则》一书第 14 章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。

冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷紶电路板可能会短路，板子冒烟了。

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

在一般软件公司的软件编写过程中，内部需要编译多个版本 (Build)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等 Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。

新版本的基本功能确认检查的测试，有的公司称为版本健康检查 (Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查 (Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查 (Build Installing Check)。

随机测试

在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试 (Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例 (TestCase) 没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。须注意针对一些特殊情况点、特殊的使用环境和可能并发性问题进行检查。尤其对以前测试发现的重大 Bug，进行再次测试，可以结合回归测试 (Regressive testing) 一起进行。

理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。

⑶ 运行游戏脚本错误是怎么回事

是你电脑装了一个软件数据的错误。 不必删除文件，只要安装语言就可以了，或者改动一下数据。 下面三个方法供你选择： 1.删文件 C:\Program Files\Alwil Software\Avast4\CHINESES\HELP\CheckListSimple.chm 2. 找到avast!安装目录下的DATA文件夹，打开“avast4.ini”配置文件，定位到：[Simple] ShowHelpCheckList=0 将“=0”改为“=1”即可。 3.就是重新安装一个英文语言。..............

⑷ shell脚本7---图形化shell

select 命令允许从单个命令行创建菜单，然后在提取输入并自动处理。格式如下：

list参数是构成菜单的空格分隔的文本选项列表。select命令会在列表中将每个选项作为一个编好号的选项显示，然后为选项显示一个特殊的由PS3环境变量定义的提示符。
举例

执行上面的脚本会有如下输出

在使用select命令时要注意，存储在变量中的是整个文本字符串而不是与之关联的数字。

dialog命令使用命令行参数来决定生成哪种窗口部件（widget）。部件是dialog包中窗口元素类型的术语，dialog支持的部件类型

创建一个message box，标题是Message，内容是“Hello, world!”。高是5，宽20，会有一个OK按钮在上面。
大多数的部件创建格式都是相同的：一个可选的title，对话框类型，显示的文本，对话框的高和宽，外加其他额外的参数。

这个命令运行后，在对话框上会看到两个按钮，分别写着"Yes"和"No"。如果选择yes那么返回给shell的状态码就是0，选择no返回的是1。

infobox只显示一段信息，而不用等着用户按OK按钮。

inputbox允许用户输入一串字符，在用户按OK之后，字符被写道标准错误输出或者指定的文件描述符。

textbox是一个简单的文件查看器，参数是一个文件名。常用的方向键可以使用，或者vi的方向键。

格式如下

menu用来创建一个可以被选择的菜单。每一个菜单由tag和与之关联的item组成。用户可以使用光标来选定tag并按enter键。被选择的itag会被选到标准输出，举例如下:

checklist展现给用户一系列选项，可以用space键来选择。

第三列是初始状态，可以是on或者off。

和checklist很像，但radiolist要求用户必须选择一个选项，且只能选择一个。

一个简单的例子如下:

更多例子参考 网络文章

⑸ delphi中 checklistbox怎样根据数据值做出选中或没选中

增加Items时，使用AddObject方法，把当前记录的Kek值存储到内存堆(heap)中，然后把此内存地址转化为TObject对象引用，并在AddObject方法中使用。简单地说，就是让每个Item记住它们对应的数据库记录。

然后，根据数据库中不同的结果，取当前记录的Key值，到Items中找到相应的条目，然后再根据当前记录业务字段的值，修改找到条目的checked状态值。

⑹ 项目管理的有效工具---Checklist

你有没有遇到这样的情况，

你可能还遇到过这种情况，

如何避免这样的情况呢？

也许checklist可以帮助你解决，上班出门前记住这个口诀，伸手要钱（身手钥钱），身--身份证，手--手机，钥--钥匙，钱--钱包，每次出门默念一遍，检查自己带的东西； 去超市买火锅前，不如在手机记事本上列个火锅材料清单，到超市对着清单逐一check。我们把这类清单或者口诀叫做checklist。

Checklist的应用非常广泛，不仅仅是应用于日常生活，还会应用在复杂，难度高，高风险的传统行业中，更多应用在创新性的行业中。

不信？给你举栗子

1935 年，波音公司的B-17试飞机型，因为飞行员Major Ployer P. Hill对新机型不太熟悉，导致误操作，机毁人亡。而后，对此机型，波音公司提供给非常简单操作checklist，让飞行员按照checklist进行机械化操作，从此，此机型没有发生过误操作事故。

同样在医疗领域，目前也已经大量运用了checklist，比如外科手术。

这些checklist不但能救命，还能给医院或者飞机公司带来极好的声誉。

建筑行业就更加多的应用了。

就是互联网创业公司也在使用checklist，以YC孵化的Homejoy公司为例子（尽管该公司已经关闭，有点可惜，但不妨碍作为例子），就算是互联网家庭保洁公司也用checklist。

除了这些，还有通用的结婚checklist。

而我们的日常项目管理中呢，同样需要这样的checklist。

假如把项目经理当做导演，那么必然需要安排各种演员，角色什么时候做什么事情，而每一个事情，需要做成什么样子，就需要一定的check，因此，定义每个事情的checklist是至关重要的。

如果你去看下IBM的IPD流程，基本上各个评审点，都会有checklist，而这个checklist也就是流程里面的精髓了。

因为我们需要用这些checklist尽量减少项目结果的不确定性。

你有你自己的checklist吗？比如验收新房子的交付，验收新买的车子。