-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathsearch.xml
10410 lines (10399 loc) · 807 KB
/
search.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<search>
<entry>
<title>Android随机测试工具Monkey简介</title>
<url>/2019/12/23/android-adb-shell-monkey-abc/</url>
<content><![CDATA[<p>Monkey 是一个在<a
href="https://developer.android.com/tools/help/emulator.html">模拟器</a>或设备上运行的程序，可生成伪随机用户事件（例如点击、轻触或手势）流以及很多系统级事件。您可以使用
Monkey 以随机且可重复的方式对正在开发的应用进行压力测试。</p>
<h1 id="概览">概览</h1>
<p>Monkey
是一个命令行工具，可以在任何模拟器实例或设备上运行。它会将伪随机用户事件流发送到系统中，从而在您正在开发的应用软件上进行压力测试。</p>
<p>Monkey 包含许多选项，主要分为以下四个类别：</p>
<ul>
<li>基本配置选项，例如设置要尝试的事件数。</li>
<li>操作限制条件，例如将测试对象限制为单个软件包。</li>
<li>事件类型和频率。</li>
<li>调试选项。</li>
</ul>
<p>Monkey
在运行时会生成事件并将其发送到系统。它还会监视被测系统并查找三种特殊情况：</p>
<ul>
<li>如果您已将 Monkey
限制为在一个或多个特定软件包中运行，它会监视转到任何其他软件包的尝试并阻止它们。</li>
<li>如果应用崩溃或收到任何未处理的异常，Monkey 会停止并报告错误。</li>
<li>如果应用生成“应用无响应”错误，Monkey 会停止并报告错误。</li>
</ul>
<p>根据您选择的详细程度级别，您还将看到有关 Monkey
进度和所生成事件的报告。</p>
<h2 id="monkey-的基本用法">Monkey 的基本用法</h2>
<p>您可以使用开发计算机上的命令行启动 Monkey，也可以通过脚本启动。由于
Monkey 在模拟器/设备环境中运行，因此您必须从该环境中通过 shell
启动它。为此，您可以在每个命令前面加上
<code>adb shell</code>，或者直接进入 shell 并输入 Monkey 命令。</p>
<p>基本语法如下：</p>
<figure class="highlight plaintext"><table><tr><td class="code"><pre><span class="line">$ adb shell monkey [options] <event-count></span><br></pre></td></tr></table></figure>
<p>如果未指定任何选项，Monkey
将以静默（非详细）模式启动，并将事件发送到目标上安装的任何（及所有）软件包。下面是一个更典型的命令行，它会启动您的应用并向其发送
500 个伪随机事件：</p>
<figure class="highlight plaintext"><table><tr><td class="code"><pre><span class="line">$ adb shell monkey -p your.package.name -v 500</span><br></pre></td></tr></table></figure>
<span id="more"></span>
<h2 id="命令选项参考">命令选项参考</h2>
<p>下表列出了您可以在 Monkey 命令行中添加的所有选项。</p>
<table>
<colgroup>
<col style="width: 0%" />
<col style="width: 43%" />
<col style="width: 55%" />
</colgroup>
<thead>
<tr class="header">
<th style="text-align: left;">类别</th>
<th style="text-align: left;">选项</th>
<th style="text-align: left;">说明</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">常规</td>
<td style="text-align: left;"><code>--help</code></td>
<td style="text-align: left;">输出简单的使用指南。</td>
</tr>
<tr class="even">
<td style="text-align: left;"><code>-v</code></td>
<td style="text-align: left;">命令行上的每个 -v
都会增加详细程度级别。级别
0（默认值）只提供启动通知、测试完成和最终结果。级别 1
提供有关测试在运行时（例如发送到您的 Activity
的各个事件）的更多详细信息。级别 2
提供更详细的设置信息，例如已选择或未选择用于测试的 Activity。</td>
<td style="text-align: left;"></td>
</tr>
<tr class="odd">
<td style="text-align: left;">事件</td>
<td style="text-align: left;"><code>-s</code></td>
<td
style="text-align: left;">伪随机数生成器的种子值。如果您使用相同的种子值重新运行
Monkey，它将会生成相同的事件序列。</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--throttle</code></td>
<td
style="text-align: left;">在事件之间插入固定的延迟时间。您可以使用此选项减慢
Monkey 速度。如果未指定，则没有延迟，系统会尽快地生成事件。</td>
</tr>
<tr class="odd">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--pct-touch</code></td>
<td
style="text-align: left;">调整轻触事件所占百分比。（轻触事件是指屏幕上的单个位置上的按下/释放事件。）</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--pct-motion</code></td>
<td
style="text-align: left;">调整动作事件所占百分比。（动作事件包括屏幕上某个位置的按下事件，一系列伪随机动作和一个释放事件。）</td>
</tr>
<tr class="odd">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--pct-trackball</code></td>
<td
style="text-align: left;">调整轨迹球事件所占百分比。（轨迹球事件包括一个或多个随机动作，有时后跟点击。）</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--pct-nav</code></td>
<td
style="text-align: left;">调整“基本”导航事件所占百分比。（导航事件包括向上/向下/向左/向右，作为方向输入设备的输入。）</td>
</tr>
<tr class="odd">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--pct-majornav</code></td>
<td
style="text-align: left;">调整“主要”导航事件所占百分比。（这些导航事件通常会导致界面中的操作，例如
5 方向键的中间按钮、返回键或菜单键。）</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--pct-syskeys</code></td>
<td
style="text-align: left;">调整“系统”按键事件所占百分比。（这些按键通常预留供系统使用，例如“主屏幕”、“返回”、“发起通话”、“结束通话”或“音量控件”。）</td>
</tr>
<tr class="odd">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--pct-appswitch</code></td>
<td style="text-align: left;">调整 Activity 启动次数所占百分比。Monkey
会以随机间隔发起 startActivity() 调用，以最大限度地覆盖软件包中的所有
Activity。</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--pct-anyevent</code></td>
<td
style="text-align: left;">调整其他类型事件所占百分比。这包括所有其他类型的事件，例如按键、设备上的其他不太常用的按钮等等。</td>
</tr>
<tr class="odd">
<td style="text-align: left;">约束</td>
<td style="text-align: left;"><code>-p</code></td>
<td
style="text-align: left;">如果您通过这种方式指定一个或多个软件包，Monkey
将仅允许系统访问这些软件包内的 Activity。如果应用需要访问其他软件包中的
Activity（例如选择联系人），您还需要指定这些软件包。如果您未指定任何软件包，Monkey
将允许系统启动所有软件包中的 Activity。要指定多个软件包，请多次使用 -p
选项 - 每个软件包对应一个 -p 选项。</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>-c</code></td>
<td
style="text-align: left;">如果您通过这种方式指定一个或多个类别，Monkey
将仅允许系统访问其中一个指定类别中所列的
Activity。如果您没有指定任何类别，Monkey 会选择 Intent.CATEGORY_LAUNCHER
或 Intent.CATEGORY_MONKEY 类别所列的
Activity。要指定多个类别，请多次使用 -c 选项 - 每个类别对应一个 -c
选项。</td>
</tr>
<tr class="odd">
<td style="text-align: left;">调试</td>
<td style="text-align: left;"><code>--dbg-no-events</code></td>
<td style="text-align: left;">指定后，Monkey 将初始启动到测试
Activity，但不会生成任何其他事件。为了获得最佳结果，请结合使用
-v、一个或多个软件包约束条件以及非零限制，以使 Monkey 运行 30
秒或更长时间。这提供了一个环境，您可以在其中监控应用调用的软件包转换操作。</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--hprof</code></td>
<td style="text-align: left;">如果设置此选项，此选项将在 Monkey
事件序列之前和之后立即生成分析报告。这将在 data/misc 下生成大型（约为
5Mb）文件，因此请谨慎使用。要了解如何分析性能分析报告，请参阅<a
href="https://developer.android.com/studio/profile">分析应用性能</a>。</td>
</tr>
<tr class="odd">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--ignore-crashes</code></td>
<td
style="text-align: left;">通常，当应用崩溃或遇到任何类型的未处理异常时，Monkey
将会停止。如果您指定此选项，Monkey
会继续向系统发送事件，直到计数完成为止。</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--ignore-timeouts</code></td>
<td
style="text-align: left;">通常情况下，如果应用遇到任何类型的超时错误（例如“应用无响应”对话框），Monkey
将会停止。如果您指定此选项，Monkey
会继续向系统发送事件，直到计数完成为止。</td>
</tr>
<tr class="odd">
<td style="text-align: left;"></td>
<td
style="text-align: left;"><code>--ignore-security-exceptions</code></td>
<td
style="text-align: left;">通常情况下，如果应用遇到任何类型的权限错误（例如，如果它尝试启动需要特定权限的
Activity），Monkey 将会停止。如果您指定此选项，Monkey
会继续向系统发送事件，直到计数完成为止。</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td
style="text-align: left;"><code>--kill-process-after-error</code></td>
<td style="text-align: left;">通常情况下，当 Monkey
因出错而停止运行时，出现故障的应用将保持运行状态。设置此选项后，它将会指示系统停止发生错误的进程。注意，在正常（成功）完成情况下，已启动的进程不会停止，并且设备仅会处于最终事件之后的最后状态。</td>
</tr>
<tr class="odd">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--monitor-native-crashes</code></td>
<td style="text-align: left;">监视并报告 Android
系统原生代码中发生的崩溃。如果设置了
--kill-process-after-error，系统将会停止。</td>
</tr>
<tr class="even">
<td style="text-align: left;"></td>
<td style="text-align: left;"><code>--wait-dbg</code></td>
<td style="text-align: left;">阻止 Monkey
执行，直到为其连接了调试程序。</td>
</tr>
</tbody>
</table>
<p><strong>来源</strong></p>
<blockquote>
<p><a
href="https://developer.android.com/studio/test/monkey">UI/Application
Exerciser Monkey</a></p>
</blockquote>
]]></content>
<categories>
<category>testing</category>
<category>android</category>
</categories>
<tags>
<tag>android</tag>
<tag>monkey</tag>
</tags>
</entry>
<entry>
<title>测试陷阱分类</title>
<url>/2020/12/21/common-system-and-software-testing-pitfalls/</url>
<content><![CDATA[<h2 id="什么是测试陷阱">什么是测试陷阱</h2>
<p>测试陷阱是指不必要的并且可能意外导致测试不那么有效，高效或者更令人沮丧的表现的决策、思维、行为或不作为。基本上，测试陷阱是一个经常发生的搞砸测试的方式，当测试人员、管理人员、需求工程师和其他测试利益相关者犯了测试相关的错误，并由此产生意想不到的负面后果时，项目就陷入了测试陷阱。</p>
<p>从某种意义上说，测试陷阱的描述构成了测试反模式。然而，术语“陷阱”是专门选择，为那些粗心大意或外行的人唤起隐蔽或不易识别的陷阱的形象。与任何陷阱一样，最好是避免测试陷阱，而不是陷入陷阱后将自己和项目挖出来。</p>
<span id="more"></span>
<h2 id="陷阱分类">陷阱分类</h2>
<p>许多测试陷阱发生在软件依赖系统和软件应用的开发或维护期间。虽然可能没有项目是如此糟糕地管理和执行，从而体验这些缺陷中的大多数，但大多数项目将遭受其中几个。同样，虽然这些测试陷阱并不保证失败，但它们必然带来需要管理的严重风险。</p>
<p>在测试过程中经常观察到的92种陷阱。这些缺陷分类如下：</p>
<ul>
<li>一般测试陷阱
<ul>
<li>测试计划和进度陷阱</li>
<li>利益相关者的参与和承诺陷阱</li>
<li>管理相关测试陷阱</li>
<li>人员配备陷阱</li>
<li>测试过程陷阱</li>
<li>测试工具和环境陷阱</li>
<li>测试沟通陷阱</li>
<li>需求相关测试陷阱</li>
</ul></li>
<li>测试类型相关陷阱
<ul>
<li>单元测试陷阱</li>
<li>集成测试陷阱</li>
<li>专业工程测试陷阱</li>
<li>系统测试陷阱</li>
<li>系统的系统测试陷阱</li>
<li>回归测试陷阱</li>
</ul></li>
</ul>
<h2 id="共同的负面后果">共同的负面后果</h2>
<p>虽然不同的测试陷阱有不同的负面后果，它们都趋向于促进以下总体最终问题：</p>
<ul>
<li>测试有效性较低。
<ul>
<li>更多遗留缺陷躲过测试进入交付系统。</li>
<li>尽管付出额外的成本和时间，软件依赖系统仍然带有比预期的或者必要的更多的遗留缺陷交付并投入运行。</li>
</ul></li>
<li>测试效率较低。
<ul>
<li>要达到没有陷阱能达到的相同质量，需要更多的时间和精力。</li>
<li>因为在开发后期花费额外的、计划外的时间和精力去发现并修复缺陷，系统交付延迟并且超出预算。</li>
<li>测试人员必须不可持续地长时间工作，这使他们变得筋疲力尽，因此，会犯过多的错误。</li>
<li>一些缺陷发现的时间比应该发现时间晚，使得缺陷更难定位和修复。</li>
</ul></li>
<li>测试人员的士气受到影响。
<ul>
<li>糟糕的测试效率和有效性，使得测试人员的工作比需要的更长、更困难。</li>
<li>糟糕的测试有效性和由此带来的遗留缺陷的增加削弱了测试人员对工作的自豪感。</li>
</ul></li>
</ul>
<h2 id="一般建议">一般建议</h2>
<p>除了在下文缺陷描述中提供的单个缺陷相关的建议之外，以下建议普遍适用于大多数常见的测试陷阱。</p>
<ul>
<li><strong>预防建议</strong>。这些一般建议可以在最初防止落入陷阱。
<ul>
<li><strong>更新测试过程</strong>。测试人员、首席工程师和过程工程师更新测试过程以帮助项目避免落入测试陷阱，若做不到这一点，那么在已经落入陷阱时能够及时发现。</li>
<li><strong>将陷阱当做风险</strong>。当相关时，陷阱应该正式在项目的风险库中识别为风险，并做相应管理。</li>
<li><strong>正式要求解决方案</strong>。客户代表在适当的文档中正式要求测试陷阱的解决方案，如需求建议书、合同和工作说明书。</li>
<li><strong>内部强制要求解决方案</strong>。管理人员、首席工程师（开发团队领导）或者首席测试人员（测试团队领导）在相应的文档中明确强制要求测试陷阱的解决方案，如系统工程管理计划、系统开发计划、测试计划文档或测试策略。</li>
<li><strong>提供培训</strong>。首席测试人员或培训人员给相关人员（如采购人员、管理层、测试人员和质量保证人员）提供适当数量和水平的测试培训，涵盖潜在的测试陷阱和如何预防、检测及应对。</li>
<li><strong>确保管理层的支持</strong>。管理人员明确说明（并提供）对测试的支持，以及避免经常发生的测试陷阱的必要性。</li>
</ul></li>
<li><strong>检测建议</strong>。以下一般建议使得识别和诊断现有的陷阱成为可能。
<ul>
<li><strong>评估文档</strong>。评审、审查或走查测试相关的文档（例如，测试计划和开发计划的测试部分）。</li>
<li><strong>确保监督</strong>。测试过程执行时提供采购方、管理层、质量保证和同行的监督。</li>
<li><strong>考虑度量指标</strong>。收集、分析并向利益相关者（例如，采购方、管理人员、技术领导或首席工程师和首席测试人员）报告相关的测试指标。</li>
</ul></li>
<li><strong>应对建议</strong>。一旦检测到陷阱，以下一般建议有助于缓解。
<ul>
<li><strong>拒绝不充分的测试文档</strong>。客户代表、管理人员和首席工程师拒绝接受测试相关的文档，指导已识别的陷阱得到解决。</li>
<li><strong>拒绝交付</strong>。客户代表、管理人员和首席工程师拒绝接受被测系统或软件，直到已识别的陷阱（例如，测试环境、测试过程或测试用例）得到解决。然后对相关缺陷进行优先级排序和修复后重新运行测试。</li>
<li><strong>提供培训</strong>。首席测试人员或培训人员给相关人员（如采购人员、管理人员、测试人员和质量保证人员）提供适当数量和水平的补救测试培训，涵盖以观察到的测试陷阱和如何预防、检测及应对测试陷阱。</li>
<li><strong>更新过程</strong>。首席工程师、首席测试人员或过程工程师更新测试过程文档（例如，流程、指南、模板、工具手册），以最大限度地减少观察到的测试陷阱再次出现的可能性。</li>
<li><strong>报告陷阱的发生</strong>。测试人员应向项目管理团队报告陷阱的发生，包括测试经理、项目经理和技术负责人。</li>
<li><strong>将陷阱当做风险</strong>。如果相关时，陷阱应该正式在项目的风险库中识别为风险，并做相应管理。</li>
</ul></li>
</ul>
<blockquote>
<p>摘抄自<a
href="https://book.douban.com/subject/26319080/">《测试反模式——有效规避常见的92种测试陷阱》</a>（美）Donald
G. Firesmish</p>
</blockquote>
]]></content>
<categories>
<category>testing</category>
</categories>
<tags>
<tag>book</tag>
<tag>testing</tag>
</tags>
</entry>
<entry>
<title>Homebrew 使用国内源</title>
<url>/2020/01/10/homebrew-speed-up-in-china/</url>
<content><![CDATA[<h1 id="homebrew-更改国内源">homebrew 更改国内源</h1>
<h2 id="修改为国内源加速">修改为国内源加速</h2>
<figure class="highlight shell"><table><tr><td class="code"><pre><span class="line">cd "$(brew --repo)"</span><br><span class="line">git remote set-url origin https://mirrors.ustc.edu.cn/brew.git</span><br><span class="line">cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"</span><br><span class="line">git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-core.git</span><br><span class="line">brew update</span><br><span class="line">cd "$(brew --repo)"/Library/Taps/caskroom/homebrew-cask</span><br><span class="line">git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-cask.git</span><br><span class="line">echo 'export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.ustc.edu.cn/homebrew-bottles"' >> ~/.zshrc</span><br><span class="line">echo 'export HOMEBREW_API_DOMAIN="https://mirrors.ustc.edu.cn/homebrew-bottles/api"' >> ~/.zshrc</span><br><span class="line"></span><br><span class="line">source ~/.zshrc</span><br><span class="line">brew update</span><br><span class="line">brew doctor</span><br></pre></td></tr></table></figure>
<span id="more"></span>
<h3 id="或者使用阿里云镜像">或者使用阿里云镜像</h3>
<h4 id="使用bash">使用bash</h4>
<figure class="highlight shell"><table><tr><td class="code"><pre><span class="line"><span class="meta prompt_"># </span><span class="language-bash">替换brew.git:</span></span><br><span class="line">cd "$(brew --repo)"</span><br><span class="line">git remote set-url origin https://mirrors.aliyun.com/homebrew/brew.git</span><br><span class="line"><span class="meta prompt_"># </span><span class="language-bash">替换homebrew-core.git:</span></span><br><span class="line">cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"</span><br><span class="line">git remote set-url origin https://mirrors.aliyun.com/homebrew/homebrew-core.git</span><br><span class="line"><span class="meta prompt_"># </span><span class="language-bash">应用生效</span></span><br><span class="line">brew update</span><br><span class="line"><span class="meta prompt_"># </span><span class="language-bash">替换homebrew-bottles:</span></span><br><span class="line">echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.aliyun.com/homebrew/homebrew-bottles' >> ~/.bash_profile</span><br><span class="line">echo 'export HOMEBREW_API_DOMAIN=https://mirrors.aliyun.com/homebrew/homebrew-bottles/api' >> ~/.bash_profile</span><br><span class="line">source ~/.bash_profile</span><br></pre></td></tr></table></figure>
<h4 id="使用zsh">使用zsh</h4>
<figure class="highlight shell"><table><tr><td class="code"><pre><span class="line"><span class="meta prompt_"># </span><span class="language-bash">替换brew.git:</span></span><br><span class="line">cd "$(brew --repo)"</span><br><span class="line">git remote set-url origin https://mirrors.aliyun.com/homebrew/brew.git</span><br><span class="line"><span class="meta prompt_"># </span><span class="language-bash">替换homebrew-core.git:</span></span><br><span class="line">cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"</span><br><span class="line">git remote set-url origin https://mirrors.aliyun.com/homebrew/homebrew-core.git</span><br><span class="line"><span class="meta prompt_"># </span><span class="language-bash">应用生效</span></span><br><span class="line">brew update</span><br><span class="line"><span class="meta prompt_"># </span><span class="language-bash">替换homebrew-bottles:</span></span><br><span class="line">export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.aliyun.com/homebrew/homebrew-bottles"</span><br><span class="line">export HOMEBREW_API_DOMAIN="https://mirrors.aliyun.com/homebrew/homebrew-bottles/api"</span><br><span class="line">source ~/.zshrc</span><br></pre></td></tr></table></figure>
<h2 id="恢复默认">恢复默认</h2>
<figure class="highlight shell"><table><tr><td class="code"><pre><span class="line">cd "$(brew --repo)"</span><br><span class="line">git remote set-url origin https://github.com/Homebrew/brew.git</span><br><span class="line">cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"</span><br><span class="line">git remote set-url origin https://github.com/Homebrew/homebrew-core.git</span><br><span class="line">cd "$(brew --repo)"/Library/Taps/caskroom/homebrew-cask</span><br><span class="line">git remote set-url origin https://github.com/Homebrew/homebrew-cask.git</span><br><span class="line">vim ~/.zshrc</span><br><span class="line">source ~/.zshrc</span><br></pre></td></tr></table></figure>
<blockquote>
<p><strong>参考</strong> <a
href="https://developer.aliyun.com/mirror/homebrew">阿里云</a> <a
href="https://mirrors.ustc.edu.cn/help/homebrew-bottles.html#id4">USTC</a></p>
</blockquote>
]]></content>
<tags>
<tag>brew</tag>
<tag>mirros</tag>
</tags>
</entry>
<entry>
<title>Draw-Diagrams-With-Markdown</title>
<url>/2020/05/23/draw-diagrams-with-markdown/</url>
<content><![CDATA[<span id="more"></span>
<h1 id="draw-diagrams-with-markdown">Draw Diagrams With Markdown</h1>
<p>August 15, 2016 by typora.io</p>
<p>Typora supports some Markdown extensions for diagrams, once they are
enabled from preference panel.</p>
<p>When exporting as HTML, PDF, epub, docx, those rendered diagrams will
also be included, but diagrams features are not supported when exporting
markdown into other file formats in current version. Besides, you should
also notice that diagrams is not supported by standard Markdown,
CommonMark or GFM. Therefore, we still recommend you to insert an image
of these diagrams instead of write them in Markdown directly.</p>
<h1 id="sequence-diagrams">Sequence Diagrams</h1>
<p>This feature uses <a
href="https://bramp.github.io/js-sequence-diagrams/">js-sequence</a>,
which turns the following code block into a rendered diagram:</p>
<div id="sequence-0">
</div>
<p>For more details, please see <a
href="https://bramp.github.io/js-sequence-diagrams/#syntax">this syntax
explanation</a>.</p>
<h1 id="flowcharts">Flowcharts</h1>
<p>This feature uses <a
href="http://flowchart.js.org/">flowchart.js</a>, which turns the
following code block into a rendered diagram:</p>
<div id="flowchart-0" class="flow-chart">
</div>
<h1 id="mermaid-diagrams">Mermaid Diagrams</h1>
<p>Typora also has integration with <a
href="https://mermaid-js.github.io/mermaid/#/">mermaid</a>, which
supports sequence diagrams, flowcharts, Gantt charts, class and state
diagrams, and pie charts.</p>
<h2 id="sequence-diagrams-1">Sequence Diagrams</h2>
<p>For more details see <a
href="https://mermaid-js.github.io/mermaid/#/sequenceDiagram">these
instructions</a>.</p>
<pre class="mermaid">%% Example of sequence diagram
sequenceDiagram
Alice->>Bob: Hello Bob, how are you?
alt is sick
Bob->>Alice: Not so good :(
else is well
Bob->>Alice: Feeling fresh like a daisy
end
opt Extra response
Bob->>Alice: Thanks for asking
end</pre>
<h2 id="flowcharts-1">Flowcharts</h2>
<p>For more details see <a
href="https://mermaid-js.github.io/mermaid/#/flowchart">these
instructions</a>.</p>
<pre class="mermaid">graph LR
A[Hard edge] -->B(Round edge)
B --> C{Decision}
C -->|One| D[Result one]
C -->|Two| E[Result two]</pre>
<h2 id="class-diagrams">Class Diagrams</h2>
<p>For more details see <a
href="https://mermaid-js.github.io/mermaid/#/classDiagram">these
instructions</a>.</p>
<pre class="mermaid">classDiagram
Animal <|-- Duck
Animal <|-- Fish
Animal <|-- Zebra
Animal : +int age
Animal : +String gender
Animal: +isMammal()
Animal: +mate()
class Duck{
+String beakColor
+swim()
+quack()
}
class Fish{
-int sizeInFeet
-canEat()
}
class Zebra{
+bool is_wild
+run()
}</pre>
<h2 id="state-diagrams">State Diagrams</h2>
<p>For more details see <a
href="https://mermaidjs.github.io/#/stateDiagram">these
instructions</a>.</p>
<pre class="mermaid">stateDiagram
[*] --> Still
Still --> [*]
Still --> Moving
Moving --> Still
Moving --> Crash
Crash --> [*]</pre>
<h2 id="pie-charts">Pie Charts</h2>
<pre class="mermaid">pie
title Pie Chart
"Dogs" : 386
"Cats" : 85
"Rats" : 150</pre>
More https://mermaid-js.github.io/mermaid/#/
<script src="https://cdnjs.cloudflare.com/ajax/libs/raphael/2.2.7/raphael.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/flowchart/1.6.5/flowchart.min.js"></script>
<textarea id="flowchart-0-code" style="display: none">st=>start: Start
op=>operation: Your Operation
cond=>condition: Yes or No?
e=>end
st->op->cond
cond(yes)->e
cond(no)->op</textarea><textarea id="flowchart-0-options" style="display: none">{"theme":"simple","scale":1,"line-width":2,"line-length":50,"text-margin":10,"font-size":12}</textarea><script> var code = document.getElementById("flowchart-0-code").value; var options = JSON.parse(decodeURIComponent(document.getElementById("flowchart-0-options").value)); var diagram = flowchart.parse(code); diagram.drawSVG("flowchart-0", options);</script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/webfont/1.6.27/webfontloader.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/snap.svg/0.4.1/snap.svg-min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/underscore.js/1.8.3/underscore-min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/js-sequence-diagrams/1.0.6/sequence-diagram-min.js"></script>
<textarea id="sequence-0-code" style="display: none">Alice->Bob: Hello Bob, how are you?
Note right of Bob: Bob thinks
Bob-->Alice: I am good thanks!</textarea><textarea id="sequence-0-options" style="display: none">{"theme":"simple","scale":1,"line-width":2,"line-length":50,"text-margin":10,"font-size":12}</textarea><script> var code = document.getElementById("sequence-0-code").value; var options = JSON.parse(decodeURIComponent(document.getElementById("sequence-0-options").value)); var diagram = Diagram.parse(code); diagram.drawSVG("sequence-0", options);</script>
]]></content>
<categories>
<category>markdown</category>
<category>mermaid</category>
<category>flowchart</category>
<category>sequence</category>
</categories>
<tags>
<tag>mermaid</tag>
<tag>markdown</tag>
<tag>flowchart</tag>
<tag>sequence</tag>
</tags>
</entry>
<entry>
<title>如何编写好的测试用例</title>
<url>/2020/06/23/how-to-write-good-test-cases/</url>
<content><![CDATA[<h2 id="什么是测试用例"><strong>什么是测试用例</strong></h2>
<p>测试用例（Test
Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式。同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。</p>
<p>通俗的讲：就是把整个测试流程的操作步骤用按照一定的格式用文字描述出来。</p>
<h2 id="为什么要写测试用例"><strong>为什么要写测试用例</strong></h2>
<p><strong><a
href="https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fwww.blogjava.net%2Fqileilove%2Farchive%2F2011%2F10%2F11%2F360942.html">*<em>测试*</em></a>用例</strong>是测试执行的指导；是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；是团队内部交流以及交叉测试的依据，便于测试<a
href="https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fwww.blogjava.net%2Fqileilove%2Farchive%2F2011%2F10%2F11%2F360942.html"><strong>工作</strong></a>的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；在测试执行工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。</p>
<p><strong>1、 理清思路，避免遗漏测试点</strong></p>
<p>理清思路是我们认为最重要的一点，有的系统本来就是一个大而复杂的项目，我们需要把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。</p>
<p><strong>2、 跟踪测试进度进展</strong></p>
<p>通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度，方便跟踪我们的测试进度。</p>
<p><strong>3、 回归测试</strong></p>
<p>首先我们的系统不是测一遍就完了的，我们需要在开发环境上测试，测试环境上还要进行回归，其次还有可能涉及到合并测试，而且也有可能会有不同的人在不同的阶段进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。</p>
<p><strong>4、 历史参考</strong></p>
<p>在我们所做项目的各个版本中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。</p>
<p>另外如果产品发布后出现了发布缺陷，测试用例也是分析发布后缺陷的依据之一。</p>
<span id="more"></span>
<p>一、编写用例的重要性</p>
<p><strong>1.深入了解需求的过程</strong>，一个项目立项开始，测试就开始介入，我们从产品的PRD文档、用户交互图，视觉图等相关文档去熟悉产品的各个模块，各个业务流程。或者在产品规划和设计阶段，测试开始熟悉产品。而编写用例的过程中，会充分的思考产品需求的细枝末节，需求的不合理、有矛盾、不明确的地方，还能对产品提出更好的建议，监督产品对需求做出更加详细的设计。整个过程是对需求深入了解的过程，产品的整个印象都在测试脑海里。</p>
<p><strong>2.测试执行的指导，</strong>用例编写是把产品需求转换为一种可操作步骤的行为，方便以后作为测试的标准，有步骤有计划的进行测试。如果没有这个标准，会使你的测试过程无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。</p>
<p><strong>3.规划测试数据的准备，</strong>在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据</p>
<p><strong>4.反应测试进度，</strong>测试人员开始按照测试用例的描述测试，每过完一个用例标记完成；这样测试也知道自己做过哪些操作，避免没有目的随机测试。并且通过测试用例的执行条数，大致了解该模块的测试进度。</p>
<p><strong>5.举一反三发现潜藏缺陷，</strong>测试人员在执行用例的过程中往往会突然发现当初设计的用例步骤中，还可以做这样一个操作，于是发现了bug，这又体现了测试用例的作用，
帮助发现拓展测试范围，扩大测试覆盖面，发现软件中潜藏的缺陷。</p>
<p><strong>6.分析缺陷的标准</strong>
通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。</p>
<p> </p>
<h2 id="好用例的标准"><strong>好用例的标准</strong></h2>
<ol type="1">
<li>https://zhuanlan.zhihu.com/p/94993557</li>
<li>https://zhuanlan.zhihu.com/p/24308453</li>
<li>https://blog.csdn.net/qq_28967695/article/details/73609070</li>
<li>https://yq.aliyun.com/articles/130204</li>
<li>https://zhuanlan.zhihu.com/p/74623927</li>
<li>https://blog.csdn.net/deyili/article/details/6640259</li>
<li>https://zhuanlan.zhihu.com/p/89633142</li>
<li>https://www.jianshu.com/p/d8931aa92b10</li>
</ol>
<p><strong>好用例的标准</strong></p>
<ol type="1">
<li>是否可以发现Bug</li>
</ol>
<p>设计测试用例的目的就是为了发现bug，如果bug都发现不了，怎么能称得上是一个好的测试用例呢？</p>
<ol start="2" type="1">
<li>是否够高效</li>
</ol>
<p>一个好的测试用例应该不止测试一个测试点，从而减少需要的用例总量。但也不能包含太多不想关的测试点，否则你这个用例就没法测试了，并且给开发的debug造成困难。</p>
<ol start="3" type="1">
<li>是否够经济</li>
</ol>
<p>这个测试用例执行起来是否容易，分析和debug是否要花太多代价，都是值得考虑的，毕竟咱也要站在组织的角度来看待测试这个事，公司是为了盈利而做这些事，而不是为了做测试而测试。</p>
<ol start="4" type="1">
<li>是否有足够的扩展性</li>
</ol>
<p>主要是考察测试用例在维护时是否要花费很大的代价。</p>
<p><strong>1、用例覆盖程度</strong></p>
<p> 毫无疑问，这一点应该是最重要的，无需多说，覆盖率最大化是一套测试用例的最重要评价标准，如果漏测就杯具了。</p>
<p><strong>2、用例是否已经达到工作量最小化</strong></p>
<p> 在满足用例覆盖程度最大化的前提下，应该尽量减小执行用例所需要的工作量。这些方面的方法有不少，如条件覆盖，分支覆盖，正交覆盖等方法。面对不同的测试对象，也有不同的方法来保证：对于网页背后的php逻辑，可以通过在网页上测试后，用一些工具比如xdebug来统计代码覆盖率；对于向外提供接口的<strong>server</strong>，采用的方式就是分析在外面暴露的接口设计用例，大致的通过接口参数来估计一下分支判断的情况。</p>
<p><strong>3、用例的分类以及描述是否足够清晰</strong></p>
<p> 用例的分类，在这里是指相同类型的用例是否放在一起了。例如：接口类的用例，参数的取值范围是1-3，但是现在却传入4；数据类用例，状态机现在位于状态2，却要求状态跳转到无法到达的4；逻辑类用例，正常功能的产出等。将相同类型的用例放在一起，有助于理清思路，清楚了解用例设计是否完备。</p>
<p> 用例的描述，是指描述的清晰程度是否能够形成文档。例如上面参数取值范围的例子，用例这样写：“传入错误的值”或者“传入非1-3的值”，明显没有写成“传入值4”有效。这与写程序一样，总是写闭区间的范围而不是开区间。</p>
<p><strong>4、用例是否表明了测试目的</strong></p>
<p> 写明用例的测试目的，对文档的易于理解性和工作交接的好处不言而喻，现代软件工程不可能只有一个人在做事情，项目于人员的变动也是难免的。在过程中留下足够的信息，可以在后续工作提高很多效率。</p>
<p><strong>5、测试用例的易于维护性</strong></p>
<p> 如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢？例如在有状态机的情况下，测试用例之间是相互依赖的（即需要一定的执行顺序），这样被依赖的用例修改后，后端不需要同步根据修改。而如果用例之间没有相互依赖关系（如用例是自己造的数据，不是依赖于前端的产出），可能一旦有变化，就需要修改这两个。当然，这两种情况不能绝对的说哪种好，是需要看实际使用时候的情况进行取舍的。不过，通过一些系统性的工具支持，也会出现一种做法绝对性的好于另外一种的情况，情况很多，做法也有很多，在这里就不多说了。</p>
<p>既然测试用例的重要性可想而知，那么用例评审更加重要，用例评审即是对用例的评议和审查，是必须的过程。在工作过程中，对于测试用例的评审，分享几点自己的心得。</p>
<p>二、用例评审内容</p>
<ol type="1">
<li><p>是否覆盖测试需求上的所有功能点，不违背产品原型和代码设计，用例设计的结构安排是否清晰合理，有利于高效覆盖需求</p></li>
<li><p>用例是否具有可执行性，前提条件、执行步骤和预期结果是否正确，有明确的验证方法。优先级安排是否合理</p></li>
<li><p>是否从用户层面来设计用户使用的场景和业务流程</p></li>
<li><p>是否包含充分的异常测试用例</p></li>
<li><p>是否简洁，不冗余，复用性强</p></li>
</ol>
<p>四、用例评审需要避免</p>
<ol type="1">
<li><p>测试点含糊用语，每个用例评审都应该确定最终版，稍有矛盾或疑惑的需求点，都应该确认下来，不能含糊不清。</p></li>
<li><p>杂乱无章的评审，有顺序有逻辑的进行评审是很重要的一点，如果臆想按照自己的思路评审，不顾他人感受，那么就等同于做无用功。这样的用例执行出来也会有一定的质量风险。</p></li>
</ol>
<p>好的测试用例编写的原则：最低的成本找到最多的问题，最短的路径验证最多的可能</p>
<p>大概有这几种风格：</p>
<ol type="1">
<li><p>精简型（每个title和标题内容都基本用一个词语概括了你需要测试的点，起点拨作用）</p></li>
<li><p>PRD型（把PRD阐述了一遍的样子，内容特别冗余，但是对于开发和产品而言可读性较强，不过不被提倡）</p></li>
<li><p>操作步骤型（在TC中把自己测试这个系统的操作步骤一步一步的详细写出来，以及所需要造的测试数据和异常步骤。但是这种对于开发只查看部分功能点的TC可读性可操作性较低，对于写作者本身实用性较高，但是后期一旦业务逻辑修改，需要修改的内容较多）</p></li>
</ol>
<p>TC是测试基础，也是最反映一个测试的思维逻辑和测试思想的地方。</p>
<p>以下5点可以判断测试用例是不是一个好的测试用例</p>
<p>1、测试覆盖面全</p>
<p>覆盖面全，是最最重要的一点，只有全面的覆盖，才能找到最多的问题，只有更全面的测试，才能更好的保障产品的质量，当然穷尽测试是不可能的，所有全面也是相对的。</p>
<p>2、测试用例精简</p>
<p>精简的case，是为了减少重复的工作，减少人工成本和时间成功，通过TC设计策略了解和对于需求的充分了解，达到精简测试用例。</p>
<p>3、步骤清晰</p>
<p>步骤清晰，主要是为了提高TC的复用型，无论是对于开发还是对于后期的自己都可以看到TC一目了然</p>
<p>4、目的明确</p>
<p>冗长的步骤前，用几个字概括你的测试目的，方便阅读</p>
<p>5、易于维护</p>
<p>易于维护，分为以下几种维护：</p>
<p>易于他人维护修改</p>
<p>易于系统升级维护修改</p>
<p>易于挑选不同纬度，不同优先级，不同功能的测试用例</p>
<p>结构清晰、优先级明确、描写清晰的测试用例更容易维护</p>
<p>想写好测试用例，前提是测试分析和需求拆解做的足够好，通过xmind或者UML图把需求和开发设计提供的产品信息提炼出来。</p>
<p>我个人的提炼标准一般是：</p>
<ol type="1">
<li><p>所有业务链路是否是闭环；</p></li>
<li><p>所有业务场景以用户层面来观察是否合情合理；</p></li>
<li><p>技术设计是否存在性能/可靠/安全等风险；</p></li>
<li><p>梳理测试要点，明确每个业务在测试环节里面需要观察的功能预期；</p></li>
<li><p>开始明确测试方案，确认列出来的测试要点要怎么样才能实施测试。这里多问自己一句：只做功能测试能满足质量覆盖的要求吗？不能就扩展考虑是否做白盒测试/接口测试/性能测试/稳定性测试/安全测试/体验测试/...；</p></li>
<li><p>然后才进入测试用例编写的阶段，通过对测试点的特征评估考虑用哪种测试用例设计方法覆盖；</p></li>
<li><p>最后输出用例。</p></li>
</ol>
<p>在这里,我想说说我对用例的个人看法：</p>
<ol type="1">
<li><p>用例不仅仅只是为了满足功能测试，它应该是通过一组输入输出的方式用来衡量产品功能是否符合预期。</p></li>
<li><p>测试用例不可能永远只被设计者执行，所以请严格按照规范来设计和编写用例，让其他后继的执行人能高效准确的执行。</p></li>
<li><p>用例设计是极其严肃的任务，但是业内很少QA会真正的做到根据被测试对象的特征来挑选测试用例设计方法并严格按照这些方法来输出用例。</p></li>
</ol>
<h2 id="如何编写好的用例">如何编写好的用例</h2>
<p>三、用例评审过程</p>
<p><strong>1.
提前发出初稿和会议邀约，</strong>至少提前一天发出用例初稿，并确定参与用例评审人员，以便项目经理，产品和开发提前阅读用例，让会议更有效率的进行</p>
<p><strong>2.
先做简单的业务流程介绍，</strong>这个是在评审开始尤为重要的一个过程，刚开始评审，参与人员会比较蒙圈，产品和开发都不知道测试的思路，或者半途加入新的开发和测试，对需求和业务都不够熟悉，如何让评审快速进入状态，先做简单的需求业务流程介绍，说明白打算如何去做评审。</p>
<p>【举个栗子】一个项目有用户体系、电子账户、理财、生活模块，可以先由大到小的细分下去；可用事先画好的脑图，各种流程图，也可当场快速写上板书。</p>
<p><strong>3.
按模块进行，</strong>有些模块，业务性不是特别强的，可以简单说下有哪些模块，每个模块评审的时候，按测试项分类，UI、核心功能、基础功能、边界测试、兼容测试和异常测试等，预期结果类似的，主要讲清楚用例主题，让参与人员知道每条用例是做什么的。</p>
<p><strong>4.
按业务流程进行，</strong>业务流程性较强的需求，需要有业务场景和逻辑，按一定的顺序来，让参与人跟着你的思想，避免东一句西一句，</p>
<p>【举个栗子】一个理财活期产品的测试用例评审，购买和赎回，跑批时间段分日间和日终，工作日和周末四个场景，按不同场景分为不同的业务流程进行评审，有理有据，逻辑思路清晰。</p>
<p><strong>5.
按测试数据进行，</strong>涉及到计算逻辑、收益、报表等需求的，用例编写时会先规划好测试数据，尽管测试数据也是按不同的业务场景来设计的，但直接用测试数据来评审你的测试点，会更清晰，跟上你思路的开发和产品会对应上自己的产品设计和代码设计去评审你的测试点是否不合理或覆盖率不全的地方，从而有效的评审测试用例。</p>
<p>三、用例评审后的确认</p>
<p>为了节约时间成本，第一次评审尽量对用例设计全面考虑，提前发现其中的不足之处；但是第一次评审难免会要修修补补的地方，在评审时尽快的修复，不能在一两分钟修复的，记录下来，在会议结束后进行修改，如果改动不是很多的，可以发出邮件，标明修改部分，再最后确认最终版。如果需要进行二次评审，那么重新开始邀约会议做二次评审。</p>
<p>四、关于提升用例编写能力的一些建议</p>
<ol type="1">
<li>熟悉业务，了解系统</li>
</ol>
<p>任何系统都有大的业务背景，只要熟悉了业务知识才能更有效的使用系统。</p>
<p>任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问题、业务问题。</p>
<ol start="2" type="1">
<li>学会换位思考，用客观的思考方式站在用户的角度分析问题</li>
</ol>
<p>作为测试人员如果想提升测试用例的编写能力，首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么，以及客户不想要什么，也就是所谓的客户的使用场景，这样有利于我们更好的挖掘和思考隐含的需求。至于这个需求该不该做，那是需求人员的职责，这个需求做起来复不复杂那是开发人员的事情，作为测试人员需要考虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景，以及一些客户基本不会用到的场景有哪些。</p>
<ol start="3" type="1">
<li>多思考，不要拘束于惯性思维</li>
</ol>
<p>一个人做一个工作时间越久，经验大概率是会越来越丰富的，但同时，也可能被自己的经验所限制。习惯性的套用经验，活在自己的舒适区，会让自己的成长停滞不前。所以作为一个测试人员如果想要提升自己的测试用例设计能力，一定要多思考，不要被惯性思维束缚，不要被所谓的经验束缚。</p>
<ol start="4" type="1">
<li>学会利用好网络资源提升自己的能力</li>
</ol>
<p>提升测试用例设计能力，多思考是非常重要的，但不是让你傻思考。当你的进步遇到瓶颈的时候，不要闭门造车，做井底之蛙，要充分利用网络上的学习资源，学习一些前辈的经验，并把这些运用到实际的测试用例设计中去。山外青山楼外楼，多浏览和关注一些关于测试用例设计的网站或者微信公众号，广开言路，相信会对你的测试用例设计能力的提升会有很大的帮助的。</p>
<ol start="5" type="1">
<li>善于总结和分享</li>
</ol>
<p>基于以上四点我们还要做到善于总结，乐于分享，把常见到的用例设计的误区和一些好的用例设计，和用例设计习惯分享给周围的小伙伴，这样可以集众人之所长，不断提升我们的用例设计能力。</p>
<p>1、要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。</p>
<p>2、要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。</p>
<p>3、尽量多参加项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。</p>
<p>4、要善于沟通，多和客户、开发、测试人员进行沟通。遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。这样才能提前解决需求理解偏差等。</p>
<p>5、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。</p>
<p>6、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。</p>
<p>7、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，我们平常的鼠标和键盘的每一动作都代表一个操作步骤。比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。</p>
<p>8、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、<a
href="https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fwww.blogjava.net%2Fqileilove%2Farchive%2F2011%2F10%2F11%2F360942.html"><strong>数据库</strong></a>相关字段的记录、界面的响应结果、输出结果的规则符合度、<a
href="https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fwww.blogjava.net%2Fqileilove%2Farchive%2F2011%2F10%2F11%2F360942.html"><strong>日志</strong></a>的检查和对<a
href="https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fwww.blogjava.net%2Fqileilove%2Farchive%2F2011%2F10%2F11%2F360942.html"><strong>其它</strong></a>业务影响的检查。</p>
<p>9、测试用例级别要划分清楚，这样在测试执行时有主次之分。</p>
<p>10、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。</p>
<p>11、评审用例很关键，因为经过测试用例的评审可以发现：<a
href="https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fwww.blogjava.net%2Fqileilove%2Farchive%2F2011%2F10%2F11%2F360942.html"><strong>用例设计</strong></a>的结构安排是否清晰、合理；是否覆盖所有的需求功能点；是否存在冗余的用例；是否具有很好的可执行性；是否存在对需求理解上的差异等。评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与，也需要客户方的开发人员和测试人员。</p>
<p>12、召开测试用例评审会议，在会议上大家可以提问互答，对模糊不清的地方可以进行讨论。这样可以站在不同的角度，站在很多人的思维和思考方式下设计用例。</p>
<p>13、站在用户的角度来设计用例，以用户的使用逻辑及操作习惯为出发点，从用户实际可能的操作场景考虑，一定要脱离系统提供功能。</p>
<p>14、测试用例需要不断更新和维护，不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在<a
href="https://yq.aliyun.com/go/articleRenderRedirect?url=http%3A%2F%2Fwww.blogjava.net%2Fqileilove%2Farchive%2F2011%2F10%2F11%2F360942.html"><strong>软件开发</strong></a>的不同的阶段都要回来重新审视和完善测试用例。并且需要在测试执行时利用发散思维不断的构造和完善测试用例。</p>
<p>总的来说，写出好的测试用例需要我们不断的积累和完善，需要我们不断的在工作中去总结。写出好的测试用例没有简单的公式或规定可以遵循。即使是多年以来在测试方面感兴趣的人也很难做到这一点。</p>
<p><strong>三、如何编写用例</strong></p>
<p><strong>1、测试需求分析，得到测试点</strong></p>
<p>在测试需求分析阶段，我们只有需求文档，所以编写测试用例的唯一依据就是需求文档，因此在进行用例编写之前一定要进行需求分析，需求分析的主要工作就是：了解需求的整个实现背景、分析需求的合理性、明确需求的范围、挖掘需求文档中隐藏的需求。</p>
<p>在通过需求交底的过程，确定开发的初步实现思路和方法。随着测试需求分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等，确定一些测试可以提前介入的工作需要说明的是对于需求中的问题一定要记录下来，找需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。</p>
<p><strong>2、分析得到用例优先级</strong></p>
<p>得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优等级，一般分为高中低三个优先级，我认为得到优先级后可以让需求用例的设计更有侧重和着重点。</p>
<p><strong>3、细化测试点变成可执行case</strong></p>
<p>根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况，还要注意各个测试点的反向测试的情况。</p>
<p>在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。</p>
<p>另外需要考虑的就是测试点细化到什么程度的问题，也就是一个度的问题，我们要把握好测试点细化的一个度的问题，太粗的测试点没有指导意义，太细的测试点容易让我们纠的太细，忽略整体的测试，反而也起不到一个指导的效果，所以一定要把握好测试点细化的度。</p>
<p><strong>4、及时更新测试用例</strong></p>
<p>需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的，所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。</p>
<p>另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，测试case描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改我们的用例。</p>
<p><strong>5、及时维护通用测试用例</strong></p>
<p>什么是通用测试用例呢？我理解的通用测试用例就是：项目中或者跨项目中很多的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测试用例。当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等，这个时候通过梳理业务的通用属性，通用用例梳理梳理成章。所以说，通用的测试用例是一个对用例不断维护的产出，因此我们在测试软件维护的过程中一定要及时的更新通用测试用例，对后面的测试和用例维护有一个很大的指导作用。</p>
]]></content>
<tags>
<tag>testing</tag>
</tags>
</entry>
<entry>
<title>HTML 特殊符号编码对照表</title>
<url>/2020/05/14/html-chars/</url>
<content><![CDATA[<h1 id="html-特殊符号编码对照表">HTML 特殊符号编码对照表</h1>
<span id="more"></span>
<table style="width:100%;">
<colgroup>
<col style="width: 9%" />
<col style="width: 11%" />
<col style="width: 11%" />
<col style="width: 9%" />
<col style="width: 13%" />
<col style="width: 11%" />
<col style="width: 9%" />
<col style="width: 12%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr class="header">
<th>特殊符号</th>
<th>命名实体</th>
<th>十进制编码</th>
<th>特殊符号</th>
<th>命名实体</th>
<th>十进制编码</th>
<th>特殊符号</th>
<th>命名实体</th>
<th>十进制编码</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>Α</td>
<td><code>&Alpha;</code></td>
<td><code>&#913;</code></td>
<td>Β</td>
<td><code>&Beta;</code></td>
<td><code>&#914;</code></td>
<td>Γ</td>
<td><code>&Gamma;</code></td>
<td><code>&#915;</code></td>
</tr>
<tr class="even">
<td>Δ</td>
<td><code>&Delta;</code></td>
<td><code>&#916;</code></td>
<td>Ε</td>
<td><code>&Epsilon;</code></td>
<td><code>&#917;</code></td>
<td>Ζ</td>
<td><code>&Zeta;</code></td>
<td><code>&#918;</code></td>
</tr>
<tr class="odd">
<td>Η</td>
<td><code>&Eta;</code></td>
<td><code>&#919;</code></td>
<td>Θ</td>
<td><code>&Theta;</code></td>
<td><code>&#920;</code></td>
<td>Ι</td>
<td><code>&Iota;</code></td>
<td><code>&#921;</code></td>
</tr>
<tr class="even">
<td>Κ</td>
<td><code>&Kappa;</code></td>
<td><code>&#922;</code></td>
<td>Λ</td>
<td><code>&Lambda;</code></td>
<td><code>&#923;</code></td>
<td>Μ</td>
<td><code>&Mu;</code></td>
<td><code>&#924;</code></td>
</tr>
<tr class="odd">
<td>Ν</td>
<td><code>&Nu;</code></td>
<td><code>&#925;</code></td>
<td>Ξ</td>
<td><code>&Xi;</code></td>
<td><code>&#926;</code></td>
<td>Ο</td>
<td><code>&Omicron;</code></td>
<td><code>&#927;</code></td>
</tr>
<tr class="even">
<td>Π</td>
<td><code>&Pi;</code></td>
<td><code>&#928;</code></td>
<td>Ρ</td>
<td><code>&Rho;</code></td>
<td><code>&#929;</code></td>
<td>Σ</td>
<td><code>&Sigma;</code></td>
<td><code>&#931;</code></td>
</tr>
<tr class="odd">
<td>Τ</td>
<td><code>&Tau;</code></td>
<td><code>&#932;</code></td>
<td>Υ</td>
<td><code>&Upsilon;</code></td>
<td><code>&#933;</code></td>
<td>Φ</td>
<td><code>&Phi;</code></td>
<td><code>&#934;</code></td>
</tr>
<tr class="even">
<td>Χ</td>
<td><code>&Chi;</code></td>
<td><code>&#935;</code></td>
<td>Ψ</td>
<td><code>&Psi;</code></td>
<td><code>&#936;</code></td>
<td>Ω</td>
<td><code>&Omega;</code></td>
<td><code>&#937;</code></td>
</tr>
<tr class="odd">
<td>α</td>
<td><code>&alpha;</code></td>
<td><code>&#945;</code></td>
<td>β</td>
<td><code>&beta;</code></td>
<td><code>&#946;</code></td>
<td>γ</td>
<td><code>&gamma;</code></td>
<td><code>&#947;</code></td>
</tr>
<tr class="even">
<td>δ</td>
<td><code>&delta;</code></td>
<td><code>&#948;</code></td>
<td>ε</td>
<td><code>&epsilon;</code></td>
<td><code>&#949;</code></td>
<td>ζ</td>
<td><code>&zeta;</code></td>
<td><code>&#950;</code></td>
</tr>
<tr class="odd">
<td>η</td>
<td><code>&eta;</code></td>
<td><code>&#951;</code></td>
<td>θ</td>
<td><code>&theta;</code></td>
<td><code>&#952;</code></td>
<td>ι</td>
<td><code>&iota;</code></td>
<td><code>&#953;</code></td>
</tr>
<tr class="even">
<td>κ</td>
<td><code>&kappa;</code></td>
<td><code>&#954;</code></td>
<td>λ</td>
<td><code>&lambda;</code></td>
<td><code>&#955;</code></td>
<td>μ</td>
<td><code>&mu;</code></td>
<td><code>&#956;</code></td>
</tr>
<tr class="odd">
<td>ν</td>
<td><code>&nu;</code></td>
<td><code>&#957;</code></td>
<td>ξ</td>
<td><code>&xi;</code></td>
<td><code>&#958;</code></td>
<td>ο</td>
<td><code>&omicron;</code></td>
<td><code>&#959;</code></td>
</tr>
<tr class="even">
<td>π</td>
<td><code>&pi;</code></td>
<td><code>&#960;</code></td>
<td>ρ</td>
<td><code>&rho;</code></td>
<td><code>&#961;</code></td>
<td>ς</td>
<td><code>&sigmaf;</code></td>
<td><code>&#962;</code></td>
</tr>
<tr class="odd">
<td>σ</td>
<td><code>&sigma;</code></td>
<td><code>&#963;</code></td>
<td>τ</td>
<td><code>&tau;</code></td>
<td><code>&#964;</code></td>
<td>υ</td>
<td><code>&upsilon;</code></td>
<td><code>&#965;</code></td>
</tr>
<tr class="even">
<td>φ</td>
<td><code>&phi;</code></td>
<td><code>&#966;</code></td>
<td>χ</td>
<td><code>&chi;</code></td>
<td><code>&#967;</code></td>
<td>ψ</td>
<td><code>&psi;</code></td>
<td><code>&#968;</code></td>
</tr>
<tr class="odd">
<td>ω</td>
<td><code>&omega;</code></td>
<td><code>&#969;</code></td>
<td>ϑ</td>
<td><code>&thetasym;</code></td>
<td><code>&#977;</code></td>
<td>ϒ</td>
<td><code>&upsih;</code></td>
<td><code>&#978;</code></td>
</tr>
<tr class="even">
<td>ϖ</td>
<td><code>&piv;</code></td>
<td><code>&#982;</code></td>
<td>•</td>
<td><code>&bull;</code></td>
<td><code>&#8226;</code></td>
<td>…</td>
<td><code>&hellip;</code></td>
<td><code>&#8230;</code></td>
</tr>
<tr class="odd">
<td>′</td>
<td><code>&prime;</code></td>
<td><code>&#8242;</code></td>
<td>″</td>
<td><code>&Prime;</code></td>
<td><code>&#8243;</code></td>
<td>‾</td>
<td><code>&oline;</code></td>
<td><code>&#8254;</code></td>
</tr>
<tr class="even">
<td>⁄</td>
<td><code>&frasl;</code></td>
<td><code>&#8260;</code></td>
<td>℘</td>
<td><code>&weierp;</code></td>
<td><code>&#8472;</code></td>
<td>ℑ</td>
<td><code>&image;</code></td>
<td><code>&#8465;</code></td>
</tr>
<tr class="odd">
<td>ℜ</td>
<td><code>&real;</code></td>
<td><code>&#8476;</code></td>
<td>™</td>
<td><code>&trade;</code></td>
<td><code>&#8482;</code></td>
<td>ℵ</td>
<td><code>&alefsym;</code></td>
<td><code>&#8501;</code></td>
</tr>
<tr class="even">
<td>←</td>
<td><code>&larr;</code></td>
<td><code>&#8592;</code></td>
<td>↑</td>
<td><code>&uarr;</code></td>
<td><code>&#8593;</code></td>
<td>→</td>
<td><code>&rarr;</code></td>
<td><code>&#8594;</code></td>
</tr>
<tr class="odd">
<td>↓</td>
<td><code>&darr;</code></td>
<td><code>&#8595;</code></td>
<td>↔︎</td>
<td><code>&harr;</code></td>
<td><code>&#8596;</code></td>
<td>↵</td>
<td><code>&crarr;</code></td>
<td><code>&#8629;</code></td>
</tr>
<tr class="even">
<td>⇐</td>
<td><code>&lArr;</code></td>
<td><code>&#8656;</code></td>
<td>⇑</td>
<td><code>&uArr;</code></td>
<td><code>&#8657;</code></td>
<td>⇒</td>
<td><code>&rArr;</code></td>
<td><code>&#8658;</code></td>
</tr>
<tr class="odd">
<td>⇓</td>
<td><code>&dArr;</code></td>
<td><code>&#8659;</code></td>
<td>⇔</td>
<td><code>&hArr;</code></td>
<td><code>&#8660;</code></td>
<td>∀</td>
<td><code>&forall;</code></td>
<td><code>&#8704;</code></td>
</tr>
<tr class="even">
<td>∂</td>