- 博客(1169)
- 收藏
- 关注
RSS订阅原创 和测试角色相关的问题
曾经，我主管的某项目有重要的改进，这个改进经过研究员的研究、开发人员的设计、美工的美化、两个开发人员的配合实现、项目管理人员的督促、测试人员的测试，最后所有人都号称做好了，上线了!于是找了一个专业人士，求了好几次(专业人士很忙的)，在软件上市之前才拿到专业的文案，于是，几个人把文稿复制/粘贴几次之后，软件就向全世界发布了。我们团队的另一个windows Phone的应用也要发布，这次专业人士又出手了，写了175个英语单词的介绍，极尽溢美之词，而且找不到明显的语法问题!.专业人士做完之后，谁来负责测试?
2026-01-09 14:00:55
77
原创 UML活动图和状态图本质上属于半形式化模型
不同UML工具（如Enterprise Architect, Visual Paradigm, 开源工具）对同一张图表的“执行”或模拟可能产生细微差别，这反映了底层语义解释的不统一。：图中通常大量使用文本标签（如动作名、守卫条件、效果表达式），这些文本本身是自然语言或编程语言片段的混合，不属于形式化语法的一部分，需要人工解读。上下文中，并通过额外的约束、配置或元模型（如使用OMG的“精确UML”子集或特定领域Profile）来限定其使用时，它们可以。状态、事件、转移、守卫条件这些概念都有严格的数学对应。
2026-01-09 01:15:00
164
原创 流程的阶段（或称“状态”）以及事件
活动图的核心是和，它描述的是，而不是状态序列。您提到的“Payment completed”和“Awaiting shipment”是我们在时使用的术语，但在转换为UML活动图时，它们需要被翻译成对应的。
2026-01-08 01:00:00
248
原创 实践中的过程状态运作方式
在实际系统（尤其是使用工作流引擎如 Camunda、Activiti 或自定义状态机时）中，通常会有一个。（Activity），而这些活动的成功执行又会反过来推动状态变迁。：订单已收妥款项，货品已准备就绪，正等待仓库进行物理发货操作。：通知仓库管理系统（WMS）生成拣货单。好的状态名本身就是一个清晰的业务信号。：当仓库员工点击“发货”时，系统执行。：在管理后台筛选“待发货”订单列表。：面向数据，描述实体生命周期（如。：面向业务，描述流程阶段（如。保存在各自的数据表字段中。：“您的订单状态：待发货”
2026-01-08 01:00:00
633
原创 系统级的Activity Diagram，Object Node如何表示？
概念错误表示 (作为Object Node)正确表示一个独立的，含义模糊，无法操作。1. 活动节点[等待发货]活动本身就是状态。2. 流程数据对象。3. 信号事件：发送。关注点混淆了“数据状态”和“控制状态”。分离关注点• 活动图表达控制流（流程状态）。• 对象节点表达数据流（对象状态）。对设计的指导不明确，会导致设计出奇怪的类或属性。清晰• 方式1：直接对应一个服务或函数。• 方式2：对应一个流程控制实体类。• 方式3：对应消息队列或事件系统中的事件。结论。
2026-01-07 09:44:30
630
原创 活动图用于工作流的状态机和业务对象状态机
紧密耦合：业务对象的状态变化作为事件，驱动工作流状态机的阶段转换；而工作流状态机的阶段活动，又是触发业务对象状态改变的主要执行者。理解这种区别与联系，对于设计清晰、可维护的复杂系统至关重要。它不关心订单本身是“待支付”还是“已支付”，它只关心。它不关心发货这个动作是系统自动触发还是人工触发。阶段，该阶段的活动尝试预留库存。这个阶段的活动会调用支付网关，最终将。这个条件，触发了工作流状态机从。（常体现为其他对象的状态变化）。它定义了业务规则：订单必须在。，触发了工作流状态机转换到。：订单已接收，初始阶段。
2026-01-07 09:09:44
673
原创 程序的质量
程序的质量体现在软件外在功能的质量。衡量软件的功能，基本的判断可以用"是|否"来判定，例如，一个字处理软件能否通过拷贝/粘贴与其他软件传递信息。进一步，可以用复杂的多维度特性的综合指标来衡量，例如，衡量一个搜索引擎的质量，业界通常用准确度(Precision)和覆盖率(Recall)的综合指标([注释1]来表示。各种功能还有很多特性需要衡量，例如，网站显示查询结果的速度;订票网站能并发处理业务的吞吐量;支持同时在线用户的数量。程序的质量还有其他方面，例如用户体验的质量、国际化的质量和安全性的质量。
2026-01-06 06:58:52
90
原创 软件的质量
从浪漫的角度看软件开发，人们不禁想象软件团队一开始就理解了用户的需求，完美的分析文档如高屋建瓴般流出，软件工程师在此基础上开发了各种完美的功能，按时交付给用户;读者可以问一下周围的亲朋好友，大家使用的软件质量如何?相信回答绝不是"浪漫"。这个词应用非常广泛，在不同的语境中有不同的定义。有多种方式可以用来剖析软件的质量，关于这方面的学术论文也不少。在本书中，我们知道:软件=程序+软件工程那么我们可以套用这个公式，看看"程序的质量"和"软件工程的质量"如何影响软件的质量。软件质量=程序质量+软件工程质量。
2026-01-06 06:57:58
307
原创 如何测试效能
(Performance Counter)，这时，我们可以收集代理机器(Agent，模拟的服务请求从这里发出)和控制机器(Controller)的效能数据，更重要的是收集网络服务器的效能数据(如图 所示)。如效能测试、负载测试、压力测试。压力测试:在高峰压力是200%上座率，全国铁路系统增加20%的列车，持续15天的情况下，期望:列车能到站，乘客能活着下车，系统不至于崩溃。2.负载模型(LoadPatter):模拟的用户量是恒定在一个数值的(如:总是30个用户)，或者是分级进行的(如:开始是5个用户，每。
2026-01-05 13:43:44
405
原创 使用LLM寻找use cases-例子，比价靠谱
在基本流第10步，当商品检查通过后，系统自动创建一个新的换货订单（包含替换商品），并安排发货。其他描述内容（如收集信息、提供商品详情、重新协商、支付等）均为“下订单”用例内的基本流或备选流步骤，不构成独立用例。系统向买家（或客服屏幕）清晰展示完整的订单摘要，包括：商品列表、单价、数量、总价、预计交货日期、收货地址。系统自动生成详细的订单确认（含订单号、商品详情、支付金额、预计交货日期），并通过电子邮件或短信发送给买家。系统根据订单号检查商品是否在可退货期内、商品类型是否支持退货（如非最终销售商品）。
2026-01-04 01:15:00
582
原创 LLM识别UML Use Case
需求中“收集信息”被明确列为接待员的职责之一，且可能独立于预约或入院发生（例如，病人信息更新），因此将其作为一个独立用例。付款、保险和报告处理被描述为“可能也会”执行的职责，它们各自代表不同的业务目标，因此分别作为独立的用例。接待员在病人到达或通过电话时，收集或更新病人的个人、联系及医疗信息。接待员办理病人入院手续，包括为需要住院的病人分配病房和床位。接待员收取病人的费用，将交易记录到数据库，并为病人提供收据。是“办理入院”用例中的一个步骤或子流程，而非独立用例。接待员为病人安排门诊或检查的预约。
2026-01-04 01:15:00
739
原创 大型语言模型的抽象能力与局限
摘要：抽象建模能力指理解概念层次与逻辑关系的能力。大型语言模型(LLM)通过数据训练可识别简单抽象关系，但存在依赖训练数据、缺乏系统推理和上下文敏感等局限。研究表明，LLM能完成基础分类任务，但在处理模糊概念、无明确线索的层次关系时表现欠佳，与人类系统化抽象推理能力仍有差距。其抽象建模能力受限于概率模型本质，难以稳定输出精确的层次结构。
2026-01-03 01:15:00
328
原创 测试报告(TestReport)
在一个阶段的测试结束之后，我们要报告各个功能测试的结果，这就是测试报告。移山公司不喜欢过多的文档，我们就不必洋洋万言了，只需简单地列出一些数字即可，例如:对于某一功能，我们要收集下列数据。4)发现多少测试用例之外的Bug?所有功能的测试报告相加，就能得到整个项目的测试统计信息。这样的信息能帮助我们从宏观上了解还有多少事情没办完，各个功能相对的质量如何。测试报告(TestReport)3)有多少测试用例未完成?1)有多少测试用例通过?2)有多少测试用例失败?
2026-01-02 01:15:00
109
原创 测试中的报告
在测试中，如果发现了问题，我们就得报告，在TFS的软件过程模型中，"Bug"是第二个工作项类型。在本书第4章"两人合作与结对编程"的练习中，有些团队成员已经互相找过Bug，但是当时项目相对简单，对Bug的格式并未做严格要求。小飞拿到这个Bug，也是哭笑不得，试了试移山网站的各个页面，好像也都正常。3)如有其他补充材料，例如相关联的Bug、输出文件、日志文件、调用堆栈的列表、截屏等，应保存在Bug对应的附件或链接中4)还可以设置Bug的严重程度(Severity)、功能区域等，这些都可以记录在不同的字段中。
2026-01-02 01:00:00
131
原创 测试工作中的文档
阿超:各类人员都有文档要写，但是在敏捷模式中，我们要坚决避免为了写文档而写文档。然后还要写测试设计说明书(TDs)、测试用例(TestCase)、程序错误报告(BugReport)和测试报告(Test Repor)。测试计划和测试总纲主要说明产品是什么，要做什么样的测试，时间安排如何，谁负责什么方面，各种资源在哪里，等等。正如开发人员有功能设计说明书，测试人员也要有测试设计说明书，告诉测试人员要如何设计测试。3)如何去测试(采用什么具体方法，如何做测试自动化，准备什么样的测试数据等)?
2026-01-01 01:15:00
233
原创 测试中的文档
a.等价类划分不同的测试数据，如果只是重复触发了同样的处理逻辑，或者可能的错误，那么这些测试数据是等价的，它们属于同一等价类。例如，如果程序期待一个"日期"类型，那我们可以构造包含下面各种边界条件的数据:一年的第一天，最后一天，平年的2月28日，闰年的2月29日，或者它们的前后一天，等等。c.常见错误根据经验推测程序通常容易出错的地方，从而更有效地第设计测试用例，例如空文件名，在期望数字的字段填入文字，等等。具体地说，测试用例描述了如何设置测试前的环境，如何操作，预期的结果是什么。
2026-01-01 01:00:00
697
原创 “小强“大扫荡(BugBash)
答:Bug Bash，或者叫Bug Hunt，简而言之，就是大家一起来找小强的活动小强大扫荡。一般是安排出一段时间(如一天)，这段时间里所有测试人员(有时也加入其他角色)都放下手里的事情，专心找某种类型的小强。.鼓励测试队伍学习并应用新的测试方法，例如在做完"软件安全性测试"培训后，立马针对"安全性"做一次小强大扫荡，或者为"全球化/本地化测试"做一次小强大扫荡也是很常见的。要记住，最好的测试，是能够防止小强的出现。问:我们已经讲了太多的测试了，好像微软还有一个叫"BugBash"的活动，是啥意思?
2025-12-31 01:15:00
447
原创 似是而非的测试观念
阿超:这是远远不够的。如果你在项目后期发现了问题，可问题的根源却往往是项目早期的一些决定和设计，这时候，再要对其进行修改就比较困难了。阿超:如果你的目的是尽快让问题显现，尽快找到问题，那我建议用Debug版本，"尽快发现问题"在软件开发周期的早期特别重要。如果你的目的是尽可能测试用户所看到的软件，则用Re-lease版本，这在软件开发的后期特别是执行效能和压力测试时很有价值。这就要求我们测试人员的代码质量特别高，因为测试人员是最后一道防线，如果我们的代码和测试工作有漏洞，那么Bug就会跑到用户那里去。
2025-12-31 01:00:00
585
原创 内部/外部公开测试(Alpha/Beta Test)
在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会让特定的用户(Alpha/Beta用户)使用正处于开发过程中的版本，用户会通过特定的反馈渠道(E-mail、BBS、微博等)与开发者讨论使用中发现的问题，等等。按惯例来说，AlphaTest一般指在团队之外、公司内部进行的测试;在网络普及之前，做Beta Test费时费力，成本较高，现在由于网络的传播速度很快，与外部用户的联系渠道很畅通，很多外部用户都想先睹为快。
2025-12-30 01:15:00
174
原创 易用性测试(Usability Test)
但是我觉得"易用性测试"似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的，而是由对软件设计和软件可用性有大量研究的"可用性设计师"来实行。为了弄清楚软件的可用性，并了解用户的需求，移山公司的员工特地做了一次易用性测试小飞学了很酷的"WPF/我佩服"Web界面技术，然后做了一个小游戏-3D挖雷。苹果公司的Macintosh团队在发布革命性的Mac电脑之后，收到了不少用户的反馈，说用鼠标拖拽文件进行拷贝时，总是要反复操作很多次才能成功，团队内部反复试验，都不能重现这个问题。
2025-12-30 01:15:00
352
原创 压力测试(Stress Test)
经过47.9天之后DWORD会溢出，GetTickCount()会从O开始重新计数，你的程序如果用了不同的TickCount来计算时间，不要假设后来的Tick-Count一定会比先前的TickCount大，也许系统在运行一段时间后会出现莫名其妙的错误，但是系统重新启动后，又找不到原因。做过网络服务的都知道，网络的负载有时间性，负载压力的波峰和波谷相差很大，那么如果每时每刻负载都处于峰值，程序会不会垮掉?但是，如果用户提交的请求一部分执行，另一部分没有执行，或者出现用户信息丢失，这些都是不正常的结果，
2025-12-29 07:14:33
315
原创 效能测试 (Performance Test)
和别的测试不同，效能测试对硬件要有固定的要求，而且每次测试需要在相同的机器和网络环境中进行，这样才能避免外部随机因素的干扰，得到精准的效能数据。1.现实的静态数据比如上面提到的数据库的各种记录，如果要模拟一个实际运行的商业网站，除了一定数量的用户和商品记录外，还得模拟在运行一段时间后产生的交易记录。2.令用户满意的服务质量其次要定义什么样的质量是令用户满意的。2.服务质量的细化有些请求，是要对数据进行"写"操作，可以要求慢一些，比如"用户下订单，购买商品"，对这一服务质量，请求可以放宽为5秒钟，甚至更长。
2025-12-29 07:13:43
276
原创 伙伴测试(Buddy Test)
我们这里要讲的伙伴测试是指开发人员可以找一个测试人员作为伙伴(Buddy)，在签入新代码之前，开发人员做一个包含新模块的私人构建(Private Build)，测试人员在本地做必要的回归/功能集成/探索测试，发现问题直接与开发人员沟通。2.产生很多Bug。这些Bug都要录入到数据库中，经过层层会诊(Triage)，然后交给开发人员，然后再经历一系列Bug的旅行，才能最后修复，这样成本就变得很高。如上所述，在一个复杂系统的开发过程中，当一个新的模块(或者旧模块的新版本)加入系统中时，往往会出现下列情况。
2025-12-28 08:27:49
174
原创 场景测试是什么意思
答:就是指以场景为驱动的集成测试，关于"场景"，大家可以看本书第10章"典型用户和典型场景"一节，里面有对场景专门的介绍。我们在做场景测试的时候，就需要考虑在现实环境中用户使用软件的流程是怎样的，然后模拟这个流程，看看软件能不能满足用户的需求。以一个图像编辑软件为例，这个软件的各个模块都是独立开发的，可是用户有一定的典型流程，如果这个流程走得不好，哪怕某个模块的质量再高，用户也不会满意。如果这里面各个模块的用户界面不一致(即使是"确认"和"取消"按钮的次序不同)，用户使用起来也会很不方便。
2025-12-28 08:27:03
256
原创 验收测试(Acceptance Test)
但是，有一个重要的问题要提请大家注意:"可用"，并不是指软件的所有功能都没有问题，而是指在目前的用户场景中，按照场景的要求进行操作，都能得到预期的效果。在"基本场景"的基础上，把系统在理论上目前支持的所有场景都列出来，然后按功能分类测试，如果测试成功，就在此场景中标明"成功"，否则，就标明"失败"，并且用一个或几个"小强"/Bug来表示失败。同时，还有对系统各个方面进行的"验收"测试，如系统的全球化验收测试，或者针对某一语言环境、某一个平台做的验收测试。例如:场景中没有考虑到多种语言设置。
2025-12-27 01:15:00
287
原创 “探索式“的测试(Ad hocTest)
探索式测试的测试流程是不可重复的，因为它的测试都是"特定"测试，没法重复。比如:测试人员小飞拿到了一个新的构建，按计划是进行模块A的功能测试，但是他灵机一动，想看看另一个功能B做得如何，或者想看看模块A在某种边界条件下会出现什么问题，于是他就"Ad hoc"一把，结果还真在这一功能模块中发现了不少小强。"Adhoc"也意味着测试是尝试性的，"我来试试，在这个对话框中一通乱按，然后随意改变窗口大小，看看会出什么问题......"，如果没问题，那么以后也不会再这么做了。
2025-12-27 01:15:00
315
原创 代码覆盖率测试(Code Coverage Analysis)
前面单元测试中提到了代码覆盖率，简单来说代码被执行过，就是被"覆盖过"。如果一段程序运行一组测试用例之后，100%的代码被执行了，是不是意味着再也不用写新的测试用例了呢?1.不同的代码是否执行，有很多种组合。一行代码被执行过，没有出现问题，并不表明这一行代码在所有可能条件的组合下都能正确无误地运行。4.代码覆盖不能测出时序问题，即由时序导致的程序错误(例如:线程之间的同步)。2.代码覆盖不能测出未完成的代码(所缺少的逻辑)导致的错误。5.不能简单地以代码覆盖率来衡量代码中与用户界面相关的功能的优劣。
2025-12-26 01:15:00
112
原创 构建验证测试(Build Verification Test，BVT)
例如，对于字处理软件来说，其基本功能是必须能打开/编辑/保存一个文档文件，但是它的一些高级功能，如文本自动纠错，则不在其中;又如，对于网站系统，其基本功能是用户可以注册/上传下载信息，但是一些高级功能，如删除用户、列出用户参与的所有讨论，则不在其中。顾名思义，构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。在大多数情况下，这些验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。级，开发人员要首先处理。
2025-12-26 01:15:00
459
原创 单元测试(UnitTest)
有时单元测试报了错，再运行一次就好了，于是后来大家就不想花时间改错，多运行几次，有一次通过就行了;.单元测试中我们还要测试效能和压力，花了很多时间;.我们都这么费劲地测了，那还要测试人员干什么?单元测试耗费的时间要比写代码的时间还多，把代码覆盖率提高到90%以上太难了;单元测试中的好多错都与环境有关，在别人的机器上都运行不成功;单元测试(UnitTest)
2025-12-25 07:31:54
115
原创 按测试设计的方法分类
例如，在测试程序内部基本模块时(单元测试)，通常要求由对程序结构非常了解的程序员来设计，这是因为内部模块的"行为"和程序的外部功能并没有直接的关系，而且对内部基本模块的"行为"通常没有明确的定义。另一个例子是软件的"易用性测试"，在设计此类测试时，没必要纠缠于程序的内部结构，而是应着重于软件的界面和行为。白箱:指的是在设计测试的过程中，设计者可以"看到"软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法。问:有人说"黑箱"，有人说"黑盒"，到底是"箱子"还是"盒子"?
2025-12-25 07:30:39
245
原创 评价标准
如果软件和用户的工作相关(而不是简单的游戏)，那么基本的提示和帮助文档还是很有必要的，而且也要提供便利的检索功能。例如，给病人使用的网络挂号系统，就不宜使用只有医务工作者才熟悉的术语和界面(最坏的结果是使用软件工程师才熟悉的术语和界面，而医护人员和病人对此很不熟悉)软件的反馈要避免带给用户惊奇例如，在用户没有期待对话框的时候，软件从奇怪的角度弹出对话框，或者给用户提示"找不到对象"。对于长期使用某个软件的用户，软件应该能适应用户的使用习惯，让用户越用越顺手，最后产生感情上的好感和忠诚度。
2025-12-24 12:26:40
528
原创 用户体验设计的步骤和目标
作为练习，同学们可以讨论一下，如果用户用的是VI(或者Vim等变种)，如何完成这一任务，这个编辑器的认知阻力有多大。在上一节提到的三种设计层次之外，用户体验设计的一个重要目的就是要降低用户的认知阻力(Cog-nitive Friction)，即用户对于软件界面的认知(想象某事应该怎么做，想象某操作应该产生什么结果)和实际结果的差异。我们来看一个具体的例子，如果用户(一个生活在中国二线城市，有高中文化水平，有基本计算机基础的成年人)要在一个文稿中写居中的一句话，在下表所列的各种工具中，用户是怎么才能做到的。
2025-12-24 12:24:02
546
原创 软件的情感设计
诺尔曼进一步阐明了设计的三个层次，以及对应的产品特性:本能(Visceral)层次的设计-外形行为(Behavior)层次的设计-使用的乐趣和效率反思(Reflective)层次的设计自我形象、个人满足感、回忆三个层次的因素相互交织，共同影响了用户体验。在个人电脑发展的初期，大部分显示器都是黑白的(有大约256种灰度等级)，当彩色显示器刚出现的时候，设计师唐纳德.诺尔曼(Don Nomman)借了一台给自己用，他发现彩色显示器并没有增加可分辨的价值，但是实验结束后，他自己却很不愿意把彩色显示器还回去。
2025-12-23 01:15:00
824
原创 不让用户犯简单的错误
大家坐飞机时，都会看到座位前有一个小遥控器，它能控制座位上方的小电视、阅读灯，还能呼叫空乘人员。你会注意到遥控器的周围，尤其是右上角有不少硬物撬动的痕迹，看来一些乘客不得其门而入，干脆来硬的。据说，空姐和空哥们对此类遥控系统一个最大的抱怨，就是乘客会无意中按到"呼叫空乘人员"那个按钮等乘务员放下手中工作跑过去的时候，乘客会一脸无辜地说-啊，我没有叫你啊......如果空姐还没有太疲惫，她们会教育乘客哪个键是做什么用的，然后悻悻而去。我们看一下这几个键，左上角:呼叫乘务员，右上角:取消呼叫，下方:阅读灯。
2025-12-23 00:45:00
375
原创 软件服务始终都要记住用户的选择
在设计软件界面时，我们的设计师经常会画新功能的UI设计图，来征求大家的意见。我注意到大部分设计都假设用户是头一次使用产品，所以没有任何积累的文件、照片、处理过的图像、曾经做过的选择等数据。你的产品是下面的哪一种:a.软件用得越多，一样难用b.软件用得越多，越发难用c.软件用得越多，越来越好用这本书的大部分文字都发表在博客上，我在写博客的时候，就被一个a类型的用户体验折磨了。1.用户上了银行的门户网站，把语言改成English，开始注册，虽然界面不是那么好用，但是经过反复尝试，好歹也做完了。
2025-12-22 07:18:39
306
原创 从用户的角度考虑问题
对于自己的产品，如果我们的员工经常"吃狗食"，上面提到的问题就不会出现除非微软员工连"a"都需要解释......但是，这种优秀的传统也有一个副作用，由于我们十分了解自己写的软件，而我们的心理、技术能力和一般用户有很大差别(参见下文提到的"认知阻力")，所以也。很多程序员都没有意识到，用户对那些选项对话框中的种种选择会有很大的畏难情绪，而程序员则觉得自己开发的功能必须有几个高级选项，才显得有水平。设计不同于传统的数学题，是没有唯一的标准答案的。有一颗为用户着想的"同理心"，是好的产品设计的出发点。
2025-12-22 07:17:57
676
原创 用户体验的要素
怎样让用户在第一次使用的时候，少花时间(或者不花时间)在对用户没有价值的部分(如配置软件的基本设置、登录、填写用户的各种属性等)，而把大部分时间花在有实际价值的功能(如完成任务、消费内容、创建内容)上?大家平时都说要向某某大师或某某产品学习，把最重要的功能做好交给用户，把那些无关紧要的功能藏起来，做减法......但是程序员们还是会想着把高级功能"秀"出来。用户头一回来访问你的网站，你要给他们什么样的第一印象?下面的"设计"大胆地做了减法，解决了老年人使用的难题[注释2]:请问，这是一个好的设计么?
2025-12-21 09:17:49
327
原创 如何避免诧异的反应
在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。问:项目开发中后期，开发人员用工具一统计，乖乖，足足xx万行代码，xx千个存储过程，可是每到给客户演示时，却不时出现程序的各个功能相互不配合，不能自圆其说的尴尬场景，Devleader很郁闷，想想自己可是没少加班啊，代码量也够多，可是问题究竟出在什么方面呢?问:每次里程碑结束后，我们向客户汇报的时候，客户总是会惊讶地说，某某功能不是我们当初商量的那样啊，而PM却也同样一脸诧异地说，不对啊，当时咱们就是这么说好的啊，有文档为证。
2025-12-21 09:15:26
364
测试用的需求文档Methodology for Qualifying Safety-Related Electrical and
2025-04-06
计算机科学与软件工程中的统一大学库存系统（UUIS）功能需求与用例分析
2025-03-13
电子商务系统软件需求规范（GAMMA-J在线商店V1）详解
2025-03-13
水文管理与用水追踪系统的软件需求规范-基于地理信息系统的技术应用与需求分析
2025-03-13
Visual C++ MFC例子，从基础例子到提高，总共11个主题
2024-08-13
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人